From 891691e2d19aa0cdf142358dc34e226a7e41f59f Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 30 Sep 2006 17:19:35 +0000 Subject: [PATCH 001/541] Created trunk/tags/branches structure in project folder (forgot this when I moved sandbox/james-project out of sandbox). git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@451618 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 56 + .../src/main/resources/css/maven-theme.css | 257 + .../main/resources/images/button-bottom.gif | Bin 0 -> 590 bytes .../src/main/resources/images/button-top.gif | Bin 0 -> 392 bytes .../src/main/resources/images/collapsed.gif | Bin 0 -> 53 bytes .../src/main/resources/images/expanded.gif | Bin 0 -> 52 bytes .../src/main/resources/images/external.png | Bin 0 -> 230 bytes .../src/main/resources/images/h2feather.gif | Bin 0 -> 360 bytes maven-skin/src/main/resources/images/h4.jpg | Bin 0 -> 360 bytes .../main/resources/images/icon_error_sml.gif | Bin 0 -> 1010 bytes .../main/resources/images/icon_info_sml.gif | Bin 0 -> 606 bytes .../resources/images/icon_success_sml.gif | Bin 0 -> 990 bytes .../resources/images/icon_warning_sml.gif | Bin 0 -> 576 bytes .../src/main/resources/images/newwindow.png | Bin 0 -> 220 bytes maven-skin/src/main/resources/images/void.gif | Bin 0 -> 50 bytes pom.xml | 208 + server/2.2.0/pom.xml | 52 + .../resources/images/asf-logo-reduced.gif | Bin 0 -> 6636 bytes .../resources/images/james-server-logo.gif | Bin 0 -> 6944 bytes server/2.2.0/src/site/site.xml | 53 + server/2.2.0/src/site/xdoc/adding_users.xml | 58 + .../src/site/xdoc/build_instructions.xml | 79 + server/2.2.0/src/site/xdoc/changelog.xml | 446 ++ server/2.2.0/src/site/xdoc/custom_mailet.xml | 117 + server/2.2.0/src/site/xdoc/custom_matcher.xml | 128 + .../2.2.0/src/site/xdoc/dns_configuration.xml | 59 + .../src/site/xdoc/fetchmail_configuration.xml | 967 +++ .../src/site/xdoc/fetchpop_configuration.xml | 105 + server/2.2.0/src/site/xdoc/index.xml | 104 + .../site/xdoc/installation_instructions.xml | 110 + .../src/site/xdoc/james_and_sendmail.xml | 124 + server/2.2.0/src/site/xdoc/mailet_api.xml | 51 + server/2.2.0/src/site/xdoc/mailing_lists.xml | 115 + .../src/site/xdoc/nntp_configuration.xml | 98 + .../src/site/xdoc/pop3_configuration.xml | 74 + .../2.2.0/src/site/xdoc/provided_mailets.xml | 253 + .../2.2.0/src/site/xdoc/provided_matchers.xml | 186 + .../site/xdoc/remotemanager_configuration.xml | 78 + server/2.2.0/src/site/xdoc/repositories.xml | 86 + .../site/xdoc/serverwide_configuration.xml | 100 + server/2.2.0/src/site/xdoc/smtp_auth.xml | 70 + .../src/site/xdoc/smtp_configuration.xml | 85 + server/2.2.0/src/site/xdoc/spoolmanager.xml | 85 + .../site/xdoc/spoolmanager_configuration.xml | 99 + server/2.2.0/src/site/xdoc/summary.xml | 116 + server/2.2.0/src/site/xdoc/usingTLS.xml | 89 + server/2.2.0/src/site/xdoc/using_database.xml | 143 + server/pom.xml | 94 + server/src/site/resources/css/site.css | 31 + .../resources/images/asf-logo-reduced.gif | Bin 0 -> 6636 bytes .../resources/images/james-server-logo.gif | Bin 0 -> 6944 bytes .../images/james_config_load_balance.png | Bin 0 -> 3645 bytes .../images/james_config_secondary.png | Bin 0 -> 5758 bytes .../images/james_config_smart_host.png | Bin 0 -> 3266 bytes .../site/resources/rfclist/basic/rfc0822.txt | 2902 +++++++++ .../site/resources/rfclist/basic/rfc1123.txt | 5781 +++++++++++++++++ .../site/resources/rfclist/basic/rfc2045.txt | 1740 +++++ .../site/resources/rfclist/basic/rfc2046.txt | 2468 +++++++ .../site/resources/rfclist/basic/rfc2822.txt | 2858 ++++++++ .../site/resources/rfclist/imap4/rfc1731.txt | 340 + .../site/resources/rfclist/imap4/rfc2060.txt | 4596 +++++++++++++ .../site/resources/rfclist/imap4/rfc2086.txt | 452 ++ .../site/resources/rfclist/imap4/rfc2087.txt | 284 + .../site/resources/rfclist/imap4/rfc2088.txt | 116 + .../site/resources/rfclist/imap4/rfc2177.txt | 228 + .../site/resources/rfclist/imap4/rfc2180.txt | 787 +++ .../site/resources/rfclist/imap4/rfc2192.txt | 900 +++ .../site/resources/rfclist/imap4/rfc2193.txt | 508 ++ .../site/resources/rfclist/imap4/rfc2195.txt | 284 + .../site/resources/rfclist/imap4/rfc2221.txt | 284 + .../site/resources/rfclist/imap4/rfc2342.txt | 564 ++ .../site/resources/rfclist/imap4/rfc2359.txt | 340 + .../site/resources/rfclist/imap4/rfc2595.txt | 843 +++ .../site/resources/rfclist/imap4/rfc2683.txt | 1291 ++++ .../site/resources/rfclist/ldap/rfc2251.txt | 2803 ++++++++ .../site/resources/rfclist/ldap/rfc2252.txt | 1388 ++++ .../site/resources/rfclist/ldap/rfc2253.txt | 470 ++ .../site/resources/rfclist/ldap/rfc2254.txt | 451 ++ .../site/resources/rfclist/ldap/rfc2255.txt | 423 ++ .../site/resources/rfclist/ldap/rfc2256.txt | 1137 ++++ .../site/resources/rfclist/ldap/rfc2829.txt | 865 +++ .../site/resources/rfclist/ldap/rfc2830.txt | 419 ++ .../site/resources/rfclist/ldap/rfc3377.txt | 339 + .../nntp/draft-ietf-nntpext-base-13.txt | 3270 ++++++++++ .../site/resources/rfclist/nntp/rfc0977.txt | 1540 +++++ .../site/resources/rfclist/nntp/rfc1036.txt | 1068 +++ .../site/resources/rfclist/nntp/rfc2980.txt | 1516 +++++ .../site/resources/rfclist/pop3/rfc1725.txt | 1012 +++ .../site/resources/rfclist/pop3/rfc1734.txt | 284 + .../site/resources/rfclist/pop3/rfc1939.txt | 1290 ++++ .../site/resources/rfclist/smtp/rfc0821.txt | 4051 ++++++++++++ .../site/resources/rfclist/smtp/rfc0974.txt | 365 ++ .../site/resources/rfclist/smtp/rfc1652.txt | 340 + .../site/resources/rfclist/smtp/rfc1830.txt | 452 ++ .../site/resources/rfclist/smtp/rfc1869.txt | 620 ++ .../site/resources/rfclist/smtp/rfc1870.txt | 508 ++ .../site/resources/rfclist/smtp/rfc1891.txt | 521 ++ .../site/resources/rfclist/smtp/rfc1893.txt | 844 +++ .../site/resources/rfclist/smtp/rfc1985.txt | 396 ++ .../site/resources/rfclist/smtp/rfc2034.txt | 340 + .../site/resources/rfclist/smtp/rfc2142.txt | 338 + .../site/resources/rfclist/smtp/rfc2197.txt | 452 ++ .../site/resources/rfclist/smtp/rfc2554.txt | 620 ++ .../site/resources/rfclist/smtp/rfc2821.txt | 4426 +++++++++++++ server/src/site/site.xml | 57 + server/src/site/xdoc/FAQ.xml | 318 + .../site/xdoc/archive/announcement_2_1.xml | 57 + .../site/xdoc/archive/architecture_v1_2.xml | 51 + .../site/xdoc/archive/architecture_v2_0.xml | 55 + .../site/xdoc/archive/configuration_v2_0.xml | 716 ++ .../site/xdoc/archive/document_archive.xml | 54 + server/src/site/xdoc/archive/install.xml | 113 + .../src/site/xdoc/archive/usingJDBC_v2.0.xml | 174 + .../src/site/xdoc/archive/usingLDAP_v1_2.xml | 185 + .../src/site/xdoc/archive/usingTLS_v1_2.xml | 96 + server/src/site/xdoc/design_objectives.xml | 122 + server/src/site/xdoc/index.xml | 131 + server/src/site/xdoc/rfclist.xml | 93 + server/src/site/xdoc/todo.xml | 109 + src/site/resources/css/site.css | 13 + src/site/resources/download.cgi | 6 + src/site/resources/favicon.ico | Bin 0 -> 3638 bytes .../resources/images/asf-logo-reduced.gif | Bin 0 -> 6636 bytes .../resources/images/james-project-logo.gif | Bin 0 -> 7227 bytes src/site/resources/robots.txt | 5 + src/site/site.xml | 113 + src/site/xdoc/code-standards.xml | 97 + src/site/xdoc/contribute.xml | 112 + src/site/xdoc/download.xml | 159 + src/site/xdoc/index.xml | 46 + src/site/xdoc/license.xml | 208 + src/site/xdoc/mail.xml | 249 + src/site/xdoc/weare.xml | 172 + 133 files changed, 68401 insertions(+) create mode 100644 maven-skin/pom.xml create mode 100644 maven-skin/src/main/resources/css/maven-theme.css create mode 100644 maven-skin/src/main/resources/images/button-bottom.gif create mode 100644 maven-skin/src/main/resources/images/button-top.gif create mode 100644 maven-skin/src/main/resources/images/collapsed.gif create mode 100644 maven-skin/src/main/resources/images/expanded.gif create mode 100644 maven-skin/src/main/resources/images/external.png create mode 100644 maven-skin/src/main/resources/images/h2feather.gif create mode 100644 maven-skin/src/main/resources/images/h4.jpg create mode 100644 maven-skin/src/main/resources/images/icon_error_sml.gif create mode 100644 maven-skin/src/main/resources/images/icon_info_sml.gif create mode 100644 maven-skin/src/main/resources/images/icon_success_sml.gif create mode 100644 maven-skin/src/main/resources/images/icon_warning_sml.gif create mode 100644 maven-skin/src/main/resources/images/newwindow.png create mode 100644 maven-skin/src/main/resources/images/void.gif create mode 100644 pom.xml create mode 100644 server/2.2.0/pom.xml create mode 100644 server/2.2.0/src/site/resources/images/asf-logo-reduced.gif create mode 100644 server/2.2.0/src/site/resources/images/james-server-logo.gif create mode 100644 server/2.2.0/src/site/site.xml create mode 100644 server/2.2.0/src/site/xdoc/adding_users.xml create mode 100644 server/2.2.0/src/site/xdoc/build_instructions.xml create mode 100644 server/2.2.0/src/site/xdoc/changelog.xml create mode 100644 server/2.2.0/src/site/xdoc/custom_mailet.xml create mode 100644 server/2.2.0/src/site/xdoc/custom_matcher.xml create mode 100755 server/2.2.0/src/site/xdoc/dns_configuration.xml create mode 100755 server/2.2.0/src/site/xdoc/fetchmail_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/fetchpop_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/index.xml create mode 100644 server/2.2.0/src/site/xdoc/installation_instructions.xml create mode 100644 server/2.2.0/src/site/xdoc/james_and_sendmail.xml create mode 100644 server/2.2.0/src/site/xdoc/mailet_api.xml create mode 100644 server/2.2.0/src/site/xdoc/mailing_lists.xml create mode 100644 server/2.2.0/src/site/xdoc/nntp_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/pop3_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/provided_mailets.xml create mode 100644 server/2.2.0/src/site/xdoc/provided_matchers.xml create mode 100644 server/2.2.0/src/site/xdoc/remotemanager_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/repositories.xml create mode 100644 server/2.2.0/src/site/xdoc/serverwide_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/smtp_auth.xml create mode 100644 server/2.2.0/src/site/xdoc/smtp_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/spoolmanager.xml create mode 100644 server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/summary.xml create mode 100644 server/2.2.0/src/site/xdoc/usingTLS.xml create mode 100644 server/2.2.0/src/site/xdoc/using_database.xml create mode 100644 server/pom.xml create mode 100644 server/src/site/resources/css/site.css create mode 100644 server/src/site/resources/images/asf-logo-reduced.gif create mode 100644 server/src/site/resources/images/james-server-logo.gif create mode 100644 server/src/site/resources/images/james_config_load_balance.png create mode 100644 server/src/site/resources/images/james_config_secondary.png create mode 100644 server/src/site/resources/images/james_config_smart_host.png create mode 100644 server/src/site/resources/rfclist/basic/rfc0822.txt create mode 100644 server/src/site/resources/rfclist/basic/rfc1123.txt create mode 100644 server/src/site/resources/rfclist/basic/rfc2045.txt create mode 100644 server/src/site/resources/rfclist/basic/rfc2046.txt create mode 100644 server/src/site/resources/rfclist/basic/rfc2822.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc1731.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2060.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2086.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2087.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2088.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2177.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2180.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2192.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2193.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2195.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2221.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2342.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2359.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2595.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2683.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2251.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2252.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2253.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2254.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2255.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2256.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2829.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2830.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc3377.txt create mode 100644 server/src/site/resources/rfclist/nntp/draft-ietf-nntpext-base-13.txt create mode 100644 server/src/site/resources/rfclist/nntp/rfc0977.txt create mode 100644 server/src/site/resources/rfclist/nntp/rfc1036.txt create mode 100644 server/src/site/resources/rfclist/nntp/rfc2980.txt create mode 100644 server/src/site/resources/rfclist/pop3/rfc1725.txt create mode 100644 server/src/site/resources/rfclist/pop3/rfc1734.txt create mode 100644 server/src/site/resources/rfclist/pop3/rfc1939.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc0821.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc0974.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1652.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1830.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1869.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1870.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1891.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1893.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1985.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc2034.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc2142.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc2197.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc2554.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc2821.txt create mode 100644 server/src/site/site.xml create mode 100644 server/src/site/xdoc/FAQ.xml create mode 100755 server/src/site/xdoc/archive/announcement_2_1.xml create mode 100644 server/src/site/xdoc/archive/architecture_v1_2.xml create mode 100644 server/src/site/xdoc/archive/architecture_v2_0.xml create mode 100644 server/src/site/xdoc/archive/configuration_v2_0.xml create mode 100644 server/src/site/xdoc/archive/document_archive.xml create mode 100644 server/src/site/xdoc/archive/install.xml create mode 100644 server/src/site/xdoc/archive/usingJDBC_v2.0.xml create mode 100644 server/src/site/xdoc/archive/usingLDAP_v1_2.xml create mode 100644 server/src/site/xdoc/archive/usingTLS_v1_2.xml create mode 100644 server/src/site/xdoc/design_objectives.xml create mode 100644 server/src/site/xdoc/index.xml create mode 100644 server/src/site/xdoc/rfclist.xml create mode 100644 server/src/site/xdoc/todo.xml create mode 100644 src/site/resources/css/site.css create mode 100644 src/site/resources/download.cgi create mode 100644 src/site/resources/favicon.ico create mode 100644 src/site/resources/images/asf-logo-reduced.gif create mode 100644 src/site/resources/images/james-project-logo.gif create mode 100644 src/site/resources/robots.txt create mode 100644 src/site/site.xml create mode 100644 src/site/xdoc/code-standards.xml create mode 100644 src/site/xdoc/contribute.xml create mode 100644 src/site/xdoc/download.xml create mode 100644 src/site/xdoc/index.xml create mode 100644 src/site/xdoc/license.xml create mode 100644 src/site/xdoc/mail.xml create mode 100644 src/site/xdoc/weare.xml diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml new file mode 100644 index 00000000000..d5fc06ca6df --- /dev/null +++ b/maven-skin/pom.xml @@ -0,0 +1,56 @@ + + + 4.0.0 + org.apache.james + maven-skin + 1.1-SNAPSHOT + JAMES Skin + Apache JAMES Official Maven2 Site Skin + + + + + apache.snapshots + Apache Development Snapshot Repository + scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository + + + maven-skin-website + scp://minotaur.apache.org/www/james.apache.org/maven-skin + + + + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/maven-skin + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/maven-skin + http://svn.apache.org/viewvc/james/project/trunk/maven-skin + + + \ No newline at end of file diff --git a/maven-skin/src/main/resources/css/maven-theme.css b/maven-skin/src/main/resources/css/maven-theme.css new file mode 100644 index 00000000000..19ac0cbae3c --- /dev/null +++ b/maven-skin/src/main/resources/css/maven-theme.css @@ -0,0 +1,257 @@ +/* + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +*/ + +#apacheconbox { + margin: 20px 0px 0px 20px; + padding: 10px; + border: 1px solid #ccc; + background-color: white; + background-image: url(../images/button-top.gif); + background-repeat: repeat-x; +} +#apacheconspacer { + float: right; + margin: 0px 0px 10px 10px; + background-color: white; +} +#poweredBy { + display: none; +} +.xleft { + float: right; +} +.xright { + float: left; +} +#bannerLeft img { + margin-left: 20px; +} +#bannerRight img { + padding: 0px; + border: 0px; + margin-top: 20px; + margin-right: 20px; + margin-bottom: 0px; +} +body { + padding: 0px 0px 10px 0px; +} +body, td, select, input, li{ + font-family: Verdana, Helvetica, Arial, sans-serif; + font-size: 13px; +} +code{ + font-family: Courier, monospace; + font-size: 13px; +} +a { + text-decoration: none; +} +a:link { + color:#36a; +} +a:visited { + color:#47a; +} +a:active, a:hover { + color:#69c; +} +#legend li.externalLink { + background: url(../images/external.png) left top no-repeat; + padding-left: 18px; +} +a.externalLink, a.externalLink:link, a.externalLink:visited, a.externalLink:active, a.externalLink:hover { + background: url(../images/external.png) right center no-repeat; + padding-right: 18px; +} +#legend li.newWindow { + background: url(../images/newwindow.png) left top no-repeat; + padding-left: 18px; +} +a.newWindow, a.newWindow:link, a.newWindow:visited, a.newWindow:active, a.newWindow:hover { + background: url(../images/newwindow.png) right center no-repeat; + padding-right: 18px; +} +.section { +margin-left: 10px; +} +.section p, .section table { +margin-left: 10px; +} +h2 { + color: #904040; + background-color: white; + border: 0px; + border-bottom: 2px solid #525D76; + padding: 0px; + padding-left: 20px; + vertical-align: bottom; + font-weight:900; + font-size: large; + background: url(../images/h2feather.gif) left center no-repeat; + margin-bottom: 15px; +} +h3 { + border: thin solid #828DA6; + padding-bottom: 0px; + color: #525D76; + background-color: white; + padding: 2px 2px 2px 2px; + border: 0px; + font-weight: bold; + font-size: 15px; + margin-top: 5px; + margin-bottom: 13px; + border-bottom: 1px dotted #525D76; +} +h4 { + padding: 2px 2px 2px 2px; + border: 0px; + background: url(../images/h4.jpg) 0% 70% no-repeat; + color: black; + margin-top: 5px; + padding-left: 12px; + background-color: #fff; + font-weight: bold; + font-size: small; + margin-left: 10px; +} +h5 { + padding: 2px px 2px 2px; + border: 0px; + border-bottom: 0px; + color: black; + background-color: #fff; + font-weight: bold; + font-size: small; +} +p { + line-height: 1.3em; + font-size: small; +} +#breadcrumbs { + background: url(../images/button-top.gif) left top repeat; + border-top: 0px solid #525D76; + border-bottom: 1px solid #ccc; /* #525D76;*/ + border-top: 1px solid #ccc; + padding-top: 3px; + padding-bottom: 3px; + background-color: #eeeeee; + font-size: small; +} +#breadcrumbs a { + font-weight: bold; +} +#bodyColumn { +} +#leftColumn { + margin: 0px; + margin-top: -1px; + border: 0px; + padding: 0px; + padding-left: 20px; + background: none; +} +#leftColumn ul { + font-size: 15px; + padding-top: 4px; + padding-bottom: 10px; +} +#leftColumn li { + padding-left: 10px; + padding-bottom: 3px; +} +#navcolumn { + border: 1px solid #ccc; /* #525D76;i*/ + background: url(../images/button-bottom.gif) left bottom no-repeat; + padding: 15px; + border-top: 0px solid white; + background-color: white; +} +#navcolumn h5 { + font-size: 12px; + border-bottom: 1px solid #eee; + padding-top: 3px; + padding-bottom: 2px; + margin-right: 10px; + color: #000; +} +table.bodyTable { + padding-right: 20px; +} +table.bodyTable th { + color: black; + background-color: #bbb; + text-align: left; + font-weight: bold; + border-top: 1px solid #ccc; + border-bottom: 1px solid #ccc; + background-image: url(../images/button-top.gif); +} +#footer { + border-top: 1px solid #ccc; + margin-top: 30px; + padding: 10px; + background-image: url(../images/button-top.gif); +} +table.bodyTable th, table.bodyTable td { + padding: 2px; + font-size: 1em; +} +table.bodyTable tr.a { + background-color: #fff; +} +table.bodyTable tr.a td { + border-bottom: 1px solid #eee; +} +table.bodyTable tr.b { + background-color: #fff; +} +table.bodyTable tr.b td { + border-bottom: 1px solid #ddd; +} +.source { + border: 1px solid #525D76; +} +dl { + padding: 4px 4px 4px 6px; + border: 1px solid #aaa; + background-color: #ffc; +} +dt { + color: #900; +} +#organizationLogo img, #projectLogo img, #projectLogo span{ + margin: 8px; +} +#banner img { + padding: 10px; +} +.errormark, .warningmark, .donemark, .infomark { + background: url(../images/icon_error_sml.gif) no-repeat; +} +.warningmark { + background-image: url(../images/icon_warning_sml.gif); +} +.donemark { + background-image: url(../images/icon_success_sml.gif); +} +.infomark { + background-image: url(../images/icon_info_sml.gif); +} diff --git a/maven-skin/src/main/resources/images/button-bottom.gif b/maven-skin/src/main/resources/images/button-bottom.gif new file mode 100644 index 0000000000000000000000000000000000000000..4c992992537acd3ae629ee046c446d68dad05deb GIT binary patch literal 590 zcmV-U0M)j$~<`D4?!v>%MR- z&vb3yc&_h!@BhG{a7Zi~kI1BQ$!t2G(CBkOty-_xtai)odcWYXcuX#v&*-#z&2GEj z@VIs;jK6uCK7Mva__cwzs&sx}68TzQ4f1!o$SH#>dFX%FE2n&d<=%($mz{*4NnC z+S}aSzzyKx;^XAy=I7|?>g(+7?(gvN^7Hid_5}F(`uqI-{{H|23LHqVpuvL(6DnND zu%W|;5F<*QNU@^Dix~GM*vPS?$B!WYLy8oJq5$&6_xL z>fGtkfzO{ng9;r=w5ZXeNRujE%CxD|r%fOt?uiw9b0}CEZxUk{Fh!ZPb%($`R$B-jSo=my2 z<;$2e^HspPv**vCLyI0wy0q!js8g$6&APSg*RW&Do=v;9?c2C>>)y@#bAjK$g9{%{ zytwh>$dfBy&b+zv=g^}|pH98H_3PNPYv0bjyZ7(H7l)+46zyJRL1}IKEy*TU5yZ@lqjAUt^XsWJk>%MUO zB6Mxvc&_h!@BhG{5LhT0kI1BQ$!t2G(5Q48U0AQ!tai)odcWYXcuW>6&gisy&2GEj z@VIs;jK6uCK7J2eY)bwzs&sy1Tr+zQ4f1zX8O>#>dFX%FE2n&d<=%($E9d*4NnC z+S}aS-rwNi;^W}}=I7|?>g(+7?(gvN^7Hia4EOl?`uqI-{{H|23LHqVpuvL(6DnND zu%W|;5F<*QNU@^Dix@L%+{m$`$B!UALy8oJq5$&6_xL m>fFh*r_Y~2g9;r=w5ZXeNRujE%CxD|r%#h)yUTnvm1Iv_qshJlI4r7uBZ*YkPFU8d4p4Aua}2?(?R literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/expanded.gif b/maven-skin/src/main/resources/images/expanded.gif new file mode 100644 index 0000000000000000000000000000000000000000..0fef3d89e0df1f8bc49a0cd827f2607c7d7fd2f0 GIT binary patch literal 52 xcmZ?wbhEHbWM^P!XkdT>#h)yUTnvm1Iv_qshJlH@g}+fUi&t{amUB!D)&R0C2fzRT literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/external.png b/maven-skin/src/main/resources/images/external.png new file mode 100644 index 0000000000000000000000000000000000000000..3f999fc88b360074e41f38c3b4bc06ccb3bb7cf8 GIT binary patch literal 230 zcmeAS@N?(olHy`uVBq!ia0vp^+(699!3-oX?^2ToQY`6?zK#qG>ra@ocD)4hB}-f* zN`mv#O3D+9QW+dm@{>{(JaZG%Q-e|yQz{EjrrH1%@dWsUxR#cd{{R1fCIbVIy!atN z8e~{WkY6y6%iy53@(Yk3;OXKRQgJIOfsI*BO@UFsfhWLBc>*(#PB?Jn2*(o!76E4F z2oaVU3``tH+Kgs0GI5+@Tg}d)z%jd%F@?{8!SRZ5b1yT80-FZIMn)zc2Ca66y`pzY R*nws*Vde$l!dH+G>WG0AkX9 zkw^kO#R5~f0aWVd+rdU|kr+Si_VM}o_L~4i{{R1E0Y;4gL(m&pmH<-GRdQ4VNXrIK zG6p+K1xfSs^r&!}(M4+c|NmbFUeHl(I7LJBadO19Z?}R=@%Qb_ zUw+eqhx6az`t$SLbC2rg!|?j`%n?`h`T2zbUHbd|`u_XaJz1}qOsSPq;ibOfx3Eta zLjV8&A^8LV00000EC2ui01p5Z000JsK#Ak_D;keQ$Ij$IIwdNdtL8+?R*)8|YNQ-2 zmP~p<114LCg84U{-IRaz?G&UR! zDO+4I4H_B@0~A~@GzlCwAS{CoA{{h6WH2YD69{BK2CO~+a%4OoBm@DsKLG>;#6=#+ GK>$0AHKMBk literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/h4.jpg b/maven-skin/src/main/resources/images/h4.jpg new file mode 100644 index 0000000000000000000000000000000000000000..859f82f381a2c18f9768c9360ef25fcfa644bd8d GIT binary patch literal 360 zcmex=;a)Bf!ASz{JdmkYQwEW?*3z5*7r?ih_KO3P6U53StNg{=db*12l$7kXewy zp5f~3U3Y#L@2O4RYA;f5TH-V*;+uWii;P;?DJQfU_VT=Vx@&v)rhf(#|KH>S0HGN@ A3jhEB literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/icon_error_sml.gif b/maven-skin/src/main/resources/images/icon_error_sml.gif new file mode 100644 index 0000000000000000000000000000000000000000..61132ef2b01806f6122c31d173c98e01e499b9a0 GIT binary patch literal 1010 zcmZ?wbhEHbJMCn#OVEqF*oew~oaAu*+mN;-=y?VHT3tIe$XQqrDo-uB_a z!$aaK`z6))OKGn34?nwc^SuifkIL#EmDgV_qjg-#8v*0u4q4%1moUw{LZ54UeCgzNF^jX`uv-XK+9g@yFrG9?@ z!9&5&Tgk*j(b!GF&{N4I-Owl3GNQ;Kslp@APSw&&&ux9d>WxL~{EYoKm2KHvv3+ax zZUYB?Ae*8JnchZheXeEaa>@87?_fB*jV>(`erUx0B6j@wa!KnN)QWMO1rn9HC8 zQU}Tt3>@bftT|;oHYhlHH8T8tc{qL2LBC1&wnQeg^-S05<#H=J%;q~&KX!$OXH$lP zifQJ#9>L8|xhAVRHT-xPa*}7JK>(A*!AmL!CQC~j>707p+C5b#ib-SZ5@wfn#-0y8 zor_pb3M^%mkXhlduwjw4dk@RWhYZ<*tSUAV9x3eYyi#^d39lH{872xT#>g14FgCZb z+Lvv}DClhGVU*`8y(Qe}(9I>Lw<6->0~Q`zX3oMH2272dBARI`0wDzxS_G8b_H+a` TZ#n2*^y*Bf^Krq04Gh)*dSnrT literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/icon_info_sml.gif b/maven-skin/src/main/resources/images/icon_info_sml.gif new file mode 100644 index 0000000000000000000000000000000000000000..c6cb9ad7ce438a798426703e86a7ffc197d51dbb GIT binary patch literal 606 zcmZ?wbhEHb!Rj)7jHhhdgsOUdoQoueZi?7 z>>gViTe&E#V48n=mrru5S3;v}WQB8hiDz7$TU2Fg8RZkU)J)l4H+4sO@7jjxJ4?G(<~7c1nYFul=C0P+d#d`@bj{yi z-npcE!T#Qb2PP~z)H;3B%r(bntUlH>Y2~CvyV|C%UbyM>vTf&9?!2&e&!siHFV0_c zVB`KP8}?n^dg$7Yqc`@PxOMQ%-NWbZ9Xfk=)1K2OFF!hV;r{6>kIr6ua^~ve%eS9j zy7lbD`I|4_et!J??bq+WzI^-n`RfmdkOIfh!pgqYwSCK`t~@$#!^!1aj_y2mzyI{@?vuB79>2N$==JkApPs$`_~ygc*YCf)diVLp z{pXKfy#M&+`?nvze*gIk#Q*;N0|qHLXbBUFKUo+V7>XElKuSSz!oa?}p{S|3rL`#` zEj=M8CWV#D$GthOu#hRgfH^NPHz`Z6or!6tudIJkhF|)EqL_SUmH;#E=*;vU)ut4d z*}1MJ+3|6yK5|W*0YQlwY}}E_93D;*P3)($(!#iHyj&dYc$?gAB*f@)n?~7Mn)5Ze zB*b!gs&gB@F*e|Da`5(ac688Lp~TGAEh5PBlHo`4aV}w%hy?;49h(#+>`NXTD0Bjy;4ci{C-1K14rU#4Xoa9{m6qopA9n0cn|!>ecYkij zwyX=!4*mH3EoqLqSGiVbyFqxD(bS8XSDu{6U1jZO70Ic@{~t&7=B^ zBD)NOoAkU&Gy^LQJ5PtV?u{&65}4ZUmfYbweP{LTy^YnAGv=AGa7*6wj}%~b0?7r5!@qH7P%p1*$L z@#{ODxoUwG+WsY)zWExj-aqxpQS(e!bx&6L`u)?tfB$~}{{8*?cVO&*V`-G2NeC$Z zWMO1r=w{FXnGVVm3>>=|#5rX=HY{-DP?VFNPL-%m%>B+*~5-k^-+4*MLFr;tQ0}^rlS-^!^Q`Mx1hrB$jwn&hk~Xk=#Nl+_9Nu|Y$D G!5RQ;-6)O# literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/icon_warning_sml.gif b/maven-skin/src/main/resources/images/icon_warning_sml.gif new file mode 100644 index 0000000000000000000000000000000000000000..873bbb52cb9768103c27fbb9a9bac16ac615fce5 GIT binary patch literal 576 zcmZ?wbhEHbB!Sy%bj7w z8LP{2I!WYbmF&-Ixi?j6tD|K1XR2M#l>Aw*aXL%wXS3nYW}{zi=4WzsU5r%E6qx+# za{AThd85YVOsT`KDUrWsBtGknIa3>Sy(4;AS@f^Dxt>-=XPXm#FD(1Lr2hBv=9?3X zZS^!XrNw@)>eiN((2|w-y>{aB1+99DGMA?}+UTggT+(Z*rf8+5x~aWVOGcurtl;&U zIa)H3I&#vwvQjJBn`YHj9iKlB7`)(M#!e{yWMO1rC}Yq8NrU2qfqia6SyOXMYa1sM zM_a34eqyRfcQbQJY;^IYGTuzaxglKLqNQEA}OiQec+sQ#rUUjLqg_MpsPmY43 zsgmVV8EHK$eV-B~6*UcAW2+w%1e4o&9#aAczLGF}PmMg|6J0Ey4q A)Bpeg literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/newwindow.png b/maven-skin/src/main/resources/images/newwindow.png new file mode 100644 index 0000000000000000000000000000000000000000..6287f72bd08a870908e7361d98c35ee0d6dcbc82 GIT binary patch literal 220 zcmeAS@N?(olHy`uVBq!ia0vp^+(699!3-oX?^2ToQY`6?zK#qG>ra@ocD)4hB}-f* zN`mv#O3D+9QW+dm@{>{(JaZG%Q-e|yQz{EjrrH1%@dWsUxR#cd&SYTt4+aeuCvSob zD+%%o1`04ZXs!GLj7%Iec?BF2%&y2ZFfeUwWbk2P5nvW+xWT~4#-PT{uyM;F);OSv44$rjF6*2U FngH~|K)3(^ literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/void.gif b/maven-skin/src/main/resources/images/void.gif new file mode 100644 index 0000000000000000000000000000000000000000..e3a7d8c469d83eef8aed3cc26266438752d536ec GIT binary patch literal 50 zcmZ?wbhEHbWMp7unE0RJ|Ns9C3=9Vj8~~DvKUo+V7?>DzfNY>Fh|Ltj$Y9L{09+#q AWdHyG literal 0 HcmV?d00001 diff --git a/pom.xml b/pom.xml new file mode 100644 index 00000000000..5b788edf13f --- /dev/null +++ b/pom.xml @@ -0,0 +1,208 @@ + + + + 4.0.0 + org.apache.james + james-project + Apache JAMES Project + 1.1-SNAPSHOT + + The Apache JAMES Project + + + + maven-skin + server + + + http://james.apache.org/ + 2006 + pom + + + + + + The Apache Software Foundation + http://www.apache.org + + + + + Apache License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.html + repo + + + + + JIRA + http://issues.apache.org/jira/browse/JAMES + + + + + bago + Stefano Bagnara + apache at bago.org + 2 + + Developer + + + + norman + Norman Maurer + nm at byteaction.de + 2 + + Developer + + + + serge + Serge Knystautas + sergek at lokitech.com + + + Developer + + + + benrdf + Bernd Fondermann + bf_jak at brainlounge.de + + + Developer + + + + sbrewin + Steve Brewin + sbrewin at synsys.com + + + Developer + + + + hilmer + S�ren Hilmer + sh at widetrail.dk + + + Developer + + + + noel + Noel J. Bergman + noel at devtech.com + + + Developer + + + + danny + Danny Angus + danny at apache.org + + + Developer + + + + adc + Alan D. Cabrera + -8 + + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk + + + + + apache.releases + Apache Release Distribution Repository + scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository + + + apache.snapshots + Apache Development Snapshot Repository + scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository + + + + james-website + scp://minotaur.apache.org/www/james.apache.org/ + + + + + + central + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + true + + + true + + + + central-m1 + Apache Main M1 Repository + http://people.apache.org/repo/m1-ibiblio-rsync-repository + legacy + + true + + + true + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + + + + + Apache James Website Developement + site-dev-subscribe@james.apache.org + site-dev-unsubscribe@james.apache.org + site-dev@james.apache.org + http://mail-archives.apache.org/mod_mbox/james-site-dev/ + + + + \ No newline at end of file diff --git a/server/2.2.0/pom.xml b/server/2.2.0/pom.xml new file mode 100644 index 00000000000..6ba8a4ab0ee --- /dev/null +++ b/server/2.2.0/pom.xml @@ -0,0 +1,52 @@ + + + + 4.0.0 + org.apache.james + james-server-site-2-2-0 + JAMES Server 2.2.0 Documentation + 1.0-SNAPSHOT + + Apache JAMES Server 2.2.0 Documentation + + pom + + org.apache.james + james-server-root + 1.0-SNAPSHOT + + http://james.apache.org/server/2.2.0/ + 2006 + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/server/2.2.0 + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/server/2.2.0 + http://svn.apache.org/viewvc/james/project/trunk/server/2.2.0 + + + + + + james-server-website + scp://minotaur.apache.org/www/james.apache.org/server/2.2.0/ + + + \ No newline at end of file diff --git a/server/2.2.0/src/site/resources/images/asf-logo-reduced.gif b/server/2.2.0/src/site/resources/images/asf-logo-reduced.gif new file mode 100644 index 0000000000000000000000000000000000000000..93cc102077a940966a0bf6d77e74ac273a10ef8f GIT binary patch literal 6636 zcmW-jdpy&NB^`k5({Ud=*EWJLJM77(p_7Ubjo^?L{6ozBTG zrT8~-uT3`YA6z(iU(uWv#wdC?*LrZ+m}~LRdiKU&$f@Oy^oJ`=i6+hgRAVF_PDwp- ztgxs!1ZD4l68M_KW_UVk-#Q!$Pa@K2Br166_?3pnI2h|A-a0BAXQR5&A?Fpb?Gb8 z2*k5oCs=r^?5ey-sZ^AxYup^lC`5wE?{)1hj19^$$^{?dW+pEpj_VrXL%+<@Wf;^t zJCdiUvs(#-G^G|kfoFntz873~ctb_>t(@D#$7q=4Jv#>J`Qv=$b>~!(=u%)Bm4nQx4G0uy}~g_xl^(YUhBvak#5 zgOuvw;WT+BuH_Fe^Qfh^cx6`2s#Q)p=qizh0B=u>WgT3-Um`*}GI*J|%p$EpRN<4Y zGf~z{=<@Z%ciE4S^38-`SDls-3H17pfQxW&*i~EFS~THa;&q8l$;Vfpq4`<-XV(d$ z`-SexHAn1eerw`+&nuVTz17YrVcMN=n%6b~Pk7R#fQs2Gpwl_l;)!9Zix3)AS!c&C zQ34C)+gAHfADmZ#J!@ouF>Xj{z_YVB18pQxGV z#8&ZYQIjf}4+ukXt98XP)EbGFTjdXCr7XQ<39V`EX@7dX7sgi%K^WawfM#Gv=)Aa1 z+o?NS!01`I1iDVjJKI}zgx$&^C5Ef~EU7JH?OH!a+{=QV@_zU`-5PH*I zPuRv#n3aaLEiBR7@r{SVvX-}mUhuV3xb?k!BFIAH>qbPzbWFRFgIRYuh*K-nKBmlY zXo!mHbNn_F82LJk8Y(6HVBaJGfDmIP$=s!3^Huul_S2gBtEE}_T2@5k_$OT|Hfb(5 z)X<#6D%iKo^EXxX4F^7^85Vz6sG)}#XEvtZDoScZ&v0xHPB;j%ar+w*l2aoKKDo2- zb9>!cbUD@Cqd08ehtuEgl-E^3le=d;7%p1%H-?USDXO&=Ns#x}Gv34#dLGHj^Mbev){8$exY)@D8txn4_GgU^Q#nGSmQLy^q-T1(e6TLYS zkyodfAaB@J5Bc38m*mNB>VrC0Ux|ebUq~Fex!-O z_3SLrfr{Ra$gx{pd(y!YKvCLGkH;%6{CVnQ{;UW?4*=tq1vDz`SEy-1yIj(V2R)ZFCY__!(Zs!f z`rl=^e16E7%Pt1a*QGNC=$-{`qOzJAu$vUT+P&2n>8pCwFvLX7zj^SYb`8p=S+0`E z$XYnM2{X2F1lL-FD1N}lfYe#DT)AY*L<*-3n_K(QvY5+XtlTfjs_Xqib0@!ESbnk! zSA5ArtJN=qF`{-hEnA~6zDFo%d=8mF^^sHw%D{yEh@{rPMqBF5>hB{?M8h{}t@d0a z$TBh@8x%i2xYqf->Z_kO?ik9N@?Tnd1s`-Sm~BEsL0u8q&B1GhLXeauby8lte(=TH z=AV&6s2Bxw4Bv}#m_ApmU%KiQkf8nY=}IGzQPzj<_?tbT?S^q>@387$GCgoZ>{a?} zs*!BKHygc@UGbJ=GHbM@>qZ!K2AH8?ChBt!Rc8lW$zk7VEIyd*pHZ< zE$>3tEVKs2MMV7_y;EJ&`Ixn`WSsRp6bJd9jN0ez7 z|Ma|Lc!>!cW3KHdjTYX+6Ie1ce`!;(oJVsG#TcaQP4A00xHl)OMsj5M5|l7eC(3az zDJOcF{El8dJ#Rzx_qnmF*i5mBua?=I@#wMvrXgR?ichil(W`n;21chubB`0YX{t^$lR@)6e zzxHWowXNRH^1Qj<$tzEf&Y^`bdfs&ERfbPdDZ3B53tO443vu5as^NZ_IwXJfQLrGe z*svE7@rd$rX)~s^qXx&9l&pV0F0Lg#>vRaEt0D{^yK6JYuX|TyX#+v*D)2mcq;*Cp zfmg+{`z{X8I**n$^E#AvnZc#GzrRAukx7ov5b^QQouH>j)7lqpVBE5P^}wWc9VJMF zl|RDZCikc^4kDE8%0ixL8a>;T0`GN{#v6|OnR?@tEUXAkxLJ7eVdS$v?N0>>6O+H` z^2{Fo2$O4$vb6y!ta9)n;7$uEBjvIC)aTjix?Ev&58b zTHCwd`4prf7n;f;4aFhXHwe2DD!6nD&voHBVW_e^kk z4BA-^s7S#3%MdJ4#z`=;Gr>L_NJXrykOQM%3PUrC{5VkM211p-l*eeZE_gIfIC*wHsp5pD4ONn{s>gfc~b%Z~YZ zfnp?qAD#z;w}Pl!;NNdN^7{Ah$UuBd#BGr$q;yX1IYErS2Le0Dx zqKPdB6#2#+aF1s2nU>;y3GRIxtU@)ZW|^FpfQ~=ZZp%^@YPfu9&Thx@P=y`kq&RXQ zrP!}nk8sM64X>6!PGY$JGH6aPF_geaVX2e20;v#Fg(T&7r%qiezhli!WB6VLkCZ*B zG&`?pe<1&KTg6Y!%9gm&{(-Dz0m4ZN2hm-2e=EFq8EYj6+(TS9F#>*%LhWhDO$Eqg(i@Bw z)ysu*&R-5ba{&B^X%ph=;~Ze6V^@UXC;oaVAh3nK4e=SJ+})Q!mhX`!p&LC@;->&y z*%W2taFQ)dn8M%$JL=tRX3)qPH=>dPFsJGwCA2L|HJ%mKj z+y{JohjEIwLdk)ki%L3nlF_un1W|C)_?oXdHHJxWEt5OSuAY78a@UvZQv>#fngy#D zda$eabAW`YbKVk=e-xVk`<#M<0C`~Vq#5R;JN!<{#bsQ{XJ#H_~xNkfws>)tk=Nd2=DuVh(`? zKbj9|62X&jT2m5yRsj^6*w}MyONIWHK+*)q!^jL_U2(Mwdv&9cwJ)Nvvpa7o8k)iy zo$y3h|0JtOk~^bd8{WmujPMc%sHVchB03^Sb~uD=9ux_+r#L6jz0P(=Y$!X|c){Km z?fLK}si+@jkFBv!Q@K0>0$w#6{ub%)YMSm>%~9uFy#et(ya<}gRQ2;ElN`gOWOB)M z?>DekR{i9Jsx8$4$*0#w)Bf5RkUxJ!K+o^z4rbhv;V_6(p-7uz?>a# zDmQ!+XacocAKJy4EE*aJ5_O zOl7@}o4eoGZTmg|$@UZeg7>|qstB=;z~yyP7^X&>6Iul9wdDbqR!|(HgI(~y4bEgj z%tqp_C+GnG6Eu5vYZwFarm%kO0S`>W{wXs4Bc*Kx9v*U#|E11@P&c^;w33o+rS3mX zZ^{t6E||fFhT*& z$DjcTq$Y2;o9%Wf9FZevyFIOXQdsN9MYJA58+<3}B-N#2cE!;z5WI==7sz?xMoOhz zCcFEp2Joy;%Tm{v(b4hj?*Q^*NLZjte-Cvs+}BwF*3RDM+ZvgK2YRtLoAP1um6~CC zw@>rEM)H;)OM3k2JaP$*d$h-ya-e6dr-4L468u-H8afR_e5*9CiF(K(Cm9J@isrWu;W$PP1TA^Q5f6Fvm^0E!e%5G?i3bKu z{Y_bc)_ET~Je&J>&|Ppxty-gD7^mFzg)*;3yK$m!uh89nW?=u;;J(Ukj}X{@$o$uk z$D||T{CMs~RQp&nti<#1&O(x{p7CHf|PgnQpY-@>Nvror76~GP}JT(kgx;Nb}5NhSZnAlLKawpPv{}C;)2hij} z-VORkhG$HWlVpA6+QO`}!i1jeMpnIN(Qw3S+*Ou5@BOsu;ShlNeakxDSlH5X@`wsZ-B=B^}t8EVN2WpeWtGP7&oYjaRX;8E)O+J)+0Eg`%&btht7o@_=5B zG}L1PyFKiFGCjmEgcCDdUcVCjw?p#*6+*WFo_@ZNNb6~LvrE2P1Ru4##STL3u4F3L z*$=Vae1mATs5Qf%z+bemF7Xbf3~@o!*q#q%6(KZ*3pVUEz8tvgS;Lvcg@LO8O#eXH zq>p^m_Q3Yl@-yi5M)=KD;6NHM`7vBn)9`{|U3AEtE=_e1P?$VMP7CLdHrY4?p-KJt z?4I-SV<|g?s@V3;aUsaKmh-9j@-TT;R2b6YKEmiZGJXW%GmD56}7a!qg*ZT093>v zRz?yK$i^kR0fx>=K=sg4p)3658SV*r>97F6DgYB65WZigcl|(D>z%LO=H`Mnn`wZ$ z17R)!YJR$CP66?+0Ra!Q>N@l%0q;r2xtIPhwW?=e^`9!vZwV17-} z`v&|Lxi`;X*yrlGVH2dVIefugw~g0%h=SUIP?B$j31DUvBdWX!RR_#(g^grxEaBNF zPBtudN<)iV+FZ!d+5hg+5J&Kc{8OETWxW%AhS&-JAzgnD!y2*9@s(5EO^-9pGAbx= zg#EdZxG!MeuOgDwu1+Avr1pU-1JvD&F&{S%|h`1jKPE8AZ9k@JRFi0v2K#muJ(ewI`fD=fye1%bs?&BeGF zZ;Kf*o`hYW^tpt?tq$ty>AH5Dulshs%z~6tiW1;GG`f9=Ly2Rh*sacZBEQUkRMCso zF(ECs$v<#4B+Ci`W8DE(IH(va?>eRhd&*Ws)cPcdW>57a3zdK*%pb*f<;JNtKI0 z-OK4Xju4k0B=B+2Gi?d-6YhU0Hg-u4T3_eoi!hE{=_4w2X!!hhR9UR3Z*bVfO^dB@ z%PGwF+v0V23+}E!LbhW#s?0(LXH?3&zWt$Tk-C=x5J4Uxye3j?S>N?L*6t@Ap4dt zcM)kz>l6V3L(wORWE4ZuXZU>MMajkfSMTVD^jZMsMn!gIo{f6w>v(K0>sOvxzEw=a zrNq05F^F4qmE!-zC(QGQ`ALI5Ao<%CXooIt<-mU(5n<_HaS8j zDuLZSYT+|{!Wh1VGuH~Ji%q}YTBR-VL>(y61_$YZ82tG5K;VJrr`+k+V ifk3o@FNQYto?ua@#Ta7 literal 0 HcmV?d00001 diff --git a/server/2.2.0/src/site/resources/images/james-server-logo.gif b/server/2.2.0/src/site/resources/images/james-server-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..f69394f6bbee48b5b336395a573aa484fe1e05dc GIT binary patch literal 6944 zcmWkxc|6mPAO3tk+w8E-%ze)>cNs;Y_%OH9=^LqY!p6C5~|M5J|u1;GmLv_J0U;+RJRY#^L#+n)$-(9#+ zy+3^Y&w6}p-1uGlNG0VswXXG*g(dO&`uZY+!B`s}&P~lsA(7YD*FJoB|F25w^6WKb zd99Ji1M9yA*2H4*>UwK-`ufKY$$R6)OMgGF{}C@Oj%r!KTWpd%yu_b>F5GSvul+J5 z$1bgZUlp%brx6yve_35y`8z8-Zejk+!>YIX>X*MCYpScS+S~8<3O^L~&+P1r)wRDr zmzS?JTswcZq@(55)cg67fyaFQLjVB&)6`r={zm}7`2X<#On`)#ewY`pk%{&wQXk&ai<(K@^JgErzM-gvFd(D2gsijs=b ziMEO;C26XnVoXu-*%Ie`l$z;QS$$kQDm^wWBN5NZqe>T^t8ZvLgwn$q7@*N7GLmgk zu~(Y)JCx4or#3z6f9w~Zg}&Wpt}hwSxqn5!CQqriZ{XjTublPuskUt!+R#L*o}z_P z;&|qLNlE?h!j;v>v^N^EZLP$E7yv=fB#PjHYWmSGDbF=6w+h)%@Qfr7;U7IGq-VzC zw?v8dHt~{0bazl|Q_ts(QPtv-d=>$nLa{GH)O|YjbxCX=|IOqT1b3uF_vyGWVtPcsvaZ(clg4kUw_ryM zS{`6SG-Dx~#(|H$N`FO)PXh^x6j*8t_ncT!lPy9a@Hn0zDDl%yRJWu;m_((a?4$BC z1X~)1j?ml&r-9qw#tcX;JuAvJw1^Wzi9k759T;KLfMg|E$`kBQxuViDel4LrICBB3 zxKTBES!@g>{UR3El;n!=GEJRfR(aM+8jZhk6AmS^| zx9&s}NrH-FZXS~rk~(3&Fm`BOzM>}SxS=x^RD=-(&COhG!lt(zITQ6lE(9kj|rZKWx!)+CkEM9DSotW zAL%$wc2hPg;;VehRV}d{QR4PZV}fcllaH5roMV6GSzil)z18Mxbf?t+_G3e*wSP<*?VC1r68u=L)VR173Y%55{^Mit~opR}< zqn*Rw8IV0rP|d2ZzgDXrNjb>r$8NtC87F%}{tu(sa+s1jZu)eaAwfW_ooM}QxQE@a zlgNb~$z;1XqhVgA{i@m`!AA6^$eoLIvauuwXABhh0DW}}5E%>f?L&Z+Ckvxz2J-KOohq*THAPi3)8RUok zqZ35y58bbFwEeY1`Xz#-M9>qEAm>d#ec?(AYYfWBHnm zy~Zk)<5B?2Y&Ou=uBrYEMr}5no%Zu7)nK`$s8YOthXYN|M_FiDk!tbsByc1~oUTr* zNYl&?wc20Dg={!l(g}iIz4y#q2Hhr&_~^F#+etCCORUU{Whv-zL_h^_iiFL8TU zxG3-nQDosv^?`SLH3NaZFk$0yV%sZXbZ; z(*HJtq28i2bxL%2)Y;%AWf&kN*B@wIJHOs(vGKLb5XHH|LB@!i4s2cIv?r%hGJ9Rr zgg|Y#}$n)kX?dhIZVTN=oTa2CJt21Lp!wbFCB|ciprB-HZ zwi^B!3~XhE;nhVfRR?l0{|}XVexPiXMvV$~$rMB7wZw$z;Y1n}VVV8n-I4Z3=X2l! zxyZfiHTKspeyNJKPC*eaPXoG3%sO|!3~Sj`XZ3mDYGBwDBKz*MI;UfK+bF&#9D1r8maluh^IZ(XHL_sf(BxSx1z@J1reMKfis;a9&Ejp;TBG z3lLC_-0tC!|M6|kpC8$|f%gV{@;r-96DmRpRiDiQQIH`d`_r!rt=gr4g?~2o)Q6V; z8SML5P=czAD~*&fGK7MT)&zbEJR8JglS%vKz6r%8Iy#gf4el*Tkb48EOMV3m-@!k+ zMxOO{uvkJ$FvQ}U7Vo4oL3B_mH6jk`u*?kTe z?vCGXD&Z>Pf$6l@dQa}2@6NB2QD1Y=t(!qdI)xHnsvfW&zkC0LN2(@9`mLM@s4+k2 zsu4+H8|1a!8a^lySXWXH<}{8 zz?t(y%J{`g`r!BBU6_saWwcKLl5>+DJL06{Mk3}OOp)b^GPSm_03-|}HCEh}&JF+f zjy`#x_f4|*l6+K!!okrW#d>|pFalUd_f1O=Y3U|Mu-|_>ex?7ja zq7DQ;f>EF4z9wt_@zN7LpLSf?LPlQxl-lu2V$C;!{GO!aD8YS>ImkXqnA2oTQvk$E zMy<;E2lv-^UxyOxzEt@1#Iym~~groMgMq*${F1wcp$Y2azZMePl?F*vUlcr!Oc9fe1PmrBY5mk@+FZ zEh4V?y}E9Pn~G2916IDpRkd^@Ch#KFgBx~@kFp;v4g-pNcbEU1$>&7twM{IfsN25- zgLUVs&SMJ;&B;1V>3aiTVw#pgX^YdV+M-laO&%W|0Dzc-T!hh&r*xth%PrPZhNiKh zBo-J@5K<&c(sW;xltU&5V!0mo;LTyXvcn=zePl4_KMah$BopT*1|P6LWbj1|o4S@r z3aQIwywtDzU!vzU9+Ep_-)bcD2T%C3{_VBH%P#4;Z4rW{zW+R(aA(LP-qs+@6t+ih z^4N;DGSxo1k(VI;E<(30#I}>lE}8}6^ccpe0zLTz3nCPT%W&RJLj0CE&i&wE zDnOWRP1`(;2>F08l|SB%+DB)k*)!rr{Ydu@DUPB9Q@=Fxgfz>Q6l*`EO&zjRB=<%u zNdw-T!IbKahN!>LimVt=5M?5Ql&L$+OPqq1fC+~kDt)`ZS~y!$O!mKnDgyUZ}FJ!_**y8jd8NhC)h)`Fev@x*LGyQyo)>2e*s;%q+ht`7rg9(YKRMo zCjmMzM269wKIqqE5XVJGQJ@WsqC>rit#W|dHI}w8FT@*hyb>~j0a>iqb_SqA@*>h8 z6Izk{Dx}Sa6XTp8Hv(ypJu(e$U_^M8A~Li+gX4z7Xea= zCMO{T542`^TG1dRBg#w!s&GLwZHOQ|e)L3{3Jl53KrTv9>lCEJ0mEC^ik#D5xI3hI zU_Ml)!$&|AXu<**if0tbrGgX$hGDW@P)x}JOlUf^*GGRJS8UV^@~4#Uh|Z~MN7f!d zqL>#$bIy4(IKBHzCrS~QIfOzuTbUU}5d!Z_^|Xb+(d!_Mhj9A`k%9%yVCX4S&U+1* zF_K6?S;}=#V3}v;dfBv8DT9={oh@%gg3N@#cnl=Xhf=U*p$=+4qybG9Km>~V$Y&9Z zs3zBZU0qb+FNcfSNMnqn_>Muvihhuc_3RKY4o)(zEu{@kwH=Nu@JPW|Z` ziKs({sJw6tik76K9H*x#c_0VS;wefC^j=3JsI<$Pzd(I1q#j*Og5?SX?3wv9nX3@v zf`ToNZO8>CWSODC)KdRruYCEIA#hH6*+Qpb07_d-X6MQ z4+HNE5I2|&I~Fm|7miyo;cgbB>9>7S7qLviEaXDtN*7eP0KM&uwy2uK<4jdH%=$NN zosnINhWNY!Uy^k<>OgQAPe!?RC#TR$$r{(eOMhR<)klr<2`#^>l?C-bnj2Lp;H3+o zktn~+EZbx5xCv#WEff557bUq>&l2ri@pfd5|zu%0C{)I zC&Qy0!mbg4t4JPbBp|6Iq#ief8PO?cT#&aU(g;b-JAw4b!-}`!kb$2NVwnh3zm?~A zPmP4ZdP^*JT$*}f(eOjImqQ!)b`=U}hPLDaW*p4q!Bq8VZbPnae6+4wG&CUr5^0S# zo|IG9!GaP*vGrZ$=(}Yqe(9`+wZmn7qk)b38j@}()xlQp0iJxv%}#8Eq;-8)?!99H z^$sZ90V*=;MRNvxar-@tq3BSGGWV(0<%YqQjYF4M9i-7^$n_?|Vn)ucC7+80-EYcB zj@K?_<~QeJU-+pzWd_OH-Flk?r~<934ysi*QJ9M->72r+zNkYtk*f#KrCFT(^eHm< z=Dn*JO%}g-#EM2t1$P8QZJ?1f7-vivMDvw~;KUdAAR;5NN8fc6(F&^l2~#|xXB9`0G_*(nHd zV%>BR^>5jRdUWj}p5I))kAUYxwr&7E74kQ2eYaTMWU%#&AtF$@Wa}z|{0CynU`9D% z6Z9&J>!fGCNl3=Eu~LkgktY2QM%|9Mxfm3ad6(WEO1iLLt%HXOpRCN1=-nlHATkPS z4fk02jaZ!?X0V219N{y=4<&S{cwvKh5YQ7*l;HDyW3?uvj7!GI8P4%d7w<%lV#e>7 zng|EeaqUqb266D_=|wsIHVm&Ht(yf>d0_nP(5c+Io1zj1=YfAmME6AE!H8jJPLF48 zp^G3A|F&iR!lH0!A?OCa3z-FzO;Y+VgtI=x2d5&`cLT^Oz3FO&LD(#Yj0HTW}^woeLb% zgM82Avf7&)*0A~w@rgbM;i#~8=C8hKNcGmPN_LGTWW}aBhJuU0jjgDGT{6@ zZ{c)F5AvEynVOXqo8SyV6_*XWL9{40>VoD;Ez7#=}pJP?K>+N)SI z%BOr6cU~^(^m-pW=D8cvJAyG-S1^7l7rv2-V=lys(8YhcG(;Flf#f!}^G~~N-z!u5 zeSq^t4dTYmk2{zE`U%p(`QatMnv#_Ho4>t+XR_rJXUFnKpQXH0HTr~Nj=yLC%8%@$ zruc?Oy?2(kI7FP?{hBlcUp{TQQH^%{-Q6y#Bfe~mWE+f^bNnA_zfjtCgdo&2_oYY&L$%SJ{!Xd2Jero?$zjZyNxkPXj`5urL7bl$tq zhuS-%r*2zMlV}%~xQN#tn@i2q|0R4)cwp)3qfeZ6!XKlmOT9LyM+zo%0`OnB*Iko9@$XyZ`=s_Y_A5M{a^y}f1fxHCbUep{ zVvq!G;eSla2SCAyI%N@O-nufD^r{@w3*H#;US=_-mOYTJ$j45ii0+q>_d`6wFN%Bw z+@}N->l^ZYT$}fU7*0rqKVcy(G73S1+PT>>AVR|Y{9|VS)-|lnDENm1#7#=omHWu>n zW;BK|i4+z|lw2y-3Lzomtr*`|zMsPRsxqVlY>wc}%oJrE7@DdUvWkjFv@G^GIRsc7 z2|=1WF+CIw-F@8*(If|7j?=`27W;(y8vC!s$6Av2wI8;ht(s5%Ja*TxV(?qp>ii@LwpigzE-dgfw_;neJY(XQzRBfmcQv7e_FKPAQWE0nt zhj?9Q^~koqVe{}A6lk}>#X(UXL>Xa`4m`z0JG3KGHIdI0i|o3xim4vbeu+9gYT)X$ zxxka&mk&rJ3ur5dkW!pff(yfw-hbwH(ELo`MWp+=`>xO1*hXcI!L7dE*Z+@h(ZmN4vY|J_Bzna@DkqjBlpQhQnl$6SfCZ zQQ9XA@15C%g*I&7R@F9#IX=Y#1=5@}!fcbzlT z@ibPZ7OGwIfsT&Q4h<&Og$@{$MSdU9zuuXqk3ZHNYK@}&28!ra@It0?!n9pRW9jFO zkE!?1=Vd9sY=4ufmf-ROQxP%~+hPn7yajgPJ6an3!JiDIEb(Vern4r2<$=}DcsAy4 zIW{^?qDhxCHLpQ9x74S(Dq!Ze#G}h)ZH(WFOGH*_RPi%Y?zvj9o@Mn zIOfX&H(h#(rt7%Nn90o8W}j2}I7Pf_-ty`+Nc0o3u^XqEr=>jn<}ze#is!O43ly1I zs3(;rHZ;TL^e6{KcAZLlI<-V+*&%gk%bPq@>A4p=<6$Lb(W}JryNr{v7p8LI@beAA z^Ma$DcTc)qN?WoFuc(F{axgmjxB!%eC + + James Server + images/james-server-logo.gif + http://james.apache.org/server/ + + + The Apache Software Foundation + images/asf-logo-reduced.gif + http://www.apache.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/server/2.2.0/src/site/xdoc/adding_users.xml b/server/2.2.0/src/site/xdoc/adding_users.xml new file mode 100644 index 00000000000..e063dcf480e --- /dev/null +++ b/server/2.2.0/src/site/xdoc/adding_users.xml @@ -0,0 +1,58 @@ + + + + + + James 2.1 - Adding Users + + + +
+

User accounts are shared across services. A common user repository is shared across James +services. That is, once you've created a POP3 mail account and set a password, that same +account is available for authenticated SMTP and NNTP.

+ +

In James, user accounts are created throught the RemoteManager. So, after installation is complete, the first step to adding users +is to configure the RemoteManager. More information on RemoteManager configuration can be found +here. You will need to have configured at least one administrator account and +ensured that the RemoteManager is enabled.

+

Also, you need to make sure that your user repository configuration is correct before adding any users. If +you change your user repository type (i.e. file to database) or the configuration of your user repository +(i.e. the file or database URL) after you have added users, you may lose your user data. Please change these +values with care.

+

After you've done this, restart James to ensure that any changes you've made in the configuration are incorporated into +the running system. You are now ready to create user accounts.

+ +

Once James is up and listening, adding a user is simple:

+1. Telnet to the host and port on which the RemoteManager is listening. For command-line telnet clients +this is generally done by typing "telnet <host> <pass>" where <host> is the James +hostname and <port> is the RemoteManager port specified in the James config.xml.

+2. You will be prompted for your administrator userid and password. Enter the values you specified +in the James config.xml.

+3. After logging in, type "adduser <user> <password>" where <user> is the user name +and <password> is the password of the account you wish to create. Please note that the user name +should NOT be a complete email address. Rather, all email addresses of the form <user>@<domain> +(where <domain> is any of the values specified in the <servernames> block) will be delivered to +this account by default. Mailet configuration can change this default behavior.

+4. Repeat step 3 for all user accounts you wish to create. +

That's it. Your user accounts are now created and can be used by all James services.

+
+ + diff --git a/server/2.2.0/src/site/xdoc/build_instructions.xml b/server/2.2.0/src/site/xdoc/build_instructions.xml new file mode 100644 index 00000000000..b6ff76db084 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/build_instructions.xml @@ -0,0 +1,79 @@ + + + + + + James 2.1 - Building James + + +

This step is not necessary to use the standard out of the box version of James. A +pre-built binary version of James is available from the James download directory. But +if you wish to customize the James source code, it will be necessary for you to build the +distribution yourself. +

+
+

There are two ways to get the James source code.

+

1. Download the source distribution - the source is available from the +James release mirrors. +Simply choose the version of James you'd like to download, and pick the source distribution appropriate for your platform. +

+

2. Get the source code using CVS - this method gives you access to the cutting edge code +base. Instructions on how to use CVS to get the James source code (the jakarta-james distribution) +can be found here. +

+
+
+

To run the build you need two third-party tools.

+

1. Java Development Kit - You must have a JDK of Java version 1.3 or higher installed to build the +James distribution. The exact JDKs available depend on the platform. A JDK must be downloaded and +installed before the build can run.

+

2. Ant - This is a Java-tailored, XML-configured, extensible build or make system. The James +source tree includes Ant v1.5. You can get the latest version of Ant +here. Since Ant is currently included in the source +distribution, it is not necessary to download it separately.

+
+
+

In the top level directory of the source distribution James includes two helper scripts for running +the build. The script build.bat should be used on Windows systems, while build.sh is appropriate for +Unix systems. Each script takes an optional set of arguments that tell the script exactly what to build.

+

To use these scripts, simple set the environment variable JAVA_HOME to the base directory of the +JDK. Then run the build script, optionally with any of the following command line arguments: +

    +
  • clean - deletes the build directory, making the system ready for a clean build.
    • +
  • compile - compiles the source code.
    • +
  • dist - generates all the James distributions, packed.
    • +
  • dist-lite - generates all the James distributions, unpacked. This is the default argument.
    • +
  • javadocs - builds the James javadocs.
    • +
  • usage - prints out the usage instructions for the script.
    • +
  • website - builds the entirety of the James website.
    • +
  • xdocs - creates the documentaion for James.
    • +
+

+

All build products are output in the dist subdirectory of the James source distribution directory. There +is also a build subdirectory of the James source distribution directory that is created during the build process. Both +of these directories will be deleted if you run build with the clean argument.

+

Warning! Any changes you've made in the 'dist' directory +will be lost after a recompilation. If you are making changes to the config.xml +or other files, we recommend you backup and then change the copies in src to +avoid losing work.

+
+ + + diff --git a/server/2.2.0/src/site/xdoc/changelog.xml b/server/2.2.0/src/site/xdoc/changelog.xml new file mode 100644 index 00000000000..d9841e13ebd --- /dev/null +++ b/server/2.2.0/src/site/xdoc/changelog.xml @@ -0,0 +1,446 @@ + + + + + + ChangeLog + James Project Web Team + + + + +

This is a document that records what was done between releases. As always, thank you to everyone who contributed code, documentation, bug reports, and feedback. +

+
+

Released 15 June 2004

+

+Below are some highlights of features and changes already available: +

    +
  • mbox support
    • +
  • Mail attributes
    • +
  • JavaMail 1.3.1
    • +
  • dnsjava 1.6.2, includes auto-discover DNS servers
    • +
  • FetchMAIL, deprecating FetchPop
    • +
  • Quotas
    • +
  • Extensive message redirect system
    • +
  • Improved network address handling
    • +
  • Multiple remote delivery gateway servers
    • +
  • Many performance improvements
    • +
  • Many new matchers and mailets
    • +
  • Many bug fixes
    • +
  • And much more!
    • +
+

+

Details

+ + +
    +
  • [JAMES-9] - JamesSpoolManager doesn't shutdown gracefully
    • +
  • [JAMES-62] - Spooler loops and add message many times
    • +
  • [JAMES-72] - SMTP Handler DATA buffering issue
    • +
  • [JAMES-96] - Mailet container should not trap exceptions in init()
    • +
  • [JAMES-109] - run.bat created wrong temp dir
    • +
  • [JAMES-128] - Fix problem when invalid domain name is passed to NetMatcher
    • +
  • [JAMES-133] - NullPointerException at org.apache.james.mailrepository.AvalonMailRepository.store
    • +
  • [JAMES-135] - NPE on nonexistant mailing-list repository
    • +
  • [JAMES-142] - RemoteDelivery only tries one of multiple A record entries.
    • +
  • [JAMES-144] - POP3Handler breaks with message numbers out of bounds
    • +
  • [JAMES-147] - Update libraries
    • +
  • [JAMES-150] - NullPointer Exception when mail does not contain any Received: headers
    • +
  • [JAMES-151] - connectionLimit on services ignored
    • +
  • [JAMES-152] - When a Received header is invalid mail may be created with a null remote address and host name
    • +
  • [JAMES-153] - Looping MessageException causes system stall
    • +
  • [JAMES-156] - AbstractStorageQuota matcher subclasses never match when recipient alias is used
    • +
  • [JAMES-157] - AbstractQuotaMatcher subclasses should not match when reverse path is NULL
    • +
  • [JAMES-163] - RemoteManager buffering issues
    • +
  • [JAMES-167] - Remote delivery counting retries wrong
    • +
  • [JAMES-170] - Postmaster address should be case insensitive
    • +
  • [JAMES-176] - MySQL query not using index for string comparison
    • +
  • [JAMES-178] - MailAddress can spit OutOfBoundsException
    • +
  • [JAMES-182] - Fix the TMPDIR path under windows/cygwin use of script
    • +
  • [JAMES-187] - Bug with DNS entries with 0 TTL
    • +
  • [JAMES-189] - Remote delivery sometimes not trying all MX records
    • +
  • [JAMES-191] - HasAttachment has false positives and negatives
    • +
  • [JAMES-192] - MSSQL mail table create bug
    • +
  • [JAMES-193] - MailetConfig does not implement getInitParameterNames()
    • +
  • [JAMES-194] - DNS occassional null pointer
    • +
  • [JAMES-199] - Bounce not using null sender
    • +
  • [JAMES-200] - MailetConfig throws exception for empty getInitAttribute
    • +
  • [JAMES-202] - Proper POP3 response to QUIT
    • +
  • [JAMES-203] - File protocol URL with JDK 1.4.2
    • +
  • [JAMES-207] - Exception handling when fetching message, stranding connection
    • +
  • [JAMES-208] - Regex code is not thread-safe
    • +
  • [JAMES-215] - Javadoc corrections in mailet API
    • +
  • [JAMES-230] - File stream repository may strand resource
    • +
  • [JAMES-233] - SMTP AUTH PLAIN doesn't work
    • +
  • [JAMES-236] - java.lang.NullPointerException iterating over SMTP hosts
    • +
  • [JAMES-238] - Missing Date: header with CommandListserv
    • +
  • [JAMES-239] - CommandListserv corrupts Subject: header
    • +
  • [JAMES-240] - LinearProcessor.verifyMailAddresses should catch java.lang.ArrayStoreException
    • +
  • [JAMES-243] - FromRepository does not reset mail state
    • +
  • [JAMES-247] - James Does Not Work With Oracle DB For Spool Repository
    • +
  • [JAMES-249] - getSMTPHostAddresses doesn't resolve when MX RHS is CNAME
    • +
  • [JAMES-251] - ClassCastException
    • +
  • [JAMES-253] - deadlock in mordred connection pool
    • +
  • [JAMES-255] - SMTPHandler logs exceptions that abort the connection only at DEBUG level
    • +
  • [JAMES-261] - Text error in config.xml
    • +
  • [JAMES-262] - Invalid link in james-fetchmail.xml
    • +
  • [JAMES-265] - org.xbill.DNS.Address not resolving addresses in some configurations
    • +
  • [JAMES-267] - NullPointerException in Fetchmail when there are no From: or Sender: headers
    • +
  • [JAMES-268] - Spooler.accept(...) can leave locked messages and leak memory
    • +
  • [JAMES-269] - AvalonMailRepository emits spurious "so we're deleting it... good riddance" messages due to synchronization
    • +
  • [JAMES-271] - can't resolve when MX record direct an ip
    • +
  • [JAMES-276] - The url for the ENTITY declarations in config.xml should be just "../conf/file-name"
    • +
  • [JAMES-278] - Remove references to Jakarta where no longer accurate
    • +
  • [JAMES-280] - DNSServer does not cleanup DNS cache cleaner thread.
    • +
  • [JAMES-281] - Return-Path twice in header
    • +
  • [JAMES-282] - Partial message may be delivered if client disconnects
    • +
  • [JAMES-294] - Database Pool becomes exhausted after a short time when heavily polled
    • +
+ + +
    +
  • [JAMES-99] - RFC1894 format notification
    • +
  • [JAMES-161] - Quota framework
    • +
  • [JAMES-162] - Partial send support
    • +
  • [JAMES-169] - Network-based authorization for SMTP AUTH
    • +
  • [JAMES-171] - Improve support for character encoded subjects in mailing lists
    • +
  • [JAMES-172] - New thread pool implementation
    • +
  • [JAMES-173] - Control number of rows returned in JDBCSpoolRepository
    • +
  • [JAMES-174] - Improve performance on message size
    • +
  • [JAMES-177] - DNS settings autodiscovery
    • +
  • [JAMES-179] - Reduce memory footprint of sql resouces
    • +
  • [JAMES-180] - Faster listing usernames
    • +
  • [JAMES-181] - Better CRLF handling in protocols
    • +
  • [JAMES-183] - Overhauled Redirect mailet
    • +
  • [JAMES-184] - New network matcher classes
    • +
  • [JAMES-188] - Improved error handling in processors
    • +
  • [JAMES-198] - New listserv code.
    • +
  • [JAMES-204] - Upgrade to JavaMail 1.3.1
    • +
  • [JAMES-205] - New database connection pooler
    • +
  • [JAMES-210] - Upgrade to dnsjava 1.4.0
    • +
  • [JAMES-212] - Batch delete from mail repository
    • +
  • [JAMES-214] - Better PID handling
    • +
  • [JAMES-217] - Upgrade to dnsjava 1.4.1
    • +
  • [JAMES-218] - showalias and showforwarding commands
    • +
  • [JAMES-221] - SenderInFakeDomain network setting
    • +
  • [JAMES-222] - Make file mail repository sort FIFO
    • +
  • [JAMES-225] - Upgrade to dnsjava 1.4.2
    • +
  • [JAMES-226] - Simplify connection tracking
    • +
  • [JAMES-227] - Upgrade to dnsjava 1.4.3
    • +
  • [JAMES-228] - Upgrade to DBCP 1.1
    • +
  • [JAMES-232] - JMX exposes more server information
    • +
  • [JAMES-234] - Improved bounce from RemoteDelivery
    • +
  • [JAMES-283] - James should use default backLog value when creating a ServerSocket
    • +
+ + + + + +
    +
  • [JAMES-149] - Add soft-fail to unresolved received from domains
    • +
  • [JAMES-190] - Apache license 2.0
    • +
  • [JAMES-213] - Mail repository throw MessagingException instead of RuntimeException
    • +
  • [JAMES-223] - Remove stack traces to console
    • +
  • [JAMES-252] - Upgrade to dnsjava 1.6.2
    • +
  • [JAMES-277] - Generate mailet.jar as separate from core james.jar
    • +
+ +
+ +
+

Released 12 May 2003

+
    +
  • [NjB] (code) Fixed stream handling in MimeMessageWrapper to address a JavaMail issue introduced in v2.1.2
    • +
  • [NjB] (code) Fixes to AddFooter for text/html parts
    • +
  • [MI,PG,NjB] (code) Fixes to AddFooter for MimeMultipart messages
    • +
  • [NjB] (code) Changed ExtraDotOutputStream to enforce RFC 2821 #2.3.7
    • +
  • [NjB] (code) Corrected allowable characters for localpart of address
    • +
  • [NjB] (update) Removed generated files from source distributions
    • +
  • [PG] (code) Corrrected handling of NNTP messages to avoid character encoding issues
    • +
  • [NjB] (code) James.getId bug - courtesy of Sid Stuart
    • +
  • [KS} (code) Added NNTP linecounting support
    • +
  • [KS} (code) Fixed NNTP authentication
    • +
  • [HJ] (code) Fixed bug 18726 (optional socket factory to specify outgoing bind address)
    • +
  • [NjB] (code) Fixed bug 19418 (changed notify/wait code in spooler)
    • +
  • [NjB] (code) Fixed bug 18307 (NotifySender headers)
    • +
  • [NjB] (code) Fixed bug with non-InternetAddress addresses - courtesy of Steen Jansdal
    • +
  • [NjB] (code) Fixed bug in NotifySender with complex MIME messages
    • +
  • [SK, NjB] (code) Added Delivered-To header in LocalDelivery
    • +
  • [NjB] (code) Fixed Bug 15428 - check for valid user before attempting removal
    • +
+
+ +
+

Released 21 February 2003

+
    +
  • [NjB] (code) Fixed handling of permanent/temporary errors in RemoteDelivery
    • +
  • [NjB] (code) Fixed bug where connect error could cause outgoing mail to be discarded.
    • +
  • [PG] (code) Fixed the bounce() method to add the original message as a message MIME type with an attachment disposition.
    • +
+
+ +
+

Released 11 February 2003

+
    +
  • [KL] (code) SMTP AUTH compatibility change
    • +
  • [NjB] (code) Changed MimeMessageWrapper to use the raw stream when possible
    • +
  • [NjB] (code) Fixed synchronization bug in AvalonMailRepository
    • +
  • [NjB] (update) Updated Avalon LogKit
    • +
  • [NjB] (code) Infinite loops are interruptable
    • +
  • [HB, NjB] (code) Fixed NNTP crossposting
    • +
  • [NjB] (code) Fixed synchronizaion bug in file repository
    • +
  • [NjB] (code) Enabled log rotation
    • +
  • [NjB] (doc) Fixed broken links
    • +
  • [DA, NjB] (update) Updated JavaMail and JAF
    • +
  • [NjB] (code) Updated sqlResources.xml for PostgreSQL with patch from simon
    • +
  • [NjB] (code) Reorder primary key for JDBCMailRepository to optimize queries using just the repository name.
    • +
  • [PG,HB] (code) NNTP dot stuffing fix
    • +
  • [PG] (code) NNTP OVER/XOVER fix
    • +
  • [NjB] (code) Experimental RegexMatcher classes
    • +
+
+ +
+

Released 29 December 2002

+
    +
  • (AK) (doc) Added LDAP RFCs.
    • +
  • (PG) (code) Fixed platform-specific performance issue with the POP3 server delivery.
    • +
  • (PG) (code) Fixed bug where RemoteDelivery did not iterate through all MX records on connect failure.
    • +
  • (PG) (update) Updated James to use the Avalon Framework version 4.1.3.
    • +
  • (PG) (update) Updated James to use Avalon Phoenix version 4.0.1.
    • +
  • (PG) (doc) Added extensive commenting - specifically Javadoced the vast majority of methods.
    • +
  • (PG,AI) (code) Added a James specific abstract Service implementation. Unified configuration, logging, as well as enabling the use of thread pools and socket types on a per service basis.
    • +
  • (NjB) (code) Corrected JDBCMailRepository to obey stated contract.
    • +
  • (NjB,PG) (code) Adjusted service handlers to flush socket output streams to ensure prompt client interactions.
    • +
  • (PG) (code) Adjusted the NNTP server so that it better conforms to the NNTP specification (see bug #13564 for details).
    • +
  • (PG) (code) Corrected a typo that had been disabling NNTP using SSL functionality.
    • +
  • (PG) (code) Corrected an architectural flaw in the NNTP server implemenation that disabled NNTP authentication.
    • +
  • (NjB) (code) Fixed a bug in the GenericListserv subject normalization. Neatened the code to make later modifications easier.
    • +
  • (BW) (code) Fixed a bug in the RemoteDelivery mailet that caused the mailet to unnecessarily split the recipient list when using a gateway.
    • +
  • (NjB,PG) (code) Added object pooling for service handlers to substantially improve performance.
    • +
  • (AI,PG) (code) Added a new Watchdog interface to effectively support connection timeouts. An implementation of the interface was added that uses a second thread per connection to ensure timeouts.
    • +
  • (NjB,PG) (code) Resolved a memory leak in the source - a list of files to be deleted was being maintained that was unnecessary. The file to be deleted is now deleted immediately after it is no longer needed.
    • +
  • (PG) (code) Changed the code to ensure that all thread pool threads are returned to the thread pool in a non-interrupted state.
    • +
  • (PG) (code) Centralized the file/directory lookup code inside James and fixed it so that it handled absolute URLs properly.
    • +
  • (AI,PG) (code) Added a more substantial connection manager. This connection manager allows us to limit the maximum number of client connections per server socket. It also allows us to set the socket timeout for client sockets explicitly.
    • +
  • (DA,PG) (code) Added enabled/disabled switch to main server components.
    • +
  • (DA) (code) Added new FetchPOP functionality, to allow James to consolidate mail from a number of POP3 servers in a single server.
    • +
  • (DA) (doc) Added documentation to demonstrate how to configure James as a universal sendmail relay.
    • +
  • (NjB) (code) Made subject prefix bracketing in GenericListserv configurable.
    • +
  • (NjB) (code) Added the HasHeader matcher.
    • +
  • (NjB) (code) Added the JDBCVirtualUserTable mailet.
    • +
  • (NjB) (code) Enhanced the RemoteAddrInNetwork and RemoteAddrNotInNetwork to accept domain names.
    • +
  • (PG) (update) Fixed the log configuration so that AM and PM entries are properly distinguishable by default.
    • +
  • (NjB) (code) Added a configurable debug parameter to several mailets to allow a more granular control of debug logging.
    • +
  • (NjB) (code) Added the Habeas warrant mailet and matcher.
    • +
  • (NjB,PG) (update) Changed the server configuration to default log at INFO level. Adjusted logging statements so that they are log level appropriate.
    • +
  • (PG) (code) Fixed a critical bug in the dbfile implementation. Fixed repository implementation so that db repositories do not behave as dbfile repositories.
    • +
  • (NjB) (code) Fixed MimeMessageWrapper so that mail headers are properly updated when headers are set on the wrapper.
    • +
  • (PG) (code) Added UNSETFORWARDING functionality to the RemoteManager.
    • +
  • (PG) (code) Closed an open relay hole involving an empty Sender header.
    • +
  • (PG) (code) Fixed Oracle specific bug that limited us to messages of 4K or less in the repository.
    • +
  • (SS,NjB,PG) (code) Ensured that a number of database and I/O resources are properly closed under all conditions.
    • +
  • (NjB) (code) Changed default column sizes for JDBC repositories to be RFC compliant.
    • +
  • (NjB) (code) Fixed exception handling in JdbcDataSource when getConnection() fails.
    • +
  • (PG) (code) Fixed NotifySender/NotifyPostmaster to be more robust against ill-formed headers in the email being forwarded.
    • +
  • (SD,SS3) (code) Made a substantial performance enhancement to the LinearProcessor such that mail changes are not persisted to the store until necessary. Also reduced synchronization scope.
    • +
  • (PG) (code) Converted String concatenation to the use of StringBuffers throughout the code base.
    • +
  • (PG) (code) Fixed date formatting to be thread safe.
    • +
  • (NjB) (code) Fixed InSpammerBlacklist
    • +
  • (PH) (update) Upgrade James to the Avalon 4.0/4.1 actual releases.
    • +
  • (NjB,SK) (update) Fixed MailImpl.duplicate to include remote addr, remote host, and last updated fields.
    • +
  • (CB2) (update) Fixed NNTP server bug where the NEXT command was not being properly dispatched and handled.
    • +
  • (SK) (update) Cleaned up error handling in LocalDelivery.
    • +
  • (SS2) (code) Changed the default configuration so that log files are appending by default.
    • +
  • (SS2) (update) Reported the lack of in.close in MimeMessageSource.getSize(), which was causing stranded file handles, especially during large POP3 sessions.
    • +
  • (AI) (update) Matcher config implementation object now properly set with matcher name.
    • +
+
+
+

Released 20 April 2002

+
    +
  • (DA) (update) Fixed POP3 message size bug that prevented retrieval
    • +
  • (SK) (code) FileRepository should no longer produce 0-byte files. It checks that the source is different than the target, or confirm it is in memory before saving to disk.
    • +
  • (SK) (update) Removed check that connection is not closed before returning it. The pooler is already confirming the connection was open before putting it in the pool, so this was a big unnecessary performance drain.
    • +
  • (SK) (update) Fixed the delay in the JDBC mail spool repository as it wasn't rechecking correctly after it emptied the spool.
    • +
  • (SS2) (code) Added dot-stuffing in POP3 message delivery to fix problems with Netscape and other mail clients and to comply with RFC.
    • +
  • (JK) (code) Fixed bounce method to use the Return-Path header if there is one.
    • +
  • (SK) (update) Improved handling of delivery error messages when the remote server returns a specific 5XY complaint.
    • +
  • (SK) (code) Better diagnosing of temporary vs. permanent delivery exceptions, most notably "Could not connect to host.." is a temporary exception.
    • +
  • (SK) (code) Remote SMTP delivery now sets the remote hostname using the servername configuration setting (uses the first one).
    • +
  • (SK) (update) Have it cleanly (not print stack trace) if the remote manager handler has io/socket exceptions.
    • +
  • (SK) (update) Support in "IsSenderInFakeDomain" to handle null senders properly (was producing a false positive in this case).
    • +
  • (PH) (update) Added releaseConnection method to BaseConnectionHandler as per Paul H's bug report.
    • +
  • (SK) (update) Reordered 250 SMTP responses to fix Mac client issue per Giles Chanot's bug report.
    • +
+
+ +
+

Released 1 December 2001

+
    +
  • (*) (update) Moved to Avalon snapshot of November 2001
    • +
  • (DA) (update) Fixed POP3 message size bug that prevented retrieval
    • +
  • (SK) (code) Added Mordred database connection pooling. It is the marriage of Town's db pooling code and Excalibur's configuration.
    • +
  • (SK) (update) Changed MailImpl.getSize() to getMessageSize() and from int to long.
    • +
  • (SK) (docs) Small updates to documentation
    • +
  • (SK) (code) Added JDBCListserv, straight JDBC implementation of old TownListserv that extends GenericListserv
    • +
  • (SK) (update) Patched bug in GenericListserv for when subject was null
    • +
  • (SK) (update) Got mailets/matchers to load from something besides james.bar
    • +
  • (SK) (code) Added scheduler notification during SMTP DATA reception and POP3 RETR sending so the connection handler doesn't time out connection while data is being transfered.
    • +
  • (SK) (code) Support <gatewayPort> setting on RemoteDelivery to send all messages to a non-port 25 SMTP server. Only makes sense when <gateway> is also set.
    • +
  • (EP) (update) Used getAsBooleanValue in various configuration methods to make code more readable.
    • +
  • (SS) (update) Added support for Oracle database for mail and spool JDBC repositories.
    • +
+
+ +
+

Released 26 October 2001

+
    +
  • (CB,*) (update) Moved to Avalon snapshot of 9-25-2001.
    • +
  • (HB) (code) Added NNTP service.
    • +
  • (SK) (update) Greatly improved multi-threading support for repositories and SMTP reception.
    • +
  • (JB) (code) SMTP AUTH support
    • +
  • (SK) (update) Support null senders, i.e., MAIL RCPT: <>.
    • +
  • (DD,SK) (update) Converted Town mail and user repositories to straight JDBC ones, using Excalibur connection pooling and configurable SQL statements per DB.
    • +
  • (SK) (update) Messages are no longer loaded until absolutely necessary.
    • +
  • (GB) (update) Fixed exception being thrown on MailAddress parsing.
    • +
  • (CB) (update) Rebuilt CVS tree after hack and moved src to src/java.
    • +
  • (DA) (code) New extensible, flexible Redirect mailet that handles notifications and forwarding.
    • +
  • (SK) (code) JDBC Alias mailet.
    • +
  • (various) (docs) Added a whole bunch of related RFCs to the webdocs.
    • +
  • (DA) (update) Add date to bounced emails.
    • +
  • (HB) (update) Updated DNS library and started process to move it to Avalon service.
    • +
  • (various) (update) More checks to fix "stuck file" problem in Avalon mail repository.
    • +
  • (MP) (code) Limit the size of a message on reception (rather than waiting until processors).
    • +
  • (SK) (update) Fixed dot-stuffing in SMTP reception/delivery.
    • +
  • (SK) (update) Improved how Return-Path and Received headers are generated during SMTP reception.
    • +
  • (SK) (update) More efficient remote delivery code, better error messages, and gateway parameter to route all messages to a single target.
    • +
  • (DA) (update) Fixed timezone bug in RFC822DateFormat
    • +
  • (MP) (update) Patch to support username@[yyy.yyy.yyy.yyy] addresses
    • +
  • (GB) (update) Patch to fix size calculation from headers
    • +
  • (RS) (image) Contributed James logo
    • +
  • (SK) (update) Changed MailetException to extend MessagingException, and Mailet.init() throws MailetException.
    • +
+
+ +
+

Released 13 December 2000

+
    +
  • (SK,SR,CB) (update) Fix for "stuck file" problem in Avalon mail repository.
    • +
  • (SK) (design) Made usernames case insensitive on MailAddress
    • +
  • (SK) (code) Complete rewrite of processor code to send through Mail object through matchers and mailets. Design might be less efficient but easier to understand and more flexible for later improvements to API. Also no longer "loses" IP address and error message information when Mail object go from one processor/state to the next (ToProcessor changed as well now that processor works).
    • +
  • (SK) (update) Updated to JavaMail 1.2
    • +
  • (SK) (update) Changed instantiation of recipients on a Mail object to a Set (HashSet) whenever possible in preparation for the API having this change.
    • +
  • (IS) (code) Added UsersTownRepository to let you maintain user lists in a database
    • +
  • (SR) (update) In POP3 handler, properly includes headers in calculating size of messages.
    • +
  • (SK) (update) Removed "synchronized" attribute on many methods in town and file spool repositories. Should significantly boost performance and multithreaded capabilities.
    • +
  • (SK) (code) Optimization of town mail repository, introduction of JamesMimeMessageInputStream and the James MimeMessage. Should significantly reduce the number of unnecessary parses or saves on MimeMessages in server.
    • +
  • (SR) (update) Properly calculates hashCode for MailAddress so duplicates do not exist in Hashmaps
    • +
  • (SR) (update) Hardcoded serialVerUID on MailAddress and MailImpl to that of James 1.2 release so future releases can continue to use mail stored in earlier releases.
    • +
  • (IS) (update) Added ability on NotifySender and NotifyPostmaster to attach informative notice.
    • +
  • (SK) (update) GenericListservManager now requires existsAddress() which it uses to prevent someone already on the list from subscribing or someone not on the list from removing themselves.
    • +
  • (SK) (update) Changed User repository for file to *always* end the destination with a File.separator. Otherwise if people mixed usage of this, it would crash the repositories with confusing error messages. Child repositories were already properly created with a terminating File.separator.
    • +
  • (SK) (code) New matcher: IsSingleRecipient
    • +
  • (SK) (code) Added spam blacklist checking for 3 spam blacklists that make this available in a simple DNS lookup check. All free services through mail-abuse.org. Added to default configuration in config.xml
    • +
  • (PU) (code) Added first testing program. This would recreate file stuck problem. Would be good to build collection of testing utilities in this new package.
    • +
  • (SK) (docs) Documented what all the jars are in the lib directory (what they're called, where they're from)
    • +
+
+ +
+

Released 16 October 2000

+
    +
  • (SK) (design) Abstracted mailet API to be Avalon (implementation) independent
    • +
  • (CB) (code) Abstracted mail repository in JAMES/Avalon to allow more varied implementations.
    • +
  • (SK) (code) Database implementations of mail repositories
    • +
  • (SK) (code) Changed remote delivery to use an outgoing spool with a specified number of delivery threads
    • +
  • (CB) (code) Experimental implementation of LDAP user manager
    • +
  • (SK) (update) Reworked mailets and matchers to fit new API and added many more classes
    • +
  • (CB, SK) (update) Fixed some bugs in POP3 server
    • +
  • (CB) (update) Added full TLS support in POP3 (POP3S)
    • +
  • (SK) (update) Fixed sorting of MX records so it attempts delivery in correct order
    • +
  • (SK) (update) Changed remote manager to not allow a login if an admin account's password is empty, + and sets the root account's password empty by default (so you have to set one... prevents someone + from knowing the password to your system out of the box)
    • +
+
+
+

Release 27 July 2000

+
    +
  • (??) (code) Unknown changes
    • +
  • (SK) (code) Made DNS functionality a separate block
    • +
+
+ +
+

Released 26 February 2000

+
    +
  • (SK, FB) (code) Added DNS stuff to remote delivery.
    • +
  • (FB) (code) Add some autodetect support for easier configuration.
    • +
  • (FB) (code) Add support for Mailet.
    • +
  • (FB) (update) Add Mailet interface draft.
    • +
+
+ +
+

Released early 2000

+
    +
  • (FB) (update) Split the SMTP Server in a protocol handler and a MailServer available to + all Avalon blocks.
    • +
  • (FB) (update) Tune MessageContainer class.
    • +
+
+ +
+

Unknown release date

+
    +
  • (FB) (update) Based on much code from Serge Knystautas first implementation of JAMES on + top of the Avalon framework.
    • +
+
+ +
+

Check out our Who We Are page to see who to thank.

+
+ + + diff --git a/server/2.2.0/src/site/xdoc/custom_mailet.xml b/server/2.2.0/src/site/xdoc/custom_mailet.xml new file mode 100644 index 00000000000..3a9dab66755 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/custom_mailet.xml @@ -0,0 +1,117 @@ + + + + + + James 2.1 - Writing a Custom Mailet + + + +
+

Implementing a custom mailet is generally a simple task, most of whose complexity +lies in coding the actual work to be done by the mailet. This is largely due to the +simplicity of the Mailet interface and the fact that a GenericMailet class is provided +as part of the Mailet package.

+

In this discussion we will assume that any mailet being implemented is a subclass of +GenericMailet. The GenericMailet class serves to abstract away of the configuration and +logging details. While it provides a noop implementation of the init() and destroy() methods, +these can be easily overridden to provide useful functionality.

+

In general, the only four methods that you should need to implement are init(), destroy(), +getMailetInfo(), and service(Mail). And only the last is required in all cases.

+ +

As described in the SpoolManager configuration +section, mailets are configured with a set of String (name, value) pairs. These values are +passed into the Mailet upon initialization (although the details of this process are hidden by +the GenericMailet implementation). GenericMailet provides access to this configuration +information through use of the getInitParameter(String) method. Passing in the name of the +requested configuration value will yield the value if set, and null otherwise. Configuration +values are available inside the init(), destroy(), and service(Mail) methods.

+ + +

There is a simple logging mechanism provided by the Mailet API. It does not support +logging levels, so any log filtering will have to be implemented in the Mailet code. +Logging is done by calling one of the two logging methods on GenericMailet - log(String) +or log(String,Throwable). Logging is available inside the init(), destroy(), and service(Mail) +methods.

+

The value of getMailetInfo() for the Mailet is prepended to the log entries for that +Mailet. So it may be desirable for you to override this method so you can distinguish mailet +log entries by Mailet.

+ + +

As part of the Mailet lifecycle, a Mailet is guaranteed to be initialized immediately after +being instantiated. This happens once and only once for each Mailet instance. The +Initialization phase is where configuration parsing and per-Mailet resource creation generally +take place. Depending on your Mailet, it may or may not be necessary to do any initialization +of the mailet. Initialization logic is implemented by overriding the init() method of +GenericMailet.

+ + +

The bulk of the Mailet logic is expected to be invoked from the service(Mail) method. This +method is invoked each time a mail message is to be processed by the mailet. The message is +passed in as an instance of the Mail interface, which is part of the Mailet API.

+

The Mail interface is essentially a light wrapper around JavaMail's MimeMessage class with a +few important differences. See the Javadoc for the interface for a description of the additional +methods available on this wrapper.

+ + +

As part of the Mailet lifecycle, a Mailet is guaranteed to be destroyed when the container +cleans up the Mailet. This happens once and only once for each Mailet instance. The +Destruction phase is where per-Mailet resource release generally takes place. Depending +on your Mailet, it may or may not be necessary to do any destruction +of the mailet. Destruction logic is implemented by overriding the destroy() method of +GenericMailet.

+ +
+
+

Once a Mailet has been successfully implemented there are only a couple of +additional steps necessary to actually deploy the Mailet.

+ +

+The Mailet must be added to James' classpath so that the Mailet can be loaded by James. There +are two ways to add a custom Mailet to the classpath so that James will be able to load the +Mailet. These are: +

+

+1. Download the source distribution, add a jar file containing the custom files to the lib +directory of the unpacked source distribution, and build a new .sar file by following the +directions here. This new .sar file will now +include your custom classes. +

+

+or +

+

+2. Place a jar file containing the custom class files in the lib subdirectory of the James +installation. It will also be necessary to unpack the JavaMail and James jar files from +the provided .sar file and add them to this directory. +

+ + +

Configuration of the processor chain is discussed +elsewhere in this documentation. The +details of configuring mailet deployment is discussed at length. Here we will only comment +that it is important to add the appropriate mailet package for your custom mailet to the +<mailetpackages> list and that the name of your mailet should not conflict with any of +the mailets described here. +

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/custom_matcher.xml b/server/2.2.0/src/site/xdoc/custom_matcher.xml new file mode 100644 index 00000000000..b590166b76b --- /dev/null +++ b/server/2.2.0/src/site/xdoc/custom_matcher.xml @@ -0,0 +1,128 @@ + + + + + + James 2.1 - Writing a Custom Matcher + + + +
+

Implementing a custom matcher is generally a simple task, most of whose complexity +lies in coding the actual work to be done by the matcher. This is largely due to the +simplicity of the Matcher interface and the fact that a couple of abstract Matcher template +classes are provided in the Mailet package. These two classes, GenericMatcher and +GenericRecipientMatcher, greatly simplfy the task of Matcher authoring.

+

As discussed elsewhere in this manual, the Matcher interface does not simply match +or not match a particular message. Rather, it returns some subset of the original message +recipients as a result of the match(Mail) method. This leads to the two different abstract +Matcher implementations.

+

The first, GenericMatcher, is intended for matchers where recipient evaluation is not +necessary. Basically, you should subclass this implementation if your matcher is going to +return all or none of the recipients.

+

When subclassing this class, there are four methods that potentially need to be +overridden. These are getMatcherInfo(), init(), match(Mail), and destroy(). More on these +anon.

+

The second implementation, GenericRecipientMatcher, is intended for those matchers where +each recipient is evaluated individually. It is a subclass of GenericMatcher, and inherits +most of its behavior from that class. The only major difference is that subclasses are +expected to override matchRecipient(MailAddress) rather than match(Mail).

+ +

Matchers are passed a single String as part of their configuration. Interpretation of this +list is left entirely to the body of the Matcher. This String value is available in +the body of the Matcher through use of the getCondition() method of the +GenericMatcher class. This method returns the String value passed to the Matcher, and returns +null if no value is set. The method getCondition() is available inside the init(), destroy(), match(Mail), +and matchRecipient(MailAddress) methods.

+ + +

There is a simple logging mechanism provided by the Mailet API. It does not support +logging levels, so any log filtering will have to be implemented in the Matcher code. +Logging is done by calling one of the two logging methods on GenericMatcher/GenericRecipientMatcher - log(String) +or log(String,Throwable). Logging is available inside the init(), destroy(), match(Mail), +and matchRecipient(MailAddress) methods.

+

The value of getMatcherInfo() for the Matcher is prepended to the log entries for that +Matcher. So it may be desirable for you to override this method so you can distinguish Matcher +log entries by Matcher.

+ + +

As part of the Matcher lifecycle, a Matcher is guaranteed to be initialized immediately after +being instantiated. This happens once and only once for each Matcher instance. The +Initialization phase is where configuration parsing and per-Matcher resource creation generally +take place. Depending on your Matcher, it may or may not be necessary to do any initialization +of the Matcher. Initialization logic is implemented by overriding the init() method of +GenericMatcher/GenericRecipientMatcher.

+ + +

It is the matching phase where the Matcher's work is done. The exact form of this phase largely +depends on which Matcher superclass is subclassed.

+

If GenericMatcher is being subclassed, it is the match(Mail) that is implemented. As described +above, this method returns a Collection of MailAddresses that is a subset of the original +recipients for the Mail object.

+

If it is a purely recipient-filtering Matcher, then the GenericRecipientMatcher should be +subclassed. In this case, developers must provide an implementation of the +matchRecipient(MailAddress) method. This method returns true if the recipient matches, +and false otherwise.

+ + +

As part of the Matcher lifecycle, a Matcher is guaranteed to be destroyed when the container +cleans up the Matcher. This happens once and only once for each Matcher instance. The +Destruction phase is where per-Matcher resource release generally takes place. Depending +on your Matcher, it may or may not be necessary to do any destruction +of the Matcher. Destruction logic is implemented by overriding the destroy() method of +GenericMatcher/GenericRecipientMatcher.

+ +
+
+

Once a Matcher has been successfully implemented there are only a couple of +additional steps necessary to actually deploy the Matcher.

+ +

+The Matcher must be added to James' classpath so that the Matcher can be loaded by James. There +are two ways to add a custom Matcher to the classpath so that James will be able to load the +Matcher. These are: +

+

+1. Download the source distribution, add a jar file containing the custom files to the lib +directory of the unpacked source distribution, and build a new .sar file by following the +directions here. This new .sar file will now +include your custom classes. +

+

+or +

+

+2. Place a jar file containing the custom class files in the lib subdirectory of the James +installation. It will also be necessary to unpack the JavaMail and James jar files from +the provided .sar file and add them to this directory. +

+ + +

Configuration of the processor chain is discussed +elsewhere in this documentation. The +details of configuring matcher deployment is discussed at length. Here we will only comment +that it is important to add the appropriate matcher package for your custom matcher to the +<matcherpackages> list and that the name of your matcher should not conflict with any of +the matchers described here. +

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/dns_configuration.xml b/server/2.2.0/src/site/xdoc/dns_configuration.xml new file mode 100755 index 00000000000..2405840f245 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/dns_configuration.xml @@ -0,0 +1,59 @@ + + + + + + James 2.1 - Configuring DNS Services + + + +
+ + +

DNS Transport services are controlled by a configuration block in +the config.xml. This block affects SMTP remote delivery.

+ +

The dnsserver tag defines the boundaries of the configuration +block. It encloses all the relevant configuration for the DNS server. +The behavior of the DNS service is controlled by the attributes and +children of this tag.

+ +

The standard children of the dnsserver tag are:

+
    +
  • servers - This is a list of DNS Servers to be used by James and are +specified by one, or more server elements, which are child elements. +Each server element is the IP address of a single DNS server. + +<servers> + <server>127.0.0.1</server> + <server>166.181.194.205</server> +</servers> + +
    • + +
  • authoritative - (true/false)This tag specifies whether or not +to require authoritative (non-cached) DNS records; to only accept DNS responses that are +authoritative for the domain. It is primarily useful in an intranet/extranet environment. +

    This should always be false unless you understand the implications.

    +
    • +
+
+ + diff --git a/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml b/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml new file mode 100755 index 00000000000..512e7de1b52 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml @@ -0,0 +1,967 @@ + + + + + James 2.2 - fetchmail Configurartion + + + +
+

fetchmail acts as a gateway between an external message store such as an IMAP +or POP3 server and James. Mail is fetched from the external message store and +injected into the James input spool.

+ +

fetchmail is useful when delivery via standard SMTP is not an option, as a +means of consolidating mail delivered to several external accounts into a single +James account, or to apply the mail processing capabilities of James to mail +stored in an external message store.

+ +

fetchmail has several configuration options that control the fetching and +filtering of mail injected into the James input spool. Once there, James' +flexible mail processing engine can be used to further process the mail, just as +if it had been delivered via standard SMTP.

+ +

+How fetchmail Works
+fetchmail Configuration Parameters
+fetchmail Examples
+fetchmail Caveats +

+
+ +
+

Mail is delivered by periodically running fetch tasks that read messages from +an external message store and injects them into the James input spool. Fetch +tasks run concurrently.

+ +

A set of filters applies to each fetch task. Each filter provides the ability +to reject a message that matches the filter criteria. Rejected messages are not +injected into the James input spool; they are either marked as seen or deleted. +When a filter is configured to accept a message that matches its criteria, +messages are marked with a MailAttribute. This MailAttribute can be detected +within the James matcher/mailet chain, allowing further processing as +required.

+ +

Each fetch task is associated with a single host server. Accounts are defined +to the fetch task for each mailbox on the server from which mail is to be +fetched. Accounts run consecutively.

+ +

Optionally, the fetch task can be configured with an <alllocal> Account that +generates an Account entry for each user defined in the James user repository. +This removes the requirement to manually add or remove Account entries to the +fetchmail configuration each time a James user is added or removed. Currently +this is only useful if the server supports virtual mailboxes that allow the same +password to apply to all users within a domain.

+ +

Accounts can be configured to deliver all mail for an Account to a specified +recipient or to deduce the intended recipient from the mail headers.

+ +

Accounts are normally configured to deliver all mail for an Account to a +specified recipient, ignoring the recipient in the mail headers. This works well +in the majority of cases where a mailbox is guaranteed to contain mail for a sole +mailbox recipient.

+ +

Accounts are configured to deduce the intended recipient from the mail headers +when a mailbox contains mail for several users, typically all users in a domain. +Used alone, this is not foolproof as there are circumstances when a single unique +recipient cannot be deduced from the mail headers alone. Used in conjunction with +an appropriately configured <alllocal> account, it is always possible to deduce +the intended recipient when the recipient is a James user.

+
+ +
+

The fetchmail configuration parameters are part of the James configuration, +whose base file is config.xml. For clarity and flexibility, the +fetchmail configuration parameters are stored in the file +james-fetchmail.xml, which is referenced within +config.xml.

+ +

The configuration parameters are described below.

+ + +

The configuration block delimited by the fetchmail tag +controls fetchmail.

+ +

The tag has these attributes: +

+
enabled
+
A boolean. If "true", the fetch tasks will be run periodically. If "false", +no fetch tasks will be run. The default is "false".
+
+

+ +

The tag has these child tags (minimum cardinality, maximum cardinality): +

+

+ +

+ +<fetchmail enabled="true"> +... +</fetchmail> + +

+ + + +

The fetch tag defines a fetch task to be run +periodically. Fetch tasks run concurrently.

+ +

The tag has these attributes: +

+
name
+
A string uniquely identifying the fetch task.
+
+

+ +

The tag has these child tags (minimum cardinality, maximum cardinality): +

+

+ +

+ +<fetch name="mydomain.com"> +... +</fetch> + +

+ + + +

The accounts tag declares the accounts from which mail will +be fetched by the fetch task. Accounts run concurrently.

+ +

The tag has these child tags (minimum cardinality, maximum cardinality): +

+

+ +

+ +<accounts> +... +</accounts> + +

+ + + +

The blacklist tag declares a list of recipient addresses +for whom mail will be rejected and what happens to the rejected mail.

+ +

The tag value is a tab, comma or space delimited list of recipient +addresses, eg: wibble@mydomain.com, flobble@mydomain.com.

+ +

The tag has these attributes: +

+
reject
+
A boolean. If "true", mail for recipients in the blacklist will +not be injected into the James input spool. If "false", mail for +recipients in the blacklist will be injected into the James input spool with the +Mail Attribute org.apache.james.fetchmail.isBlacklistedRecipient +added to the mail.
+
leaveonserver
+
A boolean. If "true", mail for recipients in the blacklist will be +left on the server. If "false", mail for recipients in the blacklist +will be marked for deletion.
+
markseen
+
A boolean. If "true", mail for recipients in the blacklist will be +marked as seen on the server. If "false", mail for recipients in the blacklist +will not be marked as seen.
+
+

+ +

+ +<blacklist + reject="true" + leaveonserver="true" + markseen="true"> +wibble@mydomain.com, flobble@mydomain.com +</blacklist> + +

+ + + +

The defaultdomain tag declares the domain name to be +appended to the From: header of a mail that has a valid user part +but is missing the domain part.

+ +

If not specified, the default behaviour is to append the canonical host name +of the James server.

+ +

The tag value is the name of the server to append. The name must be a server +declared in the servernames tag of the James +block in the configuration or the name localhost.

+ +

+ +<defaultdomain> + mydomain.com +</defaultdomain> + +

+ + + +

The fetchall tag declares if all mail should be fetched from +the server, or just unseen mail.

+ +

The tag value is a boolean. If true, all mail is fetched. If false, only +unseen mail is fetched.

+ +

+ +<fetchall>false</fetchall> + +

+ + + +

The fetched tag declares what will happen to mail on the +external server that is successfully injected into the James input spool.

+ +

The tag has these attributes: +

+
leaveonserver
+
A boolean. If "true", mail injected into the James input spool +will be left on the server. If "false", mail injected into the James +input spool will be marked for deletion.
+
markseen
+
A boolean. If "true", mail injected into the James input spool +will be marked as seen on the server. If "false", mail injected into +the James input spool will not be marked as seen.
+
+

+ +

+ +<fetched leaveonserver="true" markseen="true"/> + +

+ + + +

The host tag declares the IP address of the external +server from which mail is fetched.

+ +

The tag value is the DNS name or IP address literal of the external +server.

+ +

+ +<host>pop3.server.com</host> + +

+ + + +

The interval tag declares the period between invocations of +the fetch tasks. If a fetch task is still active from a previous invocation +when the period expires, the new invocation is skipped over.

+ +

The tag value is an integer representing the number of milliseconds to elapse +between invocations of the fetch tasks.

+ +

+ +<interval>60000</interval> + +

+ + + +

The javaMailFolderName tag declares the name of the root +folder on the external server from which mail is fetched.

+ +

The tag value is the cAsE-sEnSiTiVe name of the root folder on the external +server from which mail is fetched. For POP3 servers this is always +INBOX.

+ +

+ +<javaMailFolderName>INBOX</javaMailFolderName> + +

+ + + +

The javaMailProperties tag declares the properties to be +applied to the JavaMail Session used by the fetch task. These override the +properties answered by System.getProperties(). Many JavaMail +properties are specific to the JavaMail Provider selected by the +javaMailProviderName tag.

+ +

Relying on the default values selected by the Provider can be +inappropriate. For instance, the default connection and I/O timeout +values of infinite for the default IMAP and POP3 Providers is rarely what is +required. Consult the documentation of the Provider for details and options.

+ +

Documentation for the default Provider for IMAP is located + +here.

+ +

Documentation for the default Provider for POP3 is located + +here.

+ +

Details of how to change a Provider are located + +here.

+ +

The tag has these child tags (minimum cardinality, maximum cardinality): +

+

+ +

+ +<javaMailProperties> +... +</javaMailProperties> + +

+ + + +

The javaMailProviderName tag selects the JavaMail protocol +Provider used to interact with the external server.

+ +

The tag value is the name of a JavaMail supported protocol, such as +pop3 or imap. The name is used to select the default +Provider for the protocol.

+ +

+ +<javaMailProviderName>pop3</javaMailProviderName> + +

+ + + +

The maxmessagesize tag declares the maximum permitted message +size for messages injected into the James input spool and what happens to fetched +messages that exceed this size.

+

The tag has these attributes: +

+
limit
+
An integer. The maximum message size expressed in Kilobytes. If 0, there is +no limit.
+
reject
+
A boolean. If "true", mail whose message size exceeds the maximum +permitted size will not be injected into the James input spool. If +"false", mail whose message size exceeds the maximum permitted size will +have its contents removed, an explanatory error message and the Mail Attribute +org.apache.james.fetchmail.isMaxMessageSizeExceeded added prior to +injection into the James input spool, (see below for the location of an example).
+
leaveonserver
+
A boolean. If "true", mail whose message size exceeds the maximum +permitted size will be left on the server. If "false", mail whose message +size exceeds the maximum permitted size will be marked for deletion.
+
markseen
+
A boolean. If "true", mail whose message size exceeds the maximum +permitted size will be marked as seen on the server. If "false", +mail whose message size exceeds the maximum permitted size will not be marked as +seen.
+
+

+ +

+ +<maxmessagesize + limit="4096" + reject="false" + leaveonserver="false" + markseen="false"/> + +

+ +

An example configuration using James mailet processing to bounce fetched +messages that exceed the maximum permitted size can be found in the file +$PHOENIX_HOME/apps/james/conf/samples/fetchmail/maxMessageSize.xml. +

+ + + +

The recipientnotfound tag declares what happens to mail for +which a sole intended recipient cannot be found when attempting to determine +the recipient from the mail headers.

+ +

In configurations with more than one account per fetch task, processing of +matched mail can be deferred to the next run of the fetch task. This gives +other accounts that may be able to determine a sole intended recipient an +opportunity to do so before recipientnotfound processing is invoked.

+ +

The tag has these attributes: +

+
defer
+
A boolean. If "true", mail for which a sole intended recipient +cannot be determined is left unprocessed until the next run of the fetch task. +If "false", mail for which a sole intended recipient cannot be +determined is processed immediately.
+
reject
+
A boolean. If "true", mail for which a sole intended recipient +cannot be determined will not be injected into the James input spool. If +"false", mail for which a sole intended recipient cannot be +determined will be injected into the James input spool using the recipient +attribute of the current account and with the Mail Attribute +org.apache.james.fetchmail.isRecipientNotFound added to the +mail.
+
leaveonserver
+
A boolean. If "true", mail for which a sole intended recipient +cannot be determined will be left on the server. If "false", mail for +which a sole intended recipient cannot be determined will be marked for +deletion.
+
markseen
+
A boolean. If "true", mail for which a sole intended recipient +cannot be determined will be marked as seen on the server. If "false", +mail for which a sole intended recipient cannot be determined will not be marked +as seen.
+
+

+ +

+ +<recipientnotfound + defer="true" + reject="true" + leaveonserver="true" + markseen="true"/> + +

+ + + +

The recursesubfolders tag declares if mail should be fetched +from sub-folders of the root folder, or just the root folder.

+ +

The tag value is a boolean. If true, mail is fetched from the root folder and +its subfolders. If false, mail is fetched from just the root folder.

+ +

+ +<recursesubfolders>false</recursesubfolders> + +

+ + + +

The remoteReceivedHeader tag declares the zero based +index of the RFC2822 compliant RECEIVED header used to determine the address and +host name of the remote MTA that sent a fetched message and what happens to +messages when the specified header is invalid.

+ +

Typically, the first (index = 0) RECEIVED header is for the local MTA that +delivered the message to the message store and the second (index = 1) RECEIVED +header is for the remote MTA that delivered the message to the local MTA. When +this configuration applies, the remoteReceivedHeaderIndex should +be set to 1. +

+ +

To verify the correct setting, examine the RECEIVED headers for messages +delivered to the configured message store and locate the first one containing a +remote domain in the'from' field. Remembering that zero based indexing is used, +if this the second header, use an index of 1, if this is the third header, use an +index of 2, and so forth.

+ +

Matchers such as InSpammerBlacklist use the remote address and/or remote host +name to identify illegitimate remote MTAs. If you do not use such matchers, the +remoteReceivedHeaderIndex tag may be omitted or the default +index value of -1 can be specified. This causes the remote address to be set to +127.0.0.1 and the remote host name to be set to +localhost. Matchers almost always considered these values to be +legitimate.

+ +

The tag has these attributes: +

+
index
+
An integer whose meaning is described above. +
+
reject
+
A boolean. If "true", mail whose specified recieved header is invalid +will not be injected into the James input spool. If "false", mail whose +specified recieved header is invalid will be injected into the James input spool with +the Mail Attribute org.apache.james.fetchmail.isInvalidReceivedHeader +added to the mail, the remote address set to 127.0.0.1 and the remote +host name set to localhost. +
+
leaveonserver
+
A boolean. If "true", mail whose specified recieved header is invalid +will be left on the server. If "false", mail whose specified recieved header +is invalid will be marked for deletion.
+
markseen
+
A boolean. If "true", mail whose specified recieved header is invalid +will be marked as seen on the server. If "false", mail whose specified +recieved header is invalid will not be marked as seen.
+
+

+ +

+ +<remoteReceivedHeader + index="1" + reject="true" + leaveonserver="true" + markseen="true"/> + +

+ +

An example configuration using James mailet processing to notify the postmaster +of fetched messages that contain an invalid Received header can be found in the file +$PHOENIX_HOME/apps/james/conf/samples/fetchmail/remoteReceivedHeader.xml. +

+ + + +

The remoterecipient tag declares what happens to mail for +which the domain part of the recipient is remote. A domain is remote if it is +not a server declared in the servernames tag of the +James block in the configuration.

+ +

The tag has these attributes: +

+
reject
+
A boolean. If "true", mail for remote recipients will not be +injected into the James input spool. If "false", mail for remote +recipients will be injected into the James input spool with the Mail Attribute +org.apache.james.fetchmail.isRemoteRecipient added to the mail. +
+
leaveonserver
+
A boolean. If "true", mail for remote recipients will be left on +the server. If "false", mail for remote recipients will be marked for +deletion.
+
markseen
+
A boolean. If "true", mail for remote recipients will be marked as +seen on the server. If "false", mail for remote recipients will not be +marked as seen.
+
+

+ +

+ +<remoterecipient + reject="true" + leaveonserver="true" + markseen="true"/> + +

+ + + +

The undeliverable tag declares what happens to mail that +cannot be delivered.

+ +

The tag has these attributes: +

+
leaveonserver
+
A boolean. If "true", mail that cannot be delivered will be left +on the server. If "false", mail that cannot be delivered will be +marked for deletion.
+
markseen
+
A boolean. If "true", mail for that cannot be delivered will be +marked as seen on the server. If "false", mail that cannot be +delivered will not be marked as seen.
+
+

+ +

+ +<undeliverable + leaveonserver="true" + markseen="true"/> + +

+ + + +

The userundefined tag declares what happens to mail for +which the recipient is not defined as a James user.

+ +

The tag has these attributes: +

+
reject
+
A boolean. If "true", mail for recipients who are not defined as +James users will not be injected into the James input spool. If +"false", mail for recipients who are not defined as James users will +be injected into the James input spool with the Mail Attribute +org.apache.james.fetchmail.isUserUndefined added to the mail. +
+
leaveonserver
+
A boolean. If "true", mail for recipients who are not defined as +James users will be left on the server. If "false", mail for +recipients who are not defined as James users will be marked for deletion.
+
markseen
+
A boolean. If "true", mail for recipients who are not defined as +James users will be marked as seen on the server. If "false", mail +for recipients who are not defined as James users will not be marked as seen. +
+
+

+ +

+ +<userundefined + reject="true" + leaveonserver="true" + markseen="true"/> + +

+ + + +

The account tag declares an account on the external server +from which mail should be fetched.

+ +

The tag has these attributes: +

+
user
+
The string to be passed as the user when connecting to the external server. +
+
password
+
The string to be passed as the password when connecting to the external +server.
+
recipient
+
The recipient to whom messages will be delivered when the intended recipient +cannot be determined or when the intended recipient is to be ignored.
+
ignorercpt-header
+
A boolean. If "true", mail is always delivered to the recipient +declared in the recipient attribute above. If +"false", the intended recipient is determined from the mail headers or +the process declared by the recipientnotfound tag. +
+
+

+ +

+ +<account + user="myaccount" + password="mypassword" + recipient="user@localhost" + ignorercpt-header="true"/> + +

+ + + +

The alllocal tag declares the parameters to be applied to +dynamic accounts. The set of dynamic accounts is refreshed each time the fetch +task runs by combining the alllocal tag attributes with each of +the currently defined James users to create an account for every James user.

+ +

The tag has these attributes: +

+
userprefix
+
The string to be added before the James user when constructing the string +passed as the user when connecting to the external server. +
+
usersuffix
+
The string to be added after the James user when constructing the string +passed as the user when connecting to the external server. +
+
password
+
The string to be passed as the password when connecting to the external +server.
+
recipientprefix
+
The string to be added before the James user when constructing the recipient +to whom messages will be delivered when the intended recipient cannot be +determined or when the intended recipient is to be ignored.
+
recipientsuffix
+
The string to be added after the James user when constructing the recipient +to whom messages will be delivered when the intended recipient cannot be +determined or when the intended recipient is to be ignored.
+
ignorercpt-header
+
A boolean. If "true", mail is always delivered to the recipient +constructed from the recipientprefix and +recipientsuffix attributes above and the James user. If +"false", the intended recipient is determined from the mail headers or +the process declared by the recipientnotfound tag. +
+
+

+ +

+ +<alllocal + userprefix="" + usersuffix="@external.domain.com" + password="mypassword" + recipientprefix="" + recipientsuffix="@mydomain.com" + ignorercpt-header="true"/> + +

+ + + +

The property tag declares a name/value pair.

+ +

The tag has these attributes: +

+
name
+
The name of the property. +
+
value
+
The value of the property.
+
+

+ +

+ +<property + name="mail.pop3.connectiontimeout" + value="180000"/> + +

+ + +
+ +
+

Full sources to the examples discussed below can be found in the directory +$PHOENIX_HOME/apps/james/conf/samples/fetchmail.

+ + +

When all mail for an account is to be delivered to a single user, +configure each account to ignore the recipient in the mail headers and deliver +to the specified recipient. The accounts block looks like +this:

+ +

+ +<accounts> + <account + user="user1@external.domain.com" + password="password1" + recipient="user1@localhost" + ignorercpt-header="true"/> + + <account + user="user2@external.domain.com" + password="password2" + recipient="user2@localhost" + ignorercpt-header="true"/> + + <account + user="user3@external.domain.com" + password="password3" + recipient="user3@localhost" + ignorercpt-header="true"/> +</accounts> + +

+ + + +

When an account contains mail to be delivered to many users, configure each +account to determine the recipient from the mail headers and deliver to that +user. The accounts block looks like this:

+ +

+ +<accounts> + <account + user="global@external.domain.com" + password="password" + recipient="fetchmail@localhost" + ignorercpt-header="false"/> +</accounts> + +

+ +

The recipientnotfound tag is used to declare what happens +when the recipient cannot be determined from the mail headers. In the example +below, mail is injected into the spool using the recipient declared in the +account tag:

+ +

+ +<recipientnotfound + defer="false" + reject="false" + leaveonserver="false" + markseen="false"/> + +

+ + + +

When an external server supports virtual mailboxes, fetchmail's dynamic +account facility can be used. This greatly simplifies user configuration as +the fetchmail accounts for users are automatically synchronized with those +defined in the James user repository. This guarantees that mail for all local +users will be fetched and delivered.

+ +

Currently, there is a limitation that all virtual accounts and the global +account must share the same password.

+ +

The alllocal tag declares the parameters for the dynamic +accounts. The accounts block below will deliver mail for +user1@external.domain.com to user1@localhost, +user2@external.domain.com to user2@localhost, +userZ@external.domain.com to userZ@localhost etc.:

+ +

+ +<accounts> + <alllocal + userprefix="" + usersuffix="@external.domain.com" + password="mypassword" + recipientprefix="" + recipientsuffix="@localhost" + ignorercpt-header="true"/> +</accounts> + +

+ + + +

The +One Account, One User - Dynamic +example guarantees delivery of mail for all local users, but leaves other mail +on the external server unprocessed. The +One Account, Many Users example +processes all mail on the external server, but cannot guarantee delivery to the +intended recipient. By combining the two, it is possible to guarantee the +delivery of mail for all local users and process all mail.

+ +

In the snippet below, the alllocal tag declares dynamic +accounts for all local users and the account tag configures an +account to fetch all mail.

+ +

The recipientnotfound tag rejects mail for which a recipient +cannot be determined. By the time this processing is activated, the dynamic +accounts will have processed mail for all local users, so the mail can +only be mail for non-local users or newly arrived mail for local users. It is +not possible to know which, but we want to leave mail for local users to be +dealt with by the dynamic accounts. The next time the dynamic accounts run any +newly arrived mail for local users will be processed. The remainder will be for +non-local users and can now be safely dealt with.

+ +

The <recipientnotfound defer="true" attribute +enables deferal of the processing of messages for which the recipient cannot be +determined to the next iteration of the fetch task, and is used here. The +relevant tags are:

+ +

+ +<accounts> + <alllocal + userprefix="" + usersuffix="@external.domain.com" + password="mypassword" + recipientprefix="" + recipientsuffix="@localhost" + ignorercpt-header="true"/> + + <account + user="global@external.domain.com" + password="password" + recipient="fetchmail@localhost" + ignorercpt-header="false"/> +</accounts> + +<recipientnotfound + defer="true" + reject="true" + leaveonserver="true" + markseen="true"/> + +

+ + +
+ +
+

These are some things to be aware of when using fetchmail: +

    +
  • As noted in the +One Account, One User - Dynamic +example, all virtual accounts and the global account must share the same +password. A future version might associate each James user to a set of account +credentials. +
    • + +
  • When using dynamic accounts, an account is generated and an attempt made to +fetch mail for all James users defined to James even if there is no such mailbox +on the server. This is inefficient but not fatal. The solution is the same as +described above. +
    • + +
  • When using dynamic accounts, as described in the +One Account, Many Users - Dynamic +example, the user name used to fetch the mail for all accounts must not be +defined as a James user. If it is, a dynamic account will be generated for it +and fetch all the mail before the account declared to process mail for all users +has an opportunity to run! +
    • + +
  • The now deprecated fetchPOP interacted with the FetchedFrom +matcher to detect mail injected by fetchPOP. This will not work with fetchmail. +Compared to fetchPOP, there are far fewer occasions when mail injected by +fetchmail requires special processing. When it does, use the HasMailAttribute +matcher to match the attribute named +org.apache.james.fetchmail.taskName to detect all mail injected by +fetchmail. To detect mail injected by a specific fetch task, use one of the +HasMailAttributeWithValue matchers to match on the attribute name and the +attribute value. The attribute value is the name of the fetch task that +injected the mail. +
    • + +
  • The POP3 protocol does not enforce support of any of the Flags associated +with messages other than DELETED. This means that +markseen="true" will most likely have no effect and +therefore, the fetchall tag will be inoperative. In this +situation, the only way to avoid repeatedly fetching the same mail is to delete +it from the server using leaveonserver="false"/>. +
    • +
+

+
+ + + + + diff --git a/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml b/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml new file mode 100644 index 00000000000..08bc7a5448d --- /dev/null +++ b/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml @@ -0,0 +1,105 @@ + + + + + + James 2.1 - Configuring FetchPOP + + + +
+

FetchPOP is being deprecated. +fetchMail provides a superset of +FetchPOP's functionality and is the preferred solution.

+
+ +
+

FetchPOP is controlled by a configuration block in the config.xml. +The fetchpop tag defines the boundaries of the configuration block. It encloses +all the relevant configuration for the FetchPOP scheduler. The behavior of the POP service is +controlled by the attributes and children of this tag.

+

This tag has an optional boolean attribute - enabled - that defines whether +the service is active or not. The value defaults to "false" if not present.

+

The only permitted children of the fetchpop tag are fetch elements. Each of +these fetch tags defines a single FetchPOP task.

+

The fetch tag has a single required attribute, name. The name +of each FetchPOP task must be unique.

+

In addition to the name attribute, the fetch tag has four +children, all of which are required.

+
    +
  • host - The host name or IP address of the POP3 server hosting the mail to be fetched.
    • +
  • user - The user name of the account whose mail is to be fetched.
    • +
  • password - The password for the account whose mail is to be fetched.
    • +
  • interval - A non-negative integer representing the number of milliseconds between fetches.
    • +
+
+
+

There are a number of issues which have to be considered when handling fetched mail, such as avoiding circular +routing of mail. Some scenarios are described below with suggested configurations.

+ + +

This is the intended primary use of FetchPOP. +If all mail for a domain being fetched is ultimately being handled by this server then it is enough to add +the domain name as a servername to the servernames section described here. +
This is the simplest solution and is used where James is being used to redistribute all mail from the +free catch-all POP accounts provided by many domain registration/hosting companies.

+ + +

If only part of a domain's mail (perhaps only a single user's POP account) is being handled by this instance +of James it is important that outgoing mail addressed to this domain that is not intended for James be properly delivered.

+

To enable this filtering the FetchPOP scheduler adds a header, X-fetchedby, to the fetched message. This header can be checked using +the provided matcher FetchedFrom. This matcher can be used to direct fetched mail to a processor set up +to handle mail fetched from one or more POP3 accounts. The matcher should be used exactly once in the mail +pipeline for each FetchPOP task, as the matcher removes a matching header to prevent outgoing replies or +redirections from looping.

+

The FetchedFrom matcher is configured with the name of the particular FetchPOP task it is supposed to match. In general, +this matcher will be used to direct mail to a custom processor for further processing. A mailet tag such as the +following

+ +<mailet match="FetchedFrom=fetchtaskname" class="ToProcessor">
+<processor>fetchprocessor</processor> +</mailet> + +

where fetchtaskname is the name of the FetchPOP task being matched and fetchprocessor is the name of the fetched mail +processor can be used to this purpose. The fetched mail processor should contain mailets which will filter +and forward mail to real local or remote users. This can be achieved in the usual fashion as described in the +SpoolManager configuration section and in the out of the box +configuration file.

+ + +

It is important to note that this first version of FetchPOP does not access the original intended recipient +address of the mail, but instead uses the To: address from the message headers. Since this header may contain an +alias for the intended recipient, or may never have contained the intended recipient address (it could have been +in the Cc: or Bcc: fields) it is possible that James will be unable to deliver the fetched mail. It is intended +that this behaviour be addressed in the next version of James, but in the meantime a catch-all forwarding of +locally undeliverable fetched mail is recommended.

+

To handle messages where the intended recipient can be determined but is not present in the To: header, the FetchedFrom +matcher can be used. Place a mailet tag with this matcher between the "RecipientIsLocal" and "HostIsLocal" in the +Transport processor as defined in the out of the box configuration. The mailet tag should be configured to use the +provided ToProcessor mailet to direct fetched mail to a custom processor. Thus all mail fetched by FetchPOP that +could not be trivially mapped to a local user account will undergo further processing, allowing more complex +delivery handling.

+

For safety the All matcher should be used at the end of your custom fetched mail processor. This can be used to +catch all mail not handled by previous mailets in the processor. This will enable you to ensure that your +configuration is correct and that any mail not correctly delivered is available for examination by the postmaster.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/index.xml b/server/2.2.0/src/site/xdoc/index.xml new file mode 100644 index 00000000000..837d82d68a1 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/index.xml @@ -0,0 +1,104 @@ + + + + + + James 2.1/2.2 - Table of Contents + + + +
+

+The Java Apache Mail Enterprise Server (a.k.a. Apache James) is a 100% pure Java SMTP and POP3 Mail +server and NNTP News server designed to be a complete and portable enterprise mail engine +solution. James is based on currently available open protocols. +

+

+The James server also serves as a mail application platform. The James project hosts the Apache Mailet API, +and the James server is a Mailet container. This feature makes it easy to design, write, and deploy +custom applications for mail processing. This modularity and ease of customization is one of James' +strengths, and can allow administrators to produce powerful applications surprisingly easily. +

+

+James is built on top of version 4.1.3 of the Avalon Application Framework. This +framework encourages a set of good development practices such as Component Oriented Programming and +Inversion of Control. The standard distribution of James includes version 4.0.1 of the +Phoenix Avalon Framework container. This stable +and robust container provides a strong foundation for the James server. +

+

+This documentation is intended to be an introduction to the concepts behind the James implementation, as well +as a guide to installing, configuring, (and for developers) building the James server. +

+ +

+I. James Concepts +

+II. How To Build James + +III. How To Install James + +IV. Configuring James + +V. Common Configurations + +VI. Customizing James + +V. Other Information + +

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/installation_instructions.xml b/server/2.2.0/src/site/xdoc/installation_instructions.xml new file mode 100644 index 00000000000..771619dfba6 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/installation_instructions.xml @@ -0,0 +1,110 @@ + + + + + + James 2.1 - Installation + + +
+

James requires a Java Runtime Environment of Java version 1.3 or higher installed to run the +James application. The exact JREs available depend on the platform. A JRE must be downloaded and +installed before James can run. In addition, the environment variable JAVA_HOME must be set to +the JRE home directory before running James.

+

+Warning! - Issues have been observed when using Sun's Java 1.3.0 on older Linux +distributions. It is recommended that users of these platforms run James using a more recent +Sun JRE or a JRE produced by an alternate vendor. +

+

+On Unix platforms, root access will be required to run James. On these platforms, access to ports +below 1024 is generally restricted to the root user. As SMTP, POP3, and NNTP all need to open +server sockets on such ports in standard configurations, James requires root access. +

+

+Obviously James also requires sufficient disk space, processor power, and network bandwidth. But, +other than what's been discussed here, it has no additional special requirements.

+
+
+

James installation involves a number of steps, each of which is described in some detail in the +following sections. But as this sequence of steps has confused some users in the past, additional +comments seem warranted.

+

It is important to realize that the James configuration files are not unpacked from the James +distribution until the first time James is started. This is a consequence of the design of the +Avalon Phoenix container used to run James. Once James has been started, the distribution will +be unpacked. The server should be stopped, the configuration files edited, and the server restarted.

+

So the installation sequence is: 1) Start, 2) Stop, 3) Edit, 4) Restart.

+
+
+ +

Obtain the full James binary distribution from the James +release mirrors. Unpack the archive into your James installation directory. Go to the bin subdirectory of the +installation directory and run the "run" script (either run.sh or run.bat, depending on your platform). The configuration +file is now unpacked and available for editing.

+ + +

Warning! - James requires Phoenix version 4.0.x to run. There is a known issue with logging in Phoenix 4.0, so version +4.0.1 or higher is strongly recommended. Before attempting to deploy James in a Phoenix container, please make sure +it meets these version criteria.

+

Deploying James in Phoenix is fairly easy. Obtain the james.sar file from the James +release mirrors. It can be found in the "Other Binaries" +area of the distribution directory. After downloading the james.sar, +simply place it in the apps subdirectory of your Phoenix installation. Restart Phoenix, and the james.sar should unpack and you +will be ready to configure your James installation.

+ +
+ +
+

+After installing the binary, the next step is to adjust the initial configuration. The server should be stopped, and then +configuration can proceed. The most essential configuration is set in the config.xml file. This file can be +found in the apps/james/SAR-INF subdirectory of the installation directory.

+

The out of the box configuration makes certain assumptions and has some default values that are unlikely to +be appropriate for real-world servers. There are a few issues that should be addressed immediately upon installation: +

+
    +
  • RemoteManager Administrator Account - Before the RemoteManager service can be used to add users to this server +installation an administrator account must be created. More information can be found here.
    • +
  • DNS Servers - James needs to have access to a DNS server for domain resolution. The out of the box +configuration assumes that there is a DNS server on localhost. In general administrators will have to change +the configuration to point to a valid DNS server. This can be done by adjusting the dnsserver configuration +block in the config.xml. More information can be found here.
    • +
  • Managed Domain Names/IP Addresses - Out of the box, James only handles mail that is sent to recipients at +localhost. It will attempt to deliver all other email to remote SMTP servers. To allow James to handle email +for your domain or IP address, you simply need to add the appropriate domain name or IP address to the servernames +section of the config.xml. More information can be found here.
    • +
  • Postmaster Address - More information can be found here.
    • +
+

In addition to adjusting these parameters, you may wish to consult the documentation for a discussion of +common configurations. A list of such configurations, as well as the steps necessary to configure them, can +be found here.

+
+
+

Once you have edited the configuration file you will need to restart James so that the changes take +effect. When James starts, a list of the James services and the ports on which they are listening should +be displayed on the console. Additional information about the system configuration is printed in the James log files +upon startup.

+

Finally, after configuration is complete, it will be necessary to create user accounts before the James server +will be fully operational. Instructions on creating user accounts can be found +here.

+
+ + + diff --git a/server/2.2.0/src/site/xdoc/james_and_sendmail.xml b/server/2.2.0/src/site/xdoc/james_and_sendmail.xml new file mode 100644 index 00000000000..067a7f4d755 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/james_and_sendmail.xml @@ -0,0 +1,124 @@ + + + + + + Sendmail integration + Danny Angus + + + + +
+ +

+ This document explains how to configure sendmail to route all mail generated by /usr/sbin/sendmail or local mail on a host through James on the same host, including mail to local addresses without @host.
+ All sendmail configuration file locations are for Redhat Linux 7.2, other installations may have different locations.
+ We take no responsibility for the quality of the information in this document.
You should back-up any configuration files *before* you alter them. +

+
+ +
+ +

+Ok so you want to use James for everything, including delivering mail from localhost to local users.
+Well the first step is to stop sendmail from starting up as the SMTP Daemon on port 25, otherwise it will route mail to itself and who knows what will happen then.
+Open the sendmail configuration file /etc/sysconfig/sendmail +Change the line:DAEMON=yesintoDAEMON=no +Restart sendmail with:[root@apache root]# /etc/rc.d/init.d/sendmail restartThis will make sendmail process its outgoing queue, but not listen on port 25 for incoming mail. +

+ + +

+Ok, so far so good, now you need to tell sendmail to relay everything, regardless of its rules, through James. James will take the roles of "local relay" (destination for all unqualified local addresses), "mail hub" (destination for all qualified local addresses) and "smart relay" (destination for all other mail) for this instance of sendmail, thereby catching everything.
+So open /etc/sendmail.cf and.. +

    +
  • Look for the line beginning DS make this line DSesmtp:localhost
    • +
  • Look for the line beginning DR make this line DResmtp:localhost
    • +
  • Look for the line beginning DH make this line DHesmtp:localhost
    • +
+Now that wasn't too hard was it?
+What we have done is to tell sendmail to use its "mailer" called esmtp to relay mail using ESMTP to localhost for each role.
+Of course no-one in their right mind would relay mail to localhost, because it would loop forever right? +

+ + + +

+The developers of sendmail have, wisely, built sendmail in such a way as to prevent, by default, mail being sent by sendmail back to itself, this is done by making a quick check on outgoing mail to see if its destination is our machine. If it is you'll see this message config error: mail loops back to me when you try to send mail.
+But we *want* to relay mail to localhost, and because sendmail isn't receiving our mail, James is, we won't be creating a loop. (make sure you've followed step one though).
+So open /etc/sendmail.cf again and go to the bottom of the file, start scrolling upwards until you see the declaration of the esmtp mailer it'll look something like this + +Mesmtp, P=[IPC], F=mDFMuXa, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990, + T=DNS/RFC822/SMTP, + A=TCP $h + +You need to change it so its more like this: :-D + +Mesmtp, P=[IPC], F=kmDFMuXa, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990, + T=DNS/RFC822/SMTP, + A=TCP $h + +But seriously, we've added a k to the "F=" list F=mDFMuXa becomes F=kmDFMuXa
+And again, thats it, sendmail will now skip the loopback test on mail leaving through the esmtp mailer. +

+

Now you have to make some tests.
Try each of the following, replace names in [] with names of the kind described. +/[root@apache root]# mail -v [real-localusername] + +[root@apache root]# mail -v [nonexistant-localusername] + +[root@apache root]# mail -v [real-localusername]@localhost + +[root@apache root]# mail -v [real-localusername]@[myhostname.mydomainname] + +[root@apache root]# mail -v [real-username]@[real-remote-account] + +Sendmail echoes each conversation to STDOUT so you can see what its trying to do with each mail.
+

+ + + +

+SMTP AUTH is a different Kettle of Fish.
+The scenario is that you're using SMTP AUTH on James to restrict SMTP relaying to authenticated users, allowing them to connect from any IP address but still not letting James become an open relay for spam, cool.
+However you now want to let sendmail relay through James, so you need to tell it how to authenticate.
+So open /etc/sendmail.cf again and this time.. +

    +
  • Look for the line beginning O AuthMechanisms= If this line is commented out with a leading #, remove the # then make sure LOGIN and PLAIN are at the beginning of this line like this O AuthMechanisms=LOGIN PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5
    • +
  • Look for the line beginning O DefaultAuthInfo= If this line is commented out with a leading #, remove the # then make this line O DefaultAuthInfo=/etc/mail/default-auth-info
    • +
  • Create a user account on James for sendmail to login as.
    • +
  • Create the file /etc/mail/default-auth-info
    • +
  • It should contain thisusername +username +password +localhostYes the username appears twice.
    • +
  • Replace username and password with the details of the account you just created.
    • +
  • This file has to be chmod'ed 600 (-rw------) or sendmail won't read it.
    • +
  • Look for the line beginning O AuthOptions= If this line is commented out with a leading #, remove the # and it should be O AuthOptions=A
    • +
+ +

Ta-da!

Now you're ready to run the tests in Step3, all of the mail should be accepted, the most likely rejection will be the final one. +

+ +

Thats it, good luck and happy mailing :)
Danny Angus

+
+ + + diff --git a/server/2.2.0/src/site/xdoc/mailet_api.xml b/server/2.2.0/src/site/xdoc/mailet_api.xml new file mode 100644 index 00000000000..489ab7e6401 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/mailet_api.xml @@ -0,0 +1,51 @@ + + + + + + James 2.1 - Mailet API + + + +
+

The Mailet API is a simple API used to build mail processing applications. James is a Mailet +container, allowing administrators to deploy Mailets (both custom and pre-made) to carry out a +variety of complex mail processing tasks. In the default configuration James uses Mailets to carry +out a number of tasks that are carried out deep in the source code of other mail servers (i.e. list +processing, remote and local delivery).

+

+As it stands today, the Mailet API defines interfaces for both Matchers and Mailets.

+

Matchers, as their name would suggest, match mail messages against certain conditions. They +return some subset (possibly the entire set) of the original recipients of the message if there +is a match. An inherent part of the Matcher contract is that a Matcher should not induce any changes +in a message under evaluation.

+

Mailets are responsible for actually processing the message. They may alter the message in any fashion, +or pass the message to an external API or component. This can include delivering a message to its destination +repository or SMTP server.

+

The Mailet API is currently in its second revision. Although, the Mailet API is expected to undergo substantial changes in the near future, it is our aim that existing Mailets that abided purely by the prior Mailet API interfaces will continue to run with the revised specification.

+ +

James bundles a number of Matchers and Mailets in its distribution. Descriptions of provided matchers +can be found here, while descriptions of provided mailets can be found +here.

+
+ + diff --git a/server/2.2.0/src/site/xdoc/mailing_lists.xml b/server/2.2.0/src/site/xdoc/mailing_lists.xml new file mode 100644 index 00000000000..ffdbb7515bf --- /dev/null +++ b/server/2.2.0/src/site/xdoc/mailing_lists.xml @@ -0,0 +1,115 @@ + + + + + James 2.1 - Creating Mailing Lists + + + +
+

One of the frequent questions on the James-User Mailing List is how +to create a mailing list. This document explains one way of using the +currently supplied Matchers and Mailets in James v2.1.

+ +

Basically, the process requires creating two <mailet> entries +and a repository. The first mailet handles list commands (currently +only list-name-on and list-name-off). The second mailet +handles list messages. The repository will hold the e-mail addresses +of list subscribers.

+ +

The mailets go into the processor chain (e.g., at the top of the +transport processor), the repository goes into the +<users-store> block.

+ + + +

You need to setup two mailets.

+ +

The first mailet that you need to setup is an instance of the Avalon Listserv +Manager mailet. This will handle subscribing and unsubscribing. +[Note: the current code does not support confirmed opt-in, just basic +commands.] The CommandForListserv +matcher is used to invoke match messages containing commands for the +mailing list.

+ +

The second mailet is an instance of the Avalon Listserv +mailet. That mailet actually receives messages for the list and +causes them to be distributed. The RecipientIs matcher +is used to match messages intended for the mailing list.

+ +

The following illustrates the two <mailet> elements that need to be added:

+ + + <mailet match="CommandForListserv=list-name@domain" + class="AvalonListservManager"> + <repositoryName>list-name</repositoryName> + </mailet> + + <mailet match="RecipientIs=list-name@domain" class="AvalonListserv"> + <repositoryName>list-name</repositoryName> + ... list options ... + </mailet> + + + + + + +

The mailing list mailets need a repository within which to store +the subscriber list. There is a separate repository for each mailing +list, and is completely independent of the user repository used by +James to manage e-mail accounts. This is configured in the +<users-store> block of config.xml.

+ +

The following illustrates a database-backed repository using JDBC +with the ListUsersJdbcRepository class. Notice that there will be a +single table, lists, created in the db://maildb resource +defined elsewhere. There are currently two columns: the list name and +the list subscriber.

+ + + <repository name="list-name" + class="org.apache.james.userrepository.ListUsersJdbcRepository" + destinationURL="db://maildb/lists/list-name"> + <sqlFile>file://conf/sqlResources.xml</sqlFile> + </repository> + + +

The following illustrates a file-system repository using the +UsersFileRepository class. [Note: the destination URL is a child +element when configuring a file-system repository, and an attribute +when configuring a database-backed repository. This inconsistency +will be addressed in a future version of James.]

+ + + <repository name="list-name" + class="org.apache.james.userrepository.UsersFileRepository"> + <destination URL="file://var/lists/list-name/" /> + </repository> + + + +
+ + diff --git a/server/2.2.0/src/site/xdoc/nntp_configuration.xml b/server/2.2.0/src/site/xdoc/nntp_configuration.xml new file mode 100644 index 00000000000..97ef95efe48 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/nntp_configuration.xml @@ -0,0 +1,98 @@ + + + + + + James 2.1 - Configuring the NNTP Service + + + +
+

The NNTP service is controlled by a two configuration blocks in the config.xml. These are the nntpserver block and the nntp-repository block.

+ +

The nntpserver tag defines the boundaries of the configuration block. It encloses +much of the relevant configuration for the NNTP server.

+ +

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if +not present.

+

The standard children of the nntpserver tag are:

+
    +
  • port - This is an optional integer value. This value is the port on which this NNTP server is configured +to listen.If the tag or value is omitted, the value will default to the standard NNTP port, 119.
    • +
  • bind - This is an optional value. If present, this value is a string describing +the IP address to which this service should be bound. If the tag or value is absent then the service +will bind to all network interfaces for the machine.
    • +
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" +server socket factory is used to generate the server socket for this service. If it is false, the +"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType +tag which is described under the expert configuration options.
    • +
  • handler - This is an artifact preserved for backwards compatibility. This tag +was used to group related parameters. It should disappear in future versions.
    • +
      +
    • helloName - This is a required tag with an optional body that defines the server name +used in the initial service greeting. The tag may have an optional attribute - autodetect. If +the autodetect attribute is present and true, the service will use the local hostname +returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In +this case, if no body is present, the value "localhost" will be used.
      • +
    • connectionTimeout - This is an optional tag with a non-negative integer body.
      • +
    • authRequired - This is an optional tag with a boolean body. If true, then the server will +require authentication before allowing the client to view news articles. If this tag is absent, or the value +is false then the client will not be prompted for authentication. Only simple user/password authentication is +supported at this time.
      • +
    +
+

There are a few additional children of the nntpserver tag that are appropriate for advanced +configurations. These should only be used by expert administrators. All tags in this group are optional.

+
    +
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the server socket factories specified in the socket manager block. Any other +value will result in an error. If present, this tag overrides the useTLS tag.
    • +
  • threadGroup - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the thread groups specified in the thread manager block. Any other +value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • +
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client +connections that this service will allow. If no value is specified, the value defaults to that specified in +the connectionmanager block. A value of 0 means that there is no limit imposed +by the service, although resource limitations imposed by other components +(i.e. max # of threads) may serve to limit the number of open connections.
    • +
+ + +The remainder of the NNTP service configuration is controlled by the nntp-repository configuration block. This +section of configuration data relates to the server-side NNTP article repository. +
    +
  • readOnly - This is a required boolean tag. If the value is true, posting will not be +permitted by the NNTP server.
    • +
  • rootPath - This is a required string tag. It must be in the form of a URL with a "file:" prefix. This +specifies the root directory for the NNTP repository. Groups hosted on the NNTP server will be represented as +folders under this root, and articles will be stored in the appropriate folders.
    • +
  • tempPath - This is a required string tag. It must be in the form of a URL with a "file:" prefix. This +specifies the directory where the NNTP server will store posted articles before they are added to the spool.
    • +
  • articleIDPath - This is a required string tag. It must be in the form of a URL with a "file:" prefix. This +specifies the directory where the NNTP server will store the mappings between article ID and the groups containing that article.
    • +
  • articleIDDomainSuffix - This is a required string tag. It is the suffix appended to all article IDs generated +by this NNTP server.
    • +
  • newsgroups - This is a required container tag. It has a single newsgroup child for each newsgroup +hosted on the server. The body of each of those newsgroup tags is the name of the newsgroup.
    • +
+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/pop3_configuration.xml b/server/2.2.0/src/site/xdoc/pop3_configuration.xml new file mode 100644 index 00000000000..2cc037aa6a7 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/pop3_configuration.xml @@ -0,0 +1,74 @@ + + + + + + James 2.1 - Configuring the POP3 Service + + + +
+

The POP3 service is controlled by a configuration block in the config.xml. +The pop3server tag defines the boundaries of the configuration block. It encloses +all the relevant configuration for the POP3 server. The behavior of the POP service is +controlled by the attributes and children of this tag.

+ +

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if +not present.

+

The standard children of the pop3server tag are:

+
    +
  • port - This is an optional integer value. This value is the port on which this POP3 server is configured +to listen.If the tag or value is omitted, the value will default to the standard POP3 port, 110.
    • +
  • bind - This is an optional value. If present, this value is a string describing +the IP address to which this service should be bound. If the tag or value is absent then the service +will bind to all network interfaces for the machine.
    • +
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" +server socket factory is used to generate the server socket for this service. If it is false, the +"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType +tag which is described under the expert configuration options.
    • +
  • handler - This is an artifact preserved for backwards compatibility. This tag +was used to group related parameters. It should disappear in future versions.
    • +
      +
    • helloName - This is a required tag with an optional body that defines the server name +used in the initial service greeting. The tag may have an optional attribute - autodetect. If +the autodetect attribute is present and true, the service will use the local hostname +returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In +this case, if no body is present, the value "localhost" will be used.
      • +
    • connectionTimeout - This is an optional tag with an integer body.
      • +
    +
+

There are a few additional children of the pop3server tag that are appropriate for advanced +configurations. These should only be used by expert administrators. All tags in this group are optional.

+
    +
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the server socket factories specified in the socket manager block. Any other +value will result in an error. If present, this tag overrides the useTLS tag.
    • +
  • threadGroup - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the thread groups specified in the thread manager block. Any other +value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • +
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client +connections that this service will allow. If no value is specified, the value defaults to that specified in +the connectionmanager block. A value of 0 means that there is no limit imposed +by the service, although resource limitations imposed by other components +(i.e. max # of threads) may serve to limit the number of open connections.
    • +
+
+ + diff --git a/server/2.2.0/src/site/xdoc/provided_mailets.xml b/server/2.2.0/src/site/xdoc/provided_mailets.xml new file mode 100644 index 00000000000..33c677961b7 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/provided_mailets.xml @@ -0,0 +1,253 @@ + + + + + + James 2.1 - Provided Mailets + + + + +
+ +

James provides a number of implemented Mailets for use by James administrators in their +configurations. These are primarily mailets that members of the James developer or user +communities have found useful in their own configurations. A description of how to configure +Mailets and use them in the James SpoolManager can be found here.

+ + +

Description: This mailet adds a text footer to the message.

+

Parameters: +

    +
  • text (required) - the text that will be added as a footer to the message.
    • +
+

+ + +

Description: This mailet adds a Habeas warrant mark (see http://habeas.com for details) to the message.

+

Parameters: None.

+ + +

Description: This mailet adds a text header to the message.

+

Parameters: +

    +
  • name (required) - the name of the header to be added to the message.
    • +
  • value (required) - the text that will be added as a header to the message.
    • +
+

+ + +

Provides basic list server functionality. Implements basic filters for emails sent to the list, +including restriction of senders to members, diallowing attachments in list messages, and subject line +processing

+

Parameters: +

    +
  • repositoryName (required) - the name of the user repository that contains the users +for this list.
    • +
  • membersonly (optional) - whether only members of the list can send messages to this +list. Defaults to false.
    • +
  • attachmentsallowed (optional) - whether attachments are allowed in messages sent to this +list. Defaults to true.
    • +
  • replytolist (optional) - whether the reply-to address for all messages sent to this +list is set to the list address. Defaults to true.
    • +
  • subjectprefix (optional) - a String value. If set, this value is prepended to the subject +line of all messages sent to the list.
    • +
  • autobracket (optional) - a boolean value. If a subjectprefix is set, this value determines +whether the prefix is bracketed before being prepended to the subject line. Defaults to true.
    • +
+

+ + +

Processes list management commands of the form <list-name>-on@<host> and +<list-name>-off@<host> where <list-name> and lt;host> are arbitrary. Note +that this should be used in tandem with a CommandForListserv matcher to ensure that only commands +intended for a specific list are processed.

+

Parameters: +

    +
  • repositoryName (required) - the name of the user repository that contains the users +for this list.
    • +
+

+ + +

Description: This mailet forwards the message to a set of recipients.

+

Parameters: +

    +
  • forwardto (required) - a comma delimited list of email addresses.
    • +
+

+ + +

Description: This mailet does alias translation for email addresses stored in a database table.

+

Parameters: +

    +
  • mappings (required) - a URL of the form db://<data-source>/<table>, where +<table> is the table in the database containing the alias info and <data-source> is the name +of the data-source in config.xml that is to be used.
    • +
  • source_column (required) - the column containing the aliases.
    • +
  • target_column (required) - the column containing the alias targets.
    • +
+

+ + +

Description: This mailet does complex alias translation for email addresses stored in a database table.

+

Parameters: +

    +
  • table (required) - the URL describing the database table. This URL has the form +db://<data-source>/<table> where <data-source> and <table> are the names of +the data-source as defined in config.xml and the table in the database.
    • +
  • sqlquery (optional) - the text of the SQL query used by the mailet to do user +lookup. The default is "select VirtualUserTable.target_address from VirtualUserTable, VirtualUserTable as VUTDomains where (VirtualUserTable.user like ? or VirtualUserTable.user like '\\%') and (VirtualUserTable.domain like ? or (VirtualUserTable.domain like '\\%' and VUTDomains.domain like ?)) order by concat(VirtualUserTable.user,'@',VirtualUserTable.domain) desc limit 1"
    • +
+

+ + +

Description: This mailet delivers messages to local mailboxes.

+

Parameters: None.

+ + +

Description: This mailet forwards the message as an attachment to the James postmaster.

+

Parameters: +

    +
  • sendingAddress (optional) - the address from which the forwarded email will be +sent. Defaults to the postmaster address.
    • +
  • notice (optional) - the text message that will accompany the forwarded message. Defaults +to "We were unable to deliver the attached message because of an error in the mail server."
    • +
  • attachStackTrace (optional) - whether an error stack trace is attached to the forwarded message.
    • +
+

+ + +

Description: This mailet forwards the message as an attachment to the original sender.

+

Parameters: +

    +
  • sendingAddress (optional) - the address from which the forwarded email will be +sent. Defaults to the postmaster address.
    • +
  • notice (optional) - the text message that will accompany the forwarded message. Defaults +to "We were unable to deliver the attached message because of an error in the mail server."
    • +
  • attachStackTrace (optional) - whether an error stack trace is attached to the forwarded message.
    • +
+

+ + +

Description: This mailet ends processing for this mail.

+

Parameters: None.

+ + +

Description: Intercepts all mails addressed to postmaster@<domain> where <domain> is one +of the domains managed by this James server and substitutes the configured James postmaster address for +the original recipient address. This mailet is inserted automatically by James at the head of the root +processor.

+

Parameters: None.

+ + + +

Description: A mailet providing powerful, configurable redirection services.
+ This mailet can produce listserver, forward and notify behaviour, with the + original message intact, attached, appended or left out altogether.
+ This built in functionality is controlled by the configuration as described + here.

+

It is also intended to be easily subclassed to make providing bespoke redirection + mailets simple.
+ By extending it and overriding one or more of its methods new behaviour can + be quickly created without the author having to address any other issue than + the relevant one. For more information see the javadocs + here.

+

Parameters: See javadocs.

+ + + +

Manages delivery of messages to recipients on remote SMTP hosts.

+

Parameters: +

    +
  • outgoing (required) - The URL for the repository that will hold messages being processed +by the RemoteDelivery Mailet.
    • +
  • delayTime (optional) - a non-negative Long value that is the time in +milliseconds between redelivery attempts for a particular mail. Defaults to six hours.
    • +
  • maxRetries (optional) - a non-negative Integer value that is number of times +the Mailet will attempt to deliver a particular mail. Defaults to five.
    • +
  • timeout (optional) - The SMTP connection timeout for SMTP connections generated +by this Mailet. Defaults to 60 seconds.
    • +
  • deliveryThreads (optional) - The number of threads this Mailet will use to generate +SMTP connections.
    • +
  • gateway (optional) - The host name of the SMTP server +to be used as a gateway for this server. If this value is set, then all +messages will be delivered to the gateway server, regardless of recipient +address. To specify more than one gateway server, add multiple gateway tags, +each containing one value. If more than one server is specified, they will be +tried in order until one is successful. In addition the port may be specified +for each gateway in the format <host>:<port>. If this +value is unset, delivery will occur to SMTP servers resolved by MX lookup.
    • +
  • gatewayPort (optional) - The default port number of the +SMTP server to be used as a gateway for this server. This value will be +employed when a gateway is set and the gateway value does not specify +a port as described above.
    • +
  • bind (optional) - If present, this value is a string +describing the local IP address to which the mailet should be bound while +delivering emails. If the tag is absent then the service will bind to the +default local address of the machine. This tag is useful for multihomed machines.
    +Note: Currently you must use the same IP address for all of those RemoteDelivery +instances where you explicitly supply a bind address.
    • +
  • debug (optional) - a boolean value (true/false) indicating whether debugging is +on. Defaults to false.
    • +
+

+ + +

Description: This mailet sends a message to the sender of the original mail message with a server timestamp.

+

Parameters: None.

+ + +

Redirects processing of the mail message to the specified processor.

+

Parameters: +

    +
  • processor (required) - the name of the processor to which the message +is to be redirected.
    • +
  • noticeText (optional) - a String value that, if present, +is set as the error message of the redirected message. If this value is not +present, no error message is set.
    • +
+

+ + +

Places a copy of the message in the specified repository.

+

Parameters: +

    +
  • repositoryPath (required) - the URL of the repository to which the message +is to be added.
    • +
  • passThrough (optional) - a boolean value (true/false) indicating whether +processing should continue on the message is on. If false, the original message is GHOSTed. Defaults to false.
    • +
+

+ + +

Description: Ignores the recipients associated with the Mail interface. Instead, it regenerates the +mail recipients from the MimeMessage headers (To, Cc, Bcc) and inserts a new message at the queue root +these new recipients. The original message is GHOSTed.

+

Parameters: +

    +
  • debug (optional) - a boolean value (true/false) indicating whether debugging is +on. Defaults to false.
    • +
+

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/provided_matchers.xml b/server/2.2.0/src/site/xdoc/provided_matchers.xml new file mode 100644 index 00000000000..9c461636aff --- /dev/null +++ b/server/2.2.0/src/site/xdoc/provided_matchers.xml @@ -0,0 +1,186 @@ + + + + + + James 2.1 - Provided Matchers + + + + +
+ +

James provides a number of implemented Matchers for use by James administrators in their +configurations. These are primarily matchers that members of the James developer or user +communities have found useful in their own configurations. A description of how to configure +Matchers and use them in the James SpoolManager can be found here.

+ + +

Description: This matcher is the trivial one - it matches all mails being processed. All recipients are returned.

+

Configuration string: None.

+ + +

Description: It can be used to refuse emails with SCR, PIF, EXE etc. attachments. +It matches mails that has a file attachment with a file name meeting one of the supplied filters. +All recipients are returned.

+

Configuration string: A comma or space delimited list of file names. +File names may start with a wildcard '*'. Example: *.scr,*.bat,*.pif,*.pi,*.com,*.exe

+ + +

Description: The CommandForListserv matcher is used as a simple filter to recognize emails that are list server +commands. It will match any email addressed to the list server host, as well as any email that is addressed +to a user named <prefix>-on or <prefix>-off on any host. Only those matching recipients will be returned.

+

Configuration string: An email address of the form <prefix>@<host>, where host is the hostname used for the listserver and prefix is the command prefix.

+ + +

Description: A matcher intended for use with the FetchPOP server. It matches a custom header (X-fetched-from) that is +set by the FetchPOP server. FetchPOP sets this header to the name of the FetchPOP task which originally fetched +the message. All recipients are returned.

+

Configuration string: The name of the FetchPOP task which originally fetched the message.

+ + +

Description: Matches those messages with a MIME type of "multipart/mixed". All recipients are returned.

+

Configuration string: None.

+ + +

Description: Matches mails that have the Habeas Warrant (see http://www.habeas.com for details). All recipients are returned.

+

Configuration string: None.

+ + +

Description: Matches mails that have the specified header. All recipients are returned.

+

Configuration string: The name of the header whose presence determines the match.

+ + +

Description: Matches mails that have the specified Mail Attribute. All +recipients are returned.

+

Configuration string: The name of the Mail Attribute to match. For example:
+


+<mailet match="HasMailAttribute=name" class="<any-class>">
+
+

+ + +

Description: Matches mails that have the specified Mail Attribute and the +specified MailAttribute value. All recipients are returned.

+

MailAttributes are types of Object whereas the value specified in the Matcher +condition is of type String. The toString() method is used to obtain a String +representation of the Mail Attribute value for matching. The +String.equals(String) method tests for a match.

+

Configuration string: The name of the Mail Attribute to be matched, a comma +and then the String value to be matched. For example:
+


+<mailet match="HasMailAttributeWithValue=name, value" class="<any-class>">
+
+

+ + +

Description: Matches mails that have the specified Mail Attribute and +a MailAttribute value that matches the specified regular expression. +All recipients are returned.

+

MailAttributes are types of Object whereas the value specified in the Matcher +condition is of type String. The toString() method is used to obtain a String +representation of the Mail Attribute value for matching. The regular +expression must follow Perl5 syntax.

+

Configuration string: The name of the Mail Attribute to be matched, a comma +and then the regular expression used to match the value against. For example:
+


+<mailet match="HasMailAttributeWithValueRegex=name, regex" class="<any-class>">
+
+

+ + +

Description: Matches mails that are sent to email addresses on hosts that are in the configuration list. Only +recipients that are on one of the hosts are returned.

+

Configuration string: A list of host names, comma or space delimited.

+ + +

Description: Matches mails that are sent to email addresses on local hosts. Only +recipients that are on one of the local hosts are returned.

+

Configuration string: None.

+ + +

Description: Checks the mail against one of a number of mail-abuse.org IP lists.

+

Configuration string: One of three strings - "blackholes.mail-abuse.org", "relays.mail-abuse.org", or "dialups.mail-abuse.org".

+ + +

Description: Matches those messages sent to only a single recipient. The single recipient is returned.

+

Configuration string: None.

+ + +

Description: A matcher derived from a Netscape Mail Server spam filter. If the matcher detects headers that +indicate spam, the message is matched. All recipients are returned.

+

Configuration string: None.

+ + +

Description: Matches mails that are sent to one of the recipients on a specified list. Only +matching recipients are returned.

+

Configuration string: A list of recipient addresses, comma, tab, or space delimited.

+ + +

Description: Matches mails that are sent to email addresses on local hosts with users that have local acccunts. Only +matching recipients are returned.

+

Configuration string: None.

+ + +

Description: Counts the number of Received headers in the mail (each of which represents a server +in the relay chain). If the number equals or exceeds the specified limit, the mail is +matched. All recipients are returned.

+

Configuration string: a positive integer that is the limit on the number of relays.

+ + +

Description: Checks the remote address from which the mail was received against the configured list. If the address matches one on the list, the matcher considers it a match. All recipients are returned.

+

Configuration string: A list of domain names, IP addresses, or wildcarded IP subnets of any class. The +list may be comma or space delimited.

+ + +

Description: Checks the remote address from which the mail was received against the configured list. If the address doesn't match one on the list, the matcher considers it a match. All recipients are returned.

+

Configuration string: A list of domain names, IP addresses, or wildcarded IP subnets of any class. The +list may be comma or space delimited.

+ + +

Description: Matches mails where the host name in the address of the sender cannot be resolved. All +recipients are returned.

+

Configuration string: None.

+ + +

Description: Matches mails that are sent by one of the senders on a specified list. All +recipients are returned.

+

Configuration string: A list of sender addresses, comma, tab, or space delimited.

+ + +

Description: Matches emails with a total message size (headers and body) greater than the specified limit. All recipients are returned.

+

Configuration string: a positive integer followed by an 'm' or a 'k'. This is the maximum message size permitted specified in megabytes or kilobytes respectively.

+ + +

Description: Matches emails with the specified subject. All recipients are returned.

+

Configuration string: The string against which mail subject headers are matched.

+ + +

Description: Matches emails whose subject header starts with the specified string. All recipients are returned.

+

Configuration string: The string against which mail subject headers are matched.

+ + +

Description: Matches mails that are sent to email addresses that have userids that are in the configuration list. Only +matching recipients are returned.

+

Configuration string: A list of user names, comma or space delimited.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml b/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml new file mode 100644 index 00000000000..1a3ef797089 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml @@ -0,0 +1,78 @@ + + + + + + James 2.1 - Configuring the RemoteManager + + + +
+

The RemoteManager is controlled by a configuration block in the config.xml. +The remotemanager tag defines the boundaries of the configuration block. It encloses +all the relevant configuration for the RemoteManager. The behavior of the RemoteManager is +controlled by the attributes and children of this tag.

+ +

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if +not present.

+

The standard children of the remotemanager tag are:

+
    +
  • port - This is an optional integer value. This value is the port on which this POP3 server is configured +to listen.If the tag or value is omitted, the value will default to 4555.
    • +
  • bind - This is an optional value. If present, this value is a string describing +the IP address to which this service should be bound. If the tag or value is absent then the service +will bind to all network interfaces for the machine.
    • +
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" +server socket factory is used to generate the server socket for this service. If it is false, the +"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType +tag which is described under the expert configuration options.
    • +
  • handler - This is an artifact preserved for backwards compatibility. This tag +was used to group related parameters. It should disappear in future versions.
    • +
      +
    • helloName - This is a required tag with an optional body that defines the server name +used in the initial service greeting. The tag may have an optional attribute - autodetect. If +the autodetect attribute is present and true, the service will use the local hostname +returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In +this case, if no body is present, the value "localhost" will be used.
      • +
    • administrator_accounts - This is an required container tag. It contains +one or more administrator_account elements, each of which has a login attribute +and a password attribute. These two attributes correspond to the login id and password for the +administrative account respectively. Obviously, for security reasons, these should be set upon James installation.
      • +
    • connectionTimeout - This is an optional tag with an integer body.
      • +
    +
+

There are a few additional children of the pop3server tag that are appropriate for advanced +configurations. These should only be used by expert administrators. All tags in this group are optional.

+
    +
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the server socket factories specified in the socket manager block. Any other +value will result in an error. If present, this tag overrides the useTLS tag.
    • +
  • threadGroup - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the thread groups specified in the thread manager block. Any other +value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • +
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client +connections that this service will allow. If no value is specified, the value defaults to that specified in +the connectionmanager block. A value of 0 means that there is no limit imposed +by the service, although resource limitations imposed by other components +(i.e. max # of threads) may serve to limit the number of open connections.
    • +
+
+ + diff --git a/server/2.2.0/src/site/xdoc/repositories.xml b/server/2.2.0/src/site/xdoc/repositories.xml new file mode 100644 index 00000000000..ca99c31ccf2 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/repositories.xml @@ -0,0 +1,86 @@ + + + + + + Repositories + + + +
+ +

James uses a number of different repositories to both store message data (email, news messages) and +user information. User repositories store user information, including user names, authentication +information, and aliases. Mail repositories store messages that have been delivered locally. Spool +repositories store messages that are still being processed. Finally, news repositories are used to +store news messages.

+ +
+
+ +

Aside from the type of data they store, repositories are distinguished by +where they store data. There are three types of storage - File, Database, and DBFile.

+ + +

File-based repositories store all data in the file system. In general, these repositories are extremely +simple to configure, but may compare poorly in terms of performance when compared to other repository +types. File repositories are not recommended for large or performance-critical configurations. In the +default configuration, all repositories are file repositories.

+ +

File repository paths typically begin with the prefix "file". Paths are relative to the application +base directory, unless the path begins with a slash. As an example, assume that James is running in +/usr/james/phoenix/apps/james. Then "file://var/mail/spool/" would refer to the directory /usr/james/phoenix/apps/james/var/mail/spool. +And "file:///var/mail/spool/" (note the extra '/') would refer to the directory /var/mail/spool.

+ +

All repository types (mail, spool, user, and news) have file-based implementations. No special configuration is required to enable file-based repositories

+ + + + +

Database repositories store all data in an administrator-supplied database. Configuration is somewhat +more complex, requiring that the administrator adjust the data-connections section. Detailed directions +are included in the sample configuration file. The administrator will need to know the JDBC driver class, +the appropriate URL for use with his database, and a valid username/password for the database.

+ +

If the administrator wants to configure a database other than MySQL, it will be necessary to add the jar +or zip file containing the JDBC driver classes to the lib subdirectory of the installation directory. This +will allow Phoenix to properly load the driver when it is initializing the database repository. The MySQL +driver is pre-packaged with James.

+ +

Database repository paths typically begin with the prefix "db". The format is "db://<data-source>/<table>" +where <data-source> is the name of the data-source defined in the data-connections section. And <table> is +the particular table associated with the repository.

+ +

Mail, spool, and user repositories have JDBC-based implementations.

+ + + + +

This is a special repository type used only for mail repositories. DBFile repositories store the body of +a mail message in the file system, while headers are stored in the database. This allows the administrator +to minimize the size of data stored in the database, while conserving most of the performance of the +database repository.

+ +

Only mail repositories have dbfile-based implementations.

+ + +
+ + diff --git a/server/2.2.0/src/site/xdoc/serverwide_configuration.xml b/server/2.2.0/src/site/xdoc/serverwide_configuration.xml new file mode 100644 index 00000000000..9d60dbc191a --- /dev/null +++ b/server/2.2.0/src/site/xdoc/serverwide_configuration.xml @@ -0,0 +1,100 @@ + + + + + + James 2.1 - Global Server Configuration + + + +
+

There are a number of global configuration blocks that do not fall into any one +component. They have effects that are global in scope across the server. Some of +these blocks are crucial, while others can be ignored by any but the most sophisticated +server administrators.

+ +

This configuration block is defined by the James tag. All administrators +need to adjust this configuration block upon installation. It no attributes, but several +children, all of which are required. +

    +
  • postmaster - the body of this element is the address that the server +will consider its postmaster address. This address will be listed as the sender address +of all error messages that originate from James. Also, all messages addressed to +postmaster@<servername>, where <servername> is one of the domain names whose +mail is being handled by James, will be redirected to this email address.
    • +
  • usernames - this element has no body, but instead has three required +boolean attributes. These are ignoreCase, enabledAliases, +and enableForwarding. The first of these determines whether email user names +will be treated as case-insensitive or not. The second attribute configures whether local user +aliasing will be enabled. Finally, the value of the third attribute determines whether forwarding +to potentially remote users will be enabled.
    • +
  • servernames - this element determines exactly which mail domains and IP +addresses the server will treat as local. It has two boolean attributes - +autodetect and autodetectIP. The first attribute, if true, +causes the server to attempt to determine its own host name and add that to the list of local +mail domains. The second attribute causes the server to attempt to determine its own IP +address and add it to the list of local mail domains. In addition to these attributes, this +tag has zero or more servername children.
    • +
      +
    • servername - a single host name or IP address that should be added to the list of +mail domains that the server considers local.
      • +
    +
  • inboxRepository - This is a simple container tag which contains a single child element.
    • +
      +
    • repository - this defines the mail repository that will be used to store +mail delivered locally. This element has no body. The required attribute type +is always set to "MAIL". The required attribute repositoryURL addresses the +repository as described in the repository configuration section.
      • +
    +
+

+ + +

+This block controls general connection management. There are two elements. +

    +
  • idle-timeout - the number of milliseconds that it will take for idle +client connections managed by this connection manager to be marked at timed out. If no +value is specified, the value defaults to 5 minutes, 300000 milliseconds. A value of 0 +means that client sockets will not timeout.
    • +
  • max-connections - The max-connections parameter specifies the default +maximum number of client connections that this connection manager will allow per managed +server socket. This value can be overridden by each individual service. If no value is +specified, the value defaults to 30. A value of 0 means that there is no limit imposed +by the connection manager, although resource limitations imposed by other components +(i.e. max # of threads) may serve to limit the number of open connections.
    • +
+

+ + +

This block controls the low level file repository to file mapping. There is no need to modify this.

+ + +

This block controls the socket types available inside James. Unless you are intending to enable SSL, it +shouldn't be necessary for you to adjust this block. For modifications to this block that are required to +enable TLS, see the using TLS section.

+ + +

This block controls the thread pools available inside James. Only expert administators should modify +this configuration.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/smtp_auth.xml b/server/2.2.0/src/site/xdoc/smtp_auth.xml new file mode 100644 index 00000000000..7e3577f3509 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/smtp_auth.xml @@ -0,0 +1,70 @@ + + + + + + James 2.1 - Using Authenticated SMTP + + + +
+

Authenticated SMTP is a method of securing your SMTP server. With SMTP AUTH enabled senders who wish to +relay mail through the SMTP server (that is, send mail that is eventually to be delivered to another SMTP +server) must authenticate themselves to James before sending their message. Mail that is to be delivered +locally does not require authentication. This method ensures that spammers cannot use your SMTP server +to send unauthorized mail, while still enabling users who may not have fixed IP addresses to send their +messages.

+

Mail servers that allow spammers to send unauthorized email are known as open relays. So SMTP AUTH +is a mechanism for ensuring that your server is not an open relay .

+

At this time James only supports simple user name / password authentication.

+ +

Configuring James for Authentication SMTP is a multi-step process. It requires several adjustments of +the config.xml. To enable SMTP AUTH, do the following:

+

First, as mentioned above, SMTP AUTH requires that James be able to distinguish between mail intended +for local delivery and mail intended for remote delivery. James makes this determination by matching the +domain to which the mail was sent against the <servernames> element of the James configuration block. Any +local domains should be explicitly listed as <servername> elements in this section.

+

Second, James is configured out of the box so as to not serve as an open relay for spammers. This is done +by restricting the IP addresses from which mail will be accepted using the RemoteAddrNotInNetwork mailet. This +restriction must be lifted before users can send from arbitrary clients. To do this, comment out or remove the +mailet tag containing the class attribute "RemoteAddrNotInNetwork". This tag can be found in the spoolmanager +configuration block, in the root processor configuration.

+

Third, set the authRequired element of the smtpserver configuration block to "true".

+

Fourth, if you wish to ensure that authenticated users can only send email from their own account, you may +optionally set the verifyIdentity element of the smtpserver configuration block to "true".

+

Fifth, restart James. This will pull in all of your configuration changes.

+ + +

Finally, you need to verify that your configuration was done correctly. This step is +important and should not be skipped.

+

Verify that you have not inadvertantly configured your server as an open relay. This is most easily +accomplished by using the service provided at ORDB.org. ORDB.org will +check your mail server and inform you if it is an open relay.

+

It is extremely important that your server not be configured as an open relay. Aside from potential +costs associated with usage by spammers, connections from servers that are determined to be open relays +are routinely rejected by SMTP servers. This can severely impede the ability of your mail server to +send mail.

+

Of course it is also necessary to confirm that users and log in and send +mail through your server. This can be accomplished using any standard mail client (i.e. Outlook, +Eudora, Evolution).

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/smtp_configuration.xml b/server/2.2.0/src/site/xdoc/smtp_configuration.xml new file mode 100644 index 00000000000..ef0ab3002c9 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/smtp_configuration.xml @@ -0,0 +1,85 @@ + + + + + + James 2.1 - Configuring the SMTP Service + + + +
+

The SMTP service is controlled by a configuration block in the config.xml. +The smtpserver tag defines the boundaries of the configuration block. It encloses +all the relevant configuration for the SMTP server. The behavior of the SMTP service is +controlled by the attributes and children of this tag.

+ +

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if +not present.

+

The standard children of the smtpserver tag are:

+
    +
  • port - This is an optional integer value. This value is the port on which this SMTP server is configured +to listen.If the tag or value is omitted, the value will default to the standard SMTP port, 25.
    • +
  • bind - This is an optional value. If present, this value is a string describing +the IP address to which this service should be bound. If the tag or value is absent then the service +will bind to all network interfaces for the machine.
    • +
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" +server socket factory is used to generate the server socket for this service. If it is false, the +"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType +tag which is described under the expert configuration options.
    • +
  • handler - This is an artifact preserved for backwards compatibility. This tag +was used to group related parameters. It should disappear in future versions.
    • +
      +
    • helloName - This is a required tag with an optional body that defines the server name +used in the initial service greeting. The tag may have an optional attribute - autodetect. If +the autodetect attribute is present and true, the service will use the local hostname +returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In +this case, if no body is present, the value "localhost" will be used.
      • +
    • connectionTimeout - This is an optional tag with a non-negative integer body.
      • +
    • authRequired - This is an optional tag with a boolean body. If true, then the server will +require authentication before delivering mail to non-local email addresses. If this tag is absent, or the value +is false then the client will not be prompted for authentication. Only simple user/password authentication is +supported at this time.
      • +
    • verifyIdentity - This is an optional tag with a boolean body. This option can only be used +if SMTP authentication is required. If the parameter is set to true then the sender address for the submitted message +will be verified against the authenticated subject.
      • +
    • maxmessagesize - This is an optional tag with a non-negative integer body. It specifies the maximum +size, in kbytes, of any message that will be transmitted by this SMTP server. It is a service-wide, as opposed to +a per user, limit. If the value is zero then there is no limit. If the tag isn't specified, the service will +default to an unlimited message size.
      • +
    +
+

There are a few additional children of the smtpserver tag that are appropriate for advanced +configurations. These should only be used by expert administrators. All tags in this group are optional.

+
    +
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the server socket factories specified in the socket manager block. Any other +value will result in an error. If present, this tag overrides the useTLS tag.
    • +
  • threadGroup - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the thread groups specified in the thread manager block. Any other +value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • +
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client +connections that this service will allow. If no value is specified, the value defaults to that specified in +the connectionmanager block. A value of 0 means that there is no limit imposed +by the service, although resource limitations imposed by other components +(i.e. max # of threads) may serve to limit the number of open connections.
    • +
+
+ + diff --git a/server/2.2.0/src/site/xdoc/spoolmanager.xml b/server/2.2.0/src/site/xdoc/spoolmanager.xml new file mode 100644 index 00000000000..245cd3e78c8 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/spoolmanager.xml @@ -0,0 +1,85 @@ + + + + + + James 2.1 - The SpoolManager, Matchers, and Mailets + + + +
+ +

James separates the services that deliver mail to James (i.e. SMTP, FetchPOP) +from the engine that processes mail after it is received by James. The +SpoolManager component is James' mail processing engine. James' SpoolManager component +is a Mailet container. It is these mailets and matchers that actually carry out mail processing.

+ +

Core to the SpoolManager operation are Matchers and Mailets. A Matcher is a +simple object that checks whether a mail message matches a particular condition. +A mailet is another type object that processes an email message in some way. Some +typical tasks appropriate for a mailet would be adding a header, delivering the message +to a local repository, or handling remote delivery. Both the Matcher and Mailet APIs are +public, allowing James users to write their own custom matchers and mailets. James +comes with a large set of pre-built matchers and mailets.

+ +

Matchers and mailets are used in pairs. At each stage in processing a message is checked +against a matcher. The matcher will attempt to match the mail message. The match is not simply +a yes or no issue. Instead, the match method returns a collection of matched recipients. If the +this collection of matched recipients is empty, the mailet is not invoked. If the collection of +matched recipients is the entire set of original recipients, the mail is then processed by the +associated mailet. Finally, if the matcher only matches a proper subset of the original recipients, +the original mail is duplicated. The recipients for one message are set to the matched recipients, +and that message is processed by the mailet. The recipients for the other mail are set to the +non-matching recipients, and that message is not processed by the mailet.

+ +

More on matchers and mailets can be found here.

+ +

One level up from the matchers and mailets are the processors. Each processor +is a list of matcher/mailet pairs. During mail processing, mail messages will be +processed by each pair, in order. In most cases, the message will be processed by +all the pairs in the processor. However, it is possible for a mailet to change the +state of the mail message so it is immediately directed to another processor, and no +additional processing occurs in the current processor. Typically this occurs when the mailet wants to prevent +future processing of this message (i.e. the mail message has been delivered locally, +and hence requires no further processing) or when the mail message has been identified +as a candidate for special processing (i.e. the message is spam and thus should be +routed to the spam processor). Because of this redirection, the processors in the +SpoolManager form a tree. The root processor, which must be present, is the root of +this tree.

+ +

The SpoolManager continually checks for mail in the spool repository. When +mail is first found in the repository, it is delivered to the root processor. +Mail can be placed on this spool from a number of sources (SMTP, FetchPOP, a +custom component). This spool repository is also used for storage of mail that is +being redirected from one processor to another. Mail messages are driven through +the processor tree until they reach the end of a processor or are marked completed +by a mailet.

+ +

More on configuration of the SpoolManager can be found here.

+ +

Much of the power of James lies in the SpoolManager component. Custom matchers and +mailets can be easily developed to address an administrator's particular needs. The +processor tree can easily be configured to sort, filter, and deliver mail based on any +number of criteria. Mail administrators new to James should spend some time learning how +to configure the SpoolManager to meet their needs.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml b/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml new file mode 100644 index 00000000000..da3f4846072 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml @@ -0,0 +1,99 @@ + + + + + + James 2.1 - Configuring the SpoolManager + + + +
+

The SpoolManager is controlled by a single configuration block in the config.xml. +The spoolmanager tag defines the boundaries of the configuration block. The behavior of +the SpoolManager, most importantly the routing of mail messages through the processor tree, +is controlled by this block.

+ +

The spoolmanager tag has a few simple children. These are:

+
    +
  • threads - This is a required positive integer element. It specifies +the number of threads the SpoolManager will use to process messages in the spool. This +parameter tends to substantially impact performance, so it is advisable to tune it in production +configurations.
    • +
  • mailetpackages - This is a required container tag. It contains some number +of mailetpackage children. The body of each of these mailetpackage +elements is a Java package name. It is these packages that contain the classes to be instantiated +as mailets.
    • +
  • matcherpackages - This is a required container tag. It contains some number +of matcherpackage children. The body of each of these matcherpackage +elements is a Java package name. It is these packages that contain the classes to be instantiated +as matchers.
    • +
+ +

The remaining SpoolManager configuration elements are complex enough to require a more in-depth +discussion.

+ + +

In addition to the child elements discussed above, the SpoolManager tag can have several +processor children. It is these tags and their children that define the processor tree +for the SpoolManager.

+

Each processor has a required attribute, name. The value of this attribute must be +unique for each processor tag. The name of a processor is significant. Certain processors are required +(specifically root and error). The name "ghost" is forbidden as a processor name, as it is used to denote +a message that should not undergo any further processing.

+

The James SpoolManager creates a correspondance between processor names and the "state" of a mail as defined +in the Mailet API. Specifically, after each mailet processes a mail, the state of the message is examined. If +the state has been changed, the message does not continue in the current processor. If the new state is "ghost" +then processing of that message terminates completely. If the new state is anything else, the message is +re-routed to the processor with the name matching the new state.

+

The root processor is a required processor. All new messages that the SpoolManager finds on the spool are +directed to this processor.

+

The error processor is another required processor. Under certain circumstances James itself will redirect messages +to the error processor. It is also the standard processor to which mailets redirect messages when an error +condition is encountered.

+

The transport and spam processors are two useful, but optional, processors that are included in the out of +the box configuration. These processors include logic for actual mail delivery and spam handling respectively. More +information on these processors can be found in the default config.xml.

+

Each processor element has zero or more mailet child elements. Each of these elements describes a +matcher/mailet pair. The ordering of the mailet children is crucial to the configuration, as +it is the order in which pairs will be traversed in the processor.

+

It is this mailet element that is at the core of the SpoolManager configuration.

+ + +

Consider the following simple mailet tag:

+<mailet match="RemoteAddrNotInNetwork=127.0.0.1" class="ToProcessor">
+<processor>spam</processor>
+</mailet>
+

The mailet tag has two required attributes, match and class.

+

The match attribute is set to the value of the specific Matcher class to be instantiated with a an +optional argument. If present, the argument is separated from the Matcher class name by an '='. Semantic +interpretation of the argument is left to the particular mailet.

+

The class attribute is set to the value of the Mailet class that is to be instantiated.

+

Finally, the children of the mailet tag define the configuration that is passed to the Mailet. The +tags used in this section should have no attributes or children. The names and bodies of the elements will be passed to +the mailet as (name, value) pairs.

+

So in the example above, a Matcher instance of RemoteAddrNotInNetwork would be instantiated, and the value "127.0.0.1" +would be passed to the matcher. The Mailet of the pair will be an instance of ToProcessor, and it will be passed the (name, value) +pair of ("processor", "spam").

+

James includes a number of pre-packaged Mailets and Matchers. A list of provided Mailets may be found +here. A list of provided Matchers may be found here.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/summary.xml b/server/2.2.0/src/site/xdoc/summary.xml new file mode 100644 index 00000000000..b534a06d675 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/summary.xml @@ -0,0 +1,116 @@ + + + + + + James 2.1 - Component Summary + + + + +
+ +

James is an open source project intended to produce a robust, flexible, and powerful +enterprise class server that provides email and email-related services. It is also designed to +be highly customizable, allowing administrators to configure James to process email in a +nearly endless variety of fashions.

+ +

The James server is built on top of the Avalon Framework. The standard James distribution +deploys inside the Phoenix Avalon Framework container. In addition to providing a robust +server architecuture for James, the use of Phoenix allows James administrators to deploy +their own applications inside the container. These applications can then be accessed during +mail processing.

+ +

The James server is implemented as a complete collection of servers and related components that, taken together, +provide an email solution. These components are described below.

+ +
+
+ +

The POP3 protocol allows users to retrieve email messages. It is the method +most commonly used by email clients to download and manage email messages.

+ +

The James version of the POP3 service is a simple and straightforward implementation that +provides full compliance with the specification and maximum compatibility with common +POP3 clients. In addition, James can be configured to require SSL/TLS connections for +POP3 client connecting to the server.

+ +

More information on configuring the POP3 service can be found here.

+ +
+
+ +

SMTP (Simple Mail Transport Protocol) is the standard method of sending and delivering +email on the internet. James provides a full-function implementation of the SMTP specification, +with support for some optional features such as message size limits, SMTP auth, and encrypted +client/server communication.

+ +

More information on configuring the SMTP service can be found here.

+ +
+
+ +

NNTP is used by clients to store messages on and retrieve messages from news servers. James provides +the server side of this interaction by implementing the NNTP specification as well as an appropriate +repository for storing news messages. The server implementation is simple and straightforward, but +supports some additional features such as NNTP authentication and encrypted client/server communication.

+ +

More information on configuring the NNTP service can be found here.

+ +
+
+ +

FetchPOP, unlike the other James components, is not an implementation of an RFC. Instead, it's a +component that allows the administrator to configure James to retrieve email from a number of POP3 +servers and deliver them to the local spool. This is useful for consolidating mail delivered to a +number of accounts on different machines to a single account.

+ +

More information on configuring FetchPOP can be found here.

+
+
+ +

James separates the services that deliver mail to James (i.e. SMTP, FetchPOP) +from the engine that processes mail after it is received by James. The +SpoolManager component is James' mail processing engine. James' SpoolManager component +is a Mailet container. It is these mailets and matchers that actually carry out mail processing.

+ +

More on the structure of the SpoolManager and the Mailet API can be found here.

+ +
+
+ +

James uses a number of different repositories to both store message data (email, news messages) and +user information. User repositories store user information, including user names, authentication +information, and aliases. Mail repositories store messages that have been delivered locally. Spool +repositories store messages that are still being processed. Finally, news repositories are used to +store news messages. Aside from what type of data they store, repositories are distinguished by +where they store data. There are three types of storage - File, Database, and DBFile.

+ +
+
+ +

James provides a simple telnet-based interface for control. Through this interface you can add +and delete users, configure per-user aliases and forward addresses, and shut down the server.

+ +

More on the configuring the RemoteManager can be found here.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/usingTLS.xml b/server/2.2.0/src/site/xdoc/usingTLS.xml new file mode 100644 index 00000000000..a2d25ec76c2 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/usingTLS.xml @@ -0,0 +1,89 @@ + + + + + + James 2.1 - Using TLS + + + + +
+ +

+This document explains how to enable James 2.1 services to use Transport Layer Security (TLS) for encrypted client-server communication.

+ + +

James uses the Sun Java Secure Sockets Extension (JSSE) infrastructure to provide TLS/SSL +sockets. JSSE comes packaged with several vendor Java distributions (i.e. Sun Java 1.4.x, +IBM Java 1.3.x). For these distributions, please follow the vendor provided instructions for +configuring the JVM to use JSSE services.

+ +

If you are using a Java distribution that does not include JSSE as part of the +distribution you will need to download the JSSE package separately. It can be obtained from +here. Please follow Sun's instructions for installation +and configuration of JSSE.

+

In either case, you will need to statically define a JSSE TLS provider. In general, this +is the default installation.

+

Once you've installed JSSE, James still needs to be configured to take advantage of the JSSE +functionality.

+ + +

To use TLS/SSL inside James you will need a certificate keystore.

+ + +

The out of the box configuration file contains a template for the SSL configuration in place. Specifically, +in the sockets block, under the server-sockets element, there is a commented out factory with the +name "ssl". The first step to configuring the server socket factory is uncommenting out this element.

+

The factory element contains several children. Of these, it should only be necessary to adjust two or three children.

+

The required file element specifies the location of the keystore to be used by the factory. This is specified +as a file path using Unix-style formatting. The path is taken to be relative to the apps/james/ subdirectory of +the application installation directory unless an absolute path is specified.

+

The password element should be set to the keystore password. This password should have been specified +when the keystore was created, and it is required to open the keystore. This value is required.

+

Finally, it may be necessary to adjust the type element. This element can take on any keystore type +supported by the JSSE provider being used (see the JSSE documentation for details). The out of the box +configuration specifies JKS (Java Keystore).

+

The remaining children should not need to be deleted or adjusted.

+ + +

Each of the services - SMTP, +POP3, NNTP, +and RemoteManager - supports use of TLS. Each of +these services has an optional boolean configuration element useTLS which is used to toggle +use of TLS for the service. When this value is set to true, that particular service will use the "ssl" +server socket factory to spawn server sockets.

+ + +

After you've configured a particular service to use TLS/SSL connections, the service port +should no longer accept unencrypted TCP/IP connections. This can be tested by using a telnet +client to directly connect to the service port. The telnet connection should simply hang until +the client times out.

+

+To validate that the port is properly accepting SSL connections an SSL client can be used to +open a connection to the service port. One such client is OpenSSL, available from the +OpenSSL web site. Follow the instructions provided with +the SSL client to create a connection to the service port. Upon connection, the usual +service greeting should appear.

+ +
+ + + diff --git a/server/2.2.0/src/site/xdoc/using_database.xml b/server/2.2.0/src/site/xdoc/using_database.xml new file mode 100644 index 00000000000..b7b2d7ed156 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/using_database.xml @@ -0,0 +1,143 @@ + + + + + + James 2.1 - Using a Database + + + +
+

James has the capacity to use a JDBC-compatible database for storage of both message and user +data. This section explains how to configure James to utilize a database for storage.

+ +

Using James with a database backend has certain requirements. Database configuration is +extremely vendor-specific, so we can only state the requirements in general terms.

+

There must be a database instance accessible from the James server. An account with appropriate +privileges (select, insert, delete into tables, and on initial startup creation of tables) and +with sufficient quota for the data to be inserted into the database must be available. Also, +since James will use JDBC to access the database, an appropriate JDBC driver must be +available for installation.

+

It is important to verify the functionality of the database before attempting to configure +James to use it as a repository. This will help ensure that configuration issues are properly +identified.

+ + +

Configuring the Phoenix container to work with JDBC is the first step in enabling James database support.

+

First, Phoenix must be able to load the JDBC classes. To make these classes available to Phoenix, place the +jar/zip files for the JDBC driver in the lib subdirectory of the James installation directory. Any additional +libraries upon which the JDBC library depends that are not part of the standard Java distribution should also be +added to this directory.

+

Please note that a MySQL driver is included as part of the James distribution and +so there is no need to add such a driver to the lib directory.

+

Second, the config.xml must be modified so that Phoenix initializes the database connections. The relevant +configuration is in the database-connections block. The database-connections tag has only a single child tag, +data-sources. This latter tag is a simple container tag for a number of child elements. It is these child +elements, data-source elements, that define the database connections.

+

Each data-source tag has a required attribute, name. This value +must be unique to each data-source element. It is this name that will +be used to specify the database connection in other parts of the config.xml file.

+

The data-source element has five children, all of whom are required. +

    +
  • driver - The class name of the database driver to be used.
    • +
  • dburl - The JDBC connection URL for your database/driver.
    • +
  • user - The user id of the database account to be used by this connection.
    • +
  • password - The password of the database account to be used by this connection.
    • +
  • max - The maximum number of JDBC connections to be used concurrently by this data-source.
    • +
+

+ +

Generally, you simply configure these entries in the config.xml +file, which are commented, in order to use a database with James. You +would then use the db: or dbfile: prefix instead of the file: prefix +for a particular repository. You are currently free to mix and match +your use of these different storage types for different repositories. +See Repository Configuration for +more details. A sample configuration is described below.

+ + + +

The precise SQL statements used by James to modify and view data stored in the database are specified in +an external configuration file. The sqlResources.xml file +(which can be found in the apps/james/conf directory) is a sample configuration file that contains the SQL +statements used by James. The purpose of each of these statements, as well as the repository with which +they are associated, is documented in situ.

+ +

If you are using a SQL database with unusual SQL commands or data types, you may +need to add special entries to this file. The James team +does try to keep sqlResources.xml updated, so if you do run into a +special case, please let us know.

+ +

Also, if the database tables are not created a priori, but rather are to be created by James +upon startup, special attention should be paid to the "create table" statements in this file. Such +statements tend to be both very database and very database instance specific.

+ + + +

The config.xml file has commented out examples for MySQL and +MSSQL data sources, and for each of the standard repositories. For +example, to use MySQL, you would uncomment and adjust the following +data-source element.

+ +

You must create the database, in this case named +mail, the user, and assign the user privileges. +You may create the tables before running James or, if you so choose, James +will automatically create the tables it needs. In the latter case the user +must have table creation privileges.

+ + +<data-source name="maildb" class="org.apache.james.util.mordred.JdbcDataSource"> + <driver>org.gjt.mm.mysql.Driver</driver> + <dburl>jdbc:mysql://127.0.0.1/mail</dburl> + <user>username</user> + <password>password</password> + <max>20</max> +</data-source> + + +

Once the data-source element has been created, it can be referenced elsewhere in the config.xml +file. For example, the following element tells James to use the maildb data-source and dbfile +storage mechanism for the message spool:

+ + +<spoolRepository> + <repository destinationURL="dbfile://maildb/spool/spool" type="SPOOL"/> +</spoolRepository> + + +

The following element tells James to store mailboxes in a the maildb data-source:

+ + +<inboxRepository> + <repository destinationURL="db://maildb/inbox/" type="MAIL"/> +</inboxRepository> + + +

The configuration file contains further examples.

+ + +

There are some vendor-specific subtleties in using databases with James that have been observed +by some users. These issues (and methods to resolve them) are recorded on the +James FAQ as they are reported. Please consult the FAQ if you encounter any +difficulties.

+ +
+ + diff --git a/server/pom.xml b/server/pom.xml new file mode 100644 index 00000000000..87baec87ee9 --- /dev/null +++ b/server/pom.xml @@ -0,0 +1,94 @@ + + + + 4.0.0 + org.apache.james + james-server-root + JAMES Server + 1.0-SNAPSHOT + + Apache JAMES Server + + pom + + org.apache.james + james-project + 1.1-SNAPSHOT + + + 2.2.0 + + http://james.apache.org/server/ + 2006 + + + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/server + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/server + http://svn.apache.org/viewvc/james/project/trunk/server + + + + + james-server-website + scp://minotaur.apache.org/www/james.apache.org/server/ + + + + + jira + http://issues.apache.org/jira/browse/JAMES + + + + continuum + + + mail + + +
server-dev@james.apache.org
+ + + + + + + Server User List + server-user-subscribe@james.apache.org + server-user-unsubscribe@james.apache.org + http://www.mail-archive.com/server-user@james.apache.org/ + + + Server Developer List + server-dev-subscribe@james.apache.org + server-dev-unsubscribe@james.apache.org + server-dev@james.apache.org + http://www.mail-archive.com/server-dev@james.apache.org/ + + + James General List + server-general-subscribe@james.apache.org + server-general-unsubscribe@james.apache.org + http://www.mail-archive.com/server-general@james.apache.org/ + + + + + \ No newline at end of file diff --git a/server/src/site/resources/css/site.css b/server/src/site/resources/css/site.css new file mode 100644 index 00000000000..315b8a9d8ea --- /dev/null +++ b/server/src/site/resources/css/site.css @@ -0,0 +1,31 @@ +/* + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +*/ +#apacheconbox { + margin: 20px 0px 0px 20px; + padding: 10px; + border: 1px solid #ccc; + background-color: white; + background-image: url(../images/button-top.gif); + background-repeat: repeat-x; +} +#apacheconspacer { + float: right; + margin: 0px 0px 10px 10px; + background-color: white; +} diff --git a/server/src/site/resources/images/asf-logo-reduced.gif b/server/src/site/resources/images/asf-logo-reduced.gif new file mode 100644 index 0000000000000000000000000000000000000000..93cc102077a940966a0bf6d77e74ac273a10ef8f GIT binary patch literal 6636 zcmW-jdpy&NB^`k5({Ud=*EWJLJM77(p_7Ubjo^?L{6ozBTG zrT8~-uT3`YA6z(iU(uWv#wdC?*LrZ+m}~LRdiKU&$f@Oy^oJ`=i6+hgRAVF_PDwp- ztgxs!1ZD4l68M_KW_UVk-#Q!$Pa@K2Br166_?3pnI2h|A-a0BAXQR5&A?Fpb?Gb8 z2*k5oCs=r^?5ey-sZ^AxYup^lC`5wE?{)1hj19^$$^{?dW+pEpj_VrXL%+<@Wf;^t zJCdiUvs(#-G^G|kfoFntz873~ctb_>t(@D#$7q=4Jv#>J`Qv=$b>~!(=u%)Bm4nQx4G0uy}~g_xl^(YUhBvak#5 zgOuvw;WT+BuH_Fe^Qfh^cx6`2s#Q)p=qizh0B=u>WgT3-Um`*}GI*J|%p$EpRN<4Y zGf~z{=<@Z%ciE4S^38-`SDls-3H17pfQxW&*i~EFS~THa;&q8l$;Vfpq4`<-XV(d$ z`-SexHAn1eerw`+&nuVTz17YrVcMN=n%6b~Pk7R#fQs2Gpwl_l;)!9Zix3)AS!c&C zQ34C)+gAHfADmZ#J!@ouF>Xj{z_YVB18pQxGV z#8&ZYQIjf}4+ukXt98XP)EbGFTjdXCr7XQ<39V`EX@7dX7sgi%K^WawfM#Gv=)Aa1 z+o?NS!01`I1iDVjJKI}zgx$&^C5Ef~EU7JH?OH!a+{=QV@_zU`-5PH*I zPuRv#n3aaLEiBR7@r{SVvX-}mUhuV3xb?k!BFIAH>qbPzbWFRFgIRYuh*K-nKBmlY zXo!mHbNn_F82LJk8Y(6HVBaJGfDmIP$=s!3^Huul_S2gBtEE}_T2@5k_$OT|Hfb(5 z)X<#6D%iKo^EXxX4F^7^85Vz6sG)}#XEvtZDoScZ&v0xHPB;j%ar+w*l2aoKKDo2- zb9>!cbUD@Cqd08ehtuEgl-E^3le=d;7%p1%H-?USDXO&=Ns#x}Gv34#dLGHj^Mbev){8$exY)@D8txn4_GgU^Q#nGSmQLy^q-T1(e6TLYS zkyodfAaB@J5Bc38m*mNB>VrC0Ux|ebUq~Fex!-O z_3SLrfr{Ra$gx{pd(y!YKvCLGkH;%6{CVnQ{;UW?4*=tq1vDz`SEy-1yIj(V2R)ZFCY__!(Zs!f z`rl=^e16E7%Pt1a*QGNC=$-{`qOzJAu$vUT+P&2n>8pCwFvLX7zj^SYb`8p=S+0`E z$XYnM2{X2F1lL-FD1N}lfYe#DT)AY*L<*-3n_K(QvY5+XtlTfjs_Xqib0@!ESbnk! zSA5ArtJN=qF`{-hEnA~6zDFo%d=8mF^^sHw%D{yEh@{rPMqBF5>hB{?M8h{}t@d0a z$TBh@8x%i2xYqf->Z_kO?ik9N@?Tnd1s`-Sm~BEsL0u8q&B1GhLXeauby8lte(=TH z=AV&6s2Bxw4Bv}#m_ApmU%KiQkf8nY=}IGzQPzj<_?tbT?S^q>@387$GCgoZ>{a?} zs*!BKHygc@UGbJ=GHbM@>qZ!K2AH8?ChBt!Rc8lW$zk7VEIyd*pHZ< zE$>3tEVKs2MMV7_y;EJ&`Ixn`WSsRp6bJd9jN0ez7 z|Ma|Lc!>!cW3KHdjTYX+6Ie1ce`!;(oJVsG#TcaQP4A00xHl)OMsj5M5|l7eC(3az zDJOcF{El8dJ#Rzx_qnmF*i5mBua?=I@#wMvrXgR?ichil(W`n;21chubB`0YX{t^$lR@)6e zzxHWowXNRH^1Qj<$tzEf&Y^`bdfs&ERfbPdDZ3B53tO443vu5as^NZ_IwXJfQLrGe z*svE7@rd$rX)~s^qXx&9l&pV0F0Lg#>vRaEt0D{^yK6JYuX|TyX#+v*D)2mcq;*Cp zfmg+{`z{X8I**n$^E#AvnZc#GzrRAukx7ov5b^QQouH>j)7lqpVBE5P^}wWc9VJMF zl|RDZCikc^4kDE8%0ixL8a>;T0`GN{#v6|OnR?@tEUXAkxLJ7eVdS$v?N0>>6O+H` z^2{Fo2$O4$vb6y!ta9)n;7$uEBjvIC)aTjix?Ev&58b zTHCwd`4prf7n;f;4aFhXHwe2DD!6nD&voHBVW_e^kk z4BA-^s7S#3%MdJ4#z`=;Gr>L_NJXrykOQM%3PUrC{5VkM211p-l*eeZE_gIfIC*wHsp5pD4ONn{s>gfc~b%Z~YZ zfnp?qAD#z;w}Pl!;NNdN^7{Ah$UuBd#BGr$q;yX1IYErS2Le0Dx zqKPdB6#2#+aF1s2nU>;y3GRIxtU@)ZW|^FpfQ~=ZZp%^@YPfu9&Thx@P=y`kq&RXQ zrP!}nk8sM64X>6!PGY$JGH6aPF_geaVX2e20;v#Fg(T&7r%qiezhli!WB6VLkCZ*B zG&`?pe<1&KTg6Y!%9gm&{(-Dz0m4ZN2hm-2e=EFq8EYj6+(TS9F#>*%LhWhDO$Eqg(i@Bw z)ysu*&R-5ba{&B^X%ph=;~Ze6V^@UXC;oaVAh3nK4e=SJ+})Q!mhX`!p&LC@;->&y z*%W2taFQ)dn8M%$JL=tRX3)qPH=>dPFsJGwCA2L|HJ%mKj z+y{JohjEIwLdk)ki%L3nlF_un1W|C)_?oXdHHJxWEt5OSuAY78a@UvZQv>#fngy#D zda$eabAW`YbKVk=e-xVk`<#M<0C`~Vq#5R;JN!<{#bsQ{XJ#H_~xNkfws>)tk=Nd2=DuVh(`? zKbj9|62X&jT2m5yRsj^6*w}MyONIWHK+*)q!^jL_U2(Mwdv&9cwJ)Nvvpa7o8k)iy zo$y3h|0JtOk~^bd8{WmujPMc%sHVchB03^Sb~uD=9ux_+r#L6jz0P(=Y$!X|c){Km z?fLK}si+@jkFBv!Q@K0>0$w#6{ub%)YMSm>%~9uFy#et(ya<}gRQ2;ElN`gOWOB)M z?>DekR{i9Jsx8$4$*0#w)Bf5RkUxJ!K+o^z4rbhv;V_6(p-7uz?>a# zDmQ!+XacocAKJy4EE*aJ5_O zOl7@}o4eoGZTmg|$@UZeg7>|qstB=;z~yyP7^X&>6Iul9wdDbqR!|(HgI(~y4bEgj z%tqp_C+GnG6Eu5vYZwFarm%kO0S`>W{wXs4Bc*Kx9v*U#|E11@P&c^;w33o+rS3mX zZ^{t6E||fFhT*& z$DjcTq$Y2;o9%Wf9FZevyFIOXQdsN9MYJA58+<3}B-N#2cE!;z5WI==7sz?xMoOhz zCcFEp2Joy;%Tm{v(b4hj?*Q^*NLZjte-Cvs+}BwF*3RDM+ZvgK2YRtLoAP1um6~CC zw@>rEM)H;)OM3k2JaP$*d$h-ya-e6dr-4L468u-H8afR_e5*9CiF(K(Cm9J@isrWu;W$PP1TA^Q5f6Fvm^0E!e%5G?i3bKu z{Y_bc)_ET~Je&J>&|Ppxty-gD7^mFzg)*;3yK$m!uh89nW?=u;;J(Ukj}X{@$o$uk z$D||T{CMs~RQp&nti<#1&O(x{p7CHf|PgnQpY-@>Nvror76~GP}JT(kgx;Nb}5NhSZnAlLKawpPv{}C;)2hij} z-VORkhG$HWlVpA6+QO`}!i1jeMpnIN(Qw3S+*Ou5@BOsu;ShlNeakxDSlH5X@`wsZ-B=B^}t8EVN2WpeWtGP7&oYjaRX;8E)O+J)+0Eg`%&btht7o@_=5B zG}L1PyFKiFGCjmEgcCDdUcVCjw?p#*6+*WFo_@ZNNb6~LvrE2P1Ru4##STL3u4F3L z*$=Vae1mATs5Qf%z+bemF7Xbf3~@o!*q#q%6(KZ*3pVUEz8tvgS;Lvcg@LO8O#eXH zq>p^m_Q3Yl@-yi5M)=KD;6NHM`7vBn)9`{|U3AEtE=_e1P?$VMP7CLdHrY4?p-KJt z?4I-SV<|g?s@V3;aUsaKmh-9j@-TT;R2b6YKEmiZGJXW%GmD56}7a!qg*ZT093>v zRz?yK$i^kR0fx>=K=sg4p)3658SV*r>97F6DgYB65WZigcl|(D>z%LO=H`Mnn`wZ$ z17R)!YJR$CP66?+0Ra!Q>N@l%0q;r2xtIPhwW?=e^`9!vZwV17-} z`v&|Lxi`;X*yrlGVH2dVIefugw~g0%h=SUIP?B$j31DUvBdWX!RR_#(g^grxEaBNF zPBtudN<)iV+FZ!d+5hg+5J&Kc{8OETWxW%AhS&-JAzgnD!y2*9@s(5EO^-9pGAbx= zg#EdZxG!MeuOgDwu1+Avr1pU-1JvD&F&{S%|h`1jKPE8AZ9k@JRFi0v2K#muJ(ewI`fD=fye1%bs?&BeGF zZ;Kf*o`hYW^tpt?tq$ty>AH5Dulshs%z~6tiW1;GG`f9=Ly2Rh*sacZBEQUkRMCso zF(ECs$v<#4B+Ci`W8DE(IH(va?>eRhd&*Ws)cPcdW>57a3zdK*%pb*f<;JNtKI0 z-OK4Xju4k0B=B+2Gi?d-6YhU0Hg-u4T3_eoi!hE{=_4w2X!!hhR9UR3Z*bVfO^dB@ z%PGwF+v0V23+}E!LbhW#s?0(LXH?3&zWt$Tk-C=x5J4Uxye3j?S>N?L*6t@Ap4dt zcM)kz>l6V3L(wORWE4ZuXZU>MMajkfSMTVD^jZMsMn!gIo{f6w>v(K0>sOvxzEw=a zrNq05F^F4qmE!-zC(QGQ`ALI5Ao<%CXooIt<-mU(5n<_HaS8j zDuLZSYT+|{!Wh1VGuH~Ji%q}YTBR-VL>(y61_$YZ82tG5K;VJrr`+k+V ifk3o@FNQYto?ua@#Ta7 literal 0 HcmV?d00001 diff --git a/server/src/site/resources/images/james-server-logo.gif b/server/src/site/resources/images/james-server-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..f69394f6bbee48b5b336395a573aa484fe1e05dc GIT binary patch literal 6944 zcmWkxc|6mPAO3tk+w8E-%ze)>cNs;Y_%OH9=^LqY!p6C5~|M5J|u1;GmLv_J0U;+RJRY#^L#+n)$-(9#+ zy+3^Y&w6}p-1uGlNG0VswXXG*g(dO&`uZY+!B`s}&P~lsA(7YD*FJoB|F25w^6WKb zd99Ji1M9yA*2H4*>UwK-`ufKY$$R6)OMgGF{}C@Oj%r!KTWpd%yu_b>F5GSvul+J5 z$1bgZUlp%brx6yve_35y`8z8-Zejk+!>YIX>X*MCYpScS+S~8<3O^L~&+P1r)wRDr zmzS?JTswcZq@(55)cg67fyaFQLjVB&)6`r={zm}7`2X<#On`)#ewY`pk%{&wQXk&ai<(K@^JgErzM-gvFd(D2gsijs=b ziMEO;C26XnVoXu-*%Ie`l$z;QS$$kQDm^wWBN5NZqe>T^t8ZvLgwn$q7@*N7GLmgk zu~(Y)JCx4or#3z6f9w~Zg}&Wpt}hwSxqn5!CQqriZ{XjTublPuskUt!+R#L*o}z_P z;&|qLNlE?h!j;v>v^N^EZLP$E7yv=fB#PjHYWmSGDbF=6w+h)%@Qfr7;U7IGq-VzC zw?v8dHt~{0bazl|Q_ts(QPtv-d=>$nLa{GH)O|YjbxCX=|IOqT1b3uF_vyGWVtPcsvaZ(clg4kUw_ryM zS{`6SG-Dx~#(|H$N`FO)PXh^x6j*8t_ncT!lPy9a@Hn0zDDl%yRJWu;m_((a?4$BC z1X~)1j?ml&r-9qw#tcX;JuAvJw1^Wzi9k759T;KLfMg|E$`kBQxuViDel4LrICBB3 zxKTBES!@g>{UR3El;n!=GEJRfR(aM+8jZhk6AmS^| zx9&s}NrH-FZXS~rk~(3&Fm`BOzM>}SxS=x^RD=-(&COhG!lt(zITQ6lE(9kj|rZKWx!)+CkEM9DSotW zAL%$wc2hPg;;VehRV}d{QR4PZV}fcllaH5roMV6GSzil)z18Mxbf?t+_G3e*wSP<*?VC1r68u=L)VR173Y%55{^Mit~opR}< zqn*Rw8IV0rP|d2ZzgDXrNjb>r$8NtC87F%}{tu(sa+s1jZu)eaAwfW_ooM}QxQE@a zlgNb~$z;1XqhVgA{i@m`!AA6^$eoLIvauuwXABhh0DW}}5E%>f?L&Z+Ckvxz2J-KOohq*THAPi3)8RUok zqZ35y58bbFwEeY1`Xz#-M9>qEAm>d#ec?(AYYfWBHnm zy~Zk)<5B?2Y&Ou=uBrYEMr}5no%Zu7)nK`$s8YOthXYN|M_FiDk!tbsByc1~oUTr* zNYl&?wc20Dg={!l(g}iIz4y#q2Hhr&_~^F#+etCCORUU{Whv-zL_h^_iiFL8TU zxG3-nQDosv^?`SLH3NaZFk$0yV%sZXbZ; z(*HJtq28i2bxL%2)Y;%AWf&kN*B@wIJHOs(vGKLb5XHH|LB@!i4s2cIv?r%hGJ9Rr zgg|Y#}$n)kX?dhIZVTN=oTa2CJt21Lp!wbFCB|ciprB-HZ zwi^B!3~XhE;nhVfRR?l0{|}XVexPiXMvV$~$rMB7wZw$z;Y1n}VVV8n-I4Z3=X2l! zxyZfiHTKspeyNJKPC*eaPXoG3%sO|!3~Sj`XZ3mDYGBwDBKz*MI;UfK+bF&#9D1r8maluh^IZ(XHL_sf(BxSx1z@J1reMKfis;a9&Ejp;TBG z3lLC_-0tC!|M6|kpC8$|f%gV{@;r-96DmRpRiDiQQIH`d`_r!rt=gr4g?~2o)Q6V; z8SML5P=czAD~*&fGK7MT)&zbEJR8JglS%vKz6r%8Iy#gf4el*Tkb48EOMV3m-@!k+ zMxOO{uvkJ$FvQ}U7Vo4oL3B_mH6jk`u*?kTe z?vCGXD&Z>Pf$6l@dQa}2@6NB2QD1Y=t(!qdI)xHnsvfW&zkC0LN2(@9`mLM@s4+k2 zsu4+H8|1a!8a^lySXWXH<}{8 zz?t(y%J{`g`r!BBU6_saWwcKLl5>+DJL06{Mk3}OOp)b^GPSm_03-|}HCEh}&JF+f zjy`#x_f4|*l6+K!!okrW#d>|pFalUd_f1O=Y3U|Mu-|_>ex?7ja zq7DQ;f>EF4z9wt_@zN7LpLSf?LPlQxl-lu2V$C;!{GO!aD8YS>ImkXqnA2oTQvk$E zMy<;E2lv-^UxyOxzEt@1#Iym~~groMgMq*${F1wcp$Y2azZMePl?F*vUlcr!Oc9fe1PmrBY5mk@+FZ zEh4V?y}E9Pn~G2916IDpRkd^@Ch#KFgBx~@kFp;v4g-pNcbEU1$>&7twM{IfsN25- zgLUVs&SMJ;&B;1V>3aiTVw#pgX^YdV+M-laO&%W|0Dzc-T!hh&r*xth%PrPZhNiKh zBo-J@5K<&c(sW;xltU&5V!0mo;LTyXvcn=zePl4_KMah$BopT*1|P6LWbj1|o4S@r z3aQIwywtDzU!vzU9+Ep_-)bcD2T%C3{_VBH%P#4;Z4rW{zW+R(aA(LP-qs+@6t+ih z^4N;DGSxo1k(VI;E<(30#I}>lE}8}6^ccpe0zLTz3nCPT%W&RJLj0CE&i&wE zDnOWRP1`(;2>F08l|SB%+DB)k*)!rr{Ydu@DUPB9Q@=Fxgfz>Q6l*`EO&zjRB=<%u zNdw-T!IbKahN!>LimVt=5M?5Ql&L$+OPqq1fC+~kDt)`ZS~y!$O!mKnDgyUZ}FJ!_**y8jd8NhC)h)`Fev@x*LGyQyo)>2e*s;%q+ht`7rg9(YKRMo zCjmMzM269wKIqqE5XVJGQJ@WsqC>rit#W|dHI}w8FT@*hyb>~j0a>iqb_SqA@*>h8 z6Izk{Dx}Sa6XTp8Hv(ypJu(e$U_^M8A~Li+gX4z7Xea= zCMO{T542`^TG1dRBg#w!s&GLwZHOQ|e)L3{3Jl53KrTv9>lCEJ0mEC^ik#D5xI3hI zU_Ml)!$&|AXu<**if0tbrGgX$hGDW@P)x}JOlUf^*GGRJS8UV^@~4#Uh|Z~MN7f!d zqL>#$bIy4(IKBHzCrS~QIfOzuTbUU}5d!Z_^|Xb+(d!_Mhj9A`k%9%yVCX4S&U+1* zF_K6?S;}=#V3}v;dfBv8DT9={oh@%gg3N@#cnl=Xhf=U*p$=+4qybG9Km>~V$Y&9Z zs3zBZU0qb+FNcfSNMnqn_>Muvihhuc_3RKY4o)(zEu{@kwH=Nu@JPW|Z` ziKs({sJw6tik76K9H*x#c_0VS;wefC^j=3JsI<$Pzd(I1q#j*Og5?SX?3wv9nX3@v zf`ToNZO8>CWSODC)KdRruYCEIA#hH6*+Qpb07_d-X6MQ z4+HNE5I2|&I~Fm|7miyo;cgbB>9>7S7qLviEaXDtN*7eP0KM&uwy2uK<4jdH%=$NN zosnINhWNY!Uy^k<>OgQAPe!?RC#TR$$r{(eOMhR<)klr<2`#^>l?C-bnj2Lp;H3+o zktn~+EZbx5xCv#WEff557bUq>&l2ri@pfd5|zu%0C{)I zC&Qy0!mbg4t4JPbBp|6Iq#ief8PO?cT#&aU(g;b-JAw4b!-}`!kb$2NVwnh3zm?~A zPmP4ZdP^*JT$*}f(eOjImqQ!)b`=U}hPLDaW*p4q!Bq8VZbPnae6+4wG&CUr5^0S# zo|IG9!GaP*vGrZ$=(}Yqe(9`+wZmn7qk)b38j@}()xlQp0iJxv%}#8Eq;-8)?!99H z^$sZ90V*=;MRNvxar-@tq3BSGGWV(0<%YqQjYF4M9i-7^$n_?|Vn)ucC7+80-EYcB zj@K?_<~QeJU-+pzWd_OH-Flk?r~<934ysi*QJ9M->72r+zNkYtk*f#KrCFT(^eHm< z=Dn*JO%}g-#EM2t1$P8QZJ?1f7-vivMDvw~;KUdAAR;5NN8fc6(F&^l2~#|xXB9`0G_*(nHd zV%>BR^>5jRdUWj}p5I))kAUYxwr&7E74kQ2eYaTMWU%#&AtF$@Wa}z|{0CynU`9D% z6Z9&J>!fGCNl3=Eu~LkgktY2QM%|9Mxfm3ad6(WEO1iLLt%HXOpRCN1=-nlHATkPS z4fk02jaZ!?X0V219N{y=4<&S{cwvKh5YQ7*l;HDyW3?uvj7!GI8P4%d7w<%lV#e>7 zng|EeaqUqb266D_=|wsIHVm&Ht(yf>d0_nP(5c+Io1zj1=YfAmME6AE!H8jJPLF48 zp^G3A|F&iR!lH0!A?OCa3z-FzO;Y+VgtI=x2d5&`cLT^Oz3FO&LD(#Yj0HTW}^woeLb% zgM82Avf7&)*0A~w@rgbM;i#~8=C8hKNcGmPN_LGTWW}aBhJuU0jjgDGT{6@ zZ{c)F5AvEynVOXqo8SyV6_*XWL9{40>VoD;Ez7#=}pJP?K>+N)SI z%BOr6cU~^(^m-pW=D8cvJAyG-S1^7l7rv2-V=lys(8YhcG(;Flf#f!}^G~~N-z!u5 zeSq^t4dTYmk2{zE`U%p(`QatMnv#_Ho4>t+XR_rJXUFnKpQXH0HTr~Nj=yLC%8%@$ zruc?Oy?2(kI7FP?{hBlcUp{TQQH^%{-Q6y#Bfe~mWE+f^bNnA_zfjtCgdo&2_oYY&L$%SJ{!Xd2Jero?$zjZyNxkPXj`5urL7bl$tq zhuS-%r*2zMlV}%~xQN#tn@i2q|0R4)cwp)3qfeZ6!XKlmOT9LyM+zo%0`OnB*Iko9@$XyZ`=s_Y_A5M{a^y}f1fxHCbUep{ zVvq!G;eSla2SCAyI%N@O-nufD^r{@w3*H#;US=_-mOYTJ$j45ii0+q>_d`6wFN%Bw z+@}N->l^ZYT$}fU7*0rqKVcy(G73S1+PT>>AVR|Y{9|VS)-|lnDENm1#7#=omHWu>n zW;BK|i4+z|lw2y-3Lzomtr*`|zMsPRsxqVlY>wc}%oJrE7@DdUvWkjFv@G^GIRsc7 z2|=1WF+CIw-F@8*(If|7j?=`27W;(y8vC!s$6Av2wI8;ht(s5%Ja*TxV(?qp>ii@LwpigzE-dgfw_;neJY(XQzRBfmcQv7e_FKPAQWE0nt zhj?9Q^~koqVe{}A6lk}>#X(UXL>Xa`4m`z0JG3KGHIdI0i|o3xim4vbeu+9gYT)X$ zxxka&mk&rJ3ur5dkW!pff(yfw-hbwH(ELo`MWp+=`>xO1*hXcI!L7dE*Z+@h(ZmN4vY|J_Bzna@DkqjBlpQhQnl$6SfCZ zQQ9XA@15C%g*I&7R@F9#IX=Y#1=5@}!fcbzlT z@ibPZ7OGwIfsT&Q4h<&Og$@{$MSdU9zuuXqk3ZHNYK@}&28!ra@It0?!n9pRW9jFO zkE!?1=Vd9sY=4ufmf-ROQxP%~+hPn7yajgPJ6an3!JiDIEb(Vern4r2<$=}DcsAy4 zIW{^?qDhxCHLpQ9x74S(Dq!Ze#G}h)ZH(WFOGH*_RPi%Y?zvj9o@Mn zIOfX&H(h#(rt7%Nn90o8W}j2}I7Pf_-ty`+Nc0o3u^XqEr=>jn<}ze#is!O43ly1I zs3(;rHZ;TL^e6{KcAZLlI<-V+*&%gk%bPq@>A4p=<6$Lb(W}JryNr{v7p8LI@beAA z^Ma$DcTc)qN?WoFuc(F{axgmjxB!%eCwQp0Y-^ z8YTwW!jvT=Yl$Mu`A*-i>vz4^`~B;8uJhdI+@JeC=X&nXIoI=fNT$a6B0`cv000p~ z1A-X<+z0?%8w56R5LJqfI|sOIdeY(q{BPrczZ=KnO#TV}bN)N@&xHTY|KA)A@*Dh} z{Qq+QxqoPAC@hnKuLzLg0(&FjXfB*(V6i}7AK2LePfu|BHlR>IemxX6G|ML@xVQcb`hfN>N+ODX88 z0YlEfSU;Hg06s5-EetpWurlB;CE%zF0!%=RJ;=HOs;+^~XfQzoFjoea5#TEq$cTi! zxp0&LX90&G6a_9WAT;zBJEf(7!2sjq9A2a#)PV2|gnke{fUuCm4u>yEEZA=f)GmV) zcY(zd;M4@XMnEW(jD}bWM6;nwDGaTJ6b3Bqhm3K~ZQ&Gb2|xe<6acCK7~)jBZ5upz z5E2N`))sns!N^FMnhMLx;AZ0CTF&uvIT`5_KqRk}0ml*aG_dvoKv?|O!__%-eU$_9 z`x>Gr_`A5dHty$rdC1(E6FY54z*__+%_K*~XYP^EJ>u(Z`PuPtf`ziwNtCuUdeb#! zzAJDp#Sn?CYup)_=5mh#3^yHpD{P(!nNZ?Slu zlP)?jc{KIVFdU96HW9gl=MUjS>j@m^39?b+W5Y>)i8R6ej!Z7z6vW3Q4EZ>GNm(vk z&;UVK%X!eca6G@n;Vv#-I|Cpzf$DNiA!)i7mHlL0xw%Ra?{Ylm3uysqM8w2ND3j+{ z;^)w?T&k}ku~0y{l-U^fju<>$O~4(|YVFJN^aw-F5c_Eoo6a4@RqQEK3G$QUk?WPs zAjvx5cyH{GS7 z+$oyz31L(rqUf@U^{$Yr`Kt%!+$JtGG@s?3N|``~EU&1krgUSDuKI|6>r!(o*_tS! zqtGEV-P}wL?mR|*zt=s4*X#0whZU2HV@u6G!QN!nAM>?p7EEH)XCJKeOxeVLxG?}1Z4kjNiE=L5NQ`^Z^7tO9S@nqbrQkS8^ zPv4ZmY&ASt;z}l6x$Fr-+L!v4Y`#(Bwu0nW+-Bh-*NoS!k)#-AqtP+Uz8~fH9X(~# zlg-V@V__!ahEc36`pFByHxd1ERKWI9_Id2J`a8(uhvbMV*AiK+oIj_e+s(}QrW26c z)V_%%=tpwRl{J zI{nnVN{D7oF0@mV586MlfJD6M1-K(;hUGpTJ!E8K`%3XlU^lmTo({A9nS+{JIw>P} z@j%Xud$rz$w>Nc$75S3`4dptr21(nT7iUkItTg@HTNZ;fn0x%hX^cbUW?dBivHR@;%-T4DKH$vh|Ht}$=!>sM?Luq|Pij4#2hHmG~L;kB*pc)`RQK)pIwB!-I^B zN?c3W0xK`{9=M{H-MWGYx+x}^NBzY-J{5l3SRwWQ|IlBb2qFVy;bE6sR$ zocATX@UK5^?p-SOyf8$+?I)F}exSc^M@xSE=Bj5#a(k#mSNr+d+-hr_ASRx=E3bOJ z`_jWM;=_GZM$Rk4XKG3|=%!O}V{yK>vE0+LmbP4=WF%0P7#!b|weD=lue#-_%7>R! z601$-On}LD-%VbztUn&PpM92Yrz7S(JJ{sWA%e@!=v|prj*Hp@JFNA>pHx}`D}mS0&0Rrd^M%~fa1uM5pt6jNx2XNKP&-Y0#f z;e{EVylh~tXdgt4Wb>fo8d-Nn4*lKTE<#oLYAYyhsY0<=-Ig7dS2Yn$>X{N zgE6CSW^PO+mMX?|L@rEU7InXh*0UN-cw#5RjR}cvxRwIL1FFS{yD3u)M>2K5c;p}B zIk0@5T=7`Q2{W2t5FIivjyF4wDc9sEF-NW5C4R2^WGyJ!!Sly&fFra;$aT3#c#Nle zc_?!DCX%*iUg}s6RM-nJ%X%dWAMOY~HIy62#ruDYbTOu($S;li6=*#owX~5l z@=5&$KVtojFq&NFo7Md?)$nlx*c)iW_{rB!Eyb<8wx8+q)*L8++f73 zIqqp0D%x4tqn1v88_5#>N$GjZ_xqRiO*C!B=0|Fp5-(qBkR|b_^1-NmMSI>6)g1<( z8G33Xib+y-6@0=nR3=6DjTuG*V|Dn})2^=jVRB+c%v)kx6FBt=sCbD2tW$TqrIl4f zZ=-lK_wT*`W$Wmt?B=yU2oH9x&Ah*Hb;abuOsVa_&%nzwalKJ*7k`YyZg1+O;2F*Z5cF zj;w#zz9s5F{_57!S?hi1r&oQVSKU(bl{GSbXwJe>&G%&O(D5E^cFHvIQuU!?v8$hpZ4oW&dJ8HlBBm`sx4$t+!4Tx+RYjcy4RPNPg z`$w>55S1YIvhCPC2_CvS`txP&jllO2pLMFvn~Bj@xBvZVP1fGG2G@`h>sFO|K-hQ2 zv#e^+r+V0*OkEWo*!wM*7q2jTHe{22TCAot3=3D*Y>n({EqSA}ZKqL;+sH*x@4_vI zXAa~^C!O8OlT#khQIi+TR)0r`ovgjSaNk;H*^;W+wAoJOoGqqyGQVZdZ7Yw?{u`pp z^o`o9$9uJ1tgHLd>D%kIS$n5nu^J1htSpJ*zQ*?-daDBt#w~p-*{CyeJ4#IY&s*{I zf;#=(Y)!kSp=bJOq-b9od4ALROp?{pZLLzxJk-b`R)ur{vtlxp9VcrhW+%Ktt$oQy zsxjKZ9}pg;9JAv_s?T_zNWot}q&Kg3zZdz}t@^k7QE^H1ob0_F$9d-sf5i+>7!wMP HIfnfQdu`W3 literal 0 HcmV?d00001 diff --git a/server/src/site/resources/images/james_config_secondary.png b/server/src/site/resources/images/james_config_secondary.png new file mode 100644 index 0000000000000000000000000000000000000000..2c29a53eba69116be76ab49f8679b18071103e99 GIT binary patch literal 5758 zcmbVPXIK;6wjMwM6-A0e6T|?DK;%FG0YL#7ngRytARtI@h9XM00)~JAQE8$HO79Sw z(xekg=zPD8LPKqhORatZfI|1;fFyaBKlwKt8Z%0kpXRI|L9c3dEv-0tJAq3QTDOumLaZ zAP@T+!I9oDF$yN-z|CZM2tXkKEeXI%3GmScA}oMpH=sNK=nMyD;sH1v0T-#l)pjsB z6z)rh$I0*#fIepG z07KMhIXGY>5>{1(&CFm71`Z8{lak<~BDgnm?a!kv#V{*G&Xlu-$16_ zmG6&}K|gA_HO#+nU#T6=T+(=iUmg`sbFfMT^S3y8IZIeV{$XjKdWq)=#E&CRK7!se z8Xs!zFE4E6JA;cj_B~X)f`Ftg9pygWP3y`c%m6;}_(vK2Au6TaiGo{$({(P3Xd4M|P9y=l@=QP;wMvh6OOp7C&hEuqa7{ho=f8+R`B>~*Uy zuQgKY=8Uf$R_s!V{kNiJ{r5=j=K?`|{j&1kGj7fDNQqga8^(mxrYvU%WXt4^PK*o@ z_7%B(PQ7e(q?GounZ61AVs!QqdjAgop|DvxGGFIL!Pv*cQ@77#W}WMAGvs;uTny~Y+dsYq@ znKgIvS~MRTBy4}X{i%P^gtZV#bddhW(LazAEc6TFYW?Lojg6ZCwF>Q5kBT*?h2;^Q zi%8|r@$uMZM_3I2K-LZfcN zo+$2$y}Mc#iRHGN)F^}L1|s;7)r5%$&bNt>z00NpotRT>bb0a8jV9@VDvI}7Z3}y! zgCde!@{Q?(k5^OGyBILlyytUM1JvejgvY<^3!q2NSoGBNJk_lyO7)+ z#L{+~Nu~$u`nTvb@)|Mzw5J9MjlAwwXvg@g`uwpz!!z=t8|Ndk6*)pf8gE$N~hRf@zi+gT(}`cwr341Yv)j0 zIUhDKiNdN5A+6ivyIpxG1_63dI(+ zP}*OR>8P@ZNSC8n)4O%J&3yf%-^~1fMmtQn4wHm`431wgBaR)ead>5Qr^Xv8Z&_IE zh&;M~-?yP6B7bNI;fB0BX(pPv1jcMSXyUc4(UW8m&043Spq64`(M@hw3KE$f7r)SU z(P^ghq<3Yu?0Ye+ByYAAdH~v%0(*9w?D?Xt{4d{{KZ-M%$|k8fzJvy*l|p z854Pb^<(a4QY&H1WjyDmO@+-|(Ni)8T>%Z*^Kujj3$4t{Yw_HD9@SK?#v@ZUjMDA* zl))bTg>!!~7F9kO69`}CcQ$#&>60Qkj9HR@b_6NX^x$qkjSe<~C1aoT0?N)G>LYLo z&AFpDr?FE7!dIs?;}L5P*BZ&bhGA9|&YwTu6<(cpN5e@prHRmf)39Sa;XSl&vor*5 zHP;Wai=WM{0^3O@Lh=>(N2Jv4uq7uJpV@1J1U%niHy2+L4%hcp&bjGppM&?5j8KGg zq1qnz1&dMcERWSFTBb~IS02uE=2LnzcCn@Ia@iyY=MKbi5ewD`e}n#B5*II`<|0EoE$7;*nQUG#ms<>Xd?Bg1ZE#jS^<-`H_mid)x0U!#gFTmH z^JV0=l1)^He<7nxZfb@>Qa)Ufg&NEr7tb*@g}I{ZI$Gmwn>n3y(xA1vsB2$l2c^<@ z)>G@qoYBWtSETKcgNW7YLX9b-Rz%#`8hG3GAxD@C)+sVO1{&KhJuNDs{Xq*vU%+8l z!h$J`GtJpmgw$HDB8{vVaDA5YmW1O1XGP0B@RP2B`C>n>$i&3R7Kn{~MM@4L0&I<5 z=WDbXXMB`D+#%-iTd=Hb04%MC5@J_5F*ocf0fLfZl2ZmR*zA3?9GRD!s`b_}c$cYg z3_e_`pwakSw5=E|-4S2fFeP>>4boBB@GP32C6tazl~ydm=dF$k(&7)eQtU6vjIcbV zambolgVR)=Js5ICUoxsvy{=J>59syJz@AW{gn0S9h12*DD@K^AX0Nu~WB!Y2+3CWR zyJ= zLcUQ>hwg5qe)?ZOH&u5vO*^7x zjb^x7kYm!0;2BVe&r~p~flv^U23f~!xA$D>J<%qx_EnR0JLDSISR~#}ue5h^w_N^P zd+N7D9g>EZS61d|y+~OKskJcF@bffd5NlhwrfIImS9ndu<;S883i2=$WLt2>zs`%j zEY`Vtg*Lil^)h!p6FwD6zQiV-=6%y+^lQw&b!js!$_uZs};pgw0O9&+s)`CsV@>I|i$98kyL(ax`(YWreq{SmB`} zYhUj$R>z+OiM+!TlW`|uu5yqn9mj67cucA!r?uZ#F23qrYA5ud;@Y1I8QENnJH0IY z84_d5bt;YX#Efa3Z&|KOpLA+pzd3-}$wG?}O^VDFOZXz<5XWa`$Z2QXkg{|V%tt~P zv09-enH1IZAQDk8yf`%e7-p-AAZgu}#CimzIgcq2TjQ(EQ+j8uSkAPnnkgIHwbz|> z@z;saz!ud-mn+YlKQ$VNh}_tVh#Ob7&|S4|qhVz6W5#(}<1={!lyiLSt~P7=bT}Ew zUbu4ar`x9)9p%dwmuvf5(4|ZPCTn!uFp37E8)szJu>M}}D@8~B8M%v{!_JP$1 zj`SnNz6GZCX9oo4t;u)r%V@)T9PISub*Pr|b&5jV^95#FFmYj;m<3TTa23dqQ>#Xa znFQb2czKmLb-j*TUacG$(TD1+bssHgbSk?&Y;CdD_Gj7HTEmhB3L1=9?9FPO%-E+{ z#L7fdp!%|Hu`H-vNDUf>0;eF0=p-apDlXe)bjm$(*llu zzdc|GDmD=t*bDv4YL9jmMIKL{LaHWh2P8nf1FylJJxyg@Q-#l^47x=cq-(B7krhTz zJIoDl-qVkWRL>XvSp1K|!}IhZ591&2_nPR1eh&%OUsE@g>GO zDp&Y;LkS~TO;G*)ZGgF4Exv=G#hg<`_y8hn(kDHvOlqyrLWamUbbjWCup)U*rKjH` zo$3!XW`#LlvLOF=1Mxx;C&6st~RYjy8qjn?O{v`w2& z?r}*H1(sbj*4N{OKX)$Z%Ig+5M3FRxW(ja)xwSQ_)S$lbOOM)i-h5y6Cb9%5_;vhi{|A`X%4w@_DbqkHyU(w(DzB{#s!|D#H z7)KklOa`BUXLvY7%b(?*`?n2%jr-eNxv771|Hl(3qjPpwyXp}5Xz+j$|4EGgy8%-7 z{LYo6FuO4iP${wgFB*LD<1F?)OX%qDF!3O>wNw-TmvkIg6*w0t{H!a4iP1NG4l9f$ z?=60x$_sqK1%zd*hC{u|qpK@bDG7U3Y}F{EgWuVMR;8#}p~AdKo@FgId<<#Alj+LX z!W}1KAVzfNhMFIXI}6WmY_hU?_>R@Kd$bIk&3UVMwcYKdi=1VVkMY{c@XMQ~lPz!? zb2w`K^70V)13!@Ro|}I)ebXaB_N)0Z^Tq3ij$w}(s@C&XsKw(i7?DJ(n5_wye8!!z z#rL=0p*T`QVt(2fJwT*@44@*b-d^cAq7pJ?W(1#i7sA}yW*3Tn8sF7mz`X-X>Bf@8 zqr|8ES*9o4qhb?(Y!N0Nsqxb~&>nmjuqzZY|B34V(`#7pOfN5rucl^L?zhXq=e9QY z*kprtzvTG+LcQS_2?t1fb!}r%pX;vBo1o3qfYRkOXg}bw;;~)i6Uo5Hs~lT8-NH45 z5tMiR{^Dbo-H}rK+)B*+t;rp1;; z7M(pY6Z$B2LS-O%|JO7+Np0Z18D{-MhGx5Rel92QAyo zrwl!G&mWYJ9?IBtVX;WUxqk!pex8YvdXo@;b+L12!M3djk)8A>2+LRC%z)d^4&(iu7dca! z1E&XXEo8NxyOOt;urDw#J81Uim*2iXx-rwk3h9CX=bcwi?qA`t_w5Yd5VfC-#^C3e zAw(gEN1brAezhL9;!5=BdO*=rC9%rEErTG>Zwd+V5lfm`of+e|2CpVRFRX62@7b8G zld+|k**yqcElM_s37A`*Hfp(1FSJQGwSc2|satkFxmv+~Uxois-?jpTU zwFtYr`v*?quO?+rgvj|y5pagMhNSwvL7oOn*Z7$gRV#PB>S4~W;B58I#$ik&C0B^q zGe~j7V^*LE%lF%{<1W_oguMk>qHKc%rHBT>GI_(4!2mh+zMRFFA*vSZoLb964;$i#hX%N3#oqFH_s0FP6)u z%w!Tp)nb#&)CR-%P3hq)+1=ldJTk8MRqqiuvnL9+adF8#tEtV16CbE3)+sry+;uE( zIeock->3RB9ig2g7Nl$;Hg<;3bF`IA_~Y+0)Upt@Jlu2ItlD#JTOJ;&w8yL^N7OuC z`fPw?Xi5zG7B%nfUK8l~i*8S@{0ZaQjsxX$r>pEvUQnOkW4Q;v`p?rzdi{uxO^Ez zL;wT<4<3M~CeYUhW@mYY@P;CUW)KEKmJRL101pPZS_|TPK-M%U zhM*G4KZAGTJfngrxsfD#R05un8ccn%b3B|@t_=vxI- zUck~}$N^XY$N;zl5DP#N04xB;ctC+Pl*U3V36fl(3k}i`h%h0O^M_v?kfec&JfJB7 z1Php2fP)8I5`Y%6@H`F%TfszMn3n>pO5qC*90vagNFG+=;WHP=iH7~faGV3@0S^#~ z1YBGIjrIo}CKGTtfXn4^k%bTkp%sL_5T-y_%A>>MC5;7p$w1v57{mheBH+XVo@0Op zrQ;zMfusWH!i2O&h;ShDE#z={-NGx_0swyi5CCcc80J+gApw<@As!Fy?4YM7jE;sm zIk2)4Qad{-yhh=3GBL!1=zqx?@e-lSMmF96tl#vZ z{@As=b7=4Ic*$Ya16$0*$9}j9OHuf>uG5H5{pC=L3A@B~z4%ksEv=*Sk2&TGRD`MX zNgYGW3E*Xu`09k(0ESOWj!P36B^_Iv#7lJrDS*n4p%Ft+w{vy9>#O^5VyeRtDf;x} zX-5>|^9`LHrR5po+qCObmiBRU zc?)CNLg?^Ql%PT%Tg^e%x#vj42C+onBtnah>9$)|3eN&4iJ#G7?|I7Wy3CQg^yA(g zc~;*JB3GPcDJc~?fy)-U=eOH*=Dx}mk84}Ze90L2!N4VdnU>JuWc`R}clK)jb_*xe zG5#vNqw>)M;(W$!8?^Ndxf(Y;Vfi(kEuxg&hpBN5a6(QS=cF~+n<%8SQ*oZ$ZjBVz z0Myd)1Tl;vE8B2sk&I{0WFT&egqg$v;M`g&ZRg!Ib{`Gac zQ*?Y=u=d6LQ{<3B#m~!`Mtc|0KFZzLgcD^prhVk~F5NMQ5-pDf4;fEgagQ`qp$FU~ z9h?q$)Z8vmA0u&MCmr)}WFoAFy*wb2Xp7#U%H4*mS-Vh$k@}r2N--0##2tKaPyiD~ zjFjn|#3a^V>p*#!#LkUYVn=#GZCci?-dM>-Dn<`2MPl6_np0rgd(^An^U_EZ!JRds zx9u*gwRUFRWS{(bMqntAhhtGxZ@_g%rTGlieeIzLNNL#-Qs8 zeZ^An<#nw0o!6;P{4c(Nah!K^w@;0`rDZ8){~BSOP^g)^u>m&}$PKx(L@@nc5Jha@ z-Z_g!Fj8q*6ot<6^#FNn(LkEkreetG06nBFt0=(Nc`TKiDR#PaW5=>V;dMc8P3fBi zU%}n|8K=Dbo;~hqmf?~zROycrs8Jq1oew^{?=x{Wd(+SYyI%LR;V)klv zXAOHZrrXw&GM1j6(Kx7Gc>IQ8Q7XY=p|!;4VScvr*nHMwv7wL`>Y>#^tV18n-qZ~} zbzNzQ`RFT%ti&$wm;aKMmSui`B2krFSCt&e$xWHZNPWsap&Q_kC7(MmlUF#-Tc(1$U<~=vxwWbUXGKYf&vC-_c@(v)P9YWpb;(2aPb= zWc1Mo6+1fFjE{o_;+PsYBv|O%HB60+H)l8u>CI85a|Th=Q>ygh=fB=f{P4yo3f+_X zbe)K{csFCdR%;Wo`BD3ktA*p$1CtZPw0JsUsra^I{;ABS-x)-&&h|lD#rSTaBa^yQ z&$*qU;yxZ{GB~H2)$Jmv^LV4V}r2S~{!a5o4dkW^@%UhQD5o?hvB(SngFDkKs%GURXms5$dP_=jq14NJi{| zkJb#uPm4LAnb~F>C4Z?kC~5D8?OBU5M|<-rBHH&i`5oQtvu5>si`Kbd<;bb;^7fl? zeZ@P{ez-+iADUfLTp)lEpQuK?8E$894H9BmF#0c!o8OZxosEg@rhgEkmL`vol8!WN zZ8rIe9&|zm-<|rBnV|y|B`qxm@)$bZfo)(=@%k7G`El)}9Dr^rEwTBOxDS zZ-&AklKH}UqEGB(JzLgs;3_$y_v#f5KBSA3 z-e5ZvIMvn?*sv2d9I32tg7*9JMBf(ep{g5wpSVuDGITN{`MPq#Af|kWiq$)U%hJ@Z_Vef-_dr)?M_8v~YVQiW>C3%9Crq#jUi-*m~L z>OlETo{^W_^()LT_hkRliM%qnL|qrEuj(3<&kW-(W}>JDYAM+<(jz8~H6+sR-AU)0}J zzD*+zc_BC}9+JVnUSiUCc}vJ8ROEljRiJA_n`)hUeP3DLr#ChBl(iSV;ZM+*3Wj*$ zB{#>8N2%rfh~&#KX5C#2mZqW5x46;!?XOmZ3O(93=AP9&8ZxM7aLKF8@>tMo&5?&% zT!~8;N-Vp|d4F;$sLS~?y;nsGdw^-(rEDB05uBZO1 zpU3A<6{+e$2Htd|+T3u9!otAxYKc~8U_3Dpw!qE(7ok>jf&uHs#swDTCvx-;!QkwC%7PZYFP#cvEOuyU;?d6Vo|FPS{j z_g+ldwhhdadn<{I){~gcacNDltFyGZ(c~kt&V2f#jiZZ3svl`9a((+AYq}OK`N$lbehiyf2-5zCUjEzGXzLF_=`A*|Jw@5POEUljgA@3NdXC}$2BZoUHUIzs literal 0 HcmV?d00001 diff --git a/server/src/site/resources/rfclist/basic/rfc0822.txt b/server/src/site/resources/rfclist/basic/rfc0822.txt new file mode 100644 index 00000000000..32041b362d5 --- /dev/null +++ b/server/src/site/resources/rfclist/basic/rfc0822.txt @@ -0,0 +1,2902 @@ + + + + + + RFC # 822 + + Obsoletes: RFC #733 (NIC #41952) + + + + + + + + + + + + + STANDARD FOR THE FORMAT OF + + ARPA INTERNET TEXT MESSAGES + + + + + + + August 13, 1982 + + + + + + + Revised by + + David H. Crocker + + + Dept. of Electrical Engineering + University of Delaware, Newark, DE 19711 + Network: DCrocker @ UDel-Relay + + + + + + + + + + + + + + + + Standard for ARPA Internet Text Messages + + + TABLE OF CONTENTS + + + PREFACE .................................................... ii + + 1. INTRODUCTION ........................................... 1 + + 1.1. Scope ............................................ 1 + 1.2. Communication Framework .......................... 2 + + 2. NOTATIONAL CONVENTIONS ................................. 3 + + 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 + + 3.1. General Description .............................. 5 + 3.2. Header Field Definitions ......................... 9 + 3.3. Lexical Tokens ................................... 10 + 3.4. Clarifications ................................... 11 + + 4. MESSAGE SPECIFICATION .................................. 17 + + 4.1. Syntax ........................................... 17 + 4.2. Forwarding ....................................... 19 + 4.3. Trace Fields ..................................... 20 + 4.4. Originator Fields ................................ 21 + 4.5. Receiver Fields .................................. 23 + 4.6. Reference Fields ................................. 23 + 4.7. Other Fields ..................................... 24 + + 5. DATE AND TIME SPECIFICATION ............................ 26 + + 5.1. Syntax ........................................... 26 + 5.2. Semantics ........................................ 26 + + 6. ADDRESS SPECIFICATION .................................. 27 + + 6.1. Syntax ........................................... 27 + 6.2. Semantics ........................................ 27 + 6.3. Reserved Address ................................. 33 + + 7. BIBLIOGRAPHY ........................................... 34 + + + APPENDIX + + A. EXAMPLES ............................................... 36 + B. SIMPLE FIELD PARSING ................................... 40 + C. DIFFERENCES FROM RFC #733 .............................. 41 + D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 + + + August 13, 1982 - i - RFC #822 + + + + + Standard for ARPA Internet Text Messages + + + PREFACE + + + By 1977, the Arpanet employed several informal standards for + the text messages (mail) sent among its host computers. It was + felt necessary to codify these practices and provide for those + features that seemed imminent. The result of that effort was + Request for Comments (RFC) #733, "Standard for the Format of ARPA + Network Text Message", by Crocker, Vittal, Pogran, and Henderson. + The specification attempted to avoid major changes in existing + software, while permitting several new features. + + This document revises the specifications in RFC #733, in + order to serve the needs of the larger and more complex ARPA + Internet. Some of RFC #733's features failed to gain adequate + acceptance. In order to simplify the standard and the software + that follows it, these features have been removed. A different + addressing scheme is used, to handle the case of inter-network + mail; and the concept of re-transmission has been introduced. + + This specification is intended for use in the ARPA Internet. + However, an attempt has been made to free it of any dependence on + that environment, so that it can be applied to other network text + message systems. + + The specification of RFC #733 took place over the course of + one year, using the ARPANET mail environment, itself, to provide + an on-going forum for discussing the capabilities to be included. + More than twenty individuals, from across the country, partici- + pated in the original discussion. The development of this + revised specification has, similarly, utilized network mail-based + group discussion. Both specification efforts greatly benefited + from the comments and ideas of the participants. + + The syntax of the standard, in RFC #733, was originally + specified in the Backus-Naur Form (BNF) meta-language. Ken L. + Harrenstien, of SRI International, was responsible for re-coding + the BNF into an augmented BNF that makes the representation + smaller and easier to understand. + + + + + + + + + + + + + August 13, 1982 - ii - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1. INTRODUCTION + + 1.1. SCOPE + + This standard specifies a syntax for text messages that are + sent among computer users, within the framework of "electronic + mail". The standard supersedes the one specified in ARPANET + Request for Comments #733, "Standard for the Format of ARPA Net- + work Text Messages". + + In this context, messages are viewed as having an envelope + and contents. The envelope contains whatever information is + needed to accomplish transmission and delivery. The contents + compose the object to be delivered to the recipient. This stan- + dard applies only to the format and some of the semantics of mes- + sage contents. It contains no specification of the information + in the envelope. + + However, some message systems may use information from the + contents to create the envelope. It is intended that this stan- + dard facilitate the acquisition of such information by programs. + + Some message systems may store messages in formats that + differ from the one specified in this standard. This specifica- + tion is intended strictly as a definition of what message content + format is to be passed BETWEEN hosts. + + Note: This standard is NOT intended to dictate the internal for- + mats used by sites, the specific message system features + that they are expected to support, or any of the charac- + teristics of user interface programs that create or read + messages. + + A distinction should be made between what the specification + REQUIRES and what it ALLOWS. Messages can be made complex and + rich with formally-structured components of information or can be + kept small and simple, with a minimum of such information. Also, + the standard simplifies the interpretation of differing visual + formats in messages; only the visual aspect of a message is + affected and not the interpretation of information within it. + Implementors may choose to retain such visual distinctions. + + The formal definition is divided into four levels. The bot- + tom level describes the meta-notation used in this document. The + second level describes basic lexical analyzers that feed tokens + to higher-level parsers. Next is an overall specification for + messages; it permits distinguishing individual fields. Finally, + there is definition of the contents of several structured fields. + + + + August 13, 1982 - 1 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1.2. COMMUNICATION FRAMEWORK + + Messages consist of lines of text. No special provisions + are made for encoding drawings, facsimile, speech, or structured + text. No significant consideration has been given to questions + of data compression or to transmission and storage efficiency, + and the standard tends to be free with the number of bits con- + sumed. For example, field names are specified as free text, + rather than special terse codes. + + A general "memo" framework is used. That is, a message con- + sists of some information in a rigid format, followed by the main + part of the message, with a format that is not specified in this + document. The syntax of several fields of the rigidly-formated + ("headers") section is defined in this specification; some of + these fields must be included in all messages. + + The syntax that distinguishes between header fields is + specified separately from the internal syntax for particular + fields. This separation is intended to allow simple parsers to + operate on the general structure of messages, without concern for + the detailed structure of individual header fields. Appendix B + is provided to facilitate construction of these parsers. + + In addition to the fields specified in this document, it is + expected that other fields will gain common use. As necessary, + the specifications for these "extension-fields" will be published + through the same mechanism used to publish this document. Users + may also wish to extend the set of fields that they use + privately. Such "user-defined fields" are permitted. + + The framework severely constrains document tone and appear- + ance and is primarily useful for most intra-organization communi- + cations and well-structured inter-organization communication. + It also can be used for some types of inter-process communica- + tion, such as simple file transfer and remote job entry. A more + robust framework might allow for multi-font, multi-color, multi- + dimension encoding of information. A less robust one, as is + present in most single-machine message systems, would more + severely constrain the ability to add fields and the decision to + include specific fields. In contrast with paper-based communica- + tion, it is interesting to note that the RECEIVER of a message + can exercise an extraordinary amount of control over the + message's appearance. The amount of actual control available to + message receivers is contingent upon the capabilities of their + individual message systems. + + + + + + August 13, 1982 - 2 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2. NOTATIONAL CONVENTIONS + + This specification uses an augmented Backus-Naur Form (BNF) + notation. The differences from standard BNF involve naming rules + and indicating repetition and "local" alternatives. + + 2.1. RULE NAMING + + Angle brackets ("<", ">") are not used, in general. The + name of a rule is simply the name itself, rather than "". + Quotation-marks enclose literal text (which may be upper and/or + lower case). Certain basic rules are in uppercase, such as + SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in + rule definitions, and in the rest of this document, whenever + their presence will facilitate discerning the use of rule names. + + 2.2. RULE1 / RULE2: ALTERNATIVES + + Elements separated by slash ("/") are alternatives. There- + fore "foo / bar" will accept foo or bar. + + 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES + + Elements enclosed in parentheses are treated as a single + element. Thus, "(elem (foo / bar) elem)" allows the token + sequences "elem foo elem" and "elem bar elem". + + 2.4. *RULE: REPETITION + + The character "*" preceding an element indicates repetition. + The full form is: + + *element + + indicating at least and at most occurrences of element. + Default values are 0 and infinity so that "*(element)" allows any + number, including zero; "1*element" requires at least one; and + "1*2element" allows one or two. + + 2.5. [RULE]: OPTIONAL + + Square brackets enclose optional elements; "[foo bar]" is + equivalent to "*1(foo bar)". + + 2.6. NRULE: SPECIFIC REPETITION + + "(element)" is equivalent to "*(element)"; that is, + exactly occurrences of (element). Thus 2DIGIT is a 2-digit + number, and 3ALPHA is a string of three alphabetic characters. + + + August 13, 1982 - 3 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2.7. #RULE: LISTS + + A construct "#" is defined, similar to "*", as follows: + + #element + + indicating at least and at most elements, each separated + by one or more commas (","). This makes the usual form of lists + very easy; a rule such as '(element *("," element))' can be shown + as "1#element". Wherever this construct is used, null elements + are allowed, but do not contribute to the count of elements + present. That is, "(element),,(element)" is permitted, but + counts as only two elements. Therefore, where at least one ele- + ment is required, at least one non-null element must be present. + Default values are 0 and infinity so that "#(element)" allows any + number, including zero; "1#element" requires at least one; and + "1#2element" allows one or two. + + 2.8. ; COMMENTS + + A semi-colon, set off some distance to the right of rule + text, starts a comment that continues to the end of line. This + is a simple way of including useful notes in parallel with the + specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 4 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3. LEXICAL ANALYSIS OF MESSAGES + + 3.1. GENERAL DESCRIPTION + + A message consists of header fields and, optionally, a body. + The body is simply a sequence of lines containing ASCII charac- + ters. It is separated from the headers by a null line (i.e., a + line with nothing preceding the CRLF). + + 3.1.1. LONG HEADER FIELDS + + Each header field can be viewed as a single, logical line of + ASCII characters, comprising a field-name and a field-body. + For convenience, the field-body portion of this conceptual + entity can be split into a multiple-line representation; this + is called "folding". The general rule is that wherever there + may be linear-white-space (NOT simply LWSP-chars), a CRLF + immediately followed by AT LEAST one LWSP-char may instead be + inserted. Thus, the single line + + To: "Joe & J. Harvey" , JJV @ BBN + + can be represented as: + + To: "Joe & J. Harvey" , + JJV@BBN + + and + + To: "Joe & J. Harvey" + , JJV + @BBN + + and + + To: "Joe & + J. Harvey" , JJV @ BBN + + The process of moving from this folded multiple-line + representation of a header field to its single line represen- + tation is called "unfolding". Unfolding is accomplished by + regarding CRLF immediately followed by a LWSP-char as + equivalent to the LWSP-char. + + Note: While the standard permits folding wherever linear- + white-space is permitted, it is recommended that struc- + tured fields, such as those containing addresses, limit + folding to higher-level syntactic breaks. For address + fields, it is recommended that such folding occur + + + August 13, 1982 - 5 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + between addresses, after the separating comma. + + 3.1.2. STRUCTURE OF HEADER FIELDS + + Once a field has been unfolded, it may be viewed as being com- + posed of a field-name followed by a colon (":"), followed by a + field-body, and terminated by a carriage-return/line-feed. + The field-name must be composed of printable ASCII characters + (i.e., characters that have values between 33. and 126., + decimal, except colon). The field-body may be composed of any + ASCII characters, except CR or LF. (While CR and/or LF may be + present in the actual text, they are removed by the action of + unfolding the field.) + + Certain field-bodies of headers may be interpreted according + to an internal syntax that some systems may wish to parse. + These fields are called "structured fields". Examples + include fields containing dates and addresses. Other fields, + such as "Subject" and "Comments", are regarded simply as + strings of text. + + Note: Any field which has a field-body that is defined as + other than simply is to be treated as a struc- + tured field. + + Field-names, unstructured field bodies and structured + field bodies each are scanned by their own, independent + "lexical" analyzers. + + 3.1.3. UNSTRUCTURED FIELD BODIES + + For some fields, such as "Subject" and "Comments", no struc- + turing is assumed, and they are treated simply as s, as + in the message body. Rules of folding apply to these fields, + so that such field bodies which occupy several lines must + therefore have the second and successive lines indented by at + least one LWSP-char. + + 3.1.4. STRUCTURED FIELD BODIES + + To aid in the creation and reading of structured fields, the + free insertion of linear-white-space (which permits folding + by inclusion of CRLFs) is allowed between lexical tokens. + Rather than obscuring the syntax specifications for these + structured fields with explicit syntax for this linear-white- + space, the existence of another "lexical" analyzer is assumed. + This analyzer does not apply for unstructured field bodies + that are simply strings of text, as described above. The + analyzer provides an interpretation of the unfolded text + + + August 13, 1982 - 6 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + composing the body of the field as a sequence of lexical sym- + bols. + + These symbols are: + + - individual special characters + - quoted-strings + - domain-literals + - comments + - atoms + + The first four of these symbols are self-delimiting. Atoms + are not; they are delimited by the self-delimiting symbols and + by linear-white-space. For the purposes of regenerating + sequences of atoms and quoted-strings, exactly one SPACE is + assumed to exist, and should be used, between them. (Also, in + the "Clarifications" section on "White Space", below, note the + rules about treatment of multiple contiguous LWSP-chars.) + + So, for example, the folded body of an address field + + ":sysmail"@ Some-Group. Some-Org, + Muhammed.(I am the greatest) Ali @(the)Vegas.WBA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 7 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + is analyzed into the following lexical symbols and types: + + :sysmail quoted string + @ special + Some-Group atom + . special + Some-Org atom + , special + Muhammed atom + . special + (I am the greatest) comment + Ali atom + @ atom + (the) comment + Vegas atom + . special + WBA atom + + The canonical representations for the data in these addresses + are the following strings: + + ":sysmail"@Some-Group.Some-Org + + and + + Muhammed.Ali@Vegas.WBA + + Note: For purposes of display, and when passing such struc- + tured information to other systems, such as mail proto- + col services, there must be NO linear-white-space + between s that are separated by period (".") or + at-sign ("@") and exactly one SPACE between all other + s. Also, headers should be in a folded form. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 8 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.2. HEADER FIELD DEFINITIONS + + These rules show a field meta-syntax, without regard for the + particular type or internal syntax. Their purpose is to permit + detection of fields; also, they present to higher-level parsers + an image of each field as fitting on one line. + + field = field-name ":" [ field-body ] CRLF + + field-name = 1* + + field-body = field-body-contents + [CRLF LWSP-char field-body] + + field-body-contents = + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 9 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.3. LEXICAL TOKENS + + The following rules are used to define an underlying lexical + analyzer, which feeds tokens to higher level parsers. See the + ANSI references, in the Bibliography. + + ; ( Octal, Decimal.) + CHAR = ; ( 0-177, 0.-127.) + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + DIGIT = ; ( 60- 71, 48.- 57.) + CTL = ; ( 177, 127.) + CR = ; ( 15, 13.) + LF = ; ( 12, 10.) + SPACE = ; ( 40, 32.) + HTAB = ; ( 11, 9.) + <"> = ; ( 42, 34.) + CRLF = CR LF + + LWSP-char = SPACE / HTAB ; semantics = SPACE + + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + + delimiters = specials / linear-white-space / comment + + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + + atom = 1* + + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + + domain-literal = "[" *(dtext / quoted-pair) "]" + + + + + August 13, 1982 - 10 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + + comment = "(" *(ctext / quoted-pair / comment) ")" + + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + + quoted-pair = "\" CHAR ; may quote any char + + phrase = 1*word ; Sequence of words + + word = atom / quoted-string + + + 3.4. CLARIFICATIONS + + 3.4.1. QUOTING + + Some characters are reserved for special interpretation, such + as delimiting lexical tokens. To permit use of these charac- + ters as uninterpreted data, a quoting mechanism is provided. + To quote a character, precede it with a backslash ("\"). + + This mechanism is not fully general. Characters may be quoted + only within a subset of the lexical constructs. In particu- + lar, quoting is limited to use within: + + - quoted-string + - domain-literal + - comment + + Within these constructs, quoting is REQUIRED for CR and "\" + and for the character(s) that delimit the token (e.g., "(" and + ")" for a comment). However, quoting is PERMITTED for any + character. + + Note: In particular, quoting is NOT permitted within atoms. + For example when the local-part of an addr-spec must + contain a special character, a quoted string must be + used. Therefore, a specification such as: + + Full\ Name@Domain + + is not legal and must be specified as: + + "Full Name"@Domain + + + August 13, 1982 - 11 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.2. WHITE SPACE + + Note: In structured field bodies, multiple linear space ASCII + characters (namely HTABs and SPACEs) are treated as + single spaces and may freely surround any symbol. In + all header fields, the only place in which at least one + LWSP-char is REQUIRED is at the beginning of continua- + tion lines in a folded field. + + When passing text to processes that do not interpret text + according to this standard (e.g., mail protocol servers), then + NO linear-white-space characters should occur between a period + (".") or at-sign ("@") and a . Exactly ONE SPACE should + be used in place of arbitrary linear-white-space and comment + sequences. + + Note: Within systems conforming to this standard, wherever a + member of the list of delimiters is allowed, LWSP-chars + may also occur before and/or after it. + + Writers of mail-sending (i.e., header-generating) programs + should realize that there is no network-wide definition of the + effect of ASCII HT (horizontal-tab) characters on the appear- + ance of text at another network host; therefore, the use of + tabs in message headers, though permitted, is discouraged. + + 3.4.3. COMMENTS + + A comment is a set of ASCII characters, which is enclosed in + matching parentheses and which is not within a quoted-string + The comment construct permits message originators to add text + which will be useful for human readers, but which will be + ignored by the formal semantics. Comments should be retained + while the message is subject to interpretation according to + this standard. However, comments must NOT be included in + other cases, such as during protocol exchanges with mail + servers. + + Comments nest, so that if an unquoted left parenthesis occurs + in a comment string, there must also be a matching right + parenthesis. When a comment acts as the delimiter between a + sequence of two lexical symbols, such as two atoms, it is lex- + ically equivalent with a single SPACE, for the purposes of + regenerating the sequence, such as when passing the sequence + onto a mail protocol server. Comments are detected as such + only within field-bodies of structured fields. + + If a comment is to be "folded" onto multiple lines, then the + syntax for folding must be adhered to. (See the "Lexical + + + August 13, 1982 - 12 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Analysis of Messages" section on "Folding Long Header Fields" + above, and the section on "Case Independence" below.) Note + that the official semantics therefore do not "see" any + unquoted CRLFs that are in comments, although particular pars- + ing programs may wish to note their presence. For these pro- + grams, it would be reasonable to interpret a "CRLF LWSP-char" + as being a CRLF that is part of the comment; i.e., the CRLF is + kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a + backslash followed by a CR followed by a LF) still must be + followed by at least one LWSP-char. + + 3.4.4. DELIMITING AND QUOTING CHARACTERS + + The quote character (backslash) and characters that delimit + syntactic units are not, generally, to be taken as data that + are part of the delimited or quoted unit(s). In particular, + the quotation-marks that define a quoted-string, the + parentheses that define a comment and the backslash that + quotes a following character are NOT part of the quoted- + string, comment or quoted character. A quotation-mark that is + to be part of a quoted-string, a parenthesis that is to be + part of a comment and a backslash that is to be part of either + must each be preceded by the quote-character backslash ("\"). + Note that the syntax allows any character to be quoted within + a quoted-string or comment; however only certain characters + MUST be quoted to be included as data. These characters are + the ones that are not part of the alternate text group (i.e., + ctext or qtext). + + The one exception to this rule is that a single SPACE is + assumed to exist between contiguous words in a phrase, and + this interpretation is independent of the actual number of + LWSP-chars that the creator places between the words. To + include more than one SPACE, the creator must make the LWSP- + chars be part of a quoted-string. + + Quotation marks that delimit a quoted string and backslashes + that quote the following character should NOT accompany the + quoted-string when the string is passed to processes that do + not interpret data according to this specification (e.g., mail + protocol servers). + + 3.4.5. QUOTED-STRINGS + + Where permitted (i.e., in words in structured fields) quoted- + strings are treated as a single symbol. That is, a quoted- + string is equivalent to an atom, syntactically. If a quoted- + string is to be "folded" onto multiple lines, then the syntax + for folding must be adhered to. (See the "Lexical Analysis of + + + August 13, 1982 - 13 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Messages" section on "Folding Long Header Fields" above, and + the section on "Case Independence" below.) Therefore, the + official semantics do not "see" any bare CRLFs that are in + quoted-strings; however particular parsing programs may wish + to note their presence. For such programs, it would be rea- + sonable to interpret a "CRLF LWSP-char" as being a CRLF which + is part of the quoted-string; i.e., the CRLF is kept and the + LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- + lowed by a CR followed by a LF) are also subject to rules of + folding, but the presence of the quoting character (backslash) + explicitly indicates that the CRLF is data to the quoted + string. Stripping off the first following LWSP-char is also + appropriate when parsing quoted CRLFs. + + 3.4.6. BRACKETING CHARACTERS + + There is one type of bracket which must occur in matched pairs + and may have pairs nested within each other: + + o Parentheses ("(" and ")") are used to indicate com- + ments. + + There are three types of brackets which must occur in matched + pairs, and which may NOT be nested: + + o Colon/semi-colon (":" and ";") are used in address + specifications to indicate that the included list of + addresses are to be treated as a group. + + o Angle brackets ("<" and ">") are generally used to + indicate the presence of a one machine-usable refer- + ence (e.g., delimiting mailboxes), possibly including + source-routing to the machine. + + o Square brackets ("[" and "]") are used to indicate the + presence of a domain-literal, which the appropriate + name-domain is to use directly, bypassing normal + name-resolution mechanisms. + + 3.4.7. CASE INDEPENDENCE + + Except as noted, alphabetic strings may be represented in any + combination of upper and lower case. The only syntactic units + + + + + + + + + August 13, 1982 - 14 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + which requires preservation of case information are: + + - text + - qtext + - dtext + - ctext + - quoted-pair + - local-part, except "Postmaster" + + When matching any other syntactic unit, case is to be ignored. + For example, the field-names "From", "FROM", "from", and even + "FroM" are semantically equal and should all be treated ident- + ically. + + When generating these units, any mix of upper and lower case + alphabetic characters may be used. The case shown in this + specification is suggested for message-creating processes. + + Note: The reserved local-part address unit, "Postmaster", is + an exception. When the value "Postmaster" is being + interpreted, it must be accepted in any mixture of + case, including "POSTMASTER", and "postmaster". + + 3.4.8. FOLDING LONG HEADER FIELDS + + Each header field may be represented on exactly one line con- + sisting of the name of the field and its body, and terminated + by a CRLF; this is what the parser sees. For readability, the + field-body portion of long header fields may be "folded" onto + multiple lines of the actual field. "Long" is commonly inter- + preted to mean greater than 65 or 72 characters. The former + length serves as a limit, when the message is to be viewed on + most simple terminals which use simple display software; how- + ever, the limit is not imposed by this standard. + + Note: Some display software often can selectively fold lines, + to suit the display terminal. In such cases, sender- + provided folding can interfere with the display + software. + + 3.4.9. BACKSPACE CHARACTERS + + ASCII BS characters (Backspace, decimal 8) may be included in + texts and quoted-strings to effect overstriking. However, any + use of backspaces which effects an overstrike to the left of + the beginning of the text or quoted-string is prohibited. + + + + + + August 13, 1982 - 15 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS + + During transmission through heterogeneous networks, it may be + necessary to force data to conform to a network's local con- + ventions. For example, it may be required that a CR be fol- + lowed either by LF, making a CRLF, or by , if the CR is + to stand alone). Such transformations are reversed, when the + message exits that network. + + When crossing network boundaries, the message should be + treated as passing through two modules. It will enter the + first module containing whatever network-specific transforma- + tions that were necessary to permit migration through the + "current" network. It then passes through the modules: + + o Transformation Reversal + + The "current" network's idiosyncracies are removed and + the message is returned to the canonical form speci- + fied in this standard. + + o Transformation + + The "next" network's local idiosyncracies are imposed + on the message. + + ------------------ + From ==> | Remove Net-A | + Net-A | idiosyncracies | + ------------------ + || + \/ + Conformance + with standard + || + \/ + ------------------ + | Impose Net-B | ==> To + | idiosyncracies | Net-B + ------------------ + + + + + + + + + + + + August 13, 1982 - 16 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 4. MESSAGE SPECIFICATION + + 4.1. SYNTAX + + Note: Due to an artifact of the notational conventions, the syn- + tax indicates that, when present, some fields, must be in + a particular order. Header fields are NOT required to + occur in any particular order, except that the message + body must occur AFTER the headers. It is recommended + that, if present, headers be sent in the order "Return- + Path", "Received", "Date", "From", "Subject", "Sender", + "To", "cc", etc. + + This specification permits multiple occurrences of most + fields. Except as noted, their interpretation is not + specified here, and their use is discouraged. + + The following syntax for the bodies of various fields should + be thought of as describing each field body as a single long + string (or line). The "Lexical Analysis of Message" section on + "Long Header Fields", above, indicates how such long strings can + be represented on more than one line in the actual transmitted + message. + + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + + trace = return ; path to sender + 1*received ; receipt tags + + return = "Return-path" ":" route-addr ; return address + + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + + + August 13, 1982 - 17 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + ";" date-time ; time received + + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + + dates = orig-date ; Original + [ resent-date ] ; Forwarded + + orig-date = "Date" ":" date-time + + resent-date = "Resent-Date" ":" date-time + + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + + msg-id = "<" addr-spec ">" ; Unique message id + + + + + + + August 13, 1982 - 18 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + extension-field = + + + user-defined-field = + + + 4.2. FORWARDING + + Some systems permit mail recipients to forward a message, + retaining the original headers, by adding some new fields. This + standard supports such a service, through the "Resent-" prefix to + field names. + + Whenever the string "Resent-" begins a field name, the field + has the same semantics as a field whose name does not have the + prefix. However, the message is assumed to have been forwarded + by an original recipient who attached the "Resent-" field. This + new field is treated as being more recent than the equivalent, + original field. For example, the "Resent-From", indicates the + person that forwarded the message, whereas the "From" field indi- + cates the original author. + + Use of such precedence information depends upon partici- + pants' communication needs. For example, this standard does not + dictate when a "Resent-From:" address should receive replies, in + lieu of sending them to the "From:" address. + + Note: In general, the "Resent-" fields should be treated as con- + taining a set of information that is independent of the + set of original fields. Information for one set should + not automatically be taken from the other. The interpre- + tation of multiple "Resent-" fields, of the same type, is + undefined. + + In the remainder of this specification, occurrence of legal + "Resent-" fields are treated identically with the occurrence of + + + + + + + + + August 13, 1982 - 19 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + fields whose names do not contain this prefix. + + 4.3. TRACE FIELDS + + Trace information is used to provide an audit trail of mes- + sage handling. In addition, it indicates a route back to the + sender of the message. + + The list of known "via" and "with" values are registered + with the Network Information Center, SRI International, Menlo + Park, California. + + 4.3.1. RETURN-PATH + + This field is added by the final transport system that + delivers the message to its recipient. The field is intended + to contain definitive information about the address and route + back to the message's originator. + + Note: The "Reply-To" field is added by the originator and + serves to direct replies, whereas the "Return-Path" + field is used to identify a path back to the origina- + tor. + + While the syntax indicates that a route specification is + optional, every attempt should be made to provide that infor- + mation in this field. + + 4.3.2. RECEIVED + + A copy of this field is added by each transport service that + relays the message. The information in the field can be quite + useful for tracing transport problems. + + The names of the sending and receiving hosts and time-of- + receipt may be specified. The "via" parameter may be used, to + indicate what physical mechanism the message was sent over, + such as Arpanet or Phonenet, and the "with" parameter may be + used to indicate the mail-, or connection-, level protocol + that was used, such as the SMTP mail protocol, or X.25 tran- + sport protocol. + + Note: Several "with" parameters may be included, to fully + specify the set of protocols that were used. + + Some transport services queue mail; the internal message iden- + tifier that is assigned to the message may be noted, using the + "id" parameter. When the sending host uses a destination + address specification that the receiving host reinterprets, by + + + August 13, 1982 - 20 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + expansion or transformation, the receiving host may wish to + record the original specification, using the "for" parameter. + For example, when a copy of mail is sent to the member of a + distribution list, this parameter may be used to record the + original address that was used to specify the list. + + 4.4. ORIGINATOR FIELDS + + The standard allows only a subset of the combinations possi- + ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, + and Resent-Reply-To fields. The limitation is intentional. + + 4.4.1. FROM / RESENT-FROM + + This field contains the identity of the person(s) who wished + this message to be sent. The message-creation process should + default this field to be a single, authenticated machine + address, indicating the AGENT (person, system or process) + entering the message. If this is not done, the "Sender" field + MUST be present. If the "From" field IS defaulted this way, + the "Sender" field is optional and is redundant with the + "From" field. In all cases, addresses in the "From" field + must be machine-usable (addr-specs) and may not contain named + lists (groups). + + 4.4.2. SENDER / RESENT-SENDER + + This field contains the authenticated identity of the AGENT + (person, system or process) that sends the message. It is + intended for use when the sender is not the author of the mes- + sage, or to indicate who among a group of authors actually + sent the message. If the contents of the "Sender" field would + be completely redundant with the "From" field, then the + "Sender" field need not be present and its use is discouraged + (though still legal). In particular, the "Sender" field MUST + be present if it is NOT the same as the "From" Field. + + The Sender mailbox specification includes a word sequence + which must correspond to a specific agent (i.e., a human user + or a computer program) rather than a standard address. This + indicates the expectation that the field will identify the + single AGENT (person, system, or process) responsible for + sending the mail and not simply include the name of a mailbox + from which the mail was sent. For example in the case of a + shared login name, the name, by itself, would not be adequate. + The local-part address unit, which refers to this agent, is + expected to be a computer system term, and not (for example) a + generalized person reference which can be used outside the + network text message context. + + + August 13, 1982 - 21 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Since the critical function served by the "Sender" field is + identification of the agent responsible for sending mail and + since computer programs cannot be held accountable for their + behavior, it is strongly recommended that when a computer pro- + gram generates a message, the HUMAN who is responsible for + that program be referenced as part of the "Sender" field mail- + box specification. + + 4.4.3. REPLY-TO / RESENT-REPLY-TO + + This field provides a general mechanism for indicating any + mailbox(es) to which responses are to be sent. Three typical + uses for this feature can be distinguished. In the first + case, the author(s) may not have regular machine-based mail- + boxes and therefore wish(es) to indicate an alternate machine + address. In the second case, an author may wish additional + persons to be made aware of, or responsible for, replies. A + somewhat different use may be of some help to "text message + teleconferencing" groups equipped with automatic distribution + services: include the address of that service in the "Reply- + To" field of all messages submitted to the teleconference; + then participants can "reply" to conference submissions to + guarantee the correct distribution of any submission of their + own. + + Note: The "Return-Path" field is added by the mail transport + service, at the time of final deliver. It is intended + to identify a path back to the orginator of the mes- + sage. The "Reply-To" field is added by the message + originator and is intended to direct replies. + + 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO + + For systems which automatically generate address lists for + replies to messages, the following recommendations are made: + + o The "Sender" field mailbox should be sent notices of + any problems in transport or delivery of the original + messages. If there is no "Sender" field, then the + "From" field mailbox should be used. + + o The "Sender" field mailbox should NEVER be used + automatically, in a recipient's reply message. + + o If the "Reply-To" field exists, then the reply should + go to the addresses indicated in that field and not to + the address(es) indicated in the "From" field. + + + + + August 13, 1982 - 22 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + o If there is a "From" field, but no "Reply-To" field, + the reply should be sent to the address(es) indicated + in the "From" field. + + Sometimes, a recipient may actually wish to communicate with + the person that initiated the message transfer. In such + cases, it is reasonable to use the "Sender" address. + + This recommendation is intended only for automated use of + originator-fields and is not intended to suggest that replies + may not also be sent to other recipients of messages. It is + up to the respective mail-handling programs to decide what + additional facilities will be provided. + + Examples are provided in Appendix A. + + 4.5. RECEIVER FIELDS + + 4.5.1. TO / RESENT-TO + + This field contains the identity of the primary recipients of + the message. + + 4.5.2. CC / RESENT-CC + + This field contains the identity of the secondary (informa- + tional) recipients of the message. + + 4.5.3. BCC / RESENT-BCC + + This field contains the identity of additional recipients of + the message. The contents of this field are not included in + copies of the message sent to the primary and secondary reci- + pients. Some systems may choose to include the text of the + "Bcc" field only in the author(s)'s copy, while others may + also include it in the text sent to all those indicated in the + "Bcc" list. + + 4.6. REFERENCE FIELDS + + 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID + + This field contains a unique identifier (the local-part + address unit) which refers to THIS version of THIS message. + The uniqueness of the message identifier is guaranteed by the + host which generates it. This identifier is intended to be + machine readable and not necessarily meaningful to humans. A + message identifier pertains to exactly one instantiation of a + particular message; subsequent revisions to the message should + + + August 13, 1982 - 23 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + each receive new message identifiers. + + 4.6.2. IN-REPLY-TO + + The contents of this field identify previous correspon- + dence which this message answers. Note that if message iden- + tifiers are used in this field, they must use the msg-id + specification format. + + 4.6.3. REFERENCES + + The contents of this field identify other correspondence + which this message references. Note that if message identif- + iers are used, they must use the msg-id specification format. + + 4.6.4. KEYWORDS + + This field contains keywords or phrases, separated by + commas. + + 4.7. OTHER FIELDS + + 4.7.1. SUBJECT + + This is intended to provide a summary, or indicate the + nature, of the message. + + 4.7.2. COMMENTS + + Permits adding text comments onto the message without + disturbing the contents of the message's body. + + 4.7.3. ENCRYPTED + + Sometimes, data encryption is used to increase the + privacy of message contents. If the body of a message has + been encrypted, to keep its contents private, the "Encrypted" + field can be used to note the fact and to indicate the nature + of the encryption. The first parameter indicates the + software used to encrypt the body, and the second, optional + is intended to aid the recipient in selecting the + proper decryption key. This code word may be viewed as an + index to a table of keys held by the recipient. + + Note: Unfortunately, headers must contain envelope, as well + as contents, information. Consequently, it is neces- + sary that they remain unencrypted, so that mail tran- + sport services may access them. Since names, + addresses, and "Subject" field contents may contain + + + August 13, 1982 - 24 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + sensitive information, this requirement limits total + message privacy. + + Names of encryption software are registered with the Net- + work Information Center, SRI International, Menlo Park, Cali- + fornia. + + 4.7.4. EXTENSION-FIELD + + A limited number of common fields have been defined in + this document. As network mail requirements dictate, addi- + tional fields may be standardized. To provide user-defined + fields with a measure of safety, in name selection, such + extension-fields will never have names that begin with the + string "X-". + + Names of Extension-fields are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 4.7.5. USER-DEFINED-FIELD + + Individual users of network mail are free to define and + use additional header fields. Such fields must have names + which are not already used in the current specification or in + any definitions of extension-fields, and the overall syntax of + these user-defined-fields must conform to this specification's + rules for delimiting and folding fields. Due to the + extension-field publishing process, the name of a user- + defined-field may be pre-empted + + Note: The prefatory string "X-" will never be used in the + names of Extension-fields. This provides user-defined + fields with a protected set of names. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 25 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 5. DATE AND TIME SPECIFICATION + + 5.1. SYNTAX + + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + + time = hour zone ; ANSI and Military + + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + ; A:-1; (J not used) + ; M:-12; N:+1; Y:+12 + / ( ("+" / "-") 4DIGIT ) ; Local differential + ; hours+min. (HHMM) + + 5.2. SEMANTICS + + If included, day-of-week must be the day implied by the date + specification. + + Time zone may be indicated in several ways. "UT" is Univer- + sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- + mitted as a reference to Universal Time. The military standard + uses a single character for each zone. "Z" is Universal Time. + "A" indicates one hour earlier, and "M" indicates 12 hours ear- + lier; "N" is one hour later, and "Y" is 12 hours later. The + letter "J" is not used. The other remaining two forms are taken + from ANSI standard X3.51-1975. One allows explicit indication of + the amount of offset from UT; the other uses common 3-character + strings for indicating time zones in North America. + + + August 13, 1982 - 26 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 6. ADDRESS SPECIFICATION + + 6.1. SYNTAX + + address = mailbox ; one addressee + / group ; named list + + group = phrase ":" [#mailbox] ";" + + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + + route-addr = "<" [route] addr-spec ">" + + route = 1#("@" domain) ":" ; path-relative + + addr-spec = local-part "@" domain ; global address + + local-part = word *("." word) ; uninterpreted + ; case-preserved + + domain = sub-domain *("." sub-domain) + + sub-domain = domain-ref / domain-literal + + domain-ref = atom ; symbolic reference + + 6.2. SEMANTICS + + A mailbox receives mail. It is a conceptual entity which + does not necessarily pertain to file storage. For example, some + sites may choose to print mail on their line printer and deliver + the output to the addressee's desk. + + A mailbox specification comprises a person, system or pro- + cess name reference, a domain-dependent string, and a name-domain + reference. The name reference is optional and is usually used to + indicate the human name of a recipient. The name-domain refer- + ence specifies a sequence of sub-domains. The domain-dependent + string is uninterpreted, except by the final sub-domain; the rest + of the mail service merely transmits it as a literal string. + + 6.2.1. DOMAINS + + A name-domain is a set of registered (mail) names. A name- + domain specification resolves to a subordinate name-domain + specification or to a terminal domain-dependent string. + Hence, domain specification is extensible, permitting any + number of registration levels. + + + August 13, 1982 - 27 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Name-domains model a global, logical, hierarchical addressing + scheme. The model is logical, in that an address specifica- + tion is related to name registration and is not necessarily + tied to transmission path. The model's hierarchy is a + directed graph, called an in-tree, such that there is a single + path from the root of the tree to any node in the hierarchy. + If more than one path actually exists, they are considered to + be different addresses. + + The root node is common to all addresses; consequently, it is + not referenced. Its children constitute "top-level" name- + domains. Usually, a service has access to its own full domain + specification and to the names of all top-level name-domains. + + The "top" of the domain addressing hierarchy -- a child of the + root -- is indicated by the right-most field, in a domain + specification. Its child is specified to the left, its child + to the left, and so on. + + Some groups provide formal registration services; these con- + stitute name-domains that are independent logically of + specific machines. In addition, networks and machines impli- + citly compose name-domains, since their membership usually is + registered in name tables. + + In the case of formal registration, an organization implements + a (distributed) data base which provides an address-to-route + mapping service for addresses of the form: + + person@registry.organization + + Note that "organization" is a logical entity, separate from + any particular communication network. + + A mechanism for accessing "organization" is universally avail- + able. That mechanism, in turn, seeks an instantiation of the + registry; its location is not indicated in the address specif- + ication. It is assumed that the system which operates under + the name "organization" knows how to find a subordinate regis- + try. The registry will then use the "person" string to deter- + mine where to send the mail specification. + + The latter, network-oriented case permits simple, direct, + attachment-related address specification, such as: + + user@host.network + + Once the network is accessed, it is expected that a message + will go directly to the host and that the host will resolve + + + August 13, 1982 - 28 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + the user name, placing the message in the user's mailbox. + + 6.2.2. ABBREVIATED DOMAIN SPECIFICATION + + Since any number of levels is possible within the domain + hierarchy, specification of a fully qualified address can + become inconvenient. This standard permits abbreviated domain + specification, in a special case: + + For the address of the sender, call the left-most + sub-domain Level N. In a header address, if all of + the sub-domains above (i.e., to the right of) Level N + are the same as those of the sender, then they do not + have to appear in the specification. Otherwise, the + address must be fully qualified. + + This feature is subject to approval by local sub- + domains. Individual sub-domains may require their + member systems, which originate mail, to provide full + domain specification only. When permitted, abbrevia- + tions may be present only while the message stays + within the sub-domain of the sender. + + Use of this mechanism requires the sender's sub-domain + to reserve the names of all top-level domains, so that + full specifications can be distinguished from abbrevi- + ated specifications. + + For example, if a sender's address is: + + sender@registry-A.registry-1.organization-X + + and one recipient's address is: + + recipient@registry-B.registry-1.organization-X + + and another's is: + + recipient@registry-C.registry-2.organization-X + + then ".registry-1.organization-X" need not be specified in the + the message, but "registry-C.registry-2" DOES have to be + specified. That is, the first two addresses may be abbrevi- + ated, but the third address must be fully specified. + + When a message crosses a domain boundary, all addresses must + be specified in the full format, ending with the top-level + name-domain in the right-most field. It is the responsibility + of mail forwarding services to ensure that addresses conform + + + August 13, 1982 - 29 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + with this requirement. In the case of abbreviated addresses, + the relaying service must make the necessary expansions. It + should be noted that it often is difficult for such a service + to locate all occurrences of address abbreviations. For exam- + ple, it will not be possible to find such abbreviations within + the body of the message. The "Return-Path" field can aid + recipients in recovering from these errors. + + Note: When passing any portion of an addr-spec onto a process + which does not interpret data according to this stan- + dard (e.g., mail protocol servers). There must be NO + LWSP-chars preceding or following the at-sign or any + delimiting period ("."), such as shown in the above + examples, and only ONE SPACE between contiguous + s. + + 6.2.3. DOMAIN TERMS + + A domain-ref must be THE official name of a registry, network, + or host. It is a symbolic reference, within a name sub- + domain. At times, it is necessary to bypass standard mechan- + isms for resolving such references, using more primitive + information, such as a network host address rather than its + associated host name. + + To permit such references, this standard provides the domain- + literal construct. Its contents must conform with the needs + of the sub-domain in which it is interpreted. + + Domain-literals which refer to domains within the ARPA Inter- + net specify 32-bit Internet addresses, in four 8-bit fields + noted in decimal, as described in Request for Comments #820, + "Assigned Numbers." For example: + + [10.0.3.19] + + Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It + is permitted only as a means of bypassing temporary + system limitations, such as name tables which are not + complete. + + The names of "top-level" domains, and the names of domains + under in the ARPA Internet, are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 6.2.4. DOMAIN-DEPENDENT LOCAL STRING + + The local-part of an addr-spec in a mailbox specification + (i.e., the host's name for the mailbox) is understood to be + + + August 13, 1982 - 30 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + whatever the receiving mail protocol server allows. For exam- + ple, some systems do not understand mailbox references of the + form "P. D. Q. Bach", but others do. + + This specification treats periods (".") as lexical separators. + Hence, their presence in local-parts which are not quoted- + strings, is detected. However, such occurrences carry NO + semantics. That is, if a local-part has periods within it, an + address parser will divide the local-part into several tokens, + but the sequence of tokens will be treated as one uninter- + preted unit. The sequence will be re-assembled, when the + address is passed outside of the system such as to a mail pro- + tocol service. + + For example, the address: + + First.Last@Registry.Org + + is legal and does not require the local-part to be surrounded + with quotation-marks. (However, "First Last" DOES require + quoting.) The local-part of the address, when passed outside + of the mail system, within the Registry.Org domain, is + "First.Last", again without quotation marks. + + 6.2.5. BALANCING LOCAL-PART AND DOMAIN + + In some cases, the boundary between local-part and domain can + be flexible. The local-part may be a simple string, which is + used for the final determination of the recipient's mailbox. + All other levels of reference are, therefore, part of the + domain. + + For some systems, in the case of abbreviated reference to the + local and subordinate sub-domains, it may be possible to + specify only one reference within the domain part and place + the other, subordinate name-domain references within the + local-part. This would appear as: + + mailbox.sub1.sub2@this-domain + + Such a specification would be acceptable to address parsers + which conform to RFC #733, but do not support this newer + Internet standard. While contrary to the intent of this stan- + dard, the form is legal. + + Also, some sub-domains have a specification syntax which does + not conform to this standard. For example: + + sub-net.mailbox@sub-domain.domain + + + August 13, 1982 - 31 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + uses a different parsing sequence for local-part than for + domain. + + Note: As a rule, the domain specification should contain + fields which are encoded according to the syntax of + this standard and which contain generally-standardized + information. The local-part specification should con- + tain only that portion of the address which deviates + from the form or intention of the domain field. + + 6.2.6. MULTIPLE MAILBOXES + + An individual may have several mailboxes and wish to receive + mail at whatever mailbox is convenient for the sender to + access. This standard does not provide a means of specifying + "any member of" a list of mailboxes. + + A set of individuals may wish to receive mail as a single unit + (i.e., a distribution list). The construct permits + specification of such a list. Recipient mailboxes are speci- + fied within the bracketed part (":" - ";"). A copy of the + transmitted message is to be sent to each mailbox listed. + This standard does not permit recursive specification of + groups within groups. + + While a list must be named, it is not required that the con- + tents of the list be included. In this case, the
+ serves only as an indication of group distribution and would + appear in the form: + + name:; + + Some mail services may provide a group-list distribution + facility, accepting a single mailbox reference, expanding it + to the full distribution list, and relaying the mail to the + list's members. This standard provides no additional syntax + for indicating such a service. Using the address + alternative, while listing one mailbox in it, can mean either + that the mailbox reference will be expanded to a list or that + there is a group with one member. + + 6.2.7. EXPLICIT PATH SPECIFICATION + + At times, a message originator may wish to indicate the + transmission path that a message should follow. This is + called source routing. The normal addressing scheme, used in + an addr-spec, is carefully separated from such information; + the portion of a route-addr is provided for such occa- + sions. It specifies the sequence of hosts and/or transmission + + + August 13, 1982 - 32 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + services that are to be traversed. Both domain-refs and + domain-literals may be used. + + Note: The use of source routing is discouraged. Unless the + sender has special need of path restriction, the choice + of transmission route should be left to the mail tran- + sport service. + + 6.3. RESERVED ADDRESS + + It often is necessary to send mail to a site, without know- + ing any of its valid addresses. For example, there may be mail + system dysfunctions, or a user may wish to find out a person's + correct address, at that site. + + This standard specifies a single, reserved mailbox address + (local-part) which is to be valid at each site. Mail sent to + that address is to be routed to a person responsible for the + site's mail system or to a person with responsibility for general + site operation. The name of the reserved local-part address is: + + Postmaster + + so that "Postmaster@domain" is required to be valid. + + Note: This reserved local-part must be matched without sensi- + tivity to alphabetic case, so that "POSTMASTER", "postmas- + ter", and even "poStmASteR" is to be accepted. + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 33 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 7. BIBLIOGRAPHY + + + ANSI. "USA Standard Code for Information Interchange," X3.4. + American National Standards Institute: New York (1968). Also + in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- + book", NIC 7104. + + ANSI. "Representations of Universal Time, Local Time Differen- + tials, and United States Time Zone References for Information + Interchange," X3.51-1975. American National Standards Insti- + tute: New York (1975). + + Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. + 1979). + + Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- + ford and Appleton Laboratory: Didcot, England. + + Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. + "Standardizing Network Mail Headers," ARPANET Request for + Comments No. 561, Network Information Center No. 18516; SRI + International: Menlo Park (September 1973). + + Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. + "Grapevine: An Exercise in Distributed Computing," Communica- + tions of the ACM 25, 4 (April 1982), 260-274. + + Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. + "Standard for the Format of ARPA Network Text Message," + ARPANET Request for Comments No. 733, Network Information + Center No. 41952. SRI International: Menlo Park (November + 1977). + + Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- + work Information Center No. 7104 (NTIS AD A003890). SRI + International: Menlo Park (April 1976). + + Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. + (1969). + + Levin, R. and Schroeder, M. "Transport of Electronic Messages + through a Network," TeleInformatics 79, pp. 29-33. North + Holland (1979). Also as Xerox Palo Alto Research Center + Technical Report CSL-79-4. + + Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," + ARPANET Request for Comments, No. 680, Network Information + Center No. 32116. SRI International: Menlo Park (1975). + + + August 13, 1982 - 34 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + NBS. "Specification of Message Format for Computer Based Message + Systems, Recommended Federal Information Processing Standard." + National Bureau of Standards: Gaithersburg, Maryland + (October 1981). + + NIC. Internet Protocol Transition Workbook. Network Information + Center, SRI-International, Menlo Park, California (March + 1982). + + Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized + Agent for Locating Named Objects in a Distributed Environ- + ment," OPD-T8103. Xerox Office Products Division: Palo Alto, + CA. (October 1981). + + Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, + No. 820. SRI International: Menlo Park (August 1982). + + Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request + for Comments, No. 821. SRI International: Menlo Park (August + 1982). + + Shoch, J.F. "Internetwork naming, addressing and routing," in + Proc. 17th IEEE Computer Society International Conference, pp. + 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. + + Su, Z. and Postel, J. "The Domain Naming Convention for Internet + User Applications," ARPANET Request for Comments, No. 819. + SRI International: Menlo Park (August 1982). + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 35 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + APPENDIX + + + A. EXAMPLES + + A.1. ADDRESSES + + A.1.1. Alfred Neuman + + A.1.2. Neuman@BBN-TENEXA + + These two "Alfred Neuman" examples have identical seman- + tics, as far as the operation of the local host's mail sending + (distribution) program (also sometimes called its "mailer") + and the remote host's mail protocol server are concerned. In + the first example, the "Alfred Neuman" is ignored by the + mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- + pient. The second example contains no superfluous informa- + tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- + pient. + + Note: When the message crosses name-domain boundaries, then + these specifications must be changed, so as to indicate + the remainder of the hierarchy, starting with the top + level. + + A.1.3. "George, Ted" + + This form might be used to indicate that a single mailbox + is shared by several users. The quoted string is ignored by + the originating host's mailer, because "Shared@Group.Arpanet" + completely specifies the destination mailbox. + + A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US + + The "(the Stilt)" is a comment, which is NOT included in + the destination mailbox address handed to the originating + system's mailer. The local-part of the address is the string + "Wilt.Chamberlain", with NO space between the first and second + words. + + A.1.5. Address Lists + + Gourmets: Pompous Person , + Childs@WGBH.Boston, Galloping Gourmet@ + ANT.Down-Under (Australian National Television), + Cheapie@Discount-Liquors;, + Cruisers: Port@Portugal, Jones@SEA;, + Another@Somewhere.SomeOrg + + + August 13, 1982 - 36 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + This group list example points out the use of comments and the + mixing of addresses and groups. + + A.2. ORIGINATOR ITEMS + + A.2.1. Author-sent + + George Jones logs into his host as "Jones". He sends + mail himself. + + From: Jones@Group.Org + + or + + From: George Jones + + A.2.2. Secretary-sent + + George Jones logs in as Jones on his host. His secre- + tary, who logs in as Secy sends mail for him. Replies to the + mail should go to George. + + From: George Jones + Sender: Secy@Other-Group + + A.2.3. Secretary-sent, for user of shared directory + + George Jones' secretary sends mail for George. Replies + should go to George. + + From: George Jones + Sender: Secy@Other-Group + + Note that there need not be a space between "Jones" and the + "<", but adding a space enhances readability (as is the case + in other examples. + + A.2.4. Committee activity, with one author + + George is a member of a committee. He wishes to have any + replies to his message go to all committee members. + + From: George Jones + Sender: Jones@Host + Reply-To: The Committee: Jones@Host.Net, + Smith@Other.Org, + Doe@Somewhere-Else; + + Note that if George had not included himself in the + + + August 13, 1982 - 37 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + enumeration of The Committee, he would not have gotten an + implicit reply; the presence of the "Reply-to" field SUPER- + SEDES the sending of a reply to the person named in the "From" + field. + + A.2.5. Secretary acting as full agent of author + + George Jones asks his secretary (Secy@Host) to send a + message for him in his capacity as Group. He wants his secre- + tary to handle all replies. + + From: George Jones + Sender: Secy@Host + Reply-To: Secy@Host + + A.2.6. Agent for user without online mailbox + + A friend of George's, Sarah, is visiting. George's + secretary sends some mail to a friend of Sarah in computer- + land. Replies should go to George, whose mailbox is Jones at + Registry. + + From: Sarah Friendly + Sender: Secy-Name + Reply-To: Jones@Registry. + + A.2.7. Agent for member of a committee + + George's secretary sends out a message which was authored + jointly by all the members of a committee. Note that the name + of the committee cannot be specified, since names are + not permitted in the From field. + + From: Jones@Host, + Smith@Other-Host, + Doe@Somewhere-Else + Sender: Secy@SHost + + + + + + + + + + + + + + + August 13, 1982 - 38 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + A.3. COMPLETE HEADERS + + A.3.1. Minimum required + + Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT + From: Jones@Registry.Org or From: Jones@Registry.Org + Bcc: To: Smith@Registry.Org + + Note that the "Bcc" field may be empty, while the "To" field + is required to have at least one address. + + A.3.2. Using some of the additional fields + + Date: 26 Aug 76 1430 EDT + From: George Jones + Sender: Secy@SHOST + To: "Al Neuman"@Mad-Host, + Sam.Irving@Other-Host + Message-ID: + + A.3.3. About as complex as you're going to get + + Date : 27 Aug 76 0932 PDT + From : Ken Davis + Subject : Re: The Syntax in the RFC + Sender : KSecy@Other-Host + Reply-To : Sam.Irving@Reg.Organization + To : George Jones , + Al.Neuman@MAD.Publisher + cc : Important folk: + Tom Softwood , + "Sam Irving"@Other-Host;, + Standard Distribution: + /main/davis/people/standard@Other-Host, + "standard.dist.3"@Tops-20-Host>; + Comment : Sam is away on business. He asked me to handle + his mail for him. He'll be able to provide a + more accurate explanation when he returns + next week. + In-Reply-To: , George's message + X-Special-action: This is a sample of user-defined field- + names. There could also be a field-name + "Special-action", but its name might later be + preempted + Message-ID: <4231.629.XYzi-What@Other-Host> + + + + + + + August 13, 1982 - 39 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + B. SIMPLE FIELD PARSING + + Some mail-reading software systems may wish to perform only + minimal processing, ignoring the internal syntax of structured + field-bodies and treating them the same as unstructured-field- + bodies. Such software will need only to distinguish: + + o Header fields from the message body, + + o Beginnings of fields from lines which continue fields, + + o Field-names from field-contents. + + The abbreviated set of syntactic rules which follows will + suffice for this purpose. It describes a limited view of mes- + sages and is a subset of the syntactic rules provided in the main + part of this specification. One small exception is that the con- + tents of field-bodies consist only of text: + + B.1. SYNTAX + + + message = *field *(CRLF *text) + + field = field-name ":" [field-body] CRLF + + field-name = 1* + + field-body = *text [CRLF LWSP-char field-body] + + + B.2. SEMANTICS + + Headers occur before the message body and are terminated by + a null line (i.e., two contiguous CRLFs). + + A line which continues a header field begins with a SPACE or + HTAB character, while a line beginning a field starts with a + printable character which is not a colon. + + A field-name consists of one or more printable characters + (excluding colon, space, and control-characters). A field-name + MUST be contained on one line. Upper and lower case are not dis- + tinguished when comparing field-names. + + + + + + + + August 13, 1982 - 40 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C. DIFFERENCES FROM RFC #733 + + The following summarizes the differences between this stan- + dard and the one specified in Arpanet Request for Comments #733, + "Standard for the Format of ARPA Network Text Messages". The + differences are listed in the order of their occurrence in the + current specification. + + C.1. FIELD DEFINITIONS + + C.1.1. FIELD NAMES + + These now must be a sequence of printable characters. They + may not contain any LWSP-chars. + + C.2. LEXICAL TOKENS + + C.2.1. SPECIALS + + The characters period ("."), left-square bracket ("["), and + right-square bracket ("]") have been added. For presentation + purposes, and when passing a specification to a system that + does not conform to this standard, periods are to be contigu- + ous with their surrounding lexical tokens. No linear-white- + space is permitted between them. The presence of one LWSP- + char between other tokens is still directed. + + C.2.2. ATOM + + Atoms may not contain SPACE. + + C.2.3. SPECIAL TEXT + + ctext and qtext have had backslash ("\") added to the list of + prohibited characters. + + C.2.4. DOMAINS + + The lexical tokens and have been + added. + + C.3. MESSAGE SPECIFICATION + + C.3.1. TRACE + + The "Return-path:" and "Received:" fields have been specified. + + + + + + August 13, 1982 - 41 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.3.2. FROM + + The "From" field must contain machine-usable addresses (addr- + spec). Multiple addresses may be specified, but named-lists + (groups) may not. + + C.3.3. RESENT + + The meta-construct of prefacing field names with the string + "Resent-" has been added, to indicate that a message has been + forwarded by an intermediate recipient. + + C.3.4. DESTINATION + + A message must contain at least one destination address field. + "To" and "CC" are required to contain at least one address. + + C.3.5. IN-REPLY-TO + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.6. REFERENCE + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.7. ENCRYPTED + + A field has been specified that permits senders to indicate + that the body of a message has been encrypted. + + C.3.8. EXTENSION-FIELD + + Extension fields are prohibited from beginning with the char- + acters "X-". + + C.4. DATE AND TIME SPECIFICATION + + C.4.1. SIMPLIFICATION + + Fewer optional forms are permitted and the list of three- + letter time zones has been shortened. + + C.5. ADDRESS SPECIFICATION + + + + + + + August 13, 1982 - 42 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.5.1. ADDRESS + + The use of quoted-string, and the ":"-atom-":" construct, have + been removed. An address now is either a single mailbox + reference or is a named list of addresses. The latter indi- + cates a group distribution. + + C.5.2. GROUPS + + Group lists are now required to to have a name. Group lists + may not be nested. + + C.5.3. MAILBOX + + A mailbox specification may indicate a person's name, as + before. Such a named list no longer may specify multiple + mailboxes and may not be nested. + + C.5.4. ROUTE ADDRESSING + + Addresses now are taken to be absolute, global specifications, + independent of transmission paths. The construct has + been provided, to permit explicit specification of transmis- + sion path. RFC #733's use of multiple at-signs ("@") was + intended as a general syntax for indicating routing and/or + hierarchical addressing. The current standard separates these + specifications and only one at-sign is permitted. + + C.5.5. AT-SIGN + + The string " at " no longer is used as an address delimiter. + Only at-sign ("@") serves the function. + + C.5.6. DOMAINS + + Hierarchical, logical name-domains have been added. + + C.6. RESERVED ADDRESS + + The local-part "Postmaster" has been reserved, so that users can + be guaranteed at least one valid address at a site. + + + + + + + + + + + August 13, 1982 - 43 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + D. ALPHABETICAL LISTING OF SYNTAX RULES + + address = mailbox ; one addressee + / group ; named list + addr-spec = local-part "@" domain ; global address + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + atom = 1* + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + CHAR = ; ( 0-177, 0.-127.) + comment = "(" *(ctext / quoted-pair / comment) ")" + CR = ; ( 15, 13.) + CRLF = CR LF + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + CTL = ; ( 177, 127.) + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + dates = orig-date ; Original + [ resent-date ] ; Forwarded + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + delimiters = specials / linear-white-space / comment + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + DIGIT = ; ( 60- 71, 48.- 57.) + domain = sub-domain *("." sub-domain) + domain-literal = "[" *(dtext / quoted-pair) "]" + domain-ref = atom ; symbolic reference + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + extension-field = + + + + August 13, 1982 - 44 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + field = field-name ":" [ field-body ] CRLF + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + field-body = field-body-contents + [CRLF LWSP-char field-body] + field-body-contents = + + field-name = 1* + group = phrase ":" [#mailbox] ";" + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + HTAB = ; ( 11, 9.) + LF = ; ( 12, 10.) + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + local-part = word *("." word) ; uninterpreted + ; case-preserved + LWSP-char = SPACE / HTAB ; semantics = SPACE + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + msg-id = "<" addr-spec ">" ; Unique message id + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + orig-date = "Date" ":" date-time + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + phrase = 1*word ; Sequence of words + + + + + August 13, 1982 - 45 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + quoted-pair = "\" CHAR ; may quote any char + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + ";" date-time ; time received + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + resent-date = "Resent-Date" ":" date-time + return = "Return-path" ":" route-addr ; return address + route = 1#("@" domain) ":" ; path-relative + route-addr = "<" [route] addr-spec ">" + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + SPACE = ; ( 40, 32.) + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + sub-domain = domain-ref / domain-literal + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + time = hour zone ; ANSI and Military + trace = return ; path to sender + 1*received ; receipt tags + user-defined-field = + + word = atom / quoted-string + + + + + August 13, 1982 - 46 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + <"> = ; ( 42, 34.) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 47 - RFC #822 + + + diff --git a/server/src/site/resources/rfclist/basic/rfc1123.txt b/server/src/site/resources/rfclist/basic/rfc1123.txt new file mode 100644 index 00000000000..514528a43bc --- /dev/null +++ b/server/src/site/resources/rfclist/basic/rfc1123.txt @@ -0,0 +1,5781 @@ + + + + + +Network Working Group Internet Engineering Task Force +Request for Comments: 1123 R. Braden, Editor + October 1989 + + + Requirements for Internet Hosts -- Application and Support + +Status of This Memo + + This RFC is an official specification for the Internet community. It + incorporates by reference, amends, corrects, and supplements the + primary protocol standards documents relating to hosts. Distribution + of this document is unlimited. + +Summary + + This RFC is one of a pair that defines and discusses the requirements + for Internet host software. This RFC covers the application and + support protocols; its companion RFC-1122 covers the communication + protocol layers: link layer, IP layer, and transport layer. + + + + Table of Contents + + + + + 1. INTRODUCTION ............................................... 5 + 1.1 The Internet Architecture .............................. 6 + 1.2 General Considerations ................................. 6 + 1.2.1 Continuing Internet Evolution ..................... 6 + 1.2.2 Robustness Principle .............................. 7 + 1.2.3 Error Logging ..................................... 8 + 1.2.4 Configuration ..................................... 8 + 1.3 Reading this Document .................................. 10 + 1.3.1 Organization ...................................... 10 + 1.3.2 Requirements ...................................... 10 + 1.3.3 Terminology ....................................... 11 + 1.4 Acknowledgments ........................................ 12 + + 2. GENERAL ISSUES ............................................. 13 + 2.1 Host Names and Numbers ................................. 13 + 2.2 Using Domain Name Service .............................. 13 + 2.3 Applications on Multihomed hosts ....................... 14 + 2.4 Type-of-Service ........................................ 14 + 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15 + + + + +Internet Engineering Task Force [Page 1] + + + + +RFC1123 INTRODUCTION October 1989 + + + 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16 + 3.1 INTRODUCTION ........................................... 16 + 3.2 PROTOCOL WALK-THROUGH .................................. 16 + 3.2.1 Option Negotiation ................................ 16 + 3.2.2 Telnet Go-Ahead Function .......................... 16 + 3.2.3 Control Functions ................................. 17 + 3.2.4 Telnet "Synch" Signal ............................. 18 + 3.2.5 NVT Printer and Keyboard .......................... 19 + 3.2.6 Telnet Command Structure .......................... 20 + 3.2.7 Telnet Binary Option .............................. 20 + 3.2.8 Telnet Terminal-Type Option ....................... 20 + 3.3 SPECIFIC ISSUES ........................................ 21 + 3.3.1 Telnet End-of-Line Convention ..................... 21 + 3.3.2 Data Entry Terminals .............................. 23 + 3.3.3 Option Requirements ............................... 24 + 3.3.4 Option Initiation ................................. 24 + 3.3.5 Telnet Linemode Option ............................ 25 + 3.4 TELNET/USER INTERFACE .................................. 25 + 3.4.1 Character Set Transparency ........................ 25 + 3.4.2 Telnet Commands ................................... 26 + 3.4.3 TCP Connection Errors ............................. 26 + 3.4.4 Non-Default Telnet Contact Port ................... 26 + 3.4.5 Flushing Output ................................... 26 + 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27 + + 4. FILE TRANSFER .............................................. 29 + 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29 + 4.1.1 INTRODUCTION ...................................... 29 + 4.1.2. PROTOCOL WALK-THROUGH ............................ 29 + 4.1.2.1 LOCAL Type ................................... 29 + 4.1.2.2 Telnet Format Control ........................ 30 + 4.1.2.3 Page Structure ............................... 30 + 4.1.2.4 Data Structure Transformations ............... 30 + 4.1.2.5 Data Connection Management ................... 31 + 4.1.2.6 PASV Command ................................. 31 + 4.1.2.7 LIST and NLST Commands ....................... 31 + 4.1.2.8 SITE Command ................................. 32 + 4.1.2.9 STOU Command ................................. 32 + 4.1.2.10 Telnet End-of-line Code ..................... 32 + 4.1.2.11 FTP Replies ................................. 33 + 4.1.2.12 Connections ................................. 34 + 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34 + 4.1.3 SPECIFIC ISSUES ................................... 35 + 4.1.3.1 Non-standard Command Verbs ................... 35 + 4.1.3.2 Idle Timeout ................................. 36 + 4.1.3.3 Concurrency of Data and Control .............. 36 + 4.1.3.4 FTP Restart Mechanism ........................ 36 + 4.1.4 FTP/USER INTERFACE ................................ 39 + + + +Internet Engineering Task Force [Page 2] + + + + +RFC1123 INTRODUCTION October 1989 + + + 4.1.4.1 Pathname Specification ....................... 39 + 4.1.4.2 "QUOTE" Command .............................. 40 + 4.1.4.3 Displaying Replies to User ................... 40 + 4.1.4.4 Maintaining Synchronization .................. 40 + 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41 + 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44 + 4.2.1 INTRODUCTION ...................................... 44 + 4.2.2 PROTOCOL WALK-THROUGH ............................. 44 + 4.2.2.1 Transfer Modes ............................... 44 + 4.2.2.2 UDP Header ................................... 44 + 4.2.3 SPECIFIC ISSUES ................................... 44 + 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44 + 4.2.3.2 Timeout Algorithms ........................... 46 + 4.2.3.3 Extensions ................................... 46 + 4.2.3.4 Access Control ............................... 46 + 4.2.3.5 Broadcast Request ............................ 46 + 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47 + + 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48 + 5.1 INTRODUCTION ........................................... 48 + 5.2 PROTOCOL WALK-THROUGH .................................. 48 + 5.2.1 The SMTP Model .................................... 48 + 5.2.2 Canonicalization .................................. 49 + 5.2.3 VRFY and EXPN Commands ............................ 50 + 5.2.4 SEND, SOML, and SAML Commands ..................... 50 + 5.2.5 HELO Command ...................................... 50 + 5.2.6 Mail Relay ........................................ 51 + 5.2.7 RCPT Command ...................................... 52 + 5.2.8 DATA Command ...................................... 53 + 5.2.9 Command Syntax .................................... 54 + 5.2.10 SMTP Replies ..................................... 54 + 5.2.11 Transparency ..................................... 55 + 5.2.12 WKS Use in MX Processing ......................... 55 + 5.2.13 RFC-822 Message Specification .................... 55 + 5.2.14 RFC-822 Date and Time Specification .............. 55 + 5.2.15 RFC-822 Syntax Change ............................ 56 + 5.2.16 RFC-822 Local-part .............................. 56 + 5.2.17 Domain Literals .................................. 57 + 5.2.18 Common Address Formatting Errors ................. 58 + 5.2.19 Explicit Source Routes ........................... 58 + 5.3 SPECIFIC ISSUES ........................................ 59 + 5.3.1 SMTP Queueing Strategies .......................... 59 + 5.3.1.1 Sending Strategy .............................. 59 + 5.3.1.2 Receiving strategy ........................... 61 + 5.3.2 Timeouts in SMTP .................................. 61 + 5.3.3 Reliable Mail Receipt ............................. 63 + 5.3.4 Reliable Mail Transmission ........................ 63 + 5.3.5 Domain Name Support ............................... 65 + + + +Internet Engineering Task Force [Page 3] + + + + +RFC1123 INTRODUCTION October 1989 + + + 5.3.6 Mailing Lists and Aliases ......................... 65 + 5.3.7 Mail Gatewaying ................................... 66 + 5.3.8 Maximum Message Size .............................. 68 + 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69 + + 6. SUPPORT SERVICES ............................................ 72 + 6.1 DOMAIN NAME TRANSLATION ................................. 72 + 6.1.1 INTRODUCTION ....................................... 72 + 6.1.2 PROTOCOL WALK-THROUGH ............................. 72 + 6.1.2.1 Resource Records with Zero TTL ............... 73 + 6.1.2.2 QCLASS Values ................................ 73 + 6.1.2.3 Unused Fields ................................ 73 + 6.1.2.4 Compression .................................. 73 + 6.1.2.5 Misusing Configuration Info .................. 73 + 6.1.3 SPECIFIC ISSUES ................................... 74 + 6.1.3.1 Resolver Implementation ...................... 74 + 6.1.3.2 Transport Protocols .......................... 75 + 6.1.3.3 Efficient Resource Usage ..................... 77 + 6.1.3.4 Multihomed Hosts ............................. 78 + 6.1.3.5 Extensibility ................................ 79 + 6.1.3.6 Status of RR Types ........................... 79 + 6.1.3.7 Robustness ................................... 80 + 6.1.3.8 Local Host Table ............................. 80 + 6.1.4 DNS USER INTERFACE ................................ 81 + 6.1.4.1 DNS Administration ........................... 81 + 6.1.4.2 DNS User Interface ........................... 81 + 6.1.4.3 Interface Abbreviation Facilities ............. 82 + 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84 + 6.2 HOST INITIALIZATION .................................... 87 + 6.2.1 INTRODUCTION ...................................... 87 + 6.2.2 REQUIREMENTS ...................................... 87 + 6.2.2.1 Dynamic Configuration ........................ 87 + 6.2.2.2 Loading Phase ................................ 89 + 6.3 REMOTE MANAGEMENT ...................................... 90 + 6.3.1 INTRODUCTION ...................................... 90 + 6.3.2 PROTOCOL WALK-THROUGH ............................. 90 + 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92 + + 7. REFERENCES ................................................. 93 + + + + + + + + + + + + +Internet Engineering Task Force [Page 4] + + + + +RFC1123 INTRODUCTION October 1989 + + +1. INTRODUCTION + + This document is one of a pair that defines and discusses the + requirements for host system implementations of the Internet protocol + suite. This RFC covers the applications layer and support protocols. + Its companion RFC, "Requirements for Internet Hosts -- Communications + Layers" [INTRO:1] covers the lower layer protocols: transport layer, + IP layer, and link layer. + + These documents are intended to provide guidance for vendors, + implementors, and users of Internet communication software. They + represent the consensus of a large body of technical experience and + wisdom, contributed by members of the Internet research and vendor + communities. + + This RFC enumerates standard protocols that a host connected to the + Internet must use, and it incorporates by reference the RFCs and + other documents describing the current specifications for these + protocols. It corrects errors in the referenced documents and adds + additional discussion and guidance for an implementor. + + For each protocol, this document also contains an explicit set of + requirements, recommendations, and options. The reader must + understand that the list of requirements in this document is + incomplete by itself; the complete set of requirements for an + Internet host is primarily defined in the standard protocol + specification documents, with the corrections, amendments, and + supplements contained in this RFC. + + A good-faith implementation of the protocols that was produced after + careful reading of the RFC's and with some interaction with the + Internet technical community, and that followed good communications + software engineering practices, should differ from the requirements + of this document in only minor ways. Thus, in many cases, the + "requirements" in this RFC are already stated or implied in the + standard protocol documents, so that their inclusion here is, in a + sense, redundant. However, they were included because some past + implementation has made the wrong choice, causing problems of + interoperability, performance, and/or robustness. + + This document includes discussion and explanation of many of the + requirements and recommendations. A simple list of requirements + would be dangerous, because: + + o Some required features are more important than others, and some + features are optional. + + o There may be valid reasons why particular vendor products that + + + +Internet Engineering Task Force [Page 5] + + + + +RFC1123 INTRODUCTION October 1989 + + + are designed for restricted contexts might choose to use + different specifications. + + However, the specifications of this document must be followed to meet + the general goal of arbitrary host interoperation across the + diversity and complexity of the Internet system. Although most + current implementations fail to meet these requirements in various + ways, some minor and some major, this specification is the ideal + towards which we need to move. + + These requirements are based on the current level of Internet + architecture. This document will be updated as required to provide + additional clarifications or to include additional information in + those areas in which specifications are still evolving. + + This introductory section begins with general advice to host software + vendors, and then gives some guidance on reading the rest of the + document. Section 2 contains general requirements that may be + applicable to all application and support protocols. Sections 3, 4, + and 5 contain the requirements on protocols for the three major + applications: Telnet, file transfer, and electronic mail, + respectively. Section 6 covers the support applications: the domain + name system, system initialization, and management. Finally, all + references will be found in Section 7. + + 1.1 The Internet Architecture + + For a brief introduction to the Internet architecture from a host + viewpoint, see Section 1.1 of [INTRO:1]. That section also + contains recommended references for general background on the + Internet architecture. + + 1.2 General Considerations + + There are two important lessons that vendors of Internet host + software have learned and which a new vendor should consider + seriously. + + 1.2.1 Continuing Internet Evolution + + The enormous growth of the Internet has revealed problems of + management and scaling in a large datagram-based packet + communication system. These problems are being addressed, and + as a result there will be continuing evolution of the + specifications described in this document. These changes will + be carefully planned and controlled, since there is extensive + participation in this planning by the vendors and by the + organizations responsible for operations of the networks. + + + +Internet Engineering Task Force [Page 6] + + + + +RFC1123 INTRODUCTION October 1989 + + + Development, evolution, and revision are characteristic of + computer network protocols today, and this situation will + persist for some years. A vendor who develops computer + communication software for the Internet protocol suite (or any + other protocol suite!) and then fails to maintain and update + that software for changing specifications is going to leave a + trail of unhappy customers. The Internet is a large + communication network, and the users are in constant contact + through it. Experience has shown that knowledge of + deficiencies in vendor software propagates quickly through the + Internet technical community. + + 1.2.2 Robustness Principle + + At every layer of the protocols, there is a general rule whose + application can lead to enormous benefits in robustness and + interoperability: + + "Be liberal in what you accept, and + conservative in what you send" + + Software should be written to deal with every conceivable + error, no matter how unlikely; sooner or later a packet will + come in with that particular combination of errors and + attributes, and unless the software is prepared, chaos can + ensue. In general, it is best to assume that the network is + filled with malevolent entities that will send in packets + designed to have the worst possible effect. This assumption + will lead to suitable protective design, although the most + serious problems in the Internet have been caused by + unenvisaged mechanisms triggered by low-probability events; + mere human malice would never have taken so devious a course! + + Adaptability to change must be designed into all levels of + Internet host software. As a simple example, consider a + protocol specification that contains an enumeration of values + for a particular header field -- e.g., a type field, a port + number, or an error code; this enumeration must be assumed to + be incomplete. Thus, if a protocol specification defines four + possible error codes, the software must not break when a fifth + code shows up. An undefined code might be logged (see below), + but it must not cause a failure. + + The second part of the principle is almost as important: + software on other hosts may contain deficiencies that make it + unwise to exploit legal but obscure protocol features. It is + unwise to stray far from the obvious and simple, lest untoward + effects result elsewhere. A corollary of this is "watch out + + + +Internet Engineering Task Force [Page 7] + + + + +RFC1123 INTRODUCTION October 1989 + + + for misbehaving hosts"; host software should be prepared, not + just to survive other misbehaving hosts, but also to cooperate + to limit the amount of disruption such hosts can cause to the + shared communication facility. + + 1.2.3 Error Logging + + The Internet includes a great variety of host and gateway + systems, each implementing many protocols and protocol layers, + and some of these contain bugs and mis-features in their + Internet protocol software. As a result of complexity, + diversity, and distribution of function, the diagnosis of user + problems is often very difficult. + + Problem diagnosis will be aided if host implementations include + a carefully designed facility for logging erroneous or + "strange" protocol events. It is important to include as much + diagnostic information as possible when an error is logged. In + particular, it is often useful to record the header(s) of a + packet that caused an error. However, care must be taken to + ensure that error logging does not consume prohibitive amounts + of resources or otherwise interfere with the operation of the + host. + + There is a tendency for abnormal but harmless protocol events + to overflow error logging files; this can be avoided by using a + "circular" log, or by enabling logging only while diagnosing a + known failure. It may be useful to filter and count duplicate + successive messages. One strategy that seems to work well is: + (1) always count abnormalities and make such counts accessible + through the management protocol (see Section 6.3); and (2) + allow the logging of a great variety of events to be + selectively enabled. For example, it might useful to be able + to "log everything" or to "log everything for host X". + + Note that different managements may have differing policies + about the amount of error logging that they want normally + enabled in a host. Some will say, "if it doesn't hurt me, I + don't want to know about it", while others will want to take a + more watchful and aggressive attitude about detecting and + removing protocol abnormalities. + + 1.2.4 Configuration + + It would be ideal if a host implementation of the Internet + protocol suite could be entirely self-configuring. This would + allow the whole suite to be implemented in ROM or cast into + silicon, it would simplify diskless workstations, and it would + + + +Internet Engineering Task Force [Page 8] + + + + +RFC1123 INTRODUCTION October 1989 + + + be an immense boon to harried LAN administrators as well as + system vendors. We have not reached this ideal; in fact, we + are not even close. + + At many points in this document, you will find a requirement + that a parameter be a configurable option. There are several + different reasons behind such requirements. In a few cases, + there is current uncertainty or disagreement about the best + value, and it may be necessary to update the recommended value + in the future. In other cases, the value really depends on + external factors -- e.g., the size of the host and the + distribution of its communication load, or the speeds and + topology of nearby networks -- and self-tuning algorithms are + unavailable and may be insufficient. In some cases, + configurability is needed because of administrative + requirements. + + Finally, some configuration options are required to communicate + with obsolete or incorrect implementations of the protocols, + distributed without sources, that unfortunately persist in many + parts of the Internet. To make correct systems coexist with + these faulty systems, administrators often have to "mis- + configure" the correct systems. This problem will correct + itself gradually as the faulty systems are retired, but it + cannot be ignored by vendors. + + When we say that a parameter must be configurable, we do not + intend to require that its value be explicitly read from a + configuration file at every boot time. We recommend that + implementors set up a default for each parameter, so a + configuration file is only necessary to override those defaults + that are inappropriate in a particular installation. Thus, the + configurability requirement is an assurance that it will be + POSSIBLE to override the default when necessary, even in a + binary-only or ROM-based product. + + This document requires a particular value for such defaults in + some cases. The choice of default is a sensitive issue when + the configuration item controls the accommodation to existing + faulty systems. If the Internet is to converge successfully to + complete interoperability, the default values built into + implementations must implement the official protocol, not + "mis-configurations" to accommodate faulty implementations. + Although marketing considerations have led some vendors to + choose mis-configuration defaults, we urge vendors to choose + defaults that will conform to the standard. + + Finally, we note that a vendor needs to provide adequate + + + +Internet Engineering Task Force [Page 9] + + + + +RFC1123 INTRODUCTION October 1989 + + + documentation on all configuration parameters, their limits and + effects. + + + 1.3 Reading this Document + + 1.3.1 Organization + + In general, each major section is organized into the following + subsections: + + (1) Introduction + + (2) Protocol Walk-Through -- considers the protocol + specification documents section-by-section, correcting + errors, stating requirements that may be ambiguous or + ill-defined, and providing further clarification or + explanation. + + (3) Specific Issues -- discusses protocol design and + implementation issues that were not included in the walk- + through. + + (4) Interfaces -- discusses the service interface to the next + higher layer. + + (5) Summary -- contains a summary of the requirements of the + section. + + Under many of the individual topics in this document, there is + parenthetical material labeled "DISCUSSION" or + "IMPLEMENTATION". This material is intended to give + clarification and explanation of the preceding requirements + text. It also includes some suggestions on possible future + directions or developments. The implementation material + contains suggested approaches that an implementor may want to + consider. + + The summary sections are intended to be guides and indexes to + the text, but are necessarily cryptic and incomplete. The + summaries should never be used or referenced separately from + the complete RFC. + + 1.3.2 Requirements + + In this document, the words that are used to define the + significance of each particular requirement are capitalized. + These words are: + + + +Internet Engineering Task Force [Page 10] + + + + +RFC1123 INTRODUCTION October 1989 + + + * "MUST" + + This word or the adjective "REQUIRED" means that the item + is an absolute requirement of the specification. + + * "SHOULD" + + This word or the adjective "RECOMMENDED" means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications should be + understood and the case carefully weighed before choosing + a different course. + + * "MAY" + + This word or the adjective "OPTIONAL" means that this item + is truly optional. One vendor may choose to include the + item because a particular marketplace requires it or + because it enhances the product, for example; another + vendor may omit the same item. + + + An implementation is not compliant if it fails to satisfy one + or more of the MUST requirements for the protocols it + implements. An implementation that satisfies all the MUST and + all the SHOULD requirements for its protocols is said to be + "unconditionally compliant"; one that satisfies all the MUST + requirements but not all the SHOULD requirements for its + protocols is said to be "conditionally compliant". + + 1.3.3 Terminology + + This document uses the following technical terms: + + Segment + A segment is the unit of end-to-end transmission in the + TCP protocol. A segment consists of a TCP header followed + by application data. A segment is transmitted by + encapsulation in an IP datagram. + + Message + This term is used by some application layer protocols + (particularly SMTP) for an application data unit. + + Datagram + A [UDP] datagram is the unit of end-to-end transmission in + the UDP protocol. + + + + +Internet Engineering Task Force [Page 11] + + + + +RFC1123 INTRODUCTION October 1989 + + + Multihomed + A host is said to be multihomed if it has multiple IP + addresses to connected networks. + + + + 1.4 Acknowledgments + + This document incorporates contributions and comments from a large + group of Internet protocol experts, including representatives of + university and research labs, vendors, and government agencies. + It was assembled primarily by the Host Requirements Working Group + of the Internet Engineering Task Force (IETF). + + The Editor would especially like to acknowledge the tireless + dedication of the following people, who attended many long + meetings and generated 3 million bytes of electronic mail over the + past 18 months in pursuit of this document: Philip Almquist, Dave + Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve + Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), + John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), + Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge + (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). + + In addition, the following people made major contributions to the + effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia + (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), + Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), + John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill + Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul + (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue + Technology), and Mike StJohns (DCA). The following also made + significant contributions to particular areas: Eric Allman + (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic + (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn + (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann + (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun + Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen + (Toronto). + + We are grateful to all, including any contributors who may have + been inadvertently omitted from this list. + + + + + + + + + +Internet Engineering Task Force [Page 12] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + +2. GENERAL ISSUES + + This section contains general requirements that may be applicable to + all application-layer protocols. + + 2.1 Host Names and Numbers + + The syntax of a legal Internet host name was specified in RFC-952 + [DNS:4]. One aspect of host name syntax is hereby changed: the + restriction on the first character is relaxed to allow either a + letter or a digit. Host software MUST support this more liberal + syntax. + + Host software MUST handle host names of up to 63 characters and + SHOULD handle host names of up to 255 characters. + + Whenever a user inputs the identity of an Internet host, it SHOULD + be possible to enter either (1) a host domain name or (2) an IP + address in dotted-decimal ("#.#.#.#") form. The host SHOULD check + the string syntactically for a dotted-decimal number before + looking it up in the Domain Name System. + + DISCUSSION: + This last requirement is not intended to specify the complete + syntactic form for entering a dotted-decimal host number; + that is considered to be a user-interface issue. For + example, a dotted-decimal number must be enclosed within + "[ ]" brackets for SMTP mail (see Section 5.2.17). This + notation could be made universal within a host system, + simplifying the syntactic checking for a dotted-decimal + number. + + If a dotted-decimal number can be entered without such + identifying delimiters, then a full syntactic check must be + made, because a segment of a host domain name is now allowed + to begin with a digit and could legally be entirely numeric + (see Section 6.1.2.4). However, a valid host name can never + have the dotted-decimal form #.#.#.#, since at least the + highest-level component label will be alphabetic. + + 2.2 Using Domain Name Service + + Host domain names MUST be translated to IP addresses as described + in Section 6.1. + + Applications using domain name services MUST be able to cope with + soft error conditions. Applications MUST wait a reasonable + interval between successive retries due to a soft error, and MUST + + + +Internet Engineering Task Force [Page 13] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + + allow for the possibility that network problems may deny service + for hours or even days. + + An application SHOULD NOT rely on the ability to locate a WKS + record containing an accurate listing of all services at a + particular host address, since the WKS RR type is not often used + by Internet sites. To confirm that a service is present, simply + attempt to use it. + + 2.3 Applications on Multihomed hosts + + When the remote host is multihomed, the name-to-address + translation will return a list of alternative IP addresses. As + specified in Section 6.1.3.4, this list should be in order of + decreasing preference. Application protocol implementations + SHOULD be prepared to try multiple addresses from the list until + success is obtained. More specific requirements for SMTP are + given in Section 5.3.4. + + When the local host is multihomed, a UDP-based request/response + application SHOULD send the response with an IP source address + that is the same as the specific destination address of the UDP + request datagram. The "specific destination address" is defined + in the "IP Addressing" section of the companion RFC [INTRO:1]. + + Similarly, a server application that opens multiple TCP + connections to the same client SHOULD use the same local IP + address for all. + + 2.4 Type-of-Service + + Applications MUST select appropriate TOS values when they invoke + transport layer services, and these values MUST be configurable. + Note that a TOS value contains 5 bits, of which only the most- + significant 3 bits are currently defined; the other two bits MUST + be zero. + + DISCUSSION: + As gateway algorithms are developed to implement Type-of- + Service, the recommended values for various application + protocols may change. In addition, it is likely that + particular combinations of users and Internet paths will want + non-standard TOS values. For these reasons, the TOS values + must be configurable. + + See the latest version of the "Assigned Numbers" RFC + [INTRO:5] for the recommended TOS values for the major + application protocols. + + + +Internet Engineering Task Force [Page 14] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + + 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +User interfaces: | | | | | | | + Allow host name to begin with digit |2.1 |x| | | | | + Host names of up to 635 characters |2.1 |x| | | | | + Host names of up to 255 characters |2.1 | |x| | | | + Support dotted-decimal host numbers |2.1 | |x| | | | + Check syntactically for dotted-dec first |2.1 | |x| | | | + | | | | | | | +Map domain names per Section 6.1 |2.2 |x| | | | | +Cope with soft DNS errors |2.2 |x| | | | | + Reasonable interval between retries |2.2 |x| | | | | + Allow for long outages |2.2 |x| | | | | +Expect WKS records to be available |2.2 | | | |x| | + | | | | | | | +Try multiple addr's for remote multihomed host |2.3 | |x| | | | +UDP reply src addr is specific dest of request |2.3 | |x| | | | +Use same IP addr for related TCP connections |2.3 | |x| | | | +Specify appropriate TOS values |2.4 |x| | | | | + TOS values configurable |2.4 |x| | | | | + Unused TOS bits zero |2.4 |x| | | | | + | | | | | | | + | | | | | | | + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 15] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + +3. REMOTE LOGIN -- TELNET PROTOCOL + + 3.1 INTRODUCTION + + Telnet is the standard Internet application protocol for remote + login. It provides the encoding rules to link a user's + keyboard/display on a client ("user") system with a command + interpreter on a remote server system. A subset of the Telnet + protocol is also incorporated within other application protocols, + e.g., FTP and SMTP. + + Telnet uses a single TCP connection, and its normal data stream + ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with + escape sequences to embed control functions. Telnet also allows + the negotiation of many optional modes and functions. + + The primary Telnet specification is to be found in RFC-854 + [TELNET:1], while the options are defined in many other RFCs; see + Section 7 for references. + + 3.2 PROTOCOL WALK-THROUGH + + 3.2.1 Option Negotiation: RFC-854, pp. 2-3 + + Every Telnet implementation MUST include option negotiation and + subnegotiation machinery [TELNET:2]. + + A host MUST carefully follow the rules of RFC-854 to avoid + option-negotiation loops. A host MUST refuse (i.e, reply + WONT/DONT to a DO/WILL) an unsupported option. Option + negotiation SHOULD continue to function (even if all requests + are refused) throughout the lifetime of a Telnet connection. + + If all option negotiations fail, a Telnet implementation MUST + default to, and support, an NVT. + + DISCUSSION: + Even though more sophisticated "terminals" and supporting + option negotiations are becoming the norm, all + implementations must be prepared to support an NVT for any + user-server communication. + + 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 + + On a host that never sends the Telnet command Go Ahead (GA), + the Telnet Server MUST attempt to negotiate the Suppress Go + Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or + Server Telnet MUST always accept negotiation of the Suppress Go + + + +Internet Engineering Task Force [Page 16] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Ahead option. + + When it is driving a full-duplex terminal for which GA has no + meaning, a User Telnet implementation MAY ignore GA commands. + + DISCUSSION: + Half-duplex ("locked-keyboard") line-at-a-time terminals + for which the Go-Ahead mechanism was designed have largely + disappeared from the scene. It turned out to be difficult + to implement sending the Go-Ahead signal in many operating + systems, even some systems that support native half-duplex + terminals. The difficulty is typically that the Telnet + server code does not have access to information about + whether the user process is blocked awaiting input from + the Telnet connection, i.e., it cannot reliably determine + when to send a GA command. Therefore, most Telnet Server + hosts do not send GA commands. + + The effect of the rules in this section is to allow either + end of a Telnet connection to veto the use of GA commands. + + There is a class of half-duplex terminals that is still + commercially important: "data entry terminals," which + interact in a full-screen manner. However, supporting + data entry terminals using the Telnet protocol does not + require the Go Ahead signal; see Section 3.3.2. + + 3.2.3 Control Functions: RFC-854, pp. 7-8 + + The list of Telnet commands has been extended to include EOR + (End-of-Record), with code 239 [TELNET:9]. + + Both User and Server Telnets MAY support the control functions + EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP, + SB, and SE. + + A host MUST be able to receive and ignore any Telnet control + functions that it does not support. + + DISCUSSION: + Note that a Server Telnet is required to support the + Telnet IP (Interrupt Process) function, even if the server + host has an equivalent in-stream function (e.g., Control-C + in many systems). The Telnet IP function may be stronger + than an in-stream interrupt command, because of the out- + of-band effect of TCP urgent data. + + The EOR control function may be used to delimit the + + + +Internet Engineering Task Force [Page 17] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + stream. An important application is data entry terminal + support (see Section 3.3.2). There was concern that since + EOR had not been defined in RFC-854, a host that was not + prepared to correctly ignore unknown Telnet commands might + crash if it received an EOR. To protect such hosts, the + End-of-Record option [TELNET:9] was introduced; however, a + properly implemented Telnet program will not require this + protection. + + 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10 + + When it receives "urgent" TCP data, a User or Server Telnet + MUST discard all data except Telnet commands until the DM (and + end of urgent) is reached. + + When it sends Telnet IP (Interrupt Process), a User Telnet + SHOULD follow it by the Telnet "Synch" sequence, i.e., send as + TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent + pointer points to the DM octet. + + When it receives a Telnet IP command, a Server Telnet MAY send + a Telnet "Synch" sequence back to the user, to flush the output + stream. The choice ought to be consistent with the way the + server operating system behaves when a local user interrupts a + process. + + When it receives a Telnet AO command, a Server Telnet MUST send + a Telnet "Synch" sequence back to the user, to flush the output + stream. + + A User Telnet SHOULD have the capability of flushing output + when it sends a Telnet IP; see also Section 3.4.5. + + DISCUSSION: + There are three possible ways for a User Telnet to flush + the stream of server output data: + + (1) Send AO after IP. + + This will cause the server host to send a "flush- + buffered-output" signal to its operating system. + However, the AO may not take effect locally, i.e., + stop terminal output at the User Telnet end, until + the Server Telnet has received and processed the AO + and has sent back a "Synch". + + (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard + all output locally until a WILL/WONT TIMING-MARK is + + + +Internet Engineering Task Force [Page 18] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + received from the Server Telnet. + + Since the DO TIMING-MARK will be processed after the + IP at the server, the reply to it should be in the + right place in the output data stream. However, the + TIMING-MARK will not send a "flush buffered output" + signal to the server operating system. Whether or + not this is needed is dependent upon the server + system. + + (3) Do both. + + The best method is not entirely clear, since it must + accommodate a number of existing server hosts that do not + follow the Telnet standards in various ways. The safest + approach is probably to provide a user-controllable option + to select (1), (2), or (3). + + 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11 + + In NVT mode, a Telnet SHOULD NOT send characters with the + high-order bit 1, and MUST NOT send it as a parity bit. + Implementations that pass the high-order bit to applications + SHOULD negotiate binary mode (see Section 3.2.6). + + + DISCUSSION: + Implementors should be aware that a strict reading of + RFC-854 allows a client or server expecting NVT ASCII to + ignore characters with the high-order bit set. In + general, binary mode is expected to be used for + transmission of an extended (beyond 7-bit) character set + with Telnet. + + However, there exist applications that really need an 8- + bit NVT mode, which is currently not defined, and these + existing applications do set the high-order bit during + part or all of the life of a Telnet connection. Note that + binary mode is not the same as 8-bit NVT mode, since + binary mode turns off end-of-line processing. For this + reason, the requirements on the high-order bit are stated + as SHOULD, not MUST. + + RFC-854 defines a minimal set of properties of a "network + virtual terminal" or NVT; this is not meant to preclude + additional features in a real terminal. A Telnet + connection is fully transparent to all 7-bit ASCII + characters, including arbitrary ASCII control characters. + + + +Internet Engineering Task Force [Page 19] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + For example, a terminal might support full-screen commands + coded as ASCII escape sequences; a Telnet implementation + would pass these sequences as uninterpreted data. Thus, + an NVT should not be conceived as a terminal type of a + highly-restricted device. + + 3.2.6 Telnet Command Structure: RFC-854, p. 13 + + Since options may appear at any point in the data stream, a + Telnet escape character (known as IAC, with the value 255) to + be sent as data MUST be doubled. + + 3.2.7 Telnet Binary Option: RFC-856 + + When the Binary option has been successfully negotiated, + arbitrary 8-bit characters are allowed. However, the data + stream MUST still be scanned for IAC characters, any embedded + Telnet commands MUST be obeyed, and data bytes equal to IAC + MUST be doubled. Other character processing (e.g., replacing + CR by CR NUL or by CR LF) MUST NOT be done. In particular, + there is no end-of-line convention (see Section 3.3.1) in + binary mode. + + DISCUSSION: + The Binary option is normally negotiated in both + directions, to change the Telnet connection from NVT mode + to "binary mode". + + The sequence IAC EOR can be used to delimit blocks of data + within a binary-mode Telnet stream. + + 3.2.8 Telnet Terminal-Type Option: RFC-1091 + + The Terminal-Type option MUST use the terminal type names + officially defined in the Assigned Numbers RFC [INTRO:5], when + they are available for the particular terminal. However, the + receiver of a Terminal-Type option MUST accept any name. + + DISCUSSION: + RFC-1091 [TELNET:10] updates an earlier version of the + Terminal-Type option defined in RFC-930. The earlier + version allowed a server host capable of supporting + multiple terminal types to learn the type of a particular + client's terminal, assuming that each physical terminal + had an intrinsic type. However, today a "terminal" is + often really a terminal emulator program running in a PC, + perhaps capable of emulating a range of terminal types. + Therefore, RFC-1091 extends the specification to allow a + + + +Internet Engineering Task Force [Page 20] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + more general terminal-type negotiation between User and + Server Telnets. + + 3.3 SPECIFIC ISSUES + + 3.3.1 Telnet End-of-Line Convention + + The Telnet protocol defines the sequence CR LF to mean "end- + of-line". For terminal input, this corresponds to a command- + completion or "end-of-line" key being pressed on a user + terminal; on an ASCII terminal, this is the CR key, but it may + also be labelled "Return" or "Enter". + + When a Server Telnet receives the Telnet end-of-line sequence + CR LF as input from a remote terminal, the effect MUST be the + same as if the user had pressed the "end-of-line" key on a + local terminal. On server hosts that use ASCII, in particular, + receipt of the Telnet sequence CR LF must cause the same effect + as a local user pressing the CR key on a local terminal. Thus, + CR LF and CR NUL MUST have the same effect on an ASCII server + host when received as input over a Telnet connection. + + A User Telnet MUST be able to send any of the forms: CR LF, CR + NUL, and LF. A User Telnet on an ASCII host SHOULD have a + user-controllable mode to send either CR LF or CR NUL when the + user presses the "end-of-line" key, and CR LF SHOULD be the + default. + + The Telnet end-of-line sequence CR LF MUST be used to send + Telnet data that is not terminal-to-computer (e.g., for Server + Telnet sending output, or the Telnet protocol incorporated + another application protocol). + + DISCUSSION: + To allow interoperability between arbitrary Telnet clients + and servers, the Telnet protocol defined a standard + representation for a line terminator. Since the ASCII + character set includes no explicit end-of-line character, + systems have chosen various representations, e.g., CR, LF, + and the sequence CR LF. The Telnet protocol chose the CR + LF sequence as the standard for network transmission. + + Unfortunately, the Telnet protocol specification in RFC- + 854 [TELNET:1] has turned out to be somewhat ambiguous on + what character(s) should be sent from client to server for + the "end-of-line" key. The result has been a massive and + continuing interoperability headache, made worse by + various faulty implementations of both User and Server + + + +Internet Engineering Task Force [Page 21] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Telnets. + + Although the Telnet protocol is based on a perfectly + symmetric model, in a remote login session the role of the + user at a terminal differs from the role of the server + host. For example, RFC-854 defines the meaning of CR, LF, + and CR LF as output from the server, but does not specify + what the User Telnet should send when the user presses the + "end-of-line" key on the terminal; this turns out to be + the point at issue. + + When a user presses the "end-of-line" key, some User + Telnet implementations send CR LF, while others send CR + NUL (based on a different interpretation of the same + sentence in RFC-854). These will be equivalent for a + correctly-implemented ASCII server host, as discussed + above. For other servers, a mode in the User Telnet is + needed. + + The existence of User Telnets that send only CR NUL when + CR is pressed creates a dilemma for non-ASCII hosts: they + can either treat CR NUL as equivalent to CR LF in input, + thus precluding the possibility of entering a "bare" CR, + or else lose complete interworking. + + Suppose a user on host A uses Telnet to log into a server + host B, and then execute B's User Telnet program to log + into server host C. It is desirable for the Server/User + Telnet combination on B to be as transparent as possible, + i.e., to appear as if A were connected directly to C. In + particular, correct implementation will make B transparent + to Telnet end-of-line sequences, except that CR LF may be + translated to CR NUL or vice versa. + + IMPLEMENTATION: + To understand Telnet end-of-line issues, one must have at + least a general model of the relationship of Telnet to the + local operating system. The Server Telnet process is + typically coupled into the terminal driver software of the + operating system as a pseudo-terminal. A Telnet end-of- + line sequence received by the Server Telnet must have the + same effect as pressing the end-of-line key on a real + locally-connected terminal. + + Operating systems that support interactive character-at- + a-time applications (e.g., editors) typically have two + internal modes for their terminal I/O: a formatted mode, + in which local conventions for end-of-line and other + + + +Internet Engineering Task Force [Page 22] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + formatting rules have been applied to the data stream, and + a "raw" mode, in which the application has direct access + to every character as it was entered. A Server Telnet + must be implemented in such a way that these modes have + the same effect for remote as for local terminals. For + example, suppose a CR LF or CR NUL is received by the + Server Telnet on an ASCII host. In raw mode, a CR + character is passed to the application; in formatted mode, + the local system's end-of-line convention is used. + + 3.3.2 Data Entry Terminals + + DISCUSSION: + In addition to the line-oriented and character-oriented + ASCII terminals for which Telnet was designed, there are + several families of video display terminals that are + sometimes known as "data entry terminals" or DETs. The + IBM 3270 family is a well-known example. + + Two Internet protocols have been designed to support + generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET + option [TELNET:18, TELNET:19]. The DET option drives a + data entry terminal over a Telnet connection using (sub-) + negotiation. SUPDUP is a completely separate terminal + protocol, which can be entered from Telnet by negotiation. + Although both SUPDUP and the DET option have been used + successfully in particular environments, neither has + gained general acceptance or wide implementation. + + A different approach to DET interaction has been developed + for supporting the IBM 3270 family through Telnet, + although the same approach would be applicable to any DET. + The idea is to enter a "native DET" mode, in which the + native DET input/output stream is sent as binary data. + The Telnet EOR command is used to delimit logical records + (e.g., "screens") within this binary stream. + + IMPLEMENTATION: + The rules for entering and leaving native DET mode are as + follows: + + o The Server uses the Terminal-Type option [TELNET:10] + to learn that the client is a DET. + + o It is conventional, but not required, that both ends + negotiate the EOR option [TELNET:9]. + + o Both ends negotiate the Binary option [TELNET:3] to + + + +Internet Engineering Task Force [Page 23] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + enter native DET mode. + + o When either end negotiates out of binary mode, the + other end does too, and the mode then reverts to + normal NVT. + + + 3.3.3 Option Requirements + + Every Telnet implementation MUST support the Binary option + [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and + SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of- + Record [TELNET:9], and Extended Options List [TELNET:8] + options. + + A User or Server Telnet SHOULD support the Window Size Option + [TELNET:12] if the local operating system provides the + corresponding capability. + + DISCUSSION: + Note that the End-of-Record option only signifies that a + Telnet can receive a Telnet EOR without crashing; + therefore, every Telnet ought to be willing to accept + negotiation of the End-of-Record option. See also the + discussion in Section 3.2.3. + + 3.3.4 Option Initiation + + When the Telnet protocol is used in a client/server situation, + the server SHOULD initiate negotiation of the terminal + interaction mode it expects. + + DISCUSSION: + The Telnet protocol was defined to be perfectly + symmetrical, but its application is generally asymmetric. + Remote login has been known to fail because NEITHER side + initiated negotiation of the required non-default terminal + modes. It is generally the server that determines the + preferred mode, so the server needs to initiate the + negotiation; since the negotiation is symmetric, the user + can also initiate it. + + A client (User Telnet) SHOULD provide a means for users to + enable and disable the initiation of option negotiation. + + DISCUSSION: + A user sometimes needs to connect to an application + service (e.g., FTP or SMTP) that uses Telnet for its + + + +Internet Engineering Task Force [Page 24] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + control stream but does not support Telnet options. User + Telnet may be used for this purpose if initiation of + option negotiation is disabled. + + 3.3.5 Telnet Linemode Option + + DISCUSSION: + An important new Telnet option, LINEMODE [TELNET:12], has + been proposed. The LINEMODE option provides a standard + way for a User Telnet and a Server Telnet to agree that + the client rather than the server will perform terminal + character processing. When the client has prepared a + complete line of text, it will send it to the server in + (usually) one TCP packet. This option will greatly + decrease the packet cost of Telnet sessions and will also + give much better user response over congested or long- + delay networks. + + The LINEMODE option allows dynamic switching between local + and remote character processing. For example, the Telnet + connection will automatically negotiate into single- + character mode while a full screen editor is running, and + then return to linemode when the editor is finished. + + We expect that when this RFC is released, hosts should + implement the client side of this option, and may + implement the server side of this option. To properly + implement the server side, the server needs to be able to + tell the local system not to do any input character + processing, but to remember its current terminal state and + notify the Server Telnet process whenever the state + changes. This will allow password echoing and full screen + editors to be handled properly, for example. + + 3.4 TELNET/USER INTERFACE + + 3.4.1 Character Set Transparency + + User Telnet implementations SHOULD be able to send or receive + any 7-bit ASCII character. Where possible, any special + character interpretations by the user host's operating system + SHOULD be bypassed so that these characters can conveniently be + sent and received on the connection. + + Some character value MUST be reserved as "escape to command + mode"; conventionally, doubling this character allows it to be + entered as data. The specific character used SHOULD be user + selectable. + + + +Internet Engineering Task Force [Page 25] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + On binary-mode connections, a User Telnet program MAY provide + an escape mechanism for entering arbitrary 8-bit values, if the + host operating system doesn't allow them to be entered directly + from the keyboard. + + IMPLEMENTATION: + The transparency issues are less pressing on servers, but + implementors should take care in dealing with issues like: + masking off parity bits (sent by an older, non-conforming + client) before they reach programs that expect only NVT + ASCII, and properly handling programs that request 8-bit + data streams. + + 3.4.2 Telnet Commands + + A User Telnet program MUST provide a user the capability of + entering any of the Telnet control functions IP, AO, or AYT, + and SHOULD provide the capability of entering EC, EL, and + Break. + + 3.4.3 TCP Connection Errors + + A User Telnet program SHOULD report to the user any TCP errors + that are reported by the transport layer (see "TCP/Application + Layer Interface" section in [INTRO:1]). + + 3.4.4 Non-Default Telnet Contact Port + + A User Telnet program SHOULD allow the user to optionally + specify a non-standard contact port number at the Server Telnet + host. + + 3.4.5 Flushing Output + + A User Telnet program SHOULD provide the user the ability to + specify whether or not output should be flushed when an IP is + sent; see Section 3.2.4. + + For any output flushing scheme that causes the User Telnet to + flush output locally until a Telnet signal is received from the + Server, there SHOULD be a way for the user to manually restore + normal output, in case the Server fails to send the expected + signal. + + + + + + + + +Internet Engineering Task Force [Page 26] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + 3.5. TELNET REQUIREMENTS SUMMARY + + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------------|--------|-|-|-|-|-|-- + | | | | | | | +Option Negotiation |3.2.1 |x| | | | | + Avoid negotiation loops |3.2.1 |x| | | | | + Refuse unsupported options |3.2.1 |x| | | | | + Negotiation OK anytime on connection |3.2.1 | |x| | | | + Default to NVT |3.2.1 |x| | | | | + Send official name in Term-Type option |3.2.8 |x| | | | | + Accept any name in Term-Type option |3.2.8 |x| | | | | + Implement Binary, Suppress-GA options |3.3.3 |x| | | | | + Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | | + Implement Window-Size option if appropriate |3.3.3 | |x| | | | + Server initiate mode negotiations |3.3.4 | |x| | | | + User can enable/disable init negotiations |3.3.4 | |x| | | | + | | | | | | | +Go-Aheads | | | | | | | + Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | | + User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | | + User Telnet ignore GA's |3.2.2 | | |x| | | + | | | | | | | +Control Functions | | | | | | | + Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | | + Support EOR EC EL Break |3.2.3 | | |x| | | + Ignore unsupported control functions |3.2.3 |x| | | | | + User, Server discard urgent data up to DM |3.2.4 |x| | | | | + User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | | + Server Telnet reply Synch to IP |3.2.4 | | |x| | | + Server Telnet reply Synch to AO |3.2.4 |x| | | | | + User Telnet can flush output when send IP |3.2.4 | |x| | | | + | | | | | | | +Encoding | | | | | | | + Send high-order bit in NVT mode |3.2.5 | | | |x| | + Send high-order bit as parity bit |3.2.5 | | | | |x| + Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | | + Always double IAC data byte |3.2.6 |x| | | | | + + + +Internet Engineering Task Force [Page 27] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Double IAC data byte in binary mode |3.2.7 |x| | | | | + Obey Telnet cmds in binary mode |3.2.7 |x| | | | | + End-of-line, CR NUL in binary mode |3.2.7 | | | | |x| + | | | | | | | +End-of-Line | | | | | | | + EOL at Server same as local end-of-line |3.3.1 |x| | | | | + ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | | + User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | | + ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | | + User Telnet default mode is CR LF |3.3.1 | |x| | | | + Non-interactive uses CR LF for EOL |3.3.1 |x| | | | | + | | | | | | | +User Telnet interface | | | | | | | + Input & output all 7-bit characters |3.4.1 | |x| | | | + Bypass local op sys interpretation |3.4.1 | |x| | | | + Escape character |3.4.1 |x| | | | | + User-settable escape character |3.4.1 | |x| | | | + Escape to enter 8-bit values |3.4.1 | | |x| | | + Can input IP, AO, AYT |3.4.2 |x| | | | | + Can input EC, EL, Break |3.4.2 | |x| | | | + Report TCP connection errors to user |3.4.3 | |x| | | | + Optional non-default contact port |3.4.4 | |x| | | | + Can spec: output flushed when IP sent |3.4.5 | |x| | | | + Can manually restore output mode |3.4.5 | |x| | | | + | | | | | | | + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 28] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + +4. FILE TRANSFER + + 4.1 FILE TRANSFER PROTOCOL -- FTP + + 4.1.1 INTRODUCTION + + The File Transfer Protocol FTP is the primary Internet standard + for file transfer. The current specification is contained in + RFC-959 [FTP:1]. + + FTP uses separate simultaneous TCP connections for control and + for data transfer. The FTP protocol includes many features, + some of which are not commonly implemented. However, for every + feature in FTP, there exists at least one implementation. The + minimum implementation defined in RFC-959 was too small, so a + somewhat larger minimum implementation is defined here. + + Internet users have been unnecessarily burdened for years by + deficient FTP implementations. Protocol implementors have + suffered from the erroneous opinion that implementing FTP ought + to be a small and trivial task. This is wrong, because FTP has + a user interface, because it has to deal (correctly) with the + whole variety of communication and operating system errors that + may occur, and because it has to handle the great diversity of + real file systems in the world. + + 4.1.2. PROTOCOL WALK-THROUGH + + 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4 + + An FTP program MUST support TYPE I ("IMAGE" or binary type) + as well as TYPE L 8 ("LOCAL" type with logical byte size 8). + A machine whose memory is organized into m-bit words, where + m is not a multiple of 8, MAY also support TYPE L m. + + DISCUSSION: + The command "TYPE L 8" is often required to transfer + binary data between a machine whose memory is organized + into (e.g.) 36-bit words and a machine with an 8-bit + byte organization. For an 8-bit byte machine, TYPE L 8 + is equivalent to IMAGE. + + "TYPE L m" is sometimes specified to the FTP programs + on two m-bit word machines to ensure the correct + transfer of a native-mode binary file from one machine + to the other. However, this command should have the + same effect on these machines as "TYPE I". + + + + +Internet Engineering Task Force [Page 29] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2 + + A host that makes no distinction between TYPE N and TYPE T + SHOULD implement TYPE T to be identical to TYPE N. + + DISCUSSION: + This provision should ease interoperation with hosts + that do make this distinction. + + Many hosts represent text files internally as strings + of ASCII characters, using the embedded ASCII format + effector characters (LF, BS, FF, ...) to control the + format when a file is printed. For such hosts, there + is no distinction between "print" files and other + files. However, systems that use record structured + files typically need a special format for printable + files (e.g., ASA carriage control). For the latter + hosts, FTP allows a choice of TYPE N or TYPE T. + + 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I + + Implementation of page structure is NOT RECOMMENDED in + general. However, if a host system does need to implement + FTP for "random access" or "holey" files, it MUST use the + defined page structure format rather than define a new + private FTP format. + + 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2 + + An FTP transformation between record-structure and file- + structure SHOULD be invertible, to the extent possible while + making the result useful on the target host. + + DISCUSSION: + RFC-959 required strict invertibility between record- + structure and file-structure, but in practice, + efficiency and convenience often preclude it. + Therefore, the requirement is being relaxed. There are + two different objectives for transferring a file: + processing it on the target host, or just storage. For + storage, strict invertibility is important. For + processing, the file created on the target host needs + to be in the format expected by application programs on + that host. + + As an example of the conflict, imagine a record- + oriented operating system that requires some data files + to have exactly 80 bytes in each record. While STORing + + + +Internet Engineering Task Force [Page 30] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + a file on such a host, an FTP Server must be able to + pad each line or record to 80 bytes; a later retrieval + of such a file cannot be strictly invertible. + + 4.1.2.5 Data Connection Management: RFC-959 Section 3.3 + + A User-FTP that uses STREAM mode SHOULD send a PORT command + to assign a non-default data port before each transfer + command is issued. + + DISCUSSION: + This is required because of the long delay after a TCP + connection is closed until its socket pair can be + reused, to allow multiple transfers during a single FTP + session. Sending a port command can avoided if a + transfer mode other than stream is used, by leaving the + data transfer connection open between transfers. + + 4.1.2.6 PASV Command: RFC-959 Section 4.1.2 + + A server-FTP MUST implement the PASV command. + + If multiple third-party transfers are to be executed during + the same session, a new PASV command MUST be issued before + each transfer command, to obtain a unique port pair. + + IMPLEMENTATION: + The format of the 227 reply to a PASV command is not + well standardized. In particular, an FTP client cannot + assume that the parentheses shown on page 40 of RFC-959 + will be present (and in fact, Figure 3 on page 43 omits + them). Therefore, a User-FTP program that interprets + the PASV reply must scan the reply for the first digit + of the host and port numbers. + + Note that the host number h1,h2,h3,h4 is the IP address + of the server host that is sending the reply, and that + p1,p2 is a non-default data transfer port that PASV has + assigned. + + 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3 + + The data returned by an NLST command MUST contain only a + simple list of legal pathnames, such that the server can use + them directly as the arguments of subsequent data transfer + commands for the individual files. + + The data returned by a LIST or NLST command SHOULD use an + + + +Internet Engineering Task Force [Page 31] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + implied TYPE AN, unless the current type is EBCDIC, in which + case an implied TYPE EN SHOULD be used. + + DISCUSSION: + Many FTP clients support macro-commands that will get + or put files matching a wildcard specification, using + NLST to obtain a list of pathnames. The expansion of + "multiple-put" is local to the client, but "multiple- + get" requires cooperation by the server. + + The implied type for LIST and NLST is designed to + provide compatibility with existing User-FTPs, and in + particular with multiple-get commands. + + 4.1.2.8 SITE Command: RFC-959 Section 4.1.3 + + A Server-FTP SHOULD use the SITE command for non-standard + features, rather than invent new private commands or + unstandardized extensions to existing commands. + + 4.1.2.9 STOU Command: RFC-959 Section 4.1.3 + + The STOU command stores into a uniquely named file. When it + receives an STOU command, a Server-FTP MUST return the + actual file name in the "125 Transfer Starting" or the "150 + Opening Data Connection" message that precedes the transfer + (the 250 reply code mentioned in RFC-959 is incorrect). The + exact format of these messages is hereby defined to be as + follows: + + 125 FILE: pppp + 150 FILE: pppp + + where pppp represents the unique pathname of the file that + will be written. + + 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34 + + Implementors MUST NOT assume any correspondence between READ + boundaries on the control connection and the Telnet EOL + sequences (CR LF). + + DISCUSSION: + Thus, a server-FTP (or User-FTP) must continue reading + characters from the control connection until a complete + Telnet EOL sequence is encountered, before processing + the command (or response, respectively). Conversely, a + single READ from the control connection may include + + + +Internet Engineering Task Force [Page 32] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + more than one FTP command. + + 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35 + + A Server-FTP MUST send only correctly formatted replies on + the control connection. Note that RFC-959 (unlike earlier + versions of the FTP spec) contains no provision for a + "spontaneous" reply message. + + A Server-FTP SHOULD use the reply codes defined in RFC-959 + whenever they apply. However, a server-FTP MAY use a + different reply code when needed, as long as the general + rules of Section 4.2 are followed. When the implementor has + a choice between a 4xx and 5xx reply code, a Server-FTP + SHOULD send a 4xx (temporary failure) code when there is any + reasonable possibility that a failed FTP will succeed a few + hours later. + + A User-FTP SHOULD generally use only the highest-order digit + of a 3-digit reply code for making a procedural decision, to + prevent difficulties when a Server-FTP uses non-standard + reply codes. + + A User-FTP MUST be able to handle multi-line replies. If + the implementation imposes a limit on the number of lines + and if this limit is exceeded, the User-FTP MUST recover, + e.g., by ignoring the excess lines until the end of the + multi-line reply is reached. + + A User-FTP SHOULD NOT interpret a 421 reply code ("Service + not available, closing control connection") specially, but + SHOULD detect closing of the control connection by the + server. + + DISCUSSION: + Server implementations that fail to strictly follow the + reply rules often cause FTP user programs to hang. + Note that RFC-959 resolved ambiguities in the reply + rules found in earlier FTP specifications and must be + followed. + + It is important to choose FTP reply codes that properly + distinguish between temporary and permanent failures, + to allow the successful use of file transfer client + daemons. These programs depend on the reply codes to + decide whether or not to retry a failed transfer; using + a permanent failure code (5xx) for a temporary error + will cause these programs to give up unnecessarily. + + + +Internet Engineering Task Force [Page 33] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + When the meaning of a reply matches exactly the text + shown in RFC-959, uniformity will be enhanced by using + the RFC-959 text verbatim. However, a Server-FTP + implementor is encouraged to choose reply text that + conveys specific system-dependent information, when + appropriate. + + 4.1.2.12 Connections: RFC-959 Section 5.2 + + The words "and the port used" in the second paragraph of + this section of RFC-959 are erroneous (historical), and they + should be ignored. + + On a multihomed server host, the default data transfer port + (L-1) MUST be associated with the same local IP address as + the corresponding control connection to port L. + + A user-FTP MUST NOT send any Telnet controls other than + SYNCH and IP on an FTP control connection. In particular, it + MUST NOT attempt to negotiate Telnet options on the control + connection. However, a server-FTP MUST be capable of + accepting and refusing Telnet negotiations (i.e., sending + DONT/WONT). + + DISCUSSION: + Although the RFC says: "Server- and User- processes + should follow the conventions for the Telnet + protocol...[on the control connection]", it is not the + intent that Telnet option negotiation is to be + employed. + + 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1 + + The following commands and options MUST be supported by + every server-FTP and user-FTP, except in cases where the + underlying file system or operating system does not allow or + support a particular command. + + Type: ASCII Non-print, IMAGE, LOCAL 8 + Mode: Stream + Structure: File, Record* + Commands: + USER, PASS, ACCT, + PORT, PASV, + TYPE, MODE, STRU, + RETR, STOR, APPE, + RNFR, RNTO, DELE, + CWD, CDUP, RMD, MKD, PWD, + + + +Internet Engineering Task Force [Page 34] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + LIST, NLST, + SYST, STAT, + HELP, NOOP, QUIT. + + *Record structure is REQUIRED only for hosts whose file + systems support record structure. + + DISCUSSION: + Vendors are encouraged to implement a larger subset of + the protocol. For example, there are important + robustness features in the protocol (e.g., Restart, + ABOR, block mode) that would be an aid to some Internet + users but are not widely implemented. + + A host that does not have record structures in its file + system may still accept files with STRU R, recording + the byte stream literally. + + 4.1.3 SPECIFIC ISSUES + + 4.1.3.1 Non-standard Command Verbs + + FTP allows "experimental" commands, whose names begin with + "X". If these commands are subsequently adopted as + standards, there may still be existing implementations using + the "X" form. At present, this is true for the directory + commands: + + RFC-959 "Experimental" + + MKD XMKD + RMD XRMD + PWD XPWD + CDUP XCUP + CWD XCWD + + All FTP implementations SHOULD recognize both forms of these + commands, by simply equating them with extra entries in the + command lookup table. + + IMPLEMENTATION: + A User-FTP can access a server that supports only the + "X" forms by implementing a mode switch, or + automatically using the following procedure: if the + RFC-959 form of one of the above commands is rejected + with a 500 or 502 response code, then try the + experimental form; any other response would be passed + to the user. + + + +Internet Engineering Task Force [Page 35] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.3.2 Idle Timeout + + A Server-FTP process SHOULD have an idle timeout, which will + terminate the process and close the control connection if + the server is inactive (i.e., no command or data transfer in + progress) for a long period of time. The idle timeout time + SHOULD be configurable, and the default should be at least 5 + minutes. + + A client FTP process ("User-PI" in RFC-959) will need + timeouts on responses only if it is invoked from a program. + + DISCUSSION: + Without a timeout, a Server-FTP process may be left + pending indefinitely if the corresponding client + crashes without closing the control connection. + + 4.1.3.3 Concurrency of Data and Control + + DISCUSSION: + The intent of the designers of FTP was that a user + should be able to send a STAT command at any time while + data transfer was in progress and that the server-FTP + would reply immediately with status -- e.g., the number + of bytes transferred so far. Similarly, an ABOR + command should be possible at any time during a data + transfer. + + Unfortunately, some small-machine operating systems + make such concurrent programming difficult, and some + other implementers seek minimal solutions, so some FTP + implementations do not allow concurrent use of the data + and control connections. Even such a minimal server + must be prepared to accept and defer a STAT or ABOR + command that arrives during data transfer. + + 4.1.3.4 FTP Restart Mechanism + + The description of the 110 reply on pp. 40-41 of RFC-959 is + incorrect; the correct description is as follows. A restart + reply message, sent over the control connection from the + receiving FTP to the User-FTP, has the format: + + 110 MARK ssss = rrrr + + Here: + + * ssss is a text string that appeared in a Restart Marker + + + +Internet Engineering Task Force [Page 36] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + in the data stream and encodes a position in the + sender's file system; + + * rrrr encodes the corresponding position in the + receiver's file system. + + The encoding, which is specific to a particular file system + and network implementation, is always generated and + interpreted by the same system, either sender or receiver. + + When an FTP that implements restart receives a Restart + Marker in the data stream, it SHOULD force the data to that + point to be written to stable storage before encoding the + corresponding position rrrr. An FTP sending Restart Markers + MUST NOT assume that 110 replies will be returned + synchronously with the data, i.e., it must not await a 110 + reply before sending more data. + + Two new reply codes are hereby defined for errors + encountered in restarting a transfer: + + 554 Requested action not taken: invalid REST parameter. + + A 554 reply may result from a FTP service command that + follows a REST command. The reply indicates that the + existing file at the Server-FTP cannot be repositioned + as specified in the REST. + + 555 Requested action not taken: type or stru mismatch. + + A 555 reply may result from an APPE command or from any + FTP service command following a REST command. The + reply indicates that there is some mismatch between the + current transfer parameters (type and stru) and the + attributes of the existing file. + + DISCUSSION: + Note that the FTP Restart mechanism requires that Block + or Compressed mode be used for data transfer, to allow + the Restart Markers to be included within the data + stream. The frequency of Restart Markers can be low. + + Restart Markers mark a place in the data stream, but + the receiver may be performing some transformation on + the data as it is stored into stable storage. In + general, the receiver's encoding must include any state + information necessary to restart this transformation at + any point of the FTP data stream. For example, in TYPE + + + +Internet Engineering Task Force [Page 37] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + A transfers, some receiver hosts transform CR LF + sequences into a single LF character on disk. If a + Restart Marker happens to fall between CR and LF, the + receiver must encode in rrrr that the transfer must be + restarted in a "CR has been seen and discarded" state. + + Note that the Restart Marker is required to be encoded + as a string of printable ASCII characters, regardless + of the type of the data. + + RFC-959 says that restart information is to be returned + "to the user". This should not be taken literally. In + general, the User-FTP should save the restart + information (ssss,rrrr) in stable storage, e.g., append + it to a restart control file. An empty restart control + file should be created when the transfer first starts + and deleted automatically when the transfer completes + successfully. It is suggested that this file have a + name derived in an easily-identifiable manner from the + name of the file being transferred and the remote host + name; this is analogous to the means used by many text + editors for naming "backup" files. + + There are three cases for FTP restart. + + (1) User-to-Server Transfer + + The User-FTP puts Restart Markers at + convenient places in the data stream. When the + Server-FTP receives a Marker, it writes all prior + data to disk, encodes its file system position and + transformation state as rrrr, and returns a "110 + MARK ssss = rrrr" reply over the control + connection. The User-FTP appends the pair + (ssss,rrrr) to its restart control file. + + To restart the transfer, the User-FTP fetches the + last (ssss,rrrr) pair from the restart control + file, repositions its local file system and + transformation state using ssss, and sends the + command "REST rrrr" to the Server-FTP. + + (2) Server-to-User Transfer + + The Server-FTP puts Restart Markers at + convenient places in the data stream. When the + User-FTP receives a Marker, it writes all prior + data to disk, encodes its file system position and + + + +Internet Engineering Task Force [Page 38] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + transformation state as rrrr, and appends the pair + (rrrr,ssss) to its restart control file. + + To restart the transfer, the User-FTP fetches the + last (rrrr,ssss) pair from the restart control + file, repositions its local file system and + transformation state using rrrr, and sends the + command "REST ssss" to the Server-FTP. + + (3) Server-to-Server ("Third-Party") Transfer + + The sending Server-FTP puts Restart Markers + at convenient places in the data stream. When it + receives a Marker, the receiving Server-FTP writes + all prior data to disk, encodes its file system + position and transformation state as rrrr, and + sends a "110 MARK ssss = rrrr" reply over the + control connection to the User. The User-FTP + appends the pair (ssss,rrrr) to its restart + control file. + + To restart the transfer, the User-FTP fetches the + last (ssss,rrrr) pair from the restart control + file, sends "REST ssss" to the sending Server-FTP, + and sends "REST rrrr" to the receiving Server-FTP. + + + 4.1.4 FTP/USER INTERFACE + + This section discusses the user interface for a User-FTP + program. + + 4.1.4.1 Pathname Specification + + Since FTP is intended for use in a heterogeneous + environment, User-FTP implementations MUST support remote + pathnames as arbitrary character strings, so that their form + and content are not limited by the conventions of the local + operating system. + + DISCUSSION: + In particular, remote pathnames can be of arbitrary + length, and all the printing ASCII characters as well + as space (0x20) must be allowed. RFC-959 allows a + pathname to contain any 7-bit ASCII character except CR + or LF. + + + + + +Internet Engineering Task Force [Page 39] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.4.2 "QUOTE" Command + + A User-FTP program MUST implement a "QUOTE" command that + will pass an arbitrary character string to the server and + display all resulting response messages to the user. + + To make the "QUOTE" command useful, a User-FTP SHOULD send + transfer control commands to the server as the user enters + them, rather than saving all the commands and sending them + to the server only when a data transfer is started. + + DISCUSSION: + The "QUOTE" command is essential to allow the user to + access servers that require system-specific commands + (e.g., SITE or ALLO), or to invoke new or optional + features that are not implemented by the User-FTP. For + example, "QUOTE" may be used to specify "TYPE A T" to + send a print file to hosts that require the + distinction, even if the User-FTP does not recognize + that TYPE. + + 4.1.4.3 Displaying Replies to User + + A User-FTP SHOULD display to the user the full text of all + error reply messages it receives. It SHOULD have a + "verbose" mode in which all commands it sends and the full + text and reply codes it receives are displayed, for + diagnosis of problems. + + 4.1.4.4 Maintaining Synchronization + + The state machine in a User-FTP SHOULD be forgiving of + missing and unexpected reply messages, in order to maintain + command synchronization with the server. + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 40] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.5 FTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------|---------------|-|-|-|-|-|-- +Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | | +File/Record transform invertible if poss. |4.1.2.4 | |x| | | | +User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | | +Server-FTP implement PASV |4.1.2.6 |x| | | | | + PASV is per-transfer |4.1.2.6 |x| | | | | +NLST reply usable in RETR cmds |4.1.2.7 |x| | | | | +Implied type for LIST and NLST |4.1.2.7 | |x| | | | +SITE cmd for non-standard features |4.1.2.8 | |x| | | | +STOU cmd return pathname as specified |4.1.2.9 |x| | | | | +Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x| + | | | | | | | +Server-FTP send only correct reply format |4.1.2.11 |x| | | | | +Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | | + New reply code following Section 4.2 |4.1.2.11 | | |x| | | +User-FTP use only high digit of reply |4.1.2.11 | |x| | | | +User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | | +User-FTP handle 421 reply specially |4.1.2.11 | | | |x| | + | | | | | | | +Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | | +User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x| +User-FTP negotiate Telnet options |4.1.2.12 | | | | |x| +Server-FTP handle Telnet options |4.1.2.12 |x| | | | | +Handle "Experimental" directory cmds |4.1.3.1 | |x| | | | +Idle timeout in server-FTP |4.1.3.2 | |x| | | | + Configurable idle timeout |4.1.3.2 | |x| | | | +Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | | +Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x| + | | | | | | | +Support TYPE: | | | | | | | + ASCII - Non-Print (AN) |4.1.2.13 |x| | | | | + ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | | + ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | | + EBCDIC - (any form) |959 3.1.1.2 | | |x| | | + IMAGE |4.1.2.1 |x| | | | | + LOCAL 8 |4.1.2.1 |x| | | | | + + + +Internet Engineering Task Force [Page 41] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + LOCAL m |4.1.2.1 | | |x| | |2 + | | | | | | | +Support MODE: | | | | | | | + Stream |4.1.2.13 |x| | | | | + Block |959 3.4.2 | | |x| | | + | | | | | | | +Support STRUCTURE: | | | | | | | + File |4.1.2.13 |x| | | | | + Record |4.1.2.13 |x| | | | |3 + Page |4.1.2.3 | | | |x| | + | | | | | | | +Support commands: | | | | | | | + USER |4.1.2.13 |x| | | | | + PASS |4.1.2.13 |x| | | | | + ACCT |4.1.2.13 |x| | | | | + CWD |4.1.2.13 |x| | | | | + CDUP |4.1.2.13 |x| | | | | + SMNT |959 5.3.1 | | |x| | | + REIN |959 5.3.1 | | |x| | | + QUIT |4.1.2.13 |x| | | | | + | | | | | | | + PORT |4.1.2.13 |x| | | | | + PASV |4.1.2.6 |x| | | | | + TYPE |4.1.2.13 |x| | | | |1 + STRU |4.1.2.13 |x| | | | |1 + MODE |4.1.2.13 |x| | | | |1 + | | | | | | | + RETR |4.1.2.13 |x| | | | | + STOR |4.1.2.13 |x| | | | | + STOU |959 5.3.1 | | |x| | | + APPE |4.1.2.13 |x| | | | | + ALLO |959 5.3.1 | | |x| | | + REST |959 5.3.1 | | |x| | | + RNFR |4.1.2.13 |x| | | | | + RNTO |4.1.2.13 |x| | | | | + ABOR |959 5.3.1 | | |x| | | + DELE |4.1.2.13 |x| | | | | + RMD |4.1.2.13 |x| | | | | + MKD |4.1.2.13 |x| | | | | + PWD |4.1.2.13 |x| | | | | + LIST |4.1.2.13 |x| | | | | + NLST |4.1.2.13 |x| | | | | + SITE |4.1.2.8 | | |x| | | + STAT |4.1.2.13 |x| | | | | + SYST |4.1.2.13 |x| | | | | + HELP |4.1.2.13 |x| | | | | + NOOP |4.1.2.13 |x| | | | | + | | | | | | | + + + +Internet Engineering Task Force [Page 42] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + +User Interface: | | | | | | | + Arbitrary pathnames |4.1.4.1 |x| | | | | + Implement "QUOTE" command |4.1.4.2 |x| | | | | + Transfer control commands immediately |4.1.4.2 | |x| | | | + Display error messages to user |4.1.4.3 | |x| | | | + Verbose mode |4.1.4.3 | |x| | | | + Maintain synchronization with server |4.1.4.4 | |x| | | | + +Footnotes: + +(1) For the values shown earlier. + +(2) Here m is number of bits in a memory word. + +(3) Required for host with record-structured file system, optional + otherwise. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 43] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP + + 4.2.1 INTRODUCTION + + The Trivial File Transfer Protocol TFTP is defined in RFC-783 + [TFTP:1]. + + TFTP provides its own reliable delivery with UDP as its + transport protocol, using a simple stop-and-wait acknowledgment + system. Since TFTP has an effective window of only one 512 + octet segment, it can provide good performance only over paths + that have a small delay*bandwidth product. The TFTP file + interface is very simple, providing no access control or + security. + + TFTP's most important application is bootstrapping a host over + a local network, since it is simple and small enough to be + easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are + urged to support TFTP for booting. + + 4.2.2 PROTOCOL WALK-THROUGH + + The TFTP specification [TFTP:1] is written in an open style, + and does not fully specify many parts of the protocol. + + 4.2.2.1 Transfer Modes: RFC-783, Page 3 + + The transfer mode "mail" SHOULD NOT be supported. + + 4.2.2.2 UDP Header: RFC-783, Page 17 + + The Length field of a UDP header is incorrectly defined; it + includes the UDP header length (8). + + 4.2.3 SPECIFIC ISSUES + + 4.2.3.1 Sorcerer's Apprentice Syndrome + + There is a serious bug, known as the "Sorcerer's Apprentice + Syndrome," in the protocol specification. While it does not + cause incorrect operation of the transfer (the file will + always be transferred correctly if the transfer completes), + this bug may cause excessive retransmission, which may cause + the transfer to time out. + + Implementations MUST contain the fix for this problem: the + sender (i.e., the side originating the DATA packets) must + never resend the current DATA packet on receipt of a + + + +Internet Engineering Task Force [Page 44] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + duplicate ACK. + + DISCUSSION: + The bug is caused by the protocol rule that either + side, on receiving an old duplicate datagram, may + resend the current datagram. If a packet is delayed in + the network but later successfully delivered after + either side has timed out and retransmitted a packet, a + duplicate copy of the response may be generated. If + the other side responds to this duplicate with a + duplicate of its own, then every datagram will be sent + in duplicate for the remainder of the transfer (unless + a datagram is lost, breaking the repetition). Worse + yet, since the delay is often caused by congestion, + this duplicate transmission will usually causes more + congestion, leading to more delayed packets, etc. + + The following example may help to clarify this problem. + + TFTP A TFTP B + + (1) Receive ACK X-1 + Send DATA X + (2) Receive DATA X + Send ACK X + (ACK X is delayed in network, + and A times out): + (3) Retransmit DATA X + + (4) Receive DATA X again + Send ACK X again + (5) Receive (delayed) ACK X + Send DATA X+1 + (6) Receive DATA X+1 + Send ACK X+1 + (7) Receive ACK X again + Send DATA X+1 again + (8) Receive DATA X+1 again + Send ACK X+1 again + (9) Receive ACK X+1 + Send DATA X+2 + (10) Receive DATA X+2 + Send ACK X+3 + (11) Receive ACK X+1 again + Send DATA X+2 again + (12) Receive DATA X+2 again + Send ACK X+3 again + + + + +Internet Engineering Task Force [Page 45] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + Notice that once the delayed ACK arrives, the protocol + settles down to duplicate all further packets + (sequences 5-8 and 9-12). The problem is caused not by + either side timing out, but by both sides + retransmitting the current packet when they receive a + duplicate. + + The fix is to break the retransmission loop, as + indicated above. This is analogous to the behavior of + TCP. It is then possible to remove the retransmission + timer on the receiver, since the resent ACK will never + cause any action; this is a useful simplification where + TFTP is used in a bootstrap program. It is OK to allow + the timer to remain, and it may be helpful if the + retransmitted ACK replaces one that was genuinely lost + in the network. The sender still requires a retransmit + timer, of course. + + 4.2.3.2 Timeout Algorithms + + A TFTP implementation MUST use an adaptive timeout. + + IMPLEMENTATION: + TCP retransmission algorithms provide a useful base to + work from. At least an exponential backoff of + retransmission timeout is necessary. + + 4.2.3.3 Extensions + + A variety of non-standard extensions have been made to TFTP, + including additional transfer modes and a secure operation + mode (with passwords). None of these have been + standardized. + + 4.2.3.4 Access Control + + A server TFTP implementation SHOULD include some + configurable access control over what pathnames are allowed + in TFTP operations. + + 4.2.3.5 Broadcast Request + + A TFTP request directed to a broadcast address SHOULD be + silently ignored. + + DISCUSSION: + Due to the weak access control capability of TFTP, + directed broadcasts of TFTP requests to random networks + + + +Internet Engineering Task Force [Page 46] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + could create a significant security hole. + + 4.2.4 TFTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------------|--------|-|-|-|-|-|-- +Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | | +Transfer modes: | | | | | | | + netascii |RFC-783 |x| | | | | + octet |RFC-783 |x| | | | | + mail |4.2.2.1 | | | |x| | + extensions |4.2.3.3 | | |x| | | +Use adaptive timeout |4.2.3.2 |x| | | | | +Configurable access control |4.2.3.4 | |x| | | | +Silently ignore broadcast request |4.2.3.5 | |x| | | | +-------------------------------------------------|--------|-|-|-|-|-|-- +-------------------------------------------------|--------|-|-|-|-|-|-- + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 47] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + +5. ELECTRONIC MAIL -- SMTP and RFC-822 + + 5.1 INTRODUCTION + + In the TCP/IP protocol suite, electronic mail in a format + specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail + Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1]. + + While SMTP has remained unchanged over the years, the Internet + community has made several changes in the way SMTP is used. In + particular, the conversion to the Domain Name System (DNS) has + caused changes in address formats and in mail routing. In this + section, we assume familiarity with the concepts and terminology + of the DNS, whose requirements are given in Section 6.1. + + RFC-822 specifies the Internet standard format for electronic mail + messages. RFC-822 supercedes an older standard, RFC-733, that may + still be in use in a few places, although it is obsolete. The two + formats are sometimes referred to simply by number ("822" and + "733"). + + RFC-822 is used in some non-Internet mail environments with + different mail transfer protocols than SMTP, and SMTP has also + been adapted for use in some non-Internet environments. Note that + this document presents the rules for the use of SMTP and RFC-822 + for the Internet environment only; other mail environments that + use these protocols may be expected to have their own rules. + + 5.2 PROTOCOL WALK-THROUGH + + This section covers both RFC-821 and RFC-822. + + The SMTP specification in RFC-821 is clear and contains numerous + examples, so implementors should not find it difficult to + understand. This section simply updates or annotates portions of + RFC-821 to conform with current usage. + + RFC-822 is a long and dense document, defining a rich syntax. + Unfortunately, incomplete or defective implementations of RFC-822 + are common. In fact, nearly all of the many formats of RFC-822 + are actually used, so an implementation generally needs to + recognize and correctly interpret all of the RFC-822 syntax. + + 5.2.1 The SMTP Model: RFC-821 Section 2 + + DISCUSSION: + Mail is sent by a series of request/response transactions + between a client, the "sender-SMTP," and a server, the + + + +Internet Engineering Task Force [Page 48] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + "receiver-SMTP". These transactions pass (1) the message + proper, which is composed of header and body, and (2) SMTP + source and destination addresses, referred to as the + "envelope". + + The SMTP programs are analogous to Message Transfer Agents + (MTAs) of X.400. There will be another level of protocol + software, closer to the end user, that is responsible for + composing and analyzing RFC-822 message headers; this + component is known as the "User Agent" in X.400, and we + use that term in this document. There is a clear logical + distinction between the User Agent and the SMTP + implementation, since they operate on different levels of + protocol. Note, however, that this distinction is may not + be exactly reflected the structure of typical + implementations of Internet mail. Often there is a + program known as the "mailer" that implements SMTP and + also some of the User Agent functions; the rest of the + User Agent functions are included in a user interface used + for entering and reading mail. + + The SMTP envelope is constructed at the originating site, + typically by the User Agent when the message is first + queued for the Sender-SMTP program. The envelope + addresses may be derived from information in the message + header, supplied by the user interface (e.g., to implement + a bcc: request), or derived from local configuration + information (e.g., expansion of a mailing list). The SMTP + envelope cannot in general be re-derived from the header + at a later stage in message delivery, so the envelope is + transmitted separately from the message itself using the + MAIL and RCPT commands of SMTP. + + The text of RFC-821 suggests that mail is to be delivered + to an individual user at a host. With the advent of the + domain system and of mail routing using mail-exchange (MX) + resource records, implementors should now think of + delivering mail to a user at a domain, which may or may + not be a particular host. This DOES NOT change the fact + that SMTP is a host-to-host mail exchange protocol. + + 5.2.2 Canonicalization: RFC-821 Section 3.1 + + The domain names that a Sender-SMTP sends in MAIL and RCPT + commands MUST have been "canonicalized," i.e., they must be + fully-qualified principal names or domain literals, not + nicknames or domain abbreviations. A canonicalized name either + identifies a host directly or is an MX name; it cannot be a + + + +Internet Engineering Task Force [Page 49] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + CNAME. + + 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3 + + A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN + (this requirement overrides RFC-821). However, there MAY be + configuration information to disable VRFY and EXPN in a + particular installation; this might even allow EXPN to be + disabled for selected lists. + + A new reply code is defined for the VRFY command: + + 252 Cannot VRFY user (e.g., info is not local), but will + take message for this user and attempt delivery. + + DISCUSSION: + SMTP users and administrators make regular use of these + commands for diagnosing mail delivery problems. With the + increasing use of multi-level mailing list expansion + (sometimes more than two levels), EXPN has been + increasingly important for diagnosing inadvertent mail + loops. On the other hand, some feel that EXPN represents + a significant privacy, and perhaps even a security, + exposure. + + 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4 + + An SMTP MAY implement the commands to send a message to a + user's terminal: SEND, SOML, and SAML. + + DISCUSSION: + It has been suggested that the use of mail relaying + through an MX record is inconsistent with the intent of + SEND to deliver a message immediately and directly to a + user's terminal. However, an SMTP receiver that is unable + to write directly to the user terminal can return a "251 + User Not Local" reply to the RCPT following a SEND, to + inform the originator of possibly deferred delivery. + + 5.2.5 HELO Command: RFC-821 Section 3.5 + + The sender-SMTP MUST ensure that the parameter in a + HELO command is a valid principal host domain name for the + client host. As a result, the receiver-SMTP will not have to + perform MX resolution on this name in order to validate the + HELO parameter. + + The HELO receiver MAY verify that the HELO parameter really + + + +Internet Engineering Task Force [Page 50] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + corresponds to the IP address of the sender. However, the + receiver MUST NOT refuse to accept a message, even if the + sender's HELO command fails verification. + + DISCUSSION: + Verifying the HELO parameter requires a domain name lookup + and may therefore take considerable time. An alternative + tool for tracking bogus mail sources is suggested below + (see "DATA Command"). + + Note also that the HELO argument is still required to have + valid syntax, since it will appear in a Received: + line; otherwise, a 501 error is to be sent. + + IMPLEMENTATION: + When HELO parameter validation fails, a suggested + procedure is to insert a note about the unknown + authenticity of the sender into the message header (e.g., + in the "Received:" line). + + 5.2.6 Mail Relay: RFC-821 Section 3.6 + + We distinguish three types of mail (store-and-) forwarding: + + (1) A simple forwarder or "mail exchanger" forwards a message + using private knowledge about the recipient; see section + 3.2 of RFC-821. + + (2) An SMTP mail "relay" forwards a message within an SMTP + mail environment as the result of an explicit source route + (as defined in section 3.6 of RFC-821). The SMTP relay + function uses the "@...:" form of source route from RFC- + 822 (see Section 5.2.19 below). + + (3) A mail "gateway" passes a message between different + environments. The rules for mail gateways are discussed + below in Section 5.3.7. + + An Internet host that is forwarding a message but is not a + gateway to a different mail environment (i.e., it falls under + (1) or (2)) SHOULD NOT alter any existing header fields, + although the host will add an appropriate Received: line as + required in Section 5.2.8. + + A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an + explicit source route using the "@...:" address form. Thus, + the relay function defined in section 3.6 of RFC-821 should + not be used. + + + +Internet Engineering Task Force [Page 51] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + The intent is to discourage all source routing and to + abolish explicit source routing for mail delivery within + the Internet environment. Source-routing is unnecessary; + the simple target address "user@domain" should always + suffice. This is the result of an explicit architectural + decision to use universal naming rather than source + routing for mail. Thus, SMTP provides end-to-end + connectivity, and the DNS provides globally-unique, + location-independent names. MX records handle the major + case where source routing might otherwise be needed. + + A receiver-SMTP MUST accept the explicit source route syntax in + the envelope, but it MAY implement the relay function as + defined in section 3.6 of RFC-821. If it does not implement + the relay function, it SHOULD attempt to deliver the message + directly to the host to the right of the right-most "@" sign. + + DISCUSSION: + For example, suppose a host that does not implement the + relay function receives a message with the SMTP command: + "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and + GAMMA represent domain names. Rather than immediately + refusing the message with a 550 error reply as suggested + on page 20 of RFC-821, the host should try to forward the + message to GAMMA directly, using: "RCPT TO:". + Since this host does not support relaying, it is not + required to update the reverse path. + + Some have suggested that source routing may be needed + occasionally for manually routing mail around failures; + however, the reality and importance of this need is + controversial. The use of explicit SMTP mail relaying for + this purpose is discouraged, and in fact it may not be + successful, as many host systems do not support it. Some + have used the "%-hack" (see Section 5.2.16) for this + purpose. + + 5.2.7 RCPT Command: RFC-821 Section 4.1.1 + + A host that supports a receiver-SMTP MUST support the reserved + mailbox "Postmaster". + + The receiver-SMTP MAY verify RCPT parameters as they arrive; + however, RCPT responses MUST NOT be delayed beyond a reasonable + time (see Section 5.3.2). + + Therefore, a "250 OK" response to a RCPT does not necessarily + + + +Internet Engineering Task Force [Page 52] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + imply that the delivery address(es) are valid. Errors found + after message acceptance will be reported by mailing a + notification message to an appropriate address (see Section + 5.3.3). + + DISCUSSION: + The set of conditions under which a RCPT parameter can be + validated immediately is an engineering design choice. + Reporting destination mailbox errors to the Sender-SMTP + before mail is transferred is generally desirable to save + time and network bandwidth, but this advantage is lost if + RCPT verification is lengthy. + + For example, the receiver can verify immediately any + simple local reference, such as a single locally- + registered mailbox. On the other hand, the "reasonable + time" limitation generally implies deferring verification + of a mailing list until after the message has been + transferred and accepted, since verifying a large mailing + list can take a very long time. An implementation might + or might not choose to defer validation of addresses that + are non-local and therefore require a DNS lookup. If a + DNS lookup is performed but a soft domain system error + (e.g., timeout) occurs, validity must be assumed. + + 5.2.8 DATA Command: RFC-821 Section 4.1.1 + + Every receiver-SMTP (not just one that "accepts a message for + relaying or for final delivery" [SMTP:1]) MUST insert a + "Received:" line at the beginning of a message. In this line, + called a "time stamp line" in RFC-821: + + * The FROM field SHOULD contain both (1) the name of the + source host as presented in the HELO command and (2) a + domain literal containing the IP address of the source, + determined from the TCP connection. + + * The ID field MAY contain an "@" as suggested in RFC-822, + but this is not required. + + * The FOR field MAY contain a list of entries when + multiple RCPT commands have been given. + + + An Internet mail program MUST NOT change a Received: line that + was previously added to the message header. + + + + + +Internet Engineering Task Force [Page 53] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + Including both the source host and the IP source address + in the Received: line may provide enough information for + tracking illicit mail sources and eliminate a need to + explicitly verify the HELO parameter. + + Received: lines are primarily intended for humans tracing + mail routes, primarily of diagnosis of faults. See also + the discussion under 5.3.7. + + When the receiver-SMTP makes "final delivery" of a message, + then it MUST pass the MAIL FROM: address from the SMTP envelope + with the message, for use if an error notification message must + be sent later (see Section 5.3.3). There is an analogous + requirement when gatewaying from the Internet into a different + mail environment; see Section 5.3.7. + + DISCUSSION: + Note that the final reply to the DATA command depends only + upon the successful transfer and storage of the message. + Any problem with the destination address(es) must either + (1) have been reported in an SMTP error reply to the RCPT + command(s), or (2) be reported in a later error message + mailed to the originator. + + IMPLEMENTATION: + The MAIL FROM: information may be passed as a parameter or + in a Return-Path: line inserted at the beginning of the + message. + + 5.2.9 Command Syntax: RFC-821 Section 4.1.2 + + The syntax shown in RFC-821 for the MAIL FROM: command omits + the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page + 15). An empty reverse path MUST be supported. + + 5.2.10 SMTP Replies: RFC-821 Section 4.2 + + A receiver-SMTP SHOULD send only the reply codes listed in + section 4.2.2 of RFC-821 or in this document. A receiver-SMTP + SHOULD use the text shown in examples in RFC-821 whenever + appropriate. + + A sender-SMTP MUST determine its actions only by the reply + code, not by the text (except for 251 and 551 replies); any + text, including no text at all, must be acceptable. The space + (blank) following the reply code is considered part of the + text. Whenever possible, a sender-SMTP SHOULD test only the + + + +Internet Engineering Task Force [Page 54] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + first digit of the reply code, as specified in Appendix E of + RFC-821. + + DISCUSSION: + Interoperability problems have arisen with SMTP systems + using reply codes that are not listed explicitly in RFC- + 821 Section 4.3 but are legal according to the theory of + reply codes explained in Appendix E. + + 5.2.11 Transparency: RFC-821 Section 4.5.2 + + Implementors MUST be sure that their mail systems always add + and delete periods to ensure message transparency. + + 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 + + RFC-974 [SMTP:3] recommended that the domain system be queried + for WKS ("Well-Known Service") records, to verify that each + proposed mail target does support SMTP. Later experience has + shown that WKS is not widely supported, so the WKS step in MX + processing SHOULD NOT be used. + + The following are notes on RFC-822, organized by section of that + document. + + 5.2.13 RFC-822 Message Specification: RFC-822 Section 4 + + The syntax shown for the Return-path line omits the possibility + of a null return path, which is used to prevent looping of + error notifications (see Section 5.3.3). The complete syntax + is: + + return = "Return-path" ":" route-addr + / "Return-path" ":" "<" ">" + + The set of optional header fields is hereby expanded to include + the Content-Type field defined in RFC-1049 [SMTP:7]. This + field "allows mail reading systems to automatically identify + the type of a structured message body and to process it for + display accordingly". [SMTP:7] A User Agent MAY support this + field. + + 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 + + The syntax for the date is hereby changed to: + + date = 1*2DIGIT month 2*4DIGIT + + + + +Internet Engineering Task Force [Page 55] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + All mail software SHOULD use 4-digit years in dates, to ease + the transition to the next century. + + There is a strong trend towards the use of numeric timezone + indicators, and implementations SHOULD use numeric timezones + instead of timezone names. However, all implementations MUST + accept either notation. If timezone names are used, they MUST + be exactly as defined in RFC-822. + + The military time zones are specified incorrectly in RFC-822: + they count the wrong way from UT (the signs are reversed). As + a result, military time zones in RFC-822 headers carry no + information. + + Finally, note that there is a typo in the definition of "zone" + in the syntax summary of appendix D; the correct definition + occurs in Section 3 of RFC-822. + + 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1 + + The syntactic definition of "mailbox" in RFC-822 is hereby + changed to: + + mailbox = addr-spec ; simple address + / [phrase] route-addr ; name & addr-spec + + That is, the phrase preceding a route address is now OPTIONAL. + This change makes the following header field legal, for + example: + + From: + + 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2 + + The basic mailbox address specification has the form: "local- + part@domain". Here "local-part", sometimes called the "left- + hand side" of the address, is domain-dependent. + + A host that is forwarding the message but is not the + destination host implied by the right-hand side "domain" MUST + NOT interpret or modify the "local-part" of the address. + + When mail is to be gatewayed from the Internet mail environment + into a foreign mail environment (see Section 5.3.7), routing + information for that foreign environment MAY be embedded within + the "local-part" of the address. The gateway will then + interpret this local part appropriately for the foreign mail + environment. + + + +Internet Engineering Task Force [Page 56] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + Although source routes are discouraged within the Internet + (see Section 5.2.6), there are non-Internet mail + environments whose delivery mechanisms do depend upon + source routes. Source routes for extra-Internet + environments can generally be buried in the "local-part" + of the address (see Section 5.2.16) while mail traverses + the Internet. When the mail reaches the appropriate + Internet mail gateway, the gateway will interpret the + local-part and build the necessary address or route for + the target mail environment. + + For example, an Internet host might send mail to: + "a!b!c!user@gateway-domain". The complex local part + "a!b!c!user" would be uninterpreted within the Internet + domain, but could be parsed and understood by the + specified mail gateway. + + An embedded source route is sometimes encoded in the + "local-part" using "%" as a right-binding routing + operator. For example, in: + + user%domain%relay3%relay2@relay1 + + the "%" convention implies that the mail is to be routed + from "relay1" through "relay2", "relay3", and finally to + "user" at "domain". This is commonly known as the "%- + hack". It is suggested that "%" have lower precedence + than any other routing operator (e.g., "!") hidden in the + local-part; for example, "a!b%c" would be interpreted as + "(a!b)%c". + + Only the target host (in this case, "relay1") is permitted + to analyze the local-part "user%domain%relay3%relay2". + + 5.2.17 Domain Literals: RFC-822 Section 6.2.3 + + A mailer MUST be able to accept and parse an Internet domain + literal whose content ("dtext"; see RFC-822) is a dotted- + decimal host address. This satisfies the requirement of + Section 2.1 for the case of mail. + + An SMTP MUST accept and recognize a domain literal for any of + its own IP addresses. + + + + + + + +Internet Engineering Task Force [Page 57] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 + + Errors in formatting or parsing 822 addresses are unfortunately + common. This section mentions only the most common errors. A + User Agent MUST accept all valid RFC-822 address formats, and + MUST NOT generate illegal address syntax. + + o A common error is to leave out the semicolon after a group + identifier. + + o Some systems fail to fully-qualify domain names in + messages they generate. The right-hand side of an "@" + sign in a header address field MUST be a fully-qualified + domain name. + + For example, some systems fail to fully-qualify the From: + address; this prevents a "reply" command in the user + interface from automatically constructing a return + address. + + DISCUSSION: + Although RFC-822 allows the local use of abbreviated + domain names within a domain, the application of + RFC-822 in Internet mail does not allow this. The + intent is that an Internet host must not send an SMTP + message header containing an abbreviated domain name + in an address field. This allows the address fields + of the header to be passed without alteration across + the Internet, as required in Section 5.2.6. + + o Some systems mis-parse multiple-hop explicit source routes + such as: + + @relay1,@relay2,@relay3:user@domain. + + + o Some systems over-qualify domain names by adding a + trailing dot to some or all domain names in addresses or + message-ids. This violates RFC-822 syntax. + + + 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7 + + Internet host software SHOULD NOT create an RFC-822 header + containing an address with an explicit source route, but MUST + accept such headers for compatibility with earlier systems. + + DISCUSSION: + + + +Internet Engineering Task Force [Page 58] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + In an understatement, RFC-822 says "The use of explicit + source routing is discouraged". Many hosts implemented + RFC-822 source routes incorrectly, so the syntax cannot be + used unambiguously in practice. Many users feel the + syntax is ugly. Explicit source routes are not needed in + the mail envelope for delivery; see Section 5.2.6. For + all these reasons, explicit source routes using the RFC- + 822 notations are not to be used in Internet mail headers. + + As stated in Section 5.2.16, it is necessary to allow an + explicit source route to be buried in the local-part of an + address, e.g., using the "%-hack", in order to allow mail + to be gatewayed into another environment in which explicit + source routing is necessary. The vigilant will observe + that there is no way for a User Agent to detect and + prevent the use of such implicit source routing when the + destination is within the Internet. We can only + discourage source routing of any kind within the Internet, + as unnecessary and undesirable. + + 5.3 SPECIFIC ISSUES + + 5.3.1 SMTP Queueing Strategies + + The common structure of a host SMTP implementation includes + user mailboxes, one or more areas for queueing messages in + transit, and one or more daemon processes for sending and + receiving mail. The exact structure will vary depending on the + needs of the users on the host and the number and size of + mailing lists supported by the host. We describe several + optimizations that have proved helpful, particularly for + mailers supporting high traffic levels. + + Any queueing strategy MUST include: + + o Timeouts on all activities. See Section 5.3.2. + + o Never sending error messages in response to error + messages. + + + 5.3.1.1 Sending Strategy + + The general model of a sender-SMTP is one or more processes + that periodically attempt to transmit outgoing mail. In a + typical system, the program that composes a message has some + method for requesting immediate attention for a new piece of + outgoing mail, while mail that cannot be transmitted + + + +Internet Engineering Task Force [Page 59] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + immediately MUST be queued and periodically retried by the + sender. A mail queue entry will include not only the + message itself but also the envelope information. + + The sender MUST delay retrying a particular destination + after one attempt has failed. In general, the retry + interval SHOULD be at least 30 minutes; however, more + sophisticated and variable strategies will be beneficial + when the sender-SMTP can determine the reason for non- + delivery. + + Retries continue until the message is transmitted or the + sender gives up; the give-up time generally needs to be at + least 4-5 days. The parameters to the retry algorithm MUST + be configurable. + + A sender SHOULD keep a list of hosts it cannot reach and + corresponding timeouts, rather than just retrying queued + mail items. + + DISCUSSION: + Experience suggests that failures are typically + transient (the target system has crashed), favoring a + policy of two connection attempts in the first hour the + message is in the queue, and then backing off to once + every two or three hours. + + The sender-SMTP can shorten the queueing delay by + cooperation with the receiver-SMTP. In particular, if + mail is received from a particular address, it is good + evidence that any mail queued for that host can now be + sent. + + The strategy may be further modified as a result of + multiple addresses per host (see Section 5.3.4), to + optimize delivery time vs. resource usage. + + A sender-SMTP may have a large queue of messages for + each unavailable destination host, and if it retried + all these messages in every retry cycle, there would be + excessive Internet overhead and the daemon would be + blocked for a long period. Note that an SMTP can + generally determine that a delivery attempt has failed + only after a timeout of a minute or more; a one minute + timeout per connection will result in a very large + delay if it is repeated for dozens or even hundreds of + queued messages. + + + + +Internet Engineering Task Force [Page 60] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + When the same message is to be delivered to several users on + the same host, only one copy of the message SHOULD be + transmitted. That is, the sender-SMTP should use the + command sequence: RCPT, RCPT,... RCPT, DATA instead of the + sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA. + Implementation of this efficiency feature is strongly urged. + + Similarly, the sender-SMTP MAY support multiple concurrent + outgoing mail transactions to achieve timely delivery. + However, some limit SHOULD be imposed to protect the host + from devoting all its resources to mail. + + The use of the different addresses of a multihomed host is + discussed below. + + 5.3.1.2 Receiving strategy + + The receiver-SMTP SHOULD attempt to keep a pending listen on + the SMTP port at all times. This will require the support + of multiple incoming TCP connections for SMTP. Some limit + MAY be imposed. + + IMPLEMENTATION: + When the receiver-SMTP receives mail from a particular + host address, it could notify the sender-SMTP to retry + any mail pending for that host address. + + 5.3.2 Timeouts in SMTP + + There are two approaches to timeouts in the sender-SMTP: (a) + limit the time for each SMTP command separately, or (b) limit + the time for the entire SMTP dialogue for a single mail + message. A sender-SMTP SHOULD use option (a), per-command + timeouts. Timeouts SHOULD be easily reconfigurable, preferably + without recompiling the SMTP code. + + DISCUSSION: + Timeouts are an essential feature of an SMTP + implementation. If the timeouts are too long (or worse, + there are no timeouts), Internet communication failures or + software bugs in receiver-SMTP programs can tie up SMTP + processes indefinitely. If the timeouts are too short, + resources will be wasted with attempts that time out part + way through message delivery. + + If option (b) is used, the timeout has to be very large, + e.g., an hour, to allow time to expand very large mailing + lists. The timeout may also need to increase linearly + + + +Internet Engineering Task Force [Page 61] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + with the size of the message, to account for the time to + transmit a very large message. A large fixed timeout + leads to two problems: a failure can still tie up the + sender for a very long time, and very large messages may + still spuriously time out (which is a wasteful failure!). + + Using the recommended option (a), a timer is set for each + SMTP command and for each buffer of the data transfer. + The latter means that the overall timeout is inherently + proportional to the size of the message. + + Based on extensive experience with busy mail-relay hosts, the + minimum per-command timeout values SHOULD be as follows: + + o Initial 220 Message: 5 minutes + + A Sender-SMTP process needs to distinguish between a + failed TCP connection and a delay in receiving the initial + 220 greeting message. Many receiver-SMTPs will accept a + TCP connection but delay delivery of the 220 message until + their system load will permit more mail to be processed. + + o MAIL Command: 5 minutes + + + o RCPT Command: 5 minutes + + A longer timeout would be required if processing of + mailing lists and aliases were not deferred until after + the message was accepted. + + o DATA Initiation: 2 minutes + + This is while awaiting the "354 Start Input" reply to a + DATA command. + + o Data Block: 3 minutes + + This is while awaiting the completion of each TCP SEND + call transmitting a chunk of data. + + o DATA Termination: 10 minutes. + + This is while awaiting the "250 OK" reply. When the + receiver gets the final period terminating the message + data, it typically performs processing to deliver the + message to a user mailbox. A spurious timeout at this + point would be very wasteful, since the message has been + + + +Internet Engineering Task Force [Page 62] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + successfully sent. + + A receiver-SMTP SHOULD have a timeout of at least 5 minutes + while it is awaiting the next command from the sender. + + 5.3.3 Reliable Mail Receipt + + When the receiver-SMTP accepts a piece of mail (by sending a + "250 OK" message in response to DATA), it is accepting + responsibility for delivering or relaying the message. It must + take this responsibility seriously, i.e., it MUST NOT lose the + message for frivolous reasons, e.g., because the host later + crashes or because of a predictable resource shortage. + + If there is a delivery failure after acceptance of a message, + the receiver-SMTP MUST formulate and mail a notification + message. This notification MUST be sent using a null ("<>") + reverse path in the envelope; see Section 3.6 of RFC-821. The + recipient of this notification SHOULD be the address from the + envelope return path (or the Return-Path: line). However, if + this address is null ("<>"), the receiver-SMTP MUST NOT send a + notification. If the address is an explicit source route, it + SHOULD be stripped down to its final hop. + + DISCUSSION: + For example, suppose that an error notification must be + sent for a message that arrived with: + "MAIL FROM:<@a,@b:user@d>". The notification message + should be sent to: "RCPT TO:". + + Some delivery failures after the message is accepted by + SMTP will be unavoidable. For example, it may be + impossible for the receiver-SMTP to validate all the + delivery addresses in RCPT command(s) due to a "soft" + domain system error or because the target is a mailing + list (see earlier discussion of RCPT). + + To avoid receiving duplicate messages as the result of + timeouts, a receiver-SMTP MUST seek to minimize the time + required to respond to the final "." that ends a message + transfer. See RFC-1047 [SMTP:4] for a discussion of this + problem. + + 5.3.4 Reliable Mail Transmission + + To transmit a message, a sender-SMTP determines the IP address + of the target host from the destination address in the + envelope. Specifically, it maps the string to the right of the + + + +Internet Engineering Task Force [Page 63] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + "@" sign into an IP address. This mapping or the transfer + itself may fail with a soft error, in which case the sender- + SMTP will requeue the outgoing mail for a later retry, as + required in Section 5.3.1.1. + + When it succeeds, the mapping can result in a list of + alternative delivery addresses rather than a single address, + because of (a) multiple MX records, (b) multihoming, or both. + To provide reliable mail transmission, the sender-SMTP MUST be + able to try (and retry) each of the addresses in this list in + order, until a delivery attempt succeeds. However, there MAY + also be a configurable limit on the number of alternate + addresses that can be tried. In any case, a host SHOULD try at + least two addresses. + + The following information is to be used to rank the host + addresses: + + (1) Multiple MX Records -- these contain a preference + indication that should be used in sorting. If there are + multiple destinations with the same preference and there + is no clear reason to favor one (e.g., by address + preference), then the sender-SMTP SHOULD pick one at + random to spread the load across multiple mail exchanges + for a specific organization; note that this is a + refinement of the procedure in [DNS:3]. + + (2) Multihomed host -- The destination host (perhaps taken + from the preferred MX record) may be multihomed, in which + case the domain name resolver will return a list of + alternative IP addresses. It is the responsibility of the + domain name resolver interface (see Section 6.1.3.4 below) + to have ordered this list by decreasing preference, and + SMTP MUST try them in the order presented. + + DISCUSSION: + Although the capability to try multiple alternative + addresses is required, there may be circumstances where + specific installations want to limit or disable the use of + alternative addresses. The question of whether a sender + should attempt retries using the different addresses of a + multihomed host has been controversial. The main argument + for using the multiple addresses is that it maximizes the + probability of timely delivery, and indeed sometimes the + probability of any delivery; the counter argument is that + it may result in unnecessary resource use. + + Note that resource use is also strongly determined by the + + + +Internet Engineering Task Force [Page 64] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + sending strategy discussed in Section 5.3.1. + + 5.3.5 Domain Name Support + + SMTP implementations MUST use the mechanism defined in Section + 6.1 for mapping between domain names and IP addresses. This + means that every Internet SMTP MUST include support for the + Internet DNS. + + In particular, a sender-SMTP MUST support the MX record scheme + [SMTP:3]. See also Section 7.4 of [DNS:2] for information on + domain name support for SMTP. + + 5.3.6 Mailing Lists and Aliases + + An SMTP-capable host SHOULD support both the alias and the list + form of address expansion for multiple delivery. When a + message is delivered or forwarded to each address of an + expanded list form, the return address in the envelope + ("MAIL FROM:") MUST be changed to be the address of a person + who administers the list, but the message header MUST be left + unchanged; in particular, the "From" field of the message is + unaffected. + + DISCUSSION: + An important mail facility is a mechanism for multi- + destination delivery of a single message, by transforming + or "expanding" a pseudo-mailbox address into a list of + destination mailbox addresses. When a message is sent to + such a pseudo-mailbox (sometimes called an "exploder"), + copies are forwarded or redistributed to each mailbox in + the expanded list. We classify such a pseudo-mailbox as + an "alias" or a "list", depending upon the expansion + rules: + + (a) Alias + + To expand an alias, the recipient mailer simply + replaces the pseudo-mailbox address in the envelope + with each of the expanded addresses in turn; the rest + of the envelope and the message body are left + unchanged. The message is then delivered or + forwarded to each expanded address. + + (b) List + + A mailing list may be said to operate by + "redistribution" rather than by "forwarding". To + + + +Internet Engineering Task Force [Page 65] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + expand a list, the recipient mailer replaces the + pseudo-mailbox address in the envelope with each of + the expanded addresses in turn. The return address in + the envelope is changed so that all error messages + generated by the final deliveries will be returned to + a list administrator, not to the message originator, + who generally has no control over the contents of the + list and will typically find error messages annoying. + + + 5.3.7 Mail Gatewaying + + Gatewaying mail between different mail environments, i.e., + different mail formats and protocols, is complex and does not + easily yield to standardization. See for example [SMTP:5a], + [SMTP:5b]. However, some general requirements may be given for + a gateway between the Internet and another mail environment. + + (A) Header fields MAY be rewritten when necessary as messages + are gatewayed across mail environment boundaries. + + DISCUSSION: + This may involve interpreting the local-part of the + destination address, as suggested in Section 5.2.16. + + The other mail systems gatewayed to the Internet + generally use a subset of RFC-822 headers, but some + of them do not have an equivalent to the SMTP + envelope. Therefore, when a message leaves the + Internet environment, it may be necessary to fold the + SMTP envelope information into the message header. A + possible solution would be to create new header + fields to carry the envelope information (e.g., "X- + SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would + require changes in mail programs in the foreign + environment. + + (B) When forwarding a message into or out of the Internet + environment, a gateway MUST prepend a Received: line, but + it MUST NOT alter in any way a Received: line that is + already in the header. + + DISCUSSION: + This requirement is a subset of the general + "Received:" line requirement of Section 5.2.8; it is + restated here for emphasis. + + Received: fields of messages originating from other + + + +Internet Engineering Task Force [Page 66] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + environments may not conform exactly to RFC822. + However, the most important use of Received: lines is + for debugging mail faults, and this debugging can be + severely hampered by well-meaning gateways that try + to "fix" a Received: line. + + The gateway is strongly encouraged to indicate the + environment and protocol in the "via" clauses of + Received field(s) that it supplies. + + (C) From the Internet side, the gateway SHOULD accept all + valid address formats in SMTP commands and in RFC-822 + headers, and all valid RFC-822 messages. Although a + gateway must accept an RFC-822 explicit source route + ("@...:" format) in either the RFC-822 header or in the + envelope, it MAY or may not act on the source route; see + Sections 5.2.6 and 5.2.19. + + DISCUSSION: + It is often tempting to restrict the range of + addresses accepted at the mail gateway to simplify + the translation into addresses for the remote + environment. This practice is based on the + assumption that mail users have control over the + addresses their mailers send to the mail gateway. In + practice, however, users have little control over the + addresses that are finally sent; their mailers are + free to change addresses into any legal RFC-822 + format. + + (D) The gateway MUST ensure that all header fields of a + message that it forwards into the Internet meet the + requirements for Internet mail. In particular, all + addresses in "From:", "To:", "Cc:", etc., fields must be + transformed (if necessary) to satisfy RFC-822 syntax, and + they must be effective and useful for sending replies. + + + (E) The translation algorithm used to convert mail from the + Internet protocols to another environment's protocol + SHOULD try to ensure that error messages from the foreign + mail environment are delivered to the return path from the + SMTP envelope, not to the sender listed in the "From:" + field of the RFC-822 message. + + DISCUSSION: + Internet mail lists usually place the address of the + mail list maintainer in the envelope but leave the + + + +Internet Engineering Task Force [Page 67] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + original message header intact (with the "From:" + field containing the original sender). This yields + the behavior the average recipient expects: a reply + to the header gets sent to the original sender, not + to a mail list maintainer; however, errors get sent + to the maintainer (who can fix the problem) and not + the sender (who probably cannot). + + (F) Similarly, when forwarding a message from another + environment into the Internet, the gateway SHOULD set the + envelope return path in accordance with an error message + return address, if any, supplied by the foreign + environment. + + + 5.3.8 Maximum Message Size + + Mailer software MUST be able to send and receive messages of at + least 64K bytes in length (including header), and a much larger + maximum size is highly desirable. + + DISCUSSION: + Although SMTP does not define the maximum size of a + message, many systems impose implementation limits. + + The current de facto minimum limit in the Internet is 64K + bytes. However, electronic mail is used for a variety of + purposes that create much larger messages. For example, + mail is often used instead of FTP for transmitting ASCII + files, and in particular to transmit entire documents. As + a result, messages can be 1 megabyte or even larger. We + note that the present document together with its lower- + layer companion contains 0.5 megabytes. + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 68] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + 5.4 SMTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +RECEIVER-SMTP: | | | | | | | + Implement VRFY |5.2.3 |x| | | | | + Implement EXPN |5.2.3 | |x| | | | + EXPN, VRFY configurable |5.2.3 | | |x| | | + Implement SEND, SOML, SAML |5.2.4 | | |x| | | + Verify HELO parameter |5.2.5 | | |x| | | + Refuse message with bad HELO |5.2.5 | | | | |x| + Accept explicit src-route syntax in env. |5.2.6 |x| | | | | + Support "postmaster" |5.2.7 |x| | | | | + Process RCPT when received (except lists) |5.2.7 | | |x| | | + Long delay of RCPT responses |5.2.7 | | | | |x| + | | | | | | | + Add Received: line |5.2.8 |x| | | | | + Received: line include domain literal |5.2.8 | |x| | | | + Change previous Received: line |5.2.8 | | | | |x| + Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | | + Support empty reverse path |5.2.9 |x| | | | | + Send only official reply codes |5.2.10 | |x| | | | + Send text from RFC-821 when appropriate |5.2.10 | |x| | | | + Delete "." for transparency |5.2.11 |x| | | | | + Accept and recognize self domain literal(s) |5.2.17 |x| | | | | + | | | | | | | + Error message about error message |5.3.1 | | | | |x| + Keep pending listen on SMTP port |5.3.1.2 | |x| | | | + Provide limit on recv concurrency |5.3.1.2 | | |x| | | + Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | | + Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x| + Send error notification msg after accept |5.3.3 |x| | | | | + Send using null return path |5.3.3 |x| | | | | + Send to envelope return path |5.3.3 | |x| | | | + Send to null address |5.3.3 | | | | |x| + Strip off explicit src route |5.3.3 | |x| | | | + Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | | +-----------------------------------------------|----------|-|-|-|-|-|-- + + + +Internet Engineering Task Force [Page 69] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + | | | | | | | +SENDER-SMTP: | | | | | | | + Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | | + Implement SEND, SOML, SAML |5.2.4 | | |x| | | + Send valid principal host name in HELO |5.2.5 |x| | | | | + Send explicit source route in RCPT TO: |5.2.6 | | | |x| | + Use only reply code to determine action |5.2.10 |x| | | | | + Use only high digit of reply code when poss. |5.2.10 | |x| | | | + Add "." for transparency |5.2.11 |x| | | | | + | | | | | | | + Retry messages after soft failure |5.3.1.1 |x| | | | | + Delay before retry |5.3.1.1 |x| | | | | + Configurable retry parameters |5.3.1.1 |x| | | | | + Retry once per each queued dest host |5.3.1.1 | |x| | | | + Multiple RCPT's for same DATA |5.3.1.1 | |x| | | | + Support multiple concurrent transactions |5.3.1.1 | | |x| | | + Provide limit on concurrency |5.3.1.1 | |x| | | | + | | | | | | | + Timeouts on all activities |5.3.1 |x| | | | | + Per-command timeouts |5.3.2 | |x| | | | + Timeouts easily reconfigurable |5.3.2 | |x| | | | + Recommended times |5.3.2 | |x| | | | + Try alternate addr's in order |5.3.4 |x| | | | | + Configurable limit on alternate tries |5.3.4 | | |x| | | + Try at least two alternates |5.3.4 | |x| | | | + Load-split across equal MX alternates |5.3.4 | |x| | | | + Use the Domain Name System |5.3.5 |x| | | | | + Support MX records |5.3.5 |x| | | | | + Use WKS records in MX processing |5.2.12 | | | |x| | +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +MAIL FORWARDING: | | | | | | | + Alter existing header field(s) |5.2.6 | | | |x| | + Implement relay function: 821/section 3.6 |5.2.6 | | |x| | | + If not, deliver to RHS domain |5.2.6 | |x| | | | + Interpret 'local-part' of addr |5.2.16 | | | | |x| + | | | | | | | +MAILING LISTS AND ALIASES | | | | | | | + Support both |5.3.6 | |x| | | | + Report mail list error to local admin. |5.3.6 |x| | | | | + | | | | | | | +MAIL GATEWAYS: | | | | | | | + Embed foreign mail route in local-part |5.2.16 | | |x| | | + Rewrite header fields when necessary |5.3.7 | | |x| | | + Prepend Received: line |5.3.7 |x| | | | | + Change existing Received: line |5.3.7 | | | | |x| + Accept full RFC-822 on Internet side |5.3.7 | |x| | | | + Act on RFC-822 explicit source route |5.3.7 | | |x| | | + + + +Internet Engineering Task Force [Page 70] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + Send only valid RFC-822 on Internet side |5.3.7 |x| | | | | + Deliver error msgs to envelope addr |5.3.7 | |x| | | | + Set env return path from err return addr |5.3.7 | |x| | | | + | | | | | | | +USER AGENT -- RFC-822 | | | | | | | + Allow user to enter address |5.2.6 | | | |x| | + Support RFC-1049 Content Type field |5.2.13 | | |x| | | + Use 4-digit years |5.2.14 | |x| | | | + Generate numeric timezones |5.2.14 | |x| | | | + Accept all timezones |5.2.14 |x| | | | | + Use non-num timezones from RFC-822 |5.2.14 |x| | | | | + Omit phrase before route-addr |5.2.15 | | |x| | | + Accept and parse dot.dec. domain literals |5.2.17 |x| | | | | + Accept all RFC-822 address formats |5.2.18 |x| | | | | + Generate invalid RFC-822 address format |5.2.18 | | | | |x| + Fully-qualified domain names in header |5.2.18 |x| | | | | + Create explicit src route in header |5.2.19 | | | |x| | + Accept explicit src route in header |5.2.19 |x| | | | | + | | | | | | | +Send/recv at least 64KB messages |5.3.8 |x| | | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 71] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + +6. SUPPORT SERVICES + + 6.1 DOMAIN NAME TRANSLATION + + 6.1.1 INTRODUCTION + + Every host MUST implement a resolver for the Domain Name System + (DNS), and it MUST implement a mechanism using this DNS + resolver to convert host names to IP addresses and vice-versa + [DNS:1, DNS:2]. + + In addition to the DNS, a host MAY also implement a host name + translation mechanism that searches a local Internet host + table. See Section 6.1.3.8 for more information on this + option. + + DISCUSSION: + Internet host name translation was originally performed by + searching local copies of a table of all hosts. This + table became too large to update and distribute in a + timely manner and too large to fit into many hosts, so the + DNS was invented. + + The DNS creates a distributed database used primarily for + the translation between host names and host addresses. + Implementation of DNS software is required. The DNS + consists of two logically distinct parts: name servers and + resolvers (although implementations often combine these + two logical parts in the interest of efficiency) [DNS:2]. + + Domain name servers store authoritative data about certain + sections of the database and answer queries about the + data. Domain resolvers query domain name servers for data + on behalf of user processes. Every host therefore needs a + DNS resolver; some host machines will also need to run + domain name servers. Since no name server has complete + information, in general it is necessary to obtain + information from more than one name server to resolve a + query. + + 6.1.2 PROTOCOL WALK-THROUGH + + An implementor must study references [DNS:1] and [DNS:2] + carefully. They provide a thorough description of the theory, + protocol, and implementation of the domain name system, and + reflect several years of experience. + + + + + +Internet Engineering Task Force [Page 72] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1 + + All DNS name servers and resolvers MUST properly handle RRs + with a zero TTL: return the RR to the client but do not + cache it. + + DISCUSSION: + Zero TTL values are interpreted to mean that the RR can + only be used for the transaction in progress, and + should not be cached; they are useful for extremely + volatile data. + + 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5 + + A query with "QCLASS=*" SHOULD NOT be used unless the + requestor is seeking data from more than one class. In + particular, if the requestor is only interested in Internet + data types, QCLASS=IN MUST be used. + + 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1 + + Unused fields in a query or response message MUST be zero. + + 6.1.2.4 Compression: RFC-1035 Section 4.1.4 + + Name servers MUST use compression in responses. + + DISCUSSION: + Compression is essential to avoid overflowing UDP + datagrams; see Section 6.1.3.2. + + 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2 + + Recursive name servers and full-service resolvers generally + have some configuration information containing hints about + the location of root or local name servers. An + implementation MUST NOT include any of these hints in a + response. + + DISCUSSION: + Many implementors have found it convenient to store + these hints as if they were cached data, but some + neglected to ensure that this "cached data" was not + included in responses. This has caused serious + problems in the Internet when the hints were obsolete + or incorrect. + + + + + +Internet Engineering Task Force [Page 73] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3 SPECIFIC ISSUES + + 6.1.3.1 Resolver Implementation + + A name resolver SHOULD be able to multiplex concurrent + requests if the host supports concurrent processes. + + In implementing a DNS resolver, one of two different models + MAY optionally be chosen: a full-service resolver, or a stub + resolver. + + + (A) Full-Service Resolver + + A full-service resolver is a complete implementation of + the resolver service, and is capable of dealing with + communication failures, failure of individual name + servers, location of the proper name server for a given + name, etc. It must satisfy the following requirements: + + o The resolver MUST implement a local caching + function to avoid repeated remote access for + identical requests, and MUST time out information + in the cache. + + o The resolver SHOULD be configurable with start-up + information pointing to multiple root name servers + and multiple name servers for the local domain. + This insures that the resolver will be able to + access the whole name space in normal cases, and + will be able to access local domain information + should the local network become disconnected from + the rest of the Internet. + + + (B) Stub Resolver + + A "stub resolver" relies on the services of a recursive + name server on the connected network or a "nearby" + network. This scheme allows the host to pass on the + burden of the resolver function to a name server on + another host. This model is often essential for less + capable hosts, such as PCs, and is also recommended + when the host is one of several workstations on a local + network, because it allows all of the workstations to + share the cache of the recursive name server and hence + reduce the number of domain requests exported by the + local network. + + + +Internet Engineering Task Force [Page 74] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + At a minimum, the stub resolver MUST be capable of + directing its requests to redundant recursive name + servers. Note that recursive name servers are allowed + to restrict the sources of requests that they will + honor, so the host administrator must verify that the + service will be provided. Stub resolvers MAY implement + caching if they choose, but if so, MUST timeout cached + information. + + + 6.1.3.2 Transport Protocols + + DNS resolvers and recursive servers MUST support UDP, and + SHOULD support TCP, for sending (non-zone-transfer) queries. + Specifically, a DNS resolver or server that is sending a + non-zone-transfer query MUST send a UDP query first. If the + Answer section of the response is truncated and if the + requester supports TCP, it SHOULD try the query again using + TCP. + + DNS servers MUST be able to service UDP queries and SHOULD + be able to service TCP queries. A name server MAY limit the + resources it devotes to TCP queries, but it SHOULD NOT + refuse to service a TCP query just because it would have + succeeded with UDP. + + Truncated responses MUST NOT be saved (cached) and later + used in such a way that the fact that they are truncated is + lost. + + DISCUSSION: + UDP is preferred over TCP for queries because UDP + queries have much lower overhead, both in packet count + and in connection state. The use of UDP is essential + for heavily-loaded servers, especially the root + servers. UDP also offers additional robustness, since + a resolver can attempt several UDP queries to different + servers for the cost of a single TCP query. + + It is possible for a DNS response to be truncated, + although this is a very rare occurrence in the present + Internet DNS. Practically speaking, truncation cannot + be predicted, since it is data-dependent. The + dependencies include the number of RRs in the answer, + the size of each RR, and the savings in space realized + by the name compression algorithm. As a rule of thumb, + truncation in NS and MX lists should not occur for + answers containing 15 or fewer RRs. + + + +Internet Engineering Task Force [Page 75] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Whether it is possible to use a truncated answer + depends on the application. A mailer must not use a + truncated MX response, since this could lead to mail + loops. + + Responsible practices can make UDP suffice in the vast + majority of cases. Name servers must use compression + in responses. Resolvers must differentiate truncation + of the Additional section of a response (which only + loses extra information) from truncation of the Answer + section (which for MX records renders the response + unusable by mailers). Database administrators should + list only a reasonable number of primary names in lists + of name servers, MX alternatives, etc. + + However, it is also clear that some new DNS record + types defined in the future will contain information + exceeding the 512 byte limit that applies to UDP, and + hence will require TCP. Thus, resolvers and name + servers should implement TCP services as a backup to + UDP today, with the knowledge that they will require + the TCP service in the future. + + By private agreement, name servers and resolvers MAY arrange + to use TCP for all traffic between themselves. TCP MUST be + used for zone transfers. + + A DNS server MUST have sufficient internal concurrency that + it can continue to process UDP queries while awaiting a + response or performing a zone transfer on an open TCP + connection [DNS:2]. + + A server MAY support a UDP query that is delivered using an + IP broadcast or multicast address. However, the Recursion + Desired bit MUST NOT be set in a query that is multicast, + and MUST be ignored by name servers receiving queries via a + broadcast or multicast address. A host that sends broadcast + or multicast DNS queries SHOULD send them only as occasional + probes, caching the IP address(es) it obtains from the + response(s) so it can normally send unicast queries. + + DISCUSSION: + Broadcast or (especially) IP multicast can provide a + way to locate nearby name servers without knowing their + IP addresses in advance. However, general broadcasting + of recursive queries can result in excessive and + unnecessary load on both network and servers. + + + + +Internet Engineering Task Force [Page 76] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3.3 Efficient Resource Usage + + The following requirements on servers and resolvers are very + important to the health of the Internet as a whole, + particularly when DNS services are invoked repeatedly by + higher level automatic servers, such as mailers. + + (1) The resolver MUST implement retransmission controls to + insure that it does not waste communication bandwidth, + and MUST impose finite bounds on the resources consumed + to respond to a single request. See [DNS:2] pages 43- + 44 for specific recommendations. + + (2) After a query has been retransmitted several times + without a response, an implementation MUST give up and + return a soft error to the application. + + (3) All DNS name servers and resolvers SHOULD cache + temporary failures, with a timeout period of the order + of minutes. + + DISCUSSION: + This will prevent applications that immediately + retry soft failures (in violation of Section 2.2 + of this document) from generating excessive DNS + traffic. + + (4) All DNS name servers and resolvers SHOULD cache + negative responses that indicate the specified name, or + data of the specified type, does not exist, as + described in [DNS:2]. + + (5) When a DNS server or resolver retries a UDP query, the + retry interval SHOULD be constrained by an exponential + backoff algorithm, and SHOULD also have upper and lower + bounds. + + IMPLEMENTATION: + A measured RTT and variance (if available) should + be used to calculate an initial retransmission + interval. If this information is not available, a + default of no less than 5 seconds should be used. + Implementations may limit the retransmission + interval, but this limit must exceed twice the + Internet maximum segment lifetime plus service + delay at the name server. + + (6) When a resolver or server receives a Source Quench for + + + +Internet Engineering Task Force [Page 77] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + a query it has issued, it SHOULD take steps to reduce + the rate of querying that server in the near future. A + server MAY ignore a Source Quench that it receives as + the result of sending a response datagram. + + IMPLEMENTATION: + One recommended action to reduce the rate is to + send the next query attempt to an alternate + server, if there is one available. Another is to + backoff the retry interval for the same server. + + + 6.1.3.4 Multihomed Hosts + + When the host name-to-address function encounters a host + with multiple addresses, it SHOULD rank or sort the + addresses using knowledge of the immediately connected + network number(s) and any other applicable performance or + history information. + + DISCUSSION: + The different addresses of a multihomed host generally + imply different Internet paths, and some paths may be + preferable to others in performance, reliability, or + administrative restrictions. There is no general way + for the domain system to determine the best path. A + recommended approach is to base this decision on local + configuration information set by the system + administrator. + + IMPLEMENTATION: + The following scheme has been used successfully: + + (a) Incorporate into the host configuration data a + Network-Preference List, that is simply a list of + networks in preferred order. This list may be + empty if there is no preference. + + (b) When a host name is mapped into a list of IP + addresses, these addresses should be sorted by + network number, into the same order as the + corresponding networks in the Network-Preference + List. IP addresses whose networks do not appear + in the Network-Preference List should be placed at + the end of the list. + + + + + + +Internet Engineering Task Force [Page 78] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3.5 Extensibility + + DNS software MUST support all well-known, class-independent + formats [DNS:2], and SHOULD be written to minimize the + trauma associated with the introduction of new well-known + types and local experimentation with non-standard types. + + DISCUSSION: + The data types and classes used by the DNS are + extensible, and thus new types will be added and old + types deleted or redefined. Introduction of new data + types ought to be dependent only upon the rules for + compression of domain names inside DNS messages, and + the translation between printable (i.e., master file) + and internal formats for Resource Records (RRs). + + Compression relies on knowledge of the format of data + inside a particular RR. Hence compression must only be + used for the contents of well-known, class-independent + RRs, and must never be used for class-specific RRs or + RR types that are not well-known. The owner name of an + RR is always eligible for compression. + + A name server may acquire, via zone transfer, RRs that + the server doesn't know how to convert to printable + format. A resolver can receive similar information as + the result of queries. For proper operation, this data + must be preserved, and hence the implication is that + DNS software cannot use textual formats for internal + storage. + + The DNS defines domain name syntax very generally -- a + string of labels each containing up to 63 8-bit octets, + separated by dots, and with a maximum total of 255 + octets. Particular applications of the DNS are + permitted to further constrain the syntax of the domain + names they use, although the DNS deployment has led to + some applications allowing more general names. In + particular, Section 2.1 of this document liberalizes + slightly the syntax of a legal Internet host name that + was defined in RFC-952 [DNS:4]. + + 6.1.3.6 Status of RR Types + + Name servers MUST be able to load all RR types except MD and + MF from configuration files. The MD and MF types are + obsolete and MUST NOT be implemented; in particular, name + servers MUST NOT load these types from configuration files. + + + +Internet Engineering Task Force [Page 79] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + DISCUSSION: + The RR types MB, MG, MR, NULL, MINFO and RP are + considered experimental, and applications that use the + DNS cannot expect these RR types to be supported by + most domains. Furthermore these types are subject to + redefinition. + + The TXT and WKS RR types have not been widely used by + Internet sites; as a result, an application cannot rely + on the the existence of a TXT or WKS RR in most + domains. + + 6.1.3.7 Robustness + + DNS software may need to operate in environments where the + root servers or other servers are unavailable due to network + connectivity or other problems. In this situation, DNS name + servers and resolvers MUST continue to provide service for + the reachable part of the name space, while giving temporary + failures for the rest. + + DISCUSSION: + Although the DNS is meant to be used primarily in the + connected Internet, it should be possible to use the + system in networks which are unconnected to the + Internet. Hence implementations must not depend on + access to root servers before providing service for + local names. + + 6.1.3.8 Local Host Table + + DISCUSSION: + A host may use a local host table as a backup or + supplement to the DNS. This raises the question of + which takes precedence, the DNS or the host table; the + most flexible approach would make this a configuration + option. + + Typically, the contents of such a supplementary host + table will be determined locally by the site. However, + a publically-available table of Internet hosts is + maintained by the DDN Network Information Center (DDN + NIC), with a format documented in [DNS:4]. This table + can be retrieved from the DDN NIC using a protocol + described in [DNS:5]. It must be noted that this table + contains only a small fraction of all Internet hosts. + Hosts using this protocol to retrieve the DDN NIC host + table should use the VERSION command to check if the + + + +Internet Engineering Task Force [Page 80] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + table has changed before requesting the entire table + with the ALL command. The VERSION identifier should be + treated as an arbitrary string and tested only for + equality; no numerical sequence may be assumed. + + The DDN NIC host table includes administrative + information that is not needed for host operation and + is therefore not currently included in the DNS + database; examples include network and gateway entries. + However, much of this additional information will be + added to the DNS in the future. Conversely, the DNS + provides essential services (in particular, MX records) + that are not available from the DDN NIC host table. + + 6.1.4 DNS USER INTERFACE + + 6.1.4.1 DNS Administration + + This document is concerned with design and implementation + issues in host software, not with administrative or + operational issues. However, administrative issues are of + particular importance in the DNS, since errors in particular + segments of this large distributed database can cause poor + or erroneous performance for many sites. These issues are + discussed in [DNS:6] and [DNS:7]. + + 6.1.4.2 DNS User Interface + + Hosts MUST provide an interface to the DNS for all + application programs running on the host. This interface + will typically direct requests to a system process to + perform the resolver function [DNS:1, 6.1:2]. + + At a minimum, the basic interface MUST support a request for + all information of a specific type and class associated with + a specific name, and it MUST return either all of the + requested information, a hard error code, or a soft error + indication. When there is no error, the basic interface + returns the complete response information without + modification, deletion, or ordering, so that the basic + interface will not need to be changed to accommodate new + data types. + + DISCUSSION: + The soft error indication is an essential part of the + interface, since it may not always be possible to + access particular information from the DNS; see Section + 6.1.3.3. + + + +Internet Engineering Task Force [Page 81] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + A host MAY provide other DNS interfaces tailored to + particular functions, transforming the raw domain data into + formats more suited to these functions. In particular, a + host MUST provide a DNS interface to facilitate translation + between host addresses and host names. + + 6.1.4.3 Interface Abbreviation Facilities + + User interfaces MAY provide a method for users to enter + abbreviations for commonly-used names. Although the + definition of such methods is outside of the scope of the + DNS specification, certain rules are necessary to insure + that these methods allow access to the entire DNS name space + and to prevent excessive use of Internet resources. + + If an abbreviation method is provided, then: + + (a) There MUST be some convention for denoting that a name + is already complete, so that the abbreviation method(s) + are suppressed. A trailing dot is the usual method. + + (b) Abbreviation expansion MUST be done exactly once, and + MUST be done in the context in which the name was + entered. + + + DISCUSSION: + For example, if an abbreviation is used in a mail + program for a destination, the abbreviation should be + expanded into a full domain name and stored in the + queued message with an indication that it is already + complete. Otherwise, the abbreviation might be + expanded with a mail system search list, not the + user's, or a name could grow due to repeated + canonicalizations attempts interacting with wildcards. + + The two most common abbreviation methods are: + + (1) Interface-level aliases + + Interface-level aliases are conceptually implemented as + a list of alias/domain name pairs. The list can be + per-user or per-host, and separate lists can be + associated with different functions, e.g. one list for + host name-to-address translation, and a different list + for mail domains. When the user enters a name, the + interface attempts to match the name to the alias + component of a list entry, and if a matching entry can + + + +Internet Engineering Task Force [Page 82] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + be found, the name is replaced by the domain name found + in the pair. + + Note that interface-level aliases and CNAMEs are + completely separate mechanisms; interface-level aliases + are a local matter while CNAMEs are an Internet-wide + aliasing mechanism which is a required part of any DNS + implementation. + + (2) Search Lists + + A search list is conceptually implemented as an ordered + list of domain names. When the user enters a name, the + domain names in the search list are used as suffixes to + the user-supplied name, one by one, until a domain name + with the desired associated data is found, or the + search list is exhausted. Search lists often contain + the name of the local host's parent domain or other + ancestor domains. Search lists are often per-user or + per-process. + + It SHOULD be possible for an administrator to disable a + DNS search-list facility. Administrative denial may be + warranted in some cases, to prevent abuse of the DNS. + + There is danger that a search-list mechanism will + generate excessive queries to the root servers while + testing whether user input is a complete domain name, + lacking a final period to mark it as complete. A + search-list mechanism MUST have one of, and SHOULD have + both of, the following two provisions to prevent this: + + (a) The local resolver/name server can implement + caching of negative responses (see Section + 6.1.3.3). + + (b) The search list expander can require two or more + interior dots in a generated domain name before it + tries using the name in a query to non-local + domain servers, such as the root. + + DISCUSSION: + The intent of this requirement is to avoid + excessive delay for the user as the search list is + tested, and more importantly to prevent excessive + traffic to the root and other high-level servers. + For example, if the user supplied a name "X" and + the search list contained the root as a component, + + + +Internet Engineering Task Force [Page 83] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + a query would have to consult a root server before + the next search list alternative could be tried. + The resulting load seen by the root servers and + gateways near the root would be multiplied by the + number of hosts in the Internet. + + The negative caching alternative limits the effect + to the first time a name is used. The interior + dot rule is simpler to implement but can prevent + easy use of some top-level names. + + + 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|-----------|-|-|-|-|-|-- +GENERAL ISSUES | | | | | | | + | | | | | | | +Implement DNS name-to-address conversion |6.1.1 |x| | | | | +Implement DNS address-to-name conversion |6.1.1 |x| | | | | +Support conversions using host table |6.1.1 | | |x| | | +Properly handle RR with zero TTL |6.1.2.1 |x| | | | | +Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | | + Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | | +Unused fields zero |6.1.2.3 |x| | | | | +Use compression in responses |6.1.2.4 |x| | | | | + | | | | | | | +Include config info in responses |6.1.2.5 | | | | |x| +Support all well-known, class-indep. types |6.1.3.5 |x| | | | | +Easily expand type list |6.1.3.5 | |x| | | | +Load all RR types (except MD and MF) |6.1.3.6 |x| | | | | +Load MD or MF type |6.1.3.6 | | | | |x| +Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +RESOLVER ISSUES: | | | | | | | + | | | | | | | +Resolver support multiple concurrent requests |6.1.3.1 | |x| | | | +Full-service resolver: |6.1.3.1 | | |x| | | + Local caching |6.1.3.1 |x| | | | | + + + +Internet Engineering Task Force [Page 84] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Information in local cache times out |6.1.3.1 |x| | | | | + Configurable with starting info |6.1.3.1 | |x| | | | +Stub resolver: |6.1.3.1 | | |x| | | + Use redundant recursive name servers |6.1.3.1 |x| | | | | + Local caching |6.1.3.1 | | |x| | | + Information in local cache times out |6.1.3.1 |x| | | | | +Support for remote multi-homed hosts: | | | | | | | + Sort multiple addresses by preference list |6.1.3.4 | |x| | | | + | | | | | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +TRANSPORT PROTOCOLS: | | | | | | | + | | | | | | | +Support UDP queries |6.1.3.2 |x| | | | | +Support TCP queries |6.1.3.2 | |x| | | | + Send query using UDP first |6.1.3.2 |x| | | | |1 + Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | | +Name server limit TCP query resources |6.1.3.2 | | |x| | | + Punish unnecessary TCP query |6.1.3.2 | | | |x| | +Use truncated data as if it were not |6.1.3.2 | | | | |x| +Private agreement to use only TCP |6.1.3.2 | | |x| | | +Use TCP for zone transfers |6.1.3.2 |x| | | | | +TCP usage not block UDP queries |6.1.3.2 |x| | | | | +Support broadcast or multicast queries |6.1.3.2 | | |x| | | + RD bit set in query |6.1.3.2 | | | | |x| + RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | | + Send only as occasional probe for addr's |6.1.3.2 | |x| | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +RESOURCE USAGE: | | | | | | | + | | | | | | | +Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | | + Finite bounds per request |6.1.3.3 |x| | | | | +Failure after retries => soft error |6.1.3.3 |x| | | | | +Cache temporary failures |6.1.3.3 | |x| | | | +Cache negative responses |6.1.3.3 | |x| | | | +Retries use exponential backoff |6.1.3.3 | |x| | | | + Upper, lower bounds |6.1.3.3 | |x| | | | +Client handle Source Quench |6.1.3.3 | |x| | | | +Server ignore Source Quench |6.1.3.3 | | |x| | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +USER INTERFACE: | | | | | | | + | | | | | | | +All programs have access to DNS interface |6.1.4.2 |x| | | | | +Able to request all info for given name |6.1.4.2 |x| | | | | +Returns complete info or error |6.1.4.2 |x| | | | | +Special interfaces |6.1.4.2 | | |x| | | + Name<->Address translation |6.1.4.2 |x| | | | | + | | | | | | | +Abbreviation Facilities: |6.1.4.3 | | |x| | | + + + +Internet Engineering Task Force [Page 85] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Convention for complete names |6.1.4.3 |x| | | | | + Conversion exactly once |6.1.4.3 |x| | | | | + Conversion in proper context |6.1.4.3 |x| | | | | + Search list: |6.1.4.3 | | |x| | | + Administrator can disable |6.1.4.3 | |x| | | | + Prevention of excessive root queries |6.1.4.3 |x| | | | | + Both methods |6.1.4.3 | |x| | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +-----------------------------------------------|-----------|-|-|-|-|-|-- + +1. Unless there is private agreement between particular resolver and + particular server. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 86] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + 6.2 HOST INITIALIZATION + + 6.2.1 INTRODUCTION + + This section discusses the initialization of host software + across a connected network, or more generally across an + Internet path. This is necessary for a diskless host, and may + optionally be used for a host with disk drives. For a diskless + host, the initialization process is called "network booting" + and is controlled by a bootstrap program located in a boot ROM. + + To initialize a diskless host across the network, there are two + distinct phases: + + (1) Configure the IP layer. + + Diskless machines often have no permanent storage in which + to store network configuration information, so that + sufficient configuration information must be obtained + dynamically to support the loading phase that follows. + This information must include at least the IP addresses of + the host and of the boot server. To support booting + across a gateway, the address mask and a list of default + gateways are also required. + + (2) Load the host system code. + + During the loading phase, an appropriate file transfer + protocol is used to copy the system code across the + network from the boot server. + + A host with a disk may perform the first step, dynamic + configuration. This is important for microcomputers, whose + floppy disks allow network configuration information to be + mistakenly duplicated on more than one host. Also, + installation of new hosts is much simpler if they automatically + obtain their configuration information from a central server, + saving administrator time and decreasing the probability of + mistakes. + + 6.2.2 REQUIREMENTS + + 6.2.2.1 Dynamic Configuration + + A number of protocol provisions have been made for dynamic + configuration. + + o ICMP Information Request/Reply messages + + + +Internet Engineering Task Force [Page 87] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + This obsolete message pair was designed to allow a host + to find the number of the network it is on. + Unfortunately, it was useful only if the host already + knew the host number part of its IP address, + information that hosts requiring dynamic configuration + seldom had. + + o Reverse Address Resolution Protocol (RARP) [BOOT:4] + + RARP is a link-layer protocol for a broadcast medium + that allows a host to find its IP address given its + link layer address. Unfortunately, RARP does not work + across IP gateways and therefore requires a RARP server + on every network. In addition, RARP does not provide + any other configuration information. + + o ICMP Address Mask Request/Reply messages + + These ICMP messages allow a host to learn the address + mask for a particular network interface. + + o BOOTP Protocol [BOOT:2] + + This protocol allows a host to determine the IP + addresses of the local host and the boot server, the + name of an appropriate boot file, and optionally the + address mask and list of default gateways. To locate a + BOOTP server, the host broadcasts a BOOTP request using + UDP. Ad hoc gateway extensions have been used to + transmit the BOOTP broadcast through gateways, and in + the future the IP Multicasting facility will provide a + standard mechanism for this purpose. + + + The suggested approach to dynamic configuration is to use + the BOOTP protocol with the extensions defined in "BOOTP + Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 + defines some important general (not vendor-specific) + extensions. In particular, these extensions allow the + address mask to be supplied in BOOTP; we RECOMMEND that the + address mask be supplied in this manner. + + DISCUSSION: + Historically, subnetting was defined long after IP, and + so a separate mechanism (ICMP Address Mask messages) + was designed to supply the address mask to a host. + However, the IP address mask and the corresponding IP + address conceptually form a pair, and for operational + + + +Internet Engineering Task Force [Page 88] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + simplicity they ought to be defined at the same time + and by the same mechanism, whether a configuration file + or a dynamic mechanism like BOOTP. + + Note that BOOTP is not sufficiently general to specify + the configurations of all interfaces of a multihomed + host. A multihomed host must either use BOOTP + separately for each interface, or configure one + interface using BOOTP to perform the loading, and + perform the complete initialization from a file later. + + Application layer configuration information is expected + to be obtained from files after loading of the system + code. + + 6.2.2.2 Loading Phase + + A suggested approach for the loading phase is to use TFTP + [BOOT:1] between the IP addresses established by BOOTP. + + TFTP to a broadcast address SHOULD NOT be used, for reasons + explained in Section 4.2.3.4. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 89] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + 6.3 REMOTE MANAGEMENT + + 6.3.1 INTRODUCTION + + The Internet community has recently put considerable effort + into the development of network management protocols. The + result has been a two-pronged approach [MGT:1, MGT:6]: the + Simple Network Management Protocol (SNMP) [MGT:4] and the + Common Management Information Protocol over TCP (CMOT) [MGT:5]. + + In order to be managed using SNMP or CMOT, a host will need to + implement an appropriate management agent. An Internet host + SHOULD include an agent for either SNMP or CMOT. + + Both SNMP and CMOT operate on a Management Information Base + (MIB) that defines a collection of management values. By + reading and setting these values, a remote application may + query and change the state of the managed system. + + A standard MIB [MGT:3] has been defined for use by both + management protocols, using data types defined by the Structure + of Management Information (SMI) defined in [MGT:2]. Additional + MIB variables can be introduced under the "enterprises" and + "experimental" subtrees of the MIB naming space [MGT:2]. + + Every protocol module in the host SHOULD implement the relevant + MIB variables. A host SHOULD implement the MIB variables as + defined in the most recent standard MIB, and MAY implement + other MIB variables when appropriate and useful. + + 6.3.2 PROTOCOL WALK-THROUGH + + The MIB is intended to cover both hosts and gateways, although + there may be detailed differences in MIB application to the two + cases. This section contains the appropriate interpretation of + the MIB for hosts. It is likely that later versions of the MIB + will include more entries for host management. + + A managed host must implement the following groups of MIB + object definitions: System, Interfaces, Address Translation, + IP, ICMP, TCP, and UDP. + + The following specific interpretations apply to hosts: + + o ipInHdrErrors + + Note that the error "time-to-live exceeded" can occur in a + host only when it is forwarding a source-routed datagram. + + + +Internet Engineering Task Force [Page 90] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + o ipOutNoRoutes + + This object counts datagrams discarded because no route + can be found. This may happen in a host if all the + default gateways in the host's configuration are down. + + o ipFragOKs, ipFragFails, ipFragCreates + + A host that does not implement intentional fragmentation + (see "Fragmentation" section of [INTRO:1]) MUST return the + value zero for these three objects. + + o icmpOutRedirects + + For a host, this object MUST always be zero, since hosts + do not send Redirects. + + o icmpOutAddrMaskReps + + For a host, this object MUST always be zero, unless the + host is an authoritative source of address mask + information. + + o ipAddrTable + + For a host, the "IP Address Table" object is effectively a + table of logical interfaces. + + o ipRoutingTable + + For a host, the "IP Routing Table" object is effectively a + combination of the host's Routing Cache and the static + route table described in "Routing Outbound Datagrams" + section of [INTRO:1]. + + Within each ipRouteEntry, ipRouteMetric1...4 normally will + have no meaning for a host and SHOULD always be -1, while + ipRouteType will normally have the value "remote". + + If destinations on the connected network do not appear in + the Route Cache (see "Routing Outbound Datagrams section + of [INTRO:1]), there will be no entries with ipRouteType + of "direct". + + + DISCUSSION: + The current MIB does not include Type-of-Service in an + ipRouteEntry, but a future revision is expected to make + + + +Internet Engineering Task Force [Page 91] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + this addition. + + We also expect the MIB to be expanded to allow the remote + management of applications (e.g., the ability to partially + reconfigure mail systems). Network service applications + such as mail systems should therefore be written with the + "hooks" for remote management. + + 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|-----------|-|-|-|-|-|-- +Support SNMP or CMOT agent |6.3.1 | |x| | | | +Implement specified objects in standard MIB |6.3.1 | |x| | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 92] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + +7. REFERENCES + + This section lists the primary references with which every + implementer must be thoroughly familiar. It also lists some + secondary references that are suggested additional reading. + + INTRODUCTORY REFERENCES: + + + [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," + IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, + October 1989. + + [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, + (three volumes), SRI International, December 1985. + + [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, + RFC-1011, May 1987. + + This document is republished periodically with new RFC numbers; + the latest version must be used. + + [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. + Postel, RFC-980, March 1986. + + [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, + May 1987. + + This document is republished periodically with new RFC numbers; + the latest version must be used. + + + TELNET REFERENCES: + + + [TELNET:1] "Telnet Protocol Specification," J. Postel and J. + Reynolds, RFC-854, May 1983. + + [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, + RFC-855, May 1983. + + [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, + RFC-856, May 1983. + + [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, + May 1983. + + [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. + + + +Internet Engineering Task Force [Page 93] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + Reynolds, RFC-858, May 1983. + + [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC- + 859, May 1983. + + [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, + RFC-860, May 1983. + + [TELNET:8] "Telnet Extended Options List," J. Postel and J. + Reynolds, RFC-861, May 1983. + + [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, + December 1983. + + [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, + February 1989. + + This document supercedes RFC-930. + + [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, + October 1988. + + [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August + 1989. + + [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, + December 1988. + + [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC- + 1080, November 1988. + + + SECONDARY TELNET REFERENCES: + + + [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of + Defense, May 1984. + + This document is intended to describe the same protocol as RFC- + 854. In case of conflict, RFC-854 takes precedence, and the + present document takes precedence over both. + + [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977. + + [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October + 1977. + + [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977. + + + +Internet Engineering Task Force [Page 94] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS + Implementation," A. Yasuda and T. Thompson, RFC-1043, February + 1988. + + + FTP REFERENCES: + + + [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC- + 959, October 1985. + + [FTP:2] "Document File Format Standards," J. Postel, RFC-678, + December 1974. + + [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of + Defense, May 1984. + + This document is based on an earlier version of the FTP + specification (RFC-765) and is obsolete. + + + TFTP REFERENCES: + + + [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June + 1981. + + + MAIL REFERENCES: + + + [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August + 1982. + + [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," + D. Crocker, RFC-822, August 1982. + + This document obsoleted an earlier specification, RFC-733. + + [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC- + 974, January 1986. + + This RFC describes the use of MX records, a mandatory extension + to the mail delivery process. + + [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, + February 1988. + + + + +Internet Engineering Task Force [Page 95] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, + June 1986. + + [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. + + The two preceding RFC's define a proposed standard for + gatewaying mail between the Internet and the X.400 environments. + + [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. + Department of Defense, May 1984. + + This specification is intended to describe the same protocol as + does RFC-821. However, MIL-STD-1781 is incomplete; in + particular, it does not include MX records [SMTP:3]. + + [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, + RFC-1049, March 1988. + + + DOMAIN NAME SYSTEM REFERENCES: + + + [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, + RFC-1034, November 1987. + + This document and the following one obsolete RFC-882, RFC-883, + and RFC-973. + + [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, + P. Mockapetris, November 1987. + + + [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, + January 1986. + + + [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, + RFC-952, M. Stahl, E. Feinler, October 1985. + + SECONDARY DNS REFERENCES: + + + [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, + RFC-953, October 1985. + + [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November + 1987. + + + + +Internet Engineering Task Force [Page 96] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC- + 1033, November 1987. + + [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet + Protocol Handbook, NIC 50007, SRI Network Information Center, + August 1989. + + + SYSTEM INITIALIZATION REFERENCES: + + + [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June + 1984. + + [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC- + 951, September 1985. + + [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC- + 1084, December 1988. + + Note: this RFC revised and obsoleted RFC-1048. + + [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. + Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. + + + MANAGEMENT REFERENCES: + + + [MGT:1] "IAB Recommendations for the Development of Internet Network + Management Standards," V. Cerf, RFC-1052, April 1988. + + [MGT:2] "Structure and Identification of Management Information for + TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, + August 1988. + + [MGT:3] "Management Information Base for Network Management of + TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, + August 1988. + + [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, + M. Schoffstall, and C. Davin, RFC-1098, April 1989. + + [MGT:5] "The Common Management Information Services and Protocol + over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. + + [MGT:6] "Report of the Second Ad Hoc Network Management Review + Group," V. Cerf, RFC-1109, August 1989. + + + +Internet Engineering Task Force [Page 97] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + +Security Considerations + + There are many security issues in the application and support + programs of host software, but a full discussion is beyond the scope + of this RFC. Security-related issues are mentioned in sections + concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and + EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the + SMTP DATA command (Section 5.2.8). + +Author's Address + + Robert Braden + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + + Phone: (213) 822 1511 + + EMail: Braden@ISI.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 98] + diff --git a/server/src/site/resources/rfclist/basic/rfc2045.txt b/server/src/site/resources/rfclist/basic/rfc2045.txt new file mode 100644 index 00000000000..0179984eae5 --- /dev/null +++ b/server/src/site/resources/rfclist/basic/rfc2045.txt @@ -0,0 +1,1740 @@ + + + + + +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 := + + x-token := + + subtype := extension-token / iana-token + + iana-token := + + parameter := attribute "=" value + + attribute := token + ; Matching of attributes + ; is ALWAYS case-insensitive. + + value := token / quoted-string + + token := 1* + + 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 := + ; 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 := + +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 := + + + + +Freed & Borenstein Standards Track [Page 29] + +RFC 2045 Internet Message Bodies November 1996 + + + ietf-token := + + id := "Content-ID" ":" msg-id + + mechanism := "7bit" / "8bit" / "binary" / + "quoted-printable" / "base64" / + ietf-token / x-token + + MIME-extension-field := + + 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 := + ; Characters not listed as "mail-safe" in + ; RFC 2049 are also not recommended. + + subtype := extension-token / iana-token + + token := 1* + + 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 := + + + + + + + + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 31] + + + diff --git a/server/src/site/resources/rfclist/basic/rfc2046.txt b/server/src/site/resources/rfclist/basic/rfc2046.txt new file mode 100644 index 00000000000..ee204a53722 --- /dev/null +++ b/server/src/site/resources/rfclist/basic/rfc2046.txt @@ -0,0 +1,2468 @@ + + + + + +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 + To: Ned Freed + 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 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 := + + 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 + To: Ned Freed + 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: + 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: + 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: + 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: + 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: + 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: + Content-Type: multipart/alternative; boundary=42 + Content-ID: + + --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: + + --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: + + --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: + + 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 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/server/src/site/resources/rfclist/basic/rfc2822.txt b/server/src/site/resources/rfclist/basic/rfc2822.txt new file mode 100644 index 00000000000..92b3ec28ba7 --- /dev/null +++ b/server/src/site/resources/rfclist/basic/rfc2822.txt @@ -0,0 +1,2858 @@ + + + + + +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 +To: Mary Smith +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 +Sender: Michael Jones +To: Mary Smith +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" +To: Mary Smith , jdoe@example.org, Who? +Cc: , "Giant; \"Big\" Box" +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 +To: A Group:Chris Jones ,joe@where.test,John ; +Cc: Undisclosed recipients:; +Date: Thu, 13 Feb 1969 23:32:54 -0330 +Message-ID: + +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 +To: Mary Smith +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 +To: John Doe +Reply-To: "Mary Smith: Personal Account" +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" +From: John Doe +Subject: Re: Saying Hello +Date: Fri, 21 Nov 1997 11:00:00 -0600 +Message-ID: +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 +To: Mary Smith +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 +Resent-To: Jane Brown +Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 +Resent-Message-ID: <78910@example.net> +From: John Doe +To: Mary Smith +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 ; 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 +To: Mary Smith +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) +To:A Group(Some people) + :Chris Jones , + joe@example.org, + John (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: + +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 +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 +To: Mary Smith +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 +To : Mary Smith +__ + +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/server/src/site/resources/rfclist/imap4/rfc1731.txt b/server/src/site/resources/rfclist/imap4/rfc1731.txt new file mode 100644 index 00000000000..7c3f9535163 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc1731.txt @@ -0,0 +1,340 @@ + + + + + +Network Working Group J. Myers +Request for Comments: 1731 Carnegie Mellon +Category: Standards Track December 1994 + + + IMAP4 Authentication Mechanisms + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + + +1. Introduction + + The Internet Message Access Protocol, Version 4 [IMAP4] contains the + AUTHENTICATE command, for identifying and authenticating a user to an + IMAP4 server and for optionally negotiating a protection mechanism + for subsequent protocol interactions. This document describes + several authentication mechanisms for use by the IMAP4 AUTHENTICATE + command. + + +2. Kerberos version 4 authentication mechanism + + The authentication type associated with Kerberos version 4 is + "KERBEROS_V4". + + The data encoded in the first ready response contains a random 32-bit + number in network byte order. The client should respond with a + Kerberos ticket and an authenticator for the principal + "imap.hostname@realm", where "hostname" is the first component of the + host name of the server with all letters in lower case and where + "realm" is the Kerberos realm of the server. The encrypted checksum + field included within the Kerberos authenticator should contain the + server provided 32-bit number in network byte order. + + Upon decrypting and verifying the ticket and authenticator, the + server should verify that the contained checksum field equals the + original server provided random 32-bit number. Should the + verification be successful, the server must add one to the checksum + and construct 8 octets of data, with the first four octets containing + the incremented checksum in network byte order, the fifth octet + containing a bit-mask specifying the protection mechanisms supported + by the server, and the sixth through eighth octets containing, in + + + +Myers [Page 1] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + network byte order, the maximum cipher-text buffer size the server is + able to receive. The server must encrypt the 8 octets of data in the + session key and issue that encrypted data in a second ready response. + The client should consider the server authenticated if the first four + octets the un-encrypted data is equal to one plus the checksum it + previously sent. + + The client must construct data with the first four octets containing + the original server-issued checksum in network byte order, the fifth + octet containing the bit-mask specifying the selected protection + mechanism, the sixth through eighth octets containing in network byte + order the maximum cipher-text buffer size the client is able to + receive, and the following octets containing a user name string. The + client must then append from one to eight octets so that the length + of the data is a multiple of eight octets. The client must then PCBC + encrypt the data with the session key and respond to the second ready + response with the encrypted data. The server decrypts the data and + verifies the contained checksum. The username field identifies the + user for whom subsequent IMAP operations are to be performed; the + server must verify that the principal identified in the Kerberos + ticket is authorized to connect as that user. After these + verifications, the authentication process is complete. + + The protection mechanisms and their corresponding bit-masks are as + follows: + + 1 No protection mechanism + 2 Integrity (krb_mk_safe) protection + 4 Privacy (krb_mk_priv) protection + + + EXAMPLE: The following are two Kerberos version 4 login scenarios + (note that the line breaks in the sample authenticators are for + editorial clarity and are not in real authenticators) + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + AmFYig== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: + or//EoAADZI= + C: DiAF5A4gA+oOIALuBkAAmw== + S: A001 OK Kerberos V4 authentication successful + + + + + + + +Myers [Page 2] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + gcfgCA== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: A001 NO Kerberos V4 authentication failed + + +3. GSSAPI authentication mechanism + + The authentication type associated with all mechanisms employing the + GSSAPI [RFC1508] is "GSSAPI". + + The first ready response issued by the server contains no data. The + client should call GSS_Init_sec_context, passing in 0 for + input_context_handle (initially) and a targ_name equal to output_name + from GSS_Import_Name called with input_name_type of NULL and + input_name_string of "SERVICE:imap@hostname" where "hostname" is the + fully qualified host name of the server with all letters in lower + case. The client must then respond with the resulting output_token. + If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client + should expect the server to issue a token in a subsequent ready + response. The client must pass the token to another call to + GSS_Init_sec_context. + + If GSS_Init_sec_context returns GSS_COMPLETE, then the client should + respond with any resulting output_token. If there is no + output_token, the client should respond with no data. The client + should then expect the server to issue a token in a subsequent ready + response. The client should pass this token to GSS_Unseal and + interpret the first octet of resulting cleartext as a bit-mask + specifying the protection mechanisms supported by the server and the + second through fourth octets as the maximum size output_message to + send to the server. The client should construct data, with the first + octet containing the bit-mask specifying the selected protection + mechanism, the second through fourth octets containing in network + byte order the maximum size output_message the client is able to + receive, and the remaining octets containing a user name string. The + client must pass the data to GSS_Seal with conf_flag set to FALSE, + and respond with the generated output_message. The client can then + consider the server authenticated. + + The server must issue a ready response with no data and pass the + resulting client supplied token to GSS_Accept_sec_context as + input_token, setting acceptor_cred_handle to NULL (for "use default + credentials"), and 0 for input_context_handle (initially). If + GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should + + + +Myers [Page 3] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + return the generated output_token to the client in a ready response + and pass the resulting client supplied token to another call to + GSS_Accept_sec_context. + + If GSS_Accept_sec_context returns GSS_COMPLETE, then if an + output_token is returned, the server should return it to the client + in a ready response and expect a reply from the client with no data. + Whether or not an output_token was returned, the server then should + then construct 4 octets of data, with the first octet containing a + bit-mask specifying the protection mechanisms supported by the server + and the second through fourth octets containing in network byte order + the maximum size output_token the server is able to receive. The + server must then pass the plaintext to GSS_Seal with conf_flag set to + FALSE and issue the generated output_message to the client in a ready + response. The server must then pass the resulting client supplied + token to GSS_Unseal and interpret the first octet of resulting + cleartext as the bit-mask for the selected protection mechanism, the + second through fourth octets as the maximum size output_message to + send to the client, and the remaining octets as the user name. Upon + verifying the src_name is authorized to authenticate as the user + name, The server should then consider the client authenticated. + + The protection mechanisms and their corresponding bit-masks are as + follows: + + 1 No protection mechanism + 2 Integrity protection. + Sender calls GSS_Seal with conf_flag set to FALSE + 4 Privacy protection. + Sender calls GSS_Seal with conf_flag set to TRUE + + +4. S/Key authentication mechanism + + The authentication type associated with S/Key [SKEY] is "SKEY". + + The first ready response issued by the server contains no data. The + client responds with the user name string. + + The data encoded in the second ready response contains the decimal + sequence number followed by a single space and the seed string for + the indicated user. The client responds with the one-time-password, + as either a 64-bit value in network byte order or encoded in the "six + English words" format. + + Upon successful verification of the one-time-password, the server + should consider the client authenticated. + + + + +Myers [Page 4] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + S/Key authentication does not provide for any protection mechanisms. + + + EXAMPLE: The following are two S/Key login scenarios. + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE SKEY + S: + + C: bW9yZ2Fu + S: + OTUgUWE1ODMwOA== + C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== + S: A001 OK S/Key authentication successful + + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE SKEY + S: + + C: c21pdGg= + S: + OTUgUWE1ODMwOA== + C: BsAY3g4gBNo= + S: A001 NO S/Key authentication failed + + +5. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", + RFC 1730, University of Washington, December 1994. + + [RFC1508] Linn, J., "Generic Security Service Application Program + Interface", RFC 1508, Geer Zolot Associates, September 1993. + + [SKEY] Haller, Neil M. "The S/Key One-Time Password System", + Bellcore, Morristown, New Jersey, October 1993, + thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps + + + + + + + + + + + + + + + + + +Myers [Page 5] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + +6. Security Considerations + + Security issues are discussed throughout this memo. + + +7. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + EMail: jgm+@cmu.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers [Page 6] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2060.txt b/server/src/site/resources/rfclist/imap4/rfc2060.txt new file mode 100644 index 00000000000..5c31eb99642 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2060.txt @@ -0,0 +1,4596 @@ + + + + + +Network Working Group M. Crispin +Request for Comments: 2060 University of Washington +Obsoletes: 1730 December 1996 +Category: Standards Track + + + INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) + allows a client to access and manipulate electronic mail messages on + a server. IMAP4rev1 permits manipulation of remote message folders, + called "mailboxes", in a way that is functionally equivalent to local + mailboxes. IMAP4rev1 also provides the capability for an offline + client to resynchronize with the server (see also [IMAP-DISC]). + + IMAP4rev1 includes operations for creating, deleting, and renaming + mailboxes; checking for new messages; permanently removing messages; + setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; + searching; and selective fetching of message attributes, texts, and + portions thereof. Messages in IMAP4rev1 are accessed by the use of + numbers. These numbers are either message sequence numbers or unique + identifiers. + + IMAP4rev1 supports a single server. A mechanism for accessing + configuration information to support multiple IMAP4rev1 servers is + discussed in [ACAP]. + + IMAP4rev1 does not specify a means of posting mail; this function is + handled by a mail transfer protocol such as [SMTP]. + + IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and + unpublished IMAP2bis protocols. In the course of the evolution of + IMAP4rev1, some aspects in the earlier protocol have become obsolete. + Obsolete commands, responses, and data formats which an IMAP4rev1 + implementation may encounter when used with an earlier implementation + are described in [IMAP-OBSOLETE]. + + + + + +Crispin Standards Track [Page 1] + +RFC 2060 IMAP4rev1 December 1996 + + + Other compatibility issues with IMAP2bis, the most common variant of + the earlier protocol, are discussed in [IMAP-COMPAT]. A full + discussion of compatibility issues with rare (and presumed extinct) + variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is + primarily of historical interest. + +Table of Contents + +IMAP4rev1 Protocol Specification .................................. 4 +1. How to Read This Document ................................. 4 +1.1. Organization of This Document ............................. 4 +1.2. Conventions Used in This Document ......................... 4 +2. Protocol Overview ......................................... 5 +2.1. Link Level ................................................ 5 +2.2. Commands and Responses .................................... 6 +2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 6 +2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 7 +2.3. Message Attributes ........................................ 7 +2.3.1. Message Numbers ........................................... 7 +2.3.1.1. Unique Identifier (UID) Message Attribute ......... 7 +2.3.1.2. Message Sequence Number Message Attribute ......... 9 +2.3.2. Flags Message Attribute .................................... 9 +2.3.3. Internal Date Message Attribute ........................... 10 +2.3.4. [RFC-822] Size Message Attribute .......................... 11 +2.3.5. Envelope Structure Message Attribute ...................... 11 +2.3.6. Body Structure Message Attribute .......................... 11 +2.4. Message Texts ............................................. 11 +3. State and Flow Diagram .................................... 11 +3.1. Non-Authenticated State ................................... 11 +3.2. Authenticated State ....................................... 11 +3.3. Selected State ............................................ 12 +3.4. Logout State .............................................. 12 +4. Data Formats .............................................. 12 +4.1. Atom ...................................................... 13 +4.2. Number .................................................... 13 +4.3. String ..................................................... 13 +4.3.1. 8-bit and Binary Strings .................................. 13 +4.4. Parenthesized List ........................................ 14 +4.5. NIL ....................................................... 14 +5. Operational Considerations ................................ 14 +5.1. Mailbox Naming ............................................ 14 +5.1.1. Mailbox Hierarchy Naming .................................. 14 +5.1.2. Mailbox Namespace Naming Convention ....................... 14 +5.1.3. Mailbox International Naming Convention ................... 15 +5.2. Mailbox Size and Message Status Updates ................... 16 +5.3. Response when no Command in Progress ...................... 16 +5.4. Autologout Timer .......................................... 16 +5.5. Multiple Commands in Progress ............................. 17 + + + +Crispin Standards Track [Page 2] + +RFC 2060 IMAP4rev1 December 1996 + + +6. Client Commands ........................................... 17 +6.1. Client Commands - Any State ............................... 18 +6.1.1. CAPABILITY Command ........................................ 18 +6.1.2. NOOP Command .............................................. 19 +6.1.3. LOGOUT Command ............................................ 20 +6.2. Client Commands - Non-Authenticated State ................. 20 +6.2.1. AUTHENTICATE Command ...................................... 21 +6.2.2. LOGIN Command ............................................. 22 +6.3. Client Commands - Authenticated State ..................... 22 +6.3.1. SELECT Command ............................................ 23 +6.3.2. EXAMINE Command ........................................... 24 +6.3.3. CREATE Command ............................................ 25 +6.3.4. DELETE Command ............................................ 26 +6.3.5. RENAME Command ............................................ 27 +6.3.6. SUBSCRIBE Command ......................................... 29 +6.3.7. UNSUBSCRIBE Command ....................................... 30 +6.3.8. LIST Command .............................................. 30 +6.3.9. LSUB Command .............................................. 32 +6.3.10. STATUS Command ............................................ 33 +6.3.11. APPEND Command ............................................ 34 +6.4. Client Commands - Selected State .......................... 35 +6.4.1. CHECK Command ............................................. 36 +6.4.2. CLOSE Command ............................................. 36 +6.4.3. EXPUNGE Command ........................................... 37 +6.4.4. SEARCH Command ............................................ 37 +6.4.5. FETCH Command ............................................. 41 +6.4.6. STORE Command ............................................. 45 +6.4.7. COPY Command .............................................. 46 +6.4.8. UID Command ............................................... 47 +6.5. Client Commands - Experimental/Expansion .................. 48 +6.5.1. X Command ........................................... 48 +7. Server Responses .......................................... 48 +7.1. Server Responses - Status Responses ....................... 49 +7.1.1. OK Response ............................................... 51 +7.1.2. NO Response ............................................... 51 +7.1.3. BAD Response .............................................. 52 +7.1.4. PREAUTH Response .......................................... 52 +7.1.5. BYE Response .............................................. 52 +7.2. Server Responses - Server and Mailbox Status .............. 53 +7.2.1. CAPABILITY Response ....................................... 53 +7.2.2. LIST Response .............................................. 54 +7.2.3. LSUB Response ............................................. 55 +7.2.4 STATUS Response ........................................... 55 +7.2.5. SEARCH Response ........................................... 55 +7.2.6. FLAGS Response ............................................ 56 +7.3. Server Responses - Mailbox Size ........................... 56 +7.3.1. EXISTS Response ........................................... 56 +7.3.2. RECENT Response ........................................... 57 + + + +Crispin Standards Track [Page 3] + +RFC 2060 IMAP4rev1 December 1996 + + +7.4. Server Responses - Message Status ......................... 57 +7.4.1. EXPUNGE Response .......................................... 57 +7.4.2. FETCH Response ............................................ 58 +7.5. Server Responses - Command Continuation Request ........... 63 +8. Sample IMAP4rev1 connection ............................... 63 +9. Formal Syntax ............................................. 64 +10. Author's Note ............................................. 74 +11. Security Considerations ................................... 74 +12. Author's Address .......................................... 75 +Appendices ........................................................ 76 +A. References ................................................ 76 +B. Changes from RFC 1730 ..................................... 77 +C. Key Word Index ............................................ 79 + + +IMAP4rev1 Protocol Specification + +1. How to Read This Document + +1.1. Organization of This Document + + This document is written from the point of view of the implementor of + an IMAP4rev1 client or server. Beyond the protocol overview in + section 2, it is not optimized for someone trying to understand the + operation of the protocol. The material in sections 3 through 5 + provides the general context and definitions with which IMAP4rev1 + operates. + + Sections 6, 7, and 9 describe the IMAP commands, responses, and + syntax, respectively. The relationships among these are such that it + is almost impossible to understand any of them separately. In + particular, do not attempt to deduce command syntax from the command + section alone; instead refer to the Formal Syntax section. + +1.2. Conventions Used in This Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + The following terms are used in this document to signify the + requirements of this specification. + + 1) MUST, or the adjective REQUIRED, means that the definition is + an absolute requirement of the specification. + + 2) MUST NOT that the definition is an absolute prohibition of the + specification. + + + + +Crispin Standards Track [Page 4] + +RFC 2060 IMAP4rev1 December 1996 + + + 3) SHOULD means that there may exist valid reasons in particular + circumstances to ignore a particular item, but the full + implications MUST be understood and carefully weighed before + choosing a different course. + + 4) SHOULD NOT means that there may exist valid reasons in + particular circumstances when the particular behavior is + acceptable or even useful, but the full implications SHOULD be + understood and the case carefully weighed before implementing + any behavior described with this label. + + 5) MAY, or the adjective OPTIONAL, means that an item is truly + optional. One vendor may choose to include the item because a + particular marketplace requires it or because the vendor feels + that it enhances the product while another vendor may omit the + same item. An implementation which does not include a + particular option MUST be prepared to interoperate with another + implementation which does include the option. + + "Can" is used instead of "may" when referring to a possible + circumstance or situation, as opposed to an optional facility of + the protocol. + + "User" is used to refer to a human user, whereas "client" refers + to the software being run by the user. + + "Connection" refers to the entire sequence of client/server + interaction from the initial establishment of the network + connection until its termination. "Session" refers to the + sequence of client/server interaction from the time that a mailbox + is selected (SELECT or EXAMINE command) until the time that + selection ends (SELECT or EXAMINE of another mailbox, CLOSE + command, or connection termination). + + Characters are 7-bit US-ASCII unless otherwise specified. Other + character sets are indicated using a "CHARSET", as described in + [MIME-IMT] and defined in [CHARSET]. CHARSETs have important + additional semantics in addition to defining character set; refer + to these documents for more detail. + +2. Protocol Overview + +2.1. Link Level + + The IMAP4rev1 protocol assumes a reliable data stream such as + provided by TCP. When TCP is used, an IMAP4rev1 server listens on + port 143. + + + + +Crispin Standards Track [Page 5] + +RFC 2060 IMAP4rev1 December 1996 + + +2.2. Commands and Responses + + An IMAP4rev1 connection consists of the establishment of a + client/server network connection, an initial greeting from the + server, and client/server interactions. These client/server + interactions consist of a client command, server data, and a server + completion result response. + + All interactions transmitted by client and server are in the form of + lines; that is, strings that end with a CRLF. The protocol receiver + of an IMAP4rev1 client or server is either reading a line, or is + reading a sequence of octets with a known count followed by a line. + +2.2.1. Client Protocol Sender and Server Protocol Receiver + + The client command begins an operation. Each client command is + prefixed with an identifier (typically a short alphanumeric string, + e.g. A0001, A0002, etc.) called a "tag". A different tag is + generated by the client for each command. + + There are two cases in which a line from the client does not + represent a complete command. In one case, a command argument is + quoted with an octet count (see the description of literal in String + under Data Formats); in the other case, the command arguments require + server feedback (see the AUTHENTICATE command). In either case, the + server sends a command continuation request response if it is ready + for the octets (if appropriate) and the remainder of the command. + This response is prefixed with the token "+". + + Note: If, instead, the server detected an error in the command, it + sends a BAD completion response with tag matching the command (as + described below) to reject the command and prevent the client from + sending any more of the command. + + It is also possible for the server to send a completion response + for some other command (if multiple commands are in progress), or + untagged data. In either case, the command continuation request + is still pending; the client takes the appropriate action for the + response, and reads another response from the server. In all + cases, the client MUST send a complete command (including + receiving all command continuation request responses and command + continuations for the command) before initiating a new command. + + The protocol receiver of an IMAP4rev1 server reads a command line + from the client, parses the command and its arguments, and transmits + server data and a server command completion result response. + + + + + +Crispin Standards Track [Page 6] + +RFC 2060 IMAP4rev1 December 1996 + + +2.2.2. Server Protocol Sender and Client Protocol Receiver + + Data transmitted by the server to the client and status responses + that do not indicate command completion are prefixed with the token + "*", and are called untagged responses. + + Server data MAY be sent as a result of a client command, or MAY be + sent unilaterally by the server. There is no syntactic difference + between server data that resulted from a specific command and server + data that were sent unilaterally. + + The server completion result response indicates the success or + failure of the operation. It is tagged with the same tag as the + client command which began the operation. Thus, if more than one + command is in progress, the tag in a server completion response + identifies the command to which the response applies. There are + three possible server completion responses: OK (indicating success), + NO (indicating failure), or BAD (indicating protocol error such as + unrecognized command or command syntax error). + + The protocol receiver of an IMAP4rev1 client reads a response line + from the server. It then takes action on the response based upon the + first token of the response, which can be a tag, a "*", or a "+". + + A client MUST be prepared to accept any server response at all times. + This includes server data that was not requested. Server data SHOULD + be recorded, so that the client can reference its recorded copy + rather than sending a command to the server to request the data. In + the case of certain server data, the data MUST be recorded. + + This topic is discussed in greater detail in the Server Responses + section. + +2.3. Message Attributes + + In addition to message text, each message has several attributes + associated with it. These attributes may be retrieved individually + or in conjunction with other attributes or message texts. + +2.3.1. Message Numbers + + Messages in IMAP4rev1 are accessed by one of two numbers; the unique + identifier and the message sequence number. + +2.3.1.1. Unique Identifier (UID) Message Attribute + + A 32-bit value assigned to each message, which when used with the + unique identifier validity value (see below) forms a 64-bit value + + + +Crispin Standards Track [Page 7] + +RFC 2060 IMAP4rev1 December 1996 + + + that is permanently guaranteed not to refer to any other message in + the mailbox. Unique identifiers are assigned in a strictly ascending + fashion in the mailbox; as each message is added to the mailbox it is + assigned a higher UID than the message(s) which were added + previously. + + Unlike message sequence numbers, unique identifiers are not + necessarily contiguous. Unique identifiers also persist across + sessions. This permits a client to resynchronize its state from a + previous session with the server (e.g. disconnected or offline access + clients); this is discussed further in [IMAP-DISC]. + + Associated with every mailbox is a unique identifier validity value, + which is sent in an UIDVALIDITY response code in an OK untagged + response at mailbox selection time. If unique identifiers from an + earlier session fail to persist to this session, the unique + identifier validity value MUST be greater than the one used in the + earlier session. + + Note: Unique identifiers MUST be strictly ascending in the mailbox + at all times. If the physical message store is re-ordered by a + non-IMAP agent, this requires that the unique identifiers in the + mailbox be regenerated, since the former unique identifers are no + longer strictly ascending as a result of the re-ordering. Another + instance in which unique identifiers are regenerated is if the + message store has no mechanism to store unique identifiers. + Although this specification recognizes that this may be + unavoidable in certain server environments, it STRONGLY ENCOURAGES + message store implementation techniques that avoid this problem. + + Another cause of non-persistance is if the mailbox is deleted and + a new mailbox with the same name is created at a later date, Since + the name is the same, a client may not know that this is a new + mailbox unless the unique identifier validity is different. A + good value to use for the unique identifier validity value is a + 32-bit representation of the creation date/time of the mailbox. + It is alright to use a constant such as 1, but only if it + guaranteed that unique identifiers will never be reused, even in + the case of a mailbox being deleted (or renamed) and a new mailbox + by the same name created at some future time. + + The unique identifier of a message MUST NOT change during the + session, and SHOULD NOT change between sessions. However, if it is + not possible to preserve the unique identifier of a message in a + subsequent session, each subsequent session MUST have a new unique + identifier validity value that is larger than any that was used + previously. + + + + +Crispin Standards Track [Page 8] + +RFC 2060 IMAP4rev1 December 1996 + + +2.3.1.2. Message Sequence Number Message Attribute + + A relative position from 1 to the number of messages in the mailbox. + This position MUST be ordered by ascending unique identifier. As + each new message is added, it is assigned a message sequence number + that is 1 higher than the number of messages in the mailbox before + that new message was added. + + Message sequence numbers can be reassigned during the session. For + example, when a message is permanently removed (expunged) from the + mailbox, the message sequence number for all subsequent messages is + decremented. Similarly, a new message can be assigned a message + sequence number that was once held by some other message prior to an + expunge. + + In addition to accessing messages by relative position in the + mailbox, message sequence numbers can be used in mathematical + calculations. For example, if an untagged "EXISTS 11" is received, + and previously an untagged "8 EXISTS" was received, three new + messages have arrived with message sequence numbers of 9, 10, and 11. + Another example; if message 287 in a 523 message mailbox has UID + 12345, there are exactly 286 messages which have lesser UIDs and 236 + messages which have greater UIDs. + +2.3.2. Flags Message Attribute + + A list of zero or more named tokens associated with the message. A + flag is set by its addition to this list, and is cleared by its + removal. There are two types of flags in IMAP4rev1. A flag of + either type may be permanent or session-only. + + A system flag is a flag name that is pre-defined in this + specification. All system flags begin with "\". Certain system + flags (\Deleted and \Seen) have special semantics described + elsewhere. The currently-defined system flags are: + + \Seen Message has been read + + \Answered Message has been answered + + \Flagged Message is "flagged" for urgent/special attention + + \Deleted Message is "deleted" for removal by later EXPUNGE + + \Draft Message has not completed composition (marked as a + draft). + + + + + +Crispin Standards Track [Page 9] + +RFC 2060 IMAP4rev1 December 1996 + + + \Recent Message is "recently" arrived in this mailbox. This + session is the first session to have been notified + about this message; subsequent sessions will not see + \Recent set for this message. This flag can not be + altered by the client. + + If it is not possible to determine whether or not + this session is the first session to be notified + about a message, then that message SHOULD be + considered recent. + + If multiple connections have the same mailbox + selected simultaneously, it is undefined which of + these connections will see newly-arrives messages + with \Recent set and which will see it without + \Recent set. + + A keyword is defined by the server implementation. Keywords do + not begin with "\". Servers MAY permit the client to define new + keywords in the mailbox (see the description of the + PERMANENTFLAGS response code for more information). + + A flag may be permanent or session-only on a per-flag basis. + Permanent flags are those which the client can add or remove + from the message flags permanently; that is, subsequent sessions + will see any change in permanent flags. Changes to session + flags are valid only in that session. + + Note: The \Recent system flag is a special case of a + session flag. \Recent can not be used as an argument in a + STORE command, and thus can not be changed at all. + +2.3.3. Internal Date Message Attribute + + The internal date and time of the message on the server. This is not + the date and time in the [RFC-822] header, but rather a date and time + which reflects when the message was received. In the case of + messages delivered via [SMTP], this SHOULD be the date and time of + final delivery of the message as defined by [SMTP]. In the case of + messages delivered by the IMAP4rev1 COPY command, this SHOULD be the + internal date and time of the source message. In the case of + messages delivered by the IMAP4rev1 APPEND command, this SHOULD be + the date and time as specified in the APPEND command description. + All other cases are implementation defined. + + + + + + + +Crispin Standards Track [Page 10] + +RFC 2060 IMAP4rev1 December 1996 + + +2.3.4. [RFC-822] Size Message Attribute + + The number of octets in the message, as expressed in [RFC-822] + format. + +2.3.5. Envelope Structure Message Attribute + + A parsed representation of the [RFC-822] envelope information (not to + be confused with an [SMTP] envelope) of the message. + +2.3.6. Body Structure Message Attribute + + A parsed representation of the [MIME-IMB] body structure information + of the message. + +2.4. Message Texts + + In addition to being able to fetch the full [RFC-822] text of a + message, IMAP4rev1 permits the fetching of portions of the full + message text. Specifically, it is possible to fetch the [RFC-822] + message header, [RFC-822] message body, a [MIME-IMB] body part, or a + [MIME-IMB] header. + +3. State and Flow Diagram + + An IMAP4rev1 server is in one of four states. Most commands are + valid in only certain states. It is a protocol error for the client + to attempt a command while the command is in an inappropriate state. + In this case, a server will respond with a BAD or NO (depending upon + server implementation) command completion result. + +3.1. Non-Authenticated State + + In non-authenticated state, the client MUST supply authentication + credentials before most commands will be permitted. This state is + entered when a connection starts unless the connection has been pre- + authenticated. + +3.2. Authenticated State + + In authenticated state, the client is authenticated and MUST select a + mailbox to access before commands that affect messages will be + permitted. This state is entered when a pre-authenticated connection + starts, when acceptable authentication credentials have been + provided, or after an error in selecting a mailbox. + + + + + + +Crispin Standards Track [Page 11] + +RFC 2060 IMAP4rev1 December 1996 + + +3.3. Selected State + + In selected state, a mailbox has been selected to access. This state + is entered when a mailbox has been successfully selected. + +3.4. Logout State + + In logout state, the connection is being terminated, and the server + will close the connection. This state can be entered as a result of + a client request or by unilateral server decision. + + +--------------------------------------+ + |initial connection and server greeting| + +--------------------------------------+ + || (1) || (2) || (3) + VV || || + +-----------------+ || || + |non-authenticated| || || + +-----------------+ || || + || (7) || (4) || || + || VV VV || + || +----------------+ || + || | authenticated |<=++ || + || +----------------+ || || + || || (7) || (5) || (6) || + || || VV || || + || || +--------+ || || + || || |selected|==++ || + || || +--------+ || + || || || (7) || + VV VV VV VV + +--------------------------------------+ + | logout and close connection | + +--------------------------------------+ + + (1) connection without pre-authentication (OK greeting) + (2) pre-authenticated connection (PREAUTH greeting) + (3) rejected connection (BYE greeting) + (4) successful LOGIN or AUTHENTICATE command + (5) successful SELECT or EXAMINE command + (6) CLOSE command, or failed SELECT or EXAMINE command + (7) LOGOUT command, server shutdown, or connection closed + +4. Data Formats + + IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can + be in one of several forms: atom, number, string, parenthesized list, + or NIL. + + + +Crispin Standards Track [Page 12] + +RFC 2060 IMAP4rev1 December 1996 + + +4.1. Atom + + An atom consists of one or more non-special characters. + +4.2. Number + + A number consists of one or more digit characters, and represents a + numeric value. + +4.3. String + + A string is in one of two forms: literal and quoted string. The + literal form is the general form of string. The quoted string form + is an alternative that avoids the overhead of processing a literal at + the cost of limitations of characters that can be used in a quoted + string. + + A literal is a sequence of zero or more octets (including CR and LF), + prefix-quoted with an octet count in the form of an open brace ("{"), + the number of octets, close brace ("}"), and CRLF. In the case of + literals transmitted from server to client, the CRLF is immediately + followed by the octet data. In the case of literals transmitted from + client to server, the client MUST wait to receive a command + continuation request (described later in this document) before + sending the octet data (and the remainder of the command). + + A quoted string is a sequence of zero or more 7-bit characters, + excluding CR and LF, with double quote (<">) characters at each end. + + The empty string is represented as either "" (a quoted string with + zero characters between double quotes) or as {0} followed by CRLF (a + literal with an octet count of 0). + + Note: Even if the octet count is 0, a client transmitting a + literal MUST wait to receive a command continuation request. + +4.3.1. 8-bit and Binary Strings + + 8-bit textual and binary mail is supported through the use of a + [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY + transmit 8-bit or multi-octet characters in literals, but SHOULD do + so only when the [CHARSET] is identified. + + + + + + + + + +Crispin Standards Track [Page 13] + +RFC 2060 IMAP4rev1 December 1996 + + + Although a BINARY body encoding is defined, unencoded binary strings + are not permitted. A "binary string" is any string with NUL + characters. Implementations MUST encode binary data into a textual + form such as BASE64 before transmitting the data. A string with an + excessive amount of CTL characters MAY also be considered to be + binary. + +4.4. Parenthesized List + + Data structures are represented as a "parenthesized list"; a sequence + of data items, delimited by space, and bounded at each end by + parentheses. A parenthesized list can contain other parenthesized + lists, using multiple levels of parentheses to indicate nesting. + + The empty list is represented as () -- a parenthesized list with no + members. + +4.5. NIL + + The special atom "NIL" represents the non-existence of a particular + data item that is represented as a string or parenthesized list, as + distinct from the empty string "" or the empty parenthesized list (). + +5. Operational Considerations + +5.1. Mailbox Naming + + The interpretation of mailbox names is implementation-dependent. + However, the case-insensitive mailbox name INBOX is a special name + reserved to mean "the primary mailbox for this user on this server". + +5.1.1. Mailbox Hierarchy Naming + + If it is desired to export hierarchical mailbox names, mailbox names + MUST be left-to-right hierarchical using a single character to + separate levels of hierarchy. The same hierarchy separator character + is used for all levels of hierarchy within a single name. + +5.1.2. Mailbox Namespace Naming Convention + + By convention, the first hierarchical element of any mailbox name + which begins with "#" identifies the "namespace" of the remainder of + the name. This makes it possible to disambiguate between different + types of mailbox stores, each of which have their own namespaces. + + + + + + + +Crispin Standards Track [Page 14] + +RFC 2060 IMAP4rev1 December 1996 + + + For example, implementations which offer access to USENET + newsgroups MAY use the "#news" namespace to partition the USENET + newsgroup namespace from that of other mailboxes. Thus, the + comp.mail.misc newsgroup would have an mailbox name of + "#news.comp.mail.misc", and the name "comp.mail.misc" could refer + to a different object (e.g. a user's private mailbox). + +5.1.3. Mailbox International Naming Convention + + By convention, international mailbox names are specified using a + modified version of the UTF-7 encoding described in [UTF-7]. The + purpose of these modifications is to correct the following problems + with UTF-7: + + 1) UTF-7 uses the "+" character for shifting; this conflicts with + the common use of "+" in mailbox names, in particular USENET + newsgroup names. + + 2) UTF-7's encoding is BASE64 which uses the "/" character; this + conflicts with the use of "/" as a popular hierarchy delimiter. + + 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with + the use of "\" as a popular hierarchy delimiter. + + 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with + the use of "~" in some servers as a home directory indicator. + + 5) UTF-7 permits multiple alternate forms to represent the same + string; in particular, printable US-ASCII chararacters can be + represented in encoded form. + + In modified UTF-7, printable US-ASCII characters except for "&" + represent themselves; that is, characters with octet values 0x20-0x25 + and 0x27-0x7e. The character "&" (0x26) is represented by the two- + octet sequence "&-". + + All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all + Unicode 16-bit octets) are represented in modified BASE64, with a + further modification from [UTF-7] that "," is used instead of "/". + Modified BASE64 MUST NOT be used to represent any printing US-ASCII + character which can represent itself. + + "&" is used to shift to modified BASE64 and "-" to shift back to US- + ASCII. All names start in US-ASCII, and MUST end in US-ASCII (that + is, a name that ends with a Unicode 16-bit octet MUST end with a "- + "). + + + + + +Crispin Standards Track [Page 15] + +RFC 2060 IMAP4rev1 December 1996 + + + For example, here is a mailbox name which mixes English, Japanese, + and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw- + +5.2. Mailbox Size and Message Status Updates + + At any time, a server can send data that the client did not request. + Sometimes, such behavior is REQUIRED. For example, agents other than + the server MAY add messages to the mailbox (e.g. new mail delivery), + change the flags of message in the mailbox (e.g. simultaneous access + to the same mailbox by multiple agents), or even remove messages from + the mailbox. A server MUST send mailbox size updates automatically + if a mailbox size change is observed during the processing of a + command. A server SHOULD send message flag updates automatically, + without requiring the client to request such updates explicitly. + Special rules exist for server notification of a client about the + removal of messages to prevent synchronization errors; see the + description of the EXPUNGE response for more detail. + + Regardless of what implementation decisions a client makes on + remembering data from the server, a client implementation MUST record + mailbox size updates. It MUST NOT assume that any command after + initial mailbox selection will return the size of the mailbox. + +5.3. Response when no Command in Progress + + Server implementations are permitted to send an untagged response + (except for EXPUNGE) while there is no command in progress. Server + implementations that send such responses MUST deal with flow control + considerations. Specifically, they MUST either (1) verify that the + size of the data does not exceed the underlying transport's available + window size, or (2) use non-blocking writes. + +5.4. Autologout Timer + + If a server has an inactivity autologout timer, that timer MUST be of + at least 30 minutes' duration. The receipt of ANY command from the + client during that interval SHOULD suffice to reset the autologout + timer. + + + + + + + + + + + + + +Crispin Standards Track [Page 16] + +RFC 2060 IMAP4rev1 December 1996 + + +5.5. Multiple Commands in Progress + + The client MAY send another command without waiting for the + completion result response of a command, subject to ambiguity rules + (see below) and flow control constraints on the underlying data + stream. Similarly, a server MAY begin processing another command + before processing the current command to completion, subject to + ambiguity rules. However, any command continuation request responses + and command continuations MUST be negotiated before any subsequent + command is initiated. + + The exception is if an ambiguity would result because of a command + that would affect the results of other commands. Clients MUST NOT + send multiple commands without waiting if an ambiguity would result. + If the server detects a possible ambiguity, it MUST execute commands + to completion in the order given by the client. + + The most obvious example of ambiguity is when a command would affect + the results of another command; for example, a FETCH of a message's + flags and a STORE of that same message's flags. + + A non-obvious ambiguity occurs with commands that permit an untagged + EXPUNGE response (commands other than FETCH, STORE, and SEARCH), + since an untagged EXPUNGE response can invalidate sequence numbers in + a subsequent command. This is not a problem for FETCH, STORE, or + SEARCH commands because servers are prohibited from sending EXPUNGE + responses while any of those commands are in progress. Therefore, if + the client sends any command other than FETCH, STORE, or SEARCH, it + MUST wait for a response before sending a command with message + sequence numbers. + + For example, the following non-waiting command sequences are invalid: + + FETCH + NOOP + STORE + STORE + COPY + FETCH + COPY + COPY + CHECK + FETCH + + The following are examples of valid non-waiting command sequences: + + FETCH + STORE + SEARCH + CHECK + STORE + COPY + EXPUNGE + +6. Client Commands + + IMAP4rev1 commands are described in this section. Commands are + organized by the state in which the command is permitted. Commands + which are permitted in multiple states are listed in the minimum + + + +Crispin Standards Track [Page 17] + +RFC 2060 IMAP4rev1 December 1996 + + + permitted state (for example, commands valid in authenticated and + selected state are listed in the authenticated state commands). + + Command arguments, identified by "Arguments:" in the command + descriptions below, are described by function, not by syntax. The + precise syntax of command arguments is described in the Formal Syntax + section. + + Some commands cause specific server responses to be returned; these + are identified by "Responses:" in the command descriptions below. + See the response descriptions in the Responses section for + information on these responses, and the Formal Syntax section for the + precise syntax of these responses. It is possible for server data to + be transmitted as a result of any command; thus, commands that do not + specifically require server data specify "no specific responses for + this command" instead of "none". + + The "Result:" in the command description refers to the possible + tagged status responses to a command, and any special interpretation + of these status responses. + +6.1. Client Commands - Any State + + The following commands are valid in any state: CAPABILITY, NOOP, and + LOGOUT. + +6.1.1. CAPABILITY Command + + Arguments: none + + Responses: REQUIRED untagged response: CAPABILITY + + Result: OK - capability completed + BAD - command unknown or arguments invalid + + The CAPABILITY command requests a listing of capabilities that the + server supports. The server MUST send a single untagged + CAPABILITY response with "IMAP4rev1" as one of the listed + capabilities before the (tagged) OK response. This listing of + capabilities is not dependent upon connection state or user. It + is therefore not necessary to issue a CAPABILITY command more than + once in a connection. + + + + + + + + + +Crispin Standards Track [Page 18] + +RFC 2060 IMAP4rev1 December 1996 + + + A capability name which begins with "AUTH=" indicates that the + server supports that particular authentication mechanism. All + such names are, by definition, part of this specification. For + example, the authorization capability for an experimental + "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not + "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP". + + Other capability names refer to extensions, revisions, or + amendments to this specification. See the documentation of the + CAPABILITY response for additional information. No capabilities, + beyond the base IMAP4rev1 set defined in this specification, are + enabled without explicit client action to invoke the capability. + + See the section entitled "Client Commands - + Experimental/Expansion" for information about the form of site or + implementation-specific capabilities. + + Example: C: abcd CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 + S: abcd OK CAPABILITY completed + +6.1.2. NOOP Command + + Arguments: none + + Responses: no specific responses for this command (but see below) + + Result: OK - noop completed + BAD - command unknown or arguments invalid + + The NOOP command always succeeds. It does nothing. + + Since any command can return a status update as untagged data, the + NOOP command can be used as a periodic poll for new messages or + message status updates during a period of inactivity. The NOOP + command can also be used to reset any inactivity autologout timer + on the server. + + Example: C: a002 NOOP + S: a002 OK NOOP completed + . . . + C: a047 NOOP + S: * 22 EXPUNGE + S: * 23 EXISTS + S: * 3 RECENT + S: * 14 FETCH (FLAGS (\Seen \Deleted)) + S: a047 OK NOOP completed + + + + +Crispin Standards Track [Page 19] + +RFC 2060 IMAP4rev1 December 1996 + + +6.1.3. LOGOUT Command + + Arguments: none + + Responses: REQUIRED untagged response: BYE + + Result: OK - logout completed + BAD - command unknown or arguments invalid + + The LOGOUT command informs the server that the client is done with + the connection. The server MUST send a BYE untagged response + before the (tagged) OK response, and then close the network + connection. + + Example: C: A023 LOGOUT + S: * BYE IMAP4rev1 Server logging out + S: A023 OK LOGOUT completed + (Server and client then close the connection) + +6.2. Client Commands - Non-Authenticated State + + In non-authenticated state, the AUTHENTICATE or LOGIN command + establishes authentication and enter authenticated state. The + AUTHENTICATE command provides a general mechanism for a variety of + authentication techniques, whereas the LOGIN command uses the + traditional user name and plaintext password pair. + + Server implementations MAY allow non-authenticated access to certain + mailboxes. The convention is to use a LOGIN command with the userid + "anonymous". A password is REQUIRED. It is implementation-dependent + what requirements, if any, are placed on the password and what access + restrictions are placed on anonymous users. + + Once authenticated (including as anonymous), it is not possible to + re-enter non-authenticated state. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in non-authenticated state: + AUTHENTICATE and LOGIN. + + + + + + + + + + + + +Crispin Standards Track [Page 20] + +RFC 2060 IMAP4rev1 December 1996 + + +6.2.1. AUTHENTICATE Command + + Arguments: authentication mechanism name + + Responses: continuation data can be requested + + Result: OK - authenticate completed, now in authenticated state + NO - authenticate failure: unsupported authentication + mechanism, credentials rejected + BAD - command unknown or arguments invalid, + authentication exchange cancelled + + The AUTHENTICATE command indicates an authentication mechanism, + such as described in [IMAP-AUTH], to the server. If the server + supports the requested authentication mechanism, it performs an + authentication protocol exchange to authenticate and identify the + client. It MAY also negotiate an OPTIONAL protection mechanism + for subsequent protocol interactions. If the requested + authentication mechanism is not supported, the server SHOULD + reject the AUTHENTICATE command by sending a tagged NO response. + + The authentication protocol exchange consists of a series of + server challenges and client answers that are specific to the + authentication mechanism. A server challenge consists of a + command continuation request response with the "+" token followed + by a BASE64 encoded string. The client answer consists of a line + consisting of a BASE64 encoded string. If the client wishes to + cancel an authentication exchange, it issues a line with a single + "*". If the server receives such an answer, it MUST reject the + AUTHENTICATE command by sending a tagged BAD response. + + A protection mechanism provides integrity and privacy protection + to the connection. If a protection mechanism is negotiated, it is + applied to all subsequent data sent over the connection. The + protection mechanism takes effect immediately following the CRLF + that concludes the authentication exchange for the client, and the + CRLF of the tagged OK response for the server. Once the + protection mechanism is in effect, the stream of command and + response octets is processed into buffers of ciphertext. Each + buffer is transferred over the connection as a stream of octets + prepended with a four octet field in network byte order that + represents the length of the following data. The maximum + ciphertext buffer length is defined by the protection mechanism. + + Authentication mechanisms are OPTIONAL. Protection mechanisms are + also OPTIONAL; an authentication mechanism MAY be implemented + without any protection mechanism. If an AUTHENTICATE command + fails with a NO response, the client MAY try another + + + +Crispin Standards Track [Page 21] + +RFC 2060 IMAP4rev1 December 1996 + + + authentication mechanism by issuing another AUTHENTICATE command, + or MAY attempt to authenticate by using the LOGIN command. In + other words, the client MAY request authentication types in + decreasing order of preference, with the LOGIN command as a last + resort. + + Example: S: * OK KerberosV4 IMAP4rev1 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + AmFYig== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: + or//EoAADZI= + C: DiAF5A4gA+oOIALuBkAAmw== + S: A001 OK Kerberos V4 authentication successful + + Note: the line breaks in the first client answer are for editorial + clarity and are not in real authenticators. + +6.2.2. LOGIN Command + + Arguments: user name + password + + Responses: no specific responses for this command + + Result: OK - login completed, now in authenticated state + NO - login failure: user name or password rejected + BAD - command unknown or arguments invalid + + The LOGIN command identifies the client to the server and carries + the plaintext password authenticating this user. + + Example: C: a001 LOGIN SMITH SESAME + S: a001 OK LOGIN completed + +6.3. Client Commands - Authenticated State + + In authenticated state, commands that manipulate mailboxes as atomic + entities are permitted. Of these commands, the SELECT and EXAMINE + commands will select a mailbox for access and enter selected state. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in authenticated state: SELECT, + EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, + STATUS, and APPEND. + + + + + +Crispin Standards Track [Page 22] + +RFC 2060 IMAP4rev1 December 1996 + + +6.3.1. SELECT Command + + Arguments: mailbox name + + Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT + OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS + + Result: OK - select completed, now in selected state + NO - select failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The SELECT command selects a mailbox so that messages in the + mailbox can be accessed. Before returning an OK to the client, + the server MUST send the following untagged data to the client: + + FLAGS Defined flags in the mailbox. See the description + of the FLAGS response for more detail. + + EXISTS The number of messages in the mailbox. See the + description of the EXISTS response for more detail. + + RECENT The number of messages with the \Recent flag set. + See the description of the RECENT response for more + detail. + + OK [UIDVALIDITY ] + The unique identifier validity value. See the + description of the UID command for more detail. + + to define the initial state of the mailbox at the client. + + The server SHOULD also send an UNSEEN response code in an OK + untagged response, indicating the message sequence number of the + first unseen message in the mailbox. + + If the client can not change the permanent state of one or more of + the flags listed in the FLAGS untagged response, the server SHOULD + send a PERMANENTFLAGS response code in an OK untagged response, + listing the flags that the client can change permanently. + + Only one mailbox can be selected at a time in a connection; + simultaneous access to multiple mailboxes requires multiple + connections. The SELECT command automatically deselects any + currently selected mailbox before attempting the new selection. + Consequently, if a mailbox is selected and a SELECT command that + fails is attempted, no mailbox is selected. + + + + +Crispin Standards Track [Page 23] + +RFC 2060 IMAP4rev1 December 1996 + + + If the client is permitted to modify the mailbox, the server + SHOULD prefix the text of the tagged OK response with the + "[READ-WRITE]" response code. + + If the client is not permitted to modify the mailbox but is + permitted read access, the mailbox is selected as read-only, and + the server MUST prefix the text of the tagged OK response to + SELECT with the "[READ-ONLY]" response code. Read-only access + through SELECT differs from the EXAMINE command in that certain + read-only mailboxes MAY permit the change of permanent state on a + per-user (as opposed to global) basis. Netnews messages marked in + a server-based .newsrc file are an example of such per-user + permanent state that can be modified with read-only mailboxes. + + Example: C: A142 SELECT INBOX + S: * 172 EXISTS + S: * 1 RECENT + S: * OK [UNSEEN 12] Message 12 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited + S: A142 OK [READ-WRITE] SELECT completed + +6.3.2. EXAMINE Command + + Arguments: mailbox name + + Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT + OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS + + Result: OK - examine completed, now in selected state + NO - examine failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The EXAMINE command is identical to SELECT and returns the same + output; however, the selected mailbox is identified as read-only. + No changes to the permanent state of the mailbox, including + per-user state, are permitted. + + + + + + + + + + + + +Crispin Standards Track [Page 24] + +RFC 2060 IMAP4rev1 December 1996 + + + The text of the tagged OK response to the EXAMINE command MUST + begin with the "[READ-ONLY]" response code. + + Example: C: A932 EXAMINE blurdybloop + S: * 17 EXISTS + S: * 2 RECENT + S: * OK [UNSEEN 8] Message 8 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS ()] No permanent flags permitted + S: A932 OK [READ-ONLY] EXAMINE completed + +6.3.3. CREATE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - create completed + NO - create failure: can't create mailbox with that name + BAD - command unknown or arguments invalid + + The CREATE command creates a mailbox with the given name. An OK + response is returned only if a new mailbox with that name has been + created. It is an error to attempt to create INBOX or a mailbox + with a name that refers to an extant mailbox. Any error in + creation will return a tagged NO response. + + If the mailbox name is suffixed with the server's hierarchy + separator character (as returned from the server by a LIST + command), this is a declaration that the client intends to create + mailbox names under this name in the hierarchy. Server + implementations that do not require this declaration MUST ignore + it. + + If the server's hierarchy separator character appears elsewhere in + the name, the server SHOULD create any superior hierarchical names + that are needed for the CREATE command to complete successfully. + In other words, an attempt to create "foo/bar/zap" on a server in + which "/" is the hierarchy separator character SHOULD create foo/ + and foo/bar/ if they do not already exist. + + If a new mailbox is created with the same name as a mailbox which + was deleted, its unique identifiers MUST be greater than any + unique identifiers used in the previous incarnation of the mailbox + UNLESS the new incarnation has a different unique identifier + validity value. See the description of the UID command for more + detail. + + + +Crispin Standards Track [Page 25] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A003 CREATE owatagusiam/ + S: A003 OK CREATE completed + C: A004 CREATE owatagusiam/blurdybloop + S: A004 OK CREATE completed + + Note: the interpretation of this example depends on whether "/" + was returned as the hierarchy separator from LIST. If "/" is the + hierarchy separator, a new level of hierarchy named "owatagusiam" + with a member called "blurdybloop" is created. Otherwise, two + mailboxes at the same hierarchy level are created. + +6.3.4. DELETE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - delete completed + NO - delete failure: can't delete mailbox with that name + BAD - command unknown or arguments invalid + + The DELETE command permanently removes the mailbox with the given + name. A tagged OK response is returned only if the mailbox has + been deleted. It is an error to attempt to delete INBOX or a + mailbox name that does not exist. + + The DELETE command MUST NOT remove inferior hierarchical names. + For example, if a mailbox "foo" has an inferior "foo.bar" + (assuming "." is the hierarchy delimiter character), removing + "foo" MUST NOT remove "foo.bar". It is an error to attempt to + delete a name that has inferior hierarchical names and also has + the \Noselect mailbox name attribute (see the description of the + LIST response for more details). + + It is permitted to delete a name that has inferior hierarchical + names and does not have the \Noselect mailbox name attribute. In + this case, all messages in that mailbox are removed, and the name + will acquire the \Noselect mailbox name attribute. + + The value of the highest-used unique identifier of the deleted + mailbox MUST be preserved so that a new mailbox created with the + same name will not reuse the identifiers of the former + incarnation, UNLESS the new incarnation has a different unique + identifier validity value. See the description of the UID command + for more detail. + + + + + + +Crispin Standards Track [Page 26] + +RFC 2060 IMAP4rev1 December 1996 + + + Examples: C: A682 LIST "" * + S: * LIST () "/" blurdybloop + S: * LIST (\Noselect) "/" foo + S: * LIST () "/" foo/bar + S: A682 OK LIST completed + C: A683 DELETE blurdybloop + S: A683 OK DELETE completed + C: A684 DELETE foo + S: A684 NO Name "foo" has inferior hierarchical names + C: A685 DELETE foo/bar + S: A685 OK DELETE Completed + C: A686 LIST "" * + S: * LIST (\Noselect) "/" foo + S: A686 OK LIST completed + C: A687 DELETE foo + S: A687 OK DELETE Completed + + + C: A82 LIST "" * + S: * LIST () "." blurdybloop + S: * LIST () "." foo + S: * LIST () "." foo.bar + S: A82 OK LIST completed + C: A83 DELETE blurdybloop + S: A83 OK DELETE completed + C: A84 DELETE foo + S: A84 OK DELETE Completed + C: A85 LIST "" * + S: * LIST () "." foo.bar + S: A85 OK LIST completed + C: A86 LIST "" % + S: * LIST (\Noselect) "." foo + S: A86 OK LIST completed + +6.3.5. RENAME Command + + Arguments: existing mailbox name + new mailbox name + + Responses: no specific responses for this command + + Result: OK - rename completed + NO - rename failure: can't rename mailbox with that name, + can't rename to mailbox with that name + BAD - command unknown or arguments invalid + + The RENAME command changes the name of a mailbox. A tagged OK + response is returned only if the mailbox has been renamed. It is + + + +Crispin Standards Track [Page 27] + +RFC 2060 IMAP4rev1 December 1996 + + + an error to attempt to rename from a mailbox name that does not + exist or to a mailbox name that already exists. Any error in + renaming will return a tagged NO response. + + If the name has inferior hierarchical names, then the inferior + hierarchical names MUST also be renamed. For example, a rename of + "foo" to "zap" will rename "foo/bar" (assuming "/" is the + hierarchy delimiter character) to "zap/bar". + + The value of the highest-used unique identifier of the old mailbox + name MUST be preserved so that a new mailbox created with the same + name will not reuse the identifiers of the former incarnation, + UNLESS the new incarnation has a different unique identifier + validity value. See the description of the UID command for more + detail. + + Renaming INBOX is permitted, and has special behavior. It moves + all messages in INBOX to a new mailbox with the given name, + leaving INBOX empty. If the server implementation supports + inferior hierarchical names of INBOX, these are unaffected by a + rename of INBOX. + + Examples: C: A682 LIST "" * + S: * LIST () "/" blurdybloop + S: * LIST (\Noselect) "/" foo + S: * LIST () "/" foo/bar + S: A682 OK LIST completed + C: A683 RENAME blurdybloop sarasoop + S: A683 OK RENAME completed + C: A684 RENAME foo zowie + S: A684 OK RENAME Completed + C: A685 LIST "" * + S: * LIST () "/" sarasoop + S: * LIST (\Noselect) "/" zowie + S: * LIST () "/" zowie/bar + S: A685 OK LIST completed + + + + + + + + + + + + + + + +Crispin Standards Track [Page 28] + +RFC 2060 IMAP4rev1 December 1996 + + + C: Z432 LIST "" * + S: * LIST () "." INBOX + S: * LIST () "." INBOX.bar + S: Z432 OK LIST completed + C: Z433 RENAME INBOX old-mail + S: Z433 OK RENAME completed + C: Z434 LIST "" * + S: * LIST () "." INBOX + S: * LIST () "." INBOX.bar + S: * LIST () "." old-mail + S: Z434 OK LIST completed + +6.3.6. SUBSCRIBE Command + + Arguments: mailbox + + Responses: no specific responses for this command + + Result: OK - subscribe completed + NO - subscribe failure: can't subscribe to that name + BAD - command unknown or arguments invalid + + The SUBSCRIBE command adds the specified mailbox name to the + server's set of "active" or "subscribed" mailboxes as returned by + the LSUB command. This command returns a tagged OK response only + if the subscription is successful. + + A server MAY validate the mailbox argument to SUBSCRIBE to verify + that it exists. However, it MUST NOT unilaterally remove an + existing mailbox name from the subscription list even if a mailbox + by that name no longer exists. + + Note: this requirement is because some server sites may routinely + remove a mailbox with a well-known name (e.g. "system-alerts") + after its contents expire, with the intention of recreating it + when new contents are appropriate. + + Example: C: A002 SUBSCRIBE #news.comp.mail.mime + S: A002 OK SUBSCRIBE completed + + + + + + + + + + + + +Crispin Standards Track [Page 29] + +RFC 2060 IMAP4rev1 December 1996 + + +6.3.7. UNSUBSCRIBE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - unsubscribe completed + NO - unsubscribe failure: can't unsubscribe that name + BAD - command unknown or arguments invalid + + The UNSUBSCRIBE command removes the specified mailbox name from + the server's set of "active" or "subscribed" mailboxes as returned + by the LSUB command. This command returns a tagged OK response + only if the unsubscription is successful. + + Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime + S: A002 OK UNSUBSCRIBE completed + +6.3..8. LIST Command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LIST + + Result: OK - list completed + NO - list failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LIST command returns a subset of names from the complete set + of all names available to the client. Zero or more untagged LIST + replies are returned, containing the name attributes, hierarchy + delimiter, and name; see the description of the LIST reply for + more detail. + + The LIST command SHOULD return its data quickly, without undue + delay. For example, it SHOULD NOT go to excess trouble to + calculate \Marked or \Unmarked status or perform other processing; + if each name requires 1 second of processing, then a list of 1200 + names would take 20 minutes! + + An empty ("" string) reference name argument indicates that the + mailbox name is interpreted as by SELECT. The returned mailbox + names MUST match the supplied mailbox name pattern. A non-empty + reference name argument is the name of a mailbox or a level of + mailbox hierarchy, and indicates a context in which the mailbox + name is interpreted in an implementation-defined manner. + + + + +Crispin Standards Track [Page 30] + +RFC 2060 IMAP4rev1 December 1996 + + + An empty ("" string) mailbox name argument is a special request to + return the hierarchy delimiter and the root name of the name given + in the reference. The value returned as the root MAY be null if + the reference is non-rooted or is null. In all cases, the + hierarchy delimiter is returned. This permits a client to get the + hierarchy delimiter even when no mailboxes by that name currently + exist. + + The reference and mailbox name arguments are interpreted, in an + implementation-dependent fashion, into a canonical form that + represents an unambiguous left-to-right hierarchy. The returned + mailbox names will be in the interpreted form. + + Any part of the reference argument that is included in the + interpreted form SHOULD prefix the interpreted form. It SHOULD + also be in the same form as the reference name argument. This + rule permits the client to determine if the returned mailbox name + is in the context of the reference argument, or if something about + the mailbox argument overrode the reference argument. Without + this rule, the client would have to have knowledge of the server's + naming semantics including what characters are "breakouts" that + override a naming context. + + For example, here are some examples of how references and mailbox + names might be interpreted on a UNIX-based server: + + Reference Mailbox Name Interpretation + ------------ ------------ -------------- + ~smith/Mail/ foo.* ~smith/Mail/foo.* + archive/ % archive/% + #news. comp.mail.* #news.comp.mail.* + ~smith/Mail/ /usr/doc/foo /usr/doc/foo + archive/ ~fred/Mail/* ~fred/Mail/* + + The first three examples demonstrate interpretations in the + context of the reference argument. Note that "~smith/Mail" SHOULD + NOT be transformed into something like "/u2/users/smith/Mail", or + it would be impossible for the client to determine that the + interpretation was in the context of the reference. + + The character "*" is a wildcard, and matches zero or more + characters at this position. The character "%" is similar to "*", + but it does not match a hierarchy delimiter. If the "%" wildcard + is the last character of a mailbox name argument, matching levels + of hierarchy are also returned. If these levels of hierarchy are + not also selectable mailboxes, they are returned with the + \Noselect mailbox name attribute (see the description of the LIST + response for more details). + + + +Crispin Standards Track [Page 31] + +RFC 2060 IMAP4rev1 December 1996 + + + Server implementations are permitted to "hide" otherwise + accessible mailboxes from the wildcard characters, by preventing + certain characters or names from matching a wildcard in certain + situations. For example, a UNIX-based server might restrict the + interpretation of "*" so that an initial "/" character does not + match. + + The special name INBOX is included in the output from LIST, if + INBOX is supported by this server for this user and if the + uppercase string "INBOX" matches the interpreted reference and + mailbox name arguments with wildcards as described above. The + criteria for omitting INBOX is whether SELECT INBOX will return + failure; it is not relevant whether the user's real INBOX resides + on this or some other server. + + Example: C: A101 LIST "" "" + S: * LIST (\Noselect) "/" "" + S: A101 OK LIST Completed + C: A102 LIST #news.comp.mail.misc "" + S: * LIST (\Noselect) "." #news. + S: A102 OK LIST Completed + C: A103 LIST /usr/staff/jones "" + S: * LIST (\Noselect) "/" / + S: A103 OK LIST Completed + C: A202 LIST ~/Mail/ % + S: * LIST (\Noselect) "/" ~/Mail/foo + S: * LIST () "/" ~/Mail/meetings + S: A202 OK LIST completed + +6.3.9. LSUB Command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LSUB + + Result: OK - lsub completed + NO - lsub failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LSUB command returns a subset of names from the set of names + that the user has declared as being "active" or "subscribed". + Zero or more untagged LSUB replies are returned. The arguments to + LSUB are in the same form as those for LIST. + + A server MAY validate the subscribed names to see if they still + exist. If a name does not exist, it SHOULD be flagged with the + \Noselect attribute in the LSUB response. The server MUST NOT + + + +Crispin Standards Track [Page 32] + +RFC 2060 IMAP4rev1 December 1996 + + + unilaterally remove an existing mailbox name from the subscription + list even if a mailbox by that name no longer exists. + + Example: C: A002 LSUB "#news." "comp.mail.*" + S: * LSUB () "." #news.comp.mail.mime + S: * LSUB () "." #news.comp.mail.misc + S: A002 OK LSUB completed + +6.3.10. STATUS Command + + Arguments: mailbox name + status data item names + + Responses: untagged responses: STATUS + + Result: OK - status completed + NO - status failure: no status for that name + BAD - command unknown or arguments invalid + + The STATUS command requests the status of the indicated mailbox. + It does not change the currently selected mailbox, nor does it + affect the state of any messages in the queried mailbox (in + particular, STATUS MUST NOT cause messages to lose the \Recent + flag). + + The STATUS command provides an alternative to opening a second + IMAP4rev1 connection and doing an EXAMINE command on a mailbox to + query that mailbox's status without deselecting the current + mailbox in the first IMAP4rev1 connection. + + Unlike the LIST command, the STATUS command is not guaranteed to + be fast in its response. In some implementations, the server is + obliged to open the mailbox read-only internally to obtain certain + status information. Also unlike the LIST command, the STATUS + command does not accept wildcards. + + The currently defined status data items that can be requested are: + + MESSAGES The number of messages in the mailbox. + + RECENT The number of messages with the \Recent flag set. + + UIDNEXT The next UID value that will be assigned to a new + message in the mailbox. It is guaranteed that this + value will not change unless new messages are added + to the mailbox; and that it will change when new + messages are added even if those new messages are + subsequently expunged. + + + +Crispin Standards Track [Page 33] + +RFC 2060 IMAP4rev1 December 1996 + + + UIDVALIDITY The unique identifier validity value of the + mailbox. + + UNSEEN The number of messages which do not have the \Seen + flag set. + + + Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) + S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) + S: A042 OK STATUS completed + +6.3.11. APPEND Command + + Arguments: mailbox name + OPTIONAL flag parenthesized list + OPTIONAL date/time string + message literal + + Responses: no specific responses for this command + + Result: OK - append completed + NO - append error: can't append to that mailbox, error + in flags or date/time or message text + BAD - command unknown or arguments invalid + + The APPEND command appends the literal argument as a new message + to the end of the specified destination mailbox. This argument + SHOULD be in the format of an [RFC-822] message. 8-bit characters + are permitted in the message. A server implementation that is + unable to preserve 8-bit data properly MUST be able to reversibly + convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content + transfer encoding. + + Note: There MAY be exceptions, e.g. draft messages, in which + required [RFC-822] header lines are omitted in the message literal + argument to APPEND. The full implications of doing so MUST be + understood and carefully weighed. + + If a flag parenthesized list is specified, the flags SHOULD be set in + the resulting message; otherwise, the flag list of the resulting + message is set empty by default. + + If a date_time is specified, the internal date SHOULD be set in the + resulting message; otherwise, the internal date of the resulting + message is set to the current date and time by default. + + + + + + +Crispin Standards Track [Page 34] + +RFC 2060 IMAP4rev1 December 1996 + + + If the append is unsuccessful for any reason, the mailbox MUST be + restored to its state before the APPEND attempt; no partial appending + is permitted. + + If the destination mailbox does not exist, a server MUST return an + error, and MUST NOT automatically create the mailbox. Unless it is + certain that the destination mailbox can not be created, the server + MUST send the response code "[TRYCREATE]" as the prefix of the text + of the tagged NO response. This gives a hint to the client that it + can attempt a CREATE command and retry the APPEND if the CREATE is + successful. + + If the mailbox is currently selected, the normal new mail actions + SHOULD occur. Specifically, the server SHOULD notify the client + immediately via an untagged EXISTS response. If the server does not + do so, the client MAY issue a NOOP command (or failing that, a CHECK + command) after one or more APPEND commands. + + Example: C: A003 APPEND saved-messages (\Seen) {310} + C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) + C: From: Fred Foobar + C: Subject: afternoon meeting + C: To: mooch@owatagu.siam.edu + C: Message-Id: + C: MIME-Version: 1.0 + C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + C: + C: Hello Joe, do you think we can meet at 3:30 tomorrow? + C: + S: A003 OK APPEND completed + + Note: the APPEND command is not used for message delivery, because + it does not provide a mechanism to transfer [SMTP] envelope + information. + +6.4. Client Commands - Selected State + + In selected state, commands that manipulate messages in a mailbox are + permitted. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + and the authenticated state commands (SELECT, EXAMINE, CREATE, + DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and + APPEND), the following commands are valid in the selected state: + CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID. + + + + + + +Crispin Standards Track [Page 35] + +RFC 2060 IMAP4rev1 December 1996 + + +6.4.1. CHECK Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - check completed + BAD - command unknown or arguments invalid + + The CHECK command requests a checkpoint of the currently selected + mailbox. A checkpoint refers to any implementation-dependent + housekeeping associated with the mailbox (e.g. resolving the + server's in-memory state of the mailbox with the state on its + disk) that is not normally executed as part of each command. A + checkpoint MAY take a non-instantaneous amount of real time to + complete. If a server implementation has no such housekeeping + considerations, CHECK is equivalent to NOOP. + + There is no guarantee that an EXISTS untagged response will happen + as a result of CHECK. NOOP, not CHECK, SHOULD be used for new + mail polling. + + Example: C: FXXZ CHECK + S: FXXZ OK CHECK Completed + +6.4.2. CLOSE Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - close completed, now in authenticated state + NO - close failure: no mailbox selected + BAD - command unknown or arguments invalid + + The CLOSE command permanently removes from the currently selected + mailbox all messages that have the \Deleted flag set, and returns + to authenticated state from selected state. No untagged EXPUNGE + responses are sent. + + No messages are removed, and no error is given, if the mailbox is + selected by an EXAMINE command or is otherwise selected read-only. + + Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT + command MAY be issued without previously issuing a CLOSE command. + The SELECT, EXAMINE, and LOGOUT commands implicitly close the + currently selected mailbox without doing an expunge. However, + when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT + + + +Crispin Standards Track [Page 36] + +RFC 2060 IMAP4rev1 December 1996 + + + sequence is considerably faster than an EXPUNGE-LOGOUT or + EXPUNGE-SELECT because no untagged EXPUNGE responses (which the + client would probably ignore) are sent. + + Example: C: A341 CLOSE + S: A341 OK CLOSE completed + +6.4.3. EXPUNGE Command + + Arguments: none + + Responses: untagged responses: EXPUNGE + + Result: OK - expunge completed + NO - expunge failure: can't expunge (e.g. permission + denied) + BAD - command unknown or arguments invalid + + The EXPUNGE command permanently removes from the currently + selected mailbox all messages that have the \Deleted flag set. + Before returning an OK to the client, an untagged EXPUNGE response + is sent for each message that is removed. + + Example: C: A202 EXPUNGE + S: * 3 EXPUNGE + S: * 3 EXPUNGE + S: * 5 EXPUNGE + S: * 8 EXPUNGE + S: A202 OK EXPUNGE completed + + Note: in this example, messages 3, 4, 7, and 11 had the + \Deleted flag set. See the description of the EXPUNGE + response for further explanation. + +6.4.4. SEARCH Command + + Arguments: OPTIONAL [CHARSET] specification + searching criteria (one or more) + + Responses: REQUIRED untagged response: SEARCH + + Result: OK - search completed + NO - search error: can't search that [CHARSET] or + criteria + BAD - command unknown or arguments invalid + + + + + + +Crispin Standards Track [Page 37] + +RFC 2060 IMAP4rev1 December 1996 + + + The SEARCH command searches the mailbox for messages that match + the given searching criteria. Searching criteria consist of one + or more search keys. The untagged SEARCH response from the server + contains a listing of message sequence numbers corresponding to + those messages that match the searching criteria. + + When multiple keys are specified, the result is the intersection + (AND function) of all the messages that match those keys. For + example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers + to all deleted messages from Smith that were placed in the mailbox + since February 1, 1994. A search key can also be a parenthesized + list of one or more search keys (e.g. for use with the OR and NOT + keys). + + Server implementations MAY exclude [MIME-IMB] body parts with + terminal content media types other than TEXT and MESSAGE from + consideration in SEARCH matching. + + The OPTIONAL [CHARSET] specification consists of the word + "CHARSET" followed by a registered [CHARSET]. It indicates the + [CHARSET] of the strings that appear in the search criteria. + [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in + [RFC-822]/[MIME-IMB] headers, MUST be decoded before comparing + text in a [CHARSET] other than US-ASCII. US-ASCII MUST be + supported; other [CHARSET]s MAY be supported. If the server does + not support the specified [CHARSET], it MUST return a tagged NO + response (not a BAD). + + In all search keys that use strings, a message matches the key if + the string is a substring of the field. The matching is case- + insensitive. + + The defined search keys are as follows. Refer to the Formal + Syntax section for the precise syntactic definitions of the + arguments. + + Messages with message sequence numbers + corresponding to the specified message sequence + number set + + ALL All messages in the mailbox; the default initial + key for ANDing. + + ANSWERED Messages with the \Answered flag set. + + BCC Messages that contain the specified string in the + envelope structure's BCC field. + + + + +Crispin Standards Track [Page 38] + +RFC 2060 IMAP4rev1 December 1996 + + + BEFORE Messages whose internal date is earlier than the + specified date. + + BODY Messages that contain the specified string in the + body of the message. + + CC Messages that contain the specified string in the + envelope structure's CC field. + + DELETED Messages with the \Deleted flag set. + + DRAFT Messages with the \Draft flag set. + + FLAGGED Messages with the \Flagged flag set. + + FROM Messages that contain the specified string in the + envelope structure's FROM field. + + HEADER + Messages that have a header with the specified + field-name (as defined in [RFC-822]) and that + contains the specified string in the [RFC-822] + field-body. + + KEYWORD Messages with the specified keyword set. + + LARGER Messages with an [RFC-822] size larger than the + specified number of octets. + + NEW Messages that have the \Recent flag set but not the + \Seen flag. This is functionally equivalent to + "(RECENT UNSEEN)". + + NOT + Messages that do not match the specified search + key. + + OLD Messages that do not have the \Recent flag set. + This is functionally equivalent to "NOT RECENT" (as + opposed to "NOT NEW"). + + ON Messages whose internal date is within the + specified date. + + OR + Messages that match either search key. + + RECENT Messages that have the \Recent flag set. + + + +Crispin Standards Track [Page 39] + +RFC 2060 IMAP4rev1 December 1996 + + + SEEN Messages that have the \Seen flag set. + + SENTBEFORE + Messages whose [RFC-822] Date: header is earlier + than the specified date. + + SENTON Messages whose [RFC-822] Date: header is within the + specified date. + + SENTSINCE + Messages whose [RFC-822] Date: header is within or + later than the specified date. + + SINCE Messages whose internal date is within or later + than the specified date. + + SMALLER Messages with an [RFC-822] size smaller than the + specified number of octets. + + SUBJECT + Messages that contain the specified string in the + envelope structure's SUBJECT field. + + TEXT Messages that contain the specified string in the + header or body of the message. + + TO Messages that contain the specified string in the + envelope structure's TO field. + + UID + Messages with unique identifiers corresponding to + the specified unique identifier set. + + UNANSWERED Messages that do not have the \Answered flag set. + + UNDELETED Messages that do not have the \Deleted flag set. + + UNDRAFT Messages that do not have the \Draft flag set. + + UNFLAGGED Messages that do not have the \Flagged flag set. + + UNKEYWORD + Messages that do not have the specified keyword + set. + + UNSEEN Messages that do not have the \Seen flag set. + + + + + +Crispin Standards Track [Page 40] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" + S: * SEARCH 2 84 882 + S: A282 OK SEARCH completed + +6.4.5. FETCH Command + + Arguments: message set + message data item names + + Responses: untagged responses: FETCH + + Result: OK - fetch completed + NO - fetch error: can't fetch that data + BAD - command unknown or arguments invalid + + The FETCH command retrieves data associated with a message in the + mailbox. The data items to be fetched can be either a single atom + or a parenthesized list. + + The currently defined data items that can be fetched are: + + ALL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE) + + BODY Non-extensible form of BODYSTRUCTURE. + + BODY[
]<> + The text of a particular body section. The section + specification is a set of zero or more part + specifiers delimited by periods. A part specifier + is either a part number or one of the following: + HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and + TEXT. An empty section specification refers to the + entire message, including the header. + + Every message has at least one part number. + Non-[MIME-IMB] messages, and non-multipart + [MIME-IMB] messages with no encapsulated message, + only have a part 1. + + Multipart messages are assigned consecutive part + numbers, as they occur in the message. If a + particular part is of type message or multipart, + its parts MUST be indicated by a period followed by + the part number within that nested multipart part. + + + + + + +Crispin Standards Track [Page 41] + +RFC 2060 IMAP4rev1 December 1996 + + + A part of type MESSAGE/RFC822 also has nested part + numbers, referring to parts of the MESSAGE part's + body. + + The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and + TEXT part specifiers can be the sole part specifier + or can be prefixed by one or more numeric part + specifiers, provided that the numeric part + specifier refers to a part of type MESSAGE/RFC822. + The MIME part specifier MUST be prefixed by one or + more numeric part specifiers. + + The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT + part specifiers refer to the [RFC-822] header of + the message or of an encapsulated [MIME-IMT] + MESSAGE/RFC822 message. HEADER.FIELDS and + HEADER.FIELDS.NOT are followed by a list of + field-name (as defined in [RFC-822]) names, and + return a subset of the header. The subset returned + by HEADER.FIELDS contains only those header fields + with a field-name that matches one of the names in + the list; similarly, the subset returned by + HEADER.FIELDS.NOT contains only the header fields + with a non-matching field-name. The field-matching + is case-insensitive but otherwise exact. In all + cases, the delimiting blank line between the header + and the body is always included. + + The MIME part specifier refers to the [MIME-IMB] + header for this part. + + The TEXT part specifier refers to the text body of + the message, omitting the [RFC-822] header. + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 42] + +RFC 2060 IMAP4rev1 December 1996 + + + Here is an example of a complex message + with some of its part specifiers: + + HEADER ([RFC-822] header of the message) + TEXT MULTIPART/MIXED + 1 TEXT/PLAIN + 2 APPLICATION/OCTET-STREAM + 3 MESSAGE/RFC822 + 3.HEADER ([RFC-822] header of the message) + 3.TEXT ([RFC-822] text body of the message) + 3.1 TEXT/PLAIN + 3.2 APPLICATION/OCTET-STREAM + 4 MULTIPART/MIXED + 4.1 IMAGE/GIF + 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) + 4.2 MESSAGE/RFC822 + 4.2.HEADER ([RFC-822] header of the message) + 4.2.TEXT ([RFC-822] text body of the message) + 4.2.1 TEXT/PLAIN + 4.2.2 MULTIPART/ALTERNATIVE + 4.2.2.1 TEXT/PLAIN + 4.2.2.2 TEXT/RICHTEXT + + + It is possible to fetch a substring of the + designated text. This is done by appending an open + angle bracket ("<"), the octet position of the + first desired octet, a period, the maximum number + of octets desired, and a close angle bracket (">") + to the part specifier. If the starting octet is + beyond the end of the text, an empty string is + returned. + + Any partial fetch that attempts to read beyond the + end of the text is truncated as appropriate. A + partial fetch that starts at octet 0 is returned as + a partial fetch, even if this truncation happened. + + Note: this means that BODY[]<0.2048> of a + 1500-octet message will return BODY[]<0> + with a literal of size 1500, not BODY[]. + + Note: a substring fetch of a + HEADER.FIELDS or HEADER.FIELDS.NOT part + specifier is calculated after subsetting + the header. + + + + + +Crispin Standards Track [Page 43] + +RFC 2060 IMAP4rev1 December 1996 + + + The \Seen flag is implicitly set; if this causes + the flags to change they SHOULD be included as part + of the FETCH responses. + + BODY.PEEK[
]<> + An alternate form of BODY[
] that does not + implicitly set the \Seen flag. + + BODYSTRUCTURE The [MIME-IMB] body structure of the message. This + is computed by the server by parsing the [MIME-IMB] + header fields in the [RFC-822] header and + [MIME-IMB] headers. + + ENVELOPE The envelope structure of the message. This is + computed by the server by parsing the [RFC-822] + header into the component parts, defaulting various + fields as necessary. + + FAST Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE) + + FLAGS The flags that are set for this message. + + FULL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE BODY) + + INTERNALDATE The internal date of the message. + + RFC822 Functionally equivalent to BODY[], differing in the + syntax of the resulting untagged FETCH data (RFC822 + is returned). + + RFC822.HEADER Functionally equivalent to BODY.PEEK[HEADER], + differing in the syntax of the resulting untagged + FETCH data (RFC822.HEADER is returned). + + RFC822.SIZE The [RFC-822] size of the message. + + RFC822.TEXT Functionally equivalent to BODY[TEXT], differing in + the syntax of the resulting untagged FETCH data + (RFC822.TEXT is returned). + + UID The unique identifier for the message. + + + + + + + + +Crispin Standards Track [Page 44] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) + S: * 2 FETCH .... + S: * 3 FETCH .... + S: * 4 FETCH .... + S: A654 OK FETCH completed + +6.4.6. STORE Command + + Arguments: message set + message data item name + value for message data item + + Responses: untagged responses: FETCH + + Result: OK - store completed + NO - store error: can't store that data + BAD - command unknown or arguments invalid + + The STORE command alters data associated with a message in the + mailbox. Normally, STORE will return the updated value of the + data with an untagged FETCH response. A suffix of ".SILENT" in + the data item name prevents the untagged FETCH, and the server + SHOULD assume that the client has determined the updated value + itself or does not care about the updated value. + + Note: regardless of whether or not the ".SILENT" suffix was + used, the server SHOULD send an untagged FETCH response if a + change to a message's flags from an external source is + observed. The intent is that the status of the flags is + determinate without a race condition. + + The currently defined data items that can be stored are: + + FLAGS + Replace the flags for the message with the + argument. The new value of the flags are returned + as if a FETCH of those flags was done. + + FLAGS.SILENT + Equivalent to FLAGS, but without returning a new + value. + + +FLAGS + Add the argument to the flags for the message. The + new value of the flags are returned as if a FETCH + of those flags was done. + + + + + +Crispin Standards Track [Page 45] + +RFC 2060 IMAP4rev1 December 1996 + + + +FLAGS.SILENT + Equivalent to +FLAGS, but without returning a new + value. + + -FLAGS + Remove the argument from the flags for the message. + The new value of the flags are returned as if a + FETCH of those flags was done. + + -FLAGS.SILENT + Equivalent to -FLAGS, but without returning a new + value. + + Example: C: A003 STORE 2:4 +FLAGS (\Deleted) + S: * 2 FETCH FLAGS (\Deleted \Seen) + S: * 3 FETCH FLAGS (\Deleted) + S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) + S: A003 OK STORE completed + +6.4.7. COPY Command + + Arguments: message set + mailbox name + + Responses: no specific responses for this command + + Result: OK - copy completed + NO - copy error: can't copy those messages or to that + name + BAD - command unknown or arguments invalid + + The COPY command copies the specified message(s) to the end of the + specified destination mailbox. The flags and internal date of the + message(s) SHOULD be preserved in the copy. + + If the destination mailbox does not exist, a server SHOULD return + an error. It SHOULD NOT automatically create the mailbox. Unless + it is certain that the destination mailbox can not be created, the + server MUST send the response code "[TRYCREATE]" as the prefix of + the text of the tagged NO response. This gives a hint to the + client that it can attempt a CREATE command and retry the COPY if + the CREATE is successful. + + + + + + + + + +Crispin Standards Track [Page 46] + +RFC 2060 IMAP4rev1 December 1996 + + + If the COPY command is unsuccessful for any reason, server + implementations MUST restore the destination mailbox to its state + before the COPY attempt. + + Example: C: A003 COPY 2:4 MEETING + S: A003 OK COPY completed + +6.4.8. UID Command + + Arguments: command name + command arguments + + Responses: untagged responses: FETCH, SEARCH + + Result: OK - UID command completed + NO - UID command error + BAD - command unknown or arguments invalid + + The UID command has two forms. In the first form, it takes as its + arguments a COPY, FETCH, or STORE command with arguments + appropriate for the associated command. However, the numbers in + the message set argument are unique identifiers instead of message + sequence numbers. + + In the second form, the UID command takes a SEARCH command with + SEARCH command arguments. The interpretation of the arguments is + the same as with SEARCH; however, the numbers returned in a SEARCH + response for a UID SEARCH command are unique identifiers instead + of message sequence numbers. For example, the command UID SEARCH + 1:100 UID 443:557 returns the unique identifiers corresponding to + the intersection of the message sequence number set 1:100 and the + UID set 443:557. + + Message set ranges are permitted; however, there is no guarantee + that unique identifiers be contiguous. A non-existent unique + identifier within a message set range is ignored without any error + message generated. + + The number after the "*" in an untagged FETCH response is always a + message sequence number, not a unique identifier, even for a UID + command response. However, server implementations MUST implicitly + include the UID message data item as part of any FETCH response + caused by a UID command, regardless of whether a UID was specified + as a message data item to the FETCH. + + + + + + + +Crispin Standards Track [Page 47] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A999 UID FETCH 4827313:4828442 FLAGS + S: * 23 FETCH (FLAGS (\Seen) UID 4827313) + S: * 24 FETCH (FLAGS (\Seen) UID 4827943) + S: * 25 FETCH (FLAGS (\Seen) UID 4828442) + S: A999 UID FETCH completed + +6.5. Client Commands - Experimental/Expansion + +6.5.1. X Command + + Arguments: implementation defined + + Responses: implementation defined + + Result: OK - command completed + NO - failure + BAD - command unknown or arguments invalid + + Any command prefixed with an X is an experimental command. + Commands which are not part of this specification, a standard or + standards-track revision of this specification, or an IESG- + approved experimental protocol, MUST use the X prefix. + + Any added untagged responses issued by an experimental command + MUST also be prefixed with an X. Server implementations MUST NOT + send any such untagged responses, unless the client requested it + by issuing the associated experimental command. + + Example: C: a441 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN + S: a441 OK CAPABILITY completed + C: A442 XPIG-LATIN + S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay + S: A442 OK XPIG-LATIN ompleted-cay + +7. Server Responses + + Server responses are in three forms: status responses, server data, + and command continuation request. The information contained in a + server response, identified by "Contents:" in the response + descriptions below, is described by function, not by syntax. The + precise syntax of server responses is described in the Formal Syntax + section. + + The client MUST be prepared to accept any response at all times. + + + + + + +Crispin Standards Track [Page 48] + +RFC 2060 IMAP4rev1 December 1996 + + + Status responses can be tagged or untagged. Tagged status responses + indicate the completion result (OK, NO, or BAD status) of a client + command, and have a tag matching the command. + + Some status responses, and all server data, are untagged. An + untagged response is indicated by the token "*" instead of a tag. + Untagged status responses indicate server greeting, or server status + that does not indicate the completion of a command (for example, an + impending system shutdown alert). For historical reasons, untagged + server data responses are also called "unsolicited data", although + strictly speaking only unilateral server data is truly "unsolicited". + + Certain server data MUST be recorded by the client when it is + received; this is noted in the description of that data. Such data + conveys critical information which affects the interpretation of all + subsequent commands and responses (e.g. updates reflecting the + creation or destruction of messages). + + Other server data SHOULD be recorded for later reference; if the + client does not need to record the data, or if recording the data has + no obvious purpose (e.g. a SEARCH response when no SEARCH command is + in progress), the data SHOULD be ignored. + + An example of unilateral untagged server data occurs when the IMAP + connection is in selected state. In selected state, the server + checks the mailbox for new messages as part of command execution. + Normally, this is part of the execution of every command; hence, a + NOOP command suffices to check for new messages. If new messages are + found, the server sends untagged EXISTS and RECENT responses + reflecting the new size of the mailbox. Server implementations that + offer multiple simultaneous access to the same mailbox SHOULD also + send appropriate unilateral untagged FETCH and EXPUNGE responses if + another agent changes the state of any message flags or expunges any + messages. + + Command continuation request responses use the token "+" instead of a + tag. These responses are sent by the server to indicate acceptance + of an incomplete client command and readiness for the remainder of + the command. + +7.1. Server Responses - Status Responses + + Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD + may be tagged or untagged. PREAUTH and BYE are always untagged. + + Status responses MAY include an OPTIONAL "response code". A response + code consists of data inside square brackets in the form of an atom, + possibly followed by a space and arguments. The response code + + + +Crispin Standards Track [Page 49] + +RFC 2060 IMAP4rev1 December 1996 + + + contains additional information or status codes for client software + beyond the OK/NO/BAD condition, and are defined when there is a + specific action that a client can take based upon the additional + information. + + The currently defined response codes are: + + ALERT The human-readable text contains a special alert + that MUST be presented to the user in a fashion + that calls the user's attention to the message. + + NEWNAME Followed by a mailbox name and a new mailbox name. + A SELECT or EXAMINE is failing because the target + mailbox name no longer exists because it was + renamed to the new mailbox name. This is a hint to + the client that the operation can succeed if the + SELECT or EXAMINE is reissued with the new mailbox + name. + + PARSE The human-readable text represents an error in + parsing the [RFC-822] header or [MIME-IMB] headers + of a message in the mailbox. + + PERMANENTFLAGS Followed by a parenthesized list of flags, + indicates which of the known flags that the client + can change permanently. Any flags that are in the + FLAGS untagged response, but not the PERMANENTFLAGS + list, can not be set permanently. If the client + attempts to STORE a flag that is not in the + PERMANENTFLAGS list, the server will either reject + it with a NO reply or store the state for the + remainder of the current session only. The + PERMANENTFLAGS list can also include the special + flag \*, which indicates that it is possible to + create new keywords by attempting to store those + flags in the mailbox. + + READ-ONLY The mailbox is selected read-only, or its access + while selected has changed from read-write to + read-only. + + READ-WRITE The mailbox is selected read-write, or its access + while selected has changed from read-only to + read-write. + + + + + + + +Crispin Standards Track [Page 50] + +RFC 2060 IMAP4rev1 December 1996 + + + TRYCREATE An APPEND or COPY attempt is failing because the + target mailbox does not exist (as opposed to some + other reason). This is a hint to the client that + the operation can succeed if the mailbox is first + created by the CREATE command. + + UIDVALIDITY Followed by a decimal number, indicates the unique + identifier validity value. + + UNSEEN Followed by a decimal number, indicates the number + of the first message without the \Seen flag set. + + Additional response codes defined by particular client or server + implementations SHOULD be prefixed with an "X" until they are + added to a revision of this protocol. Client implementations + SHOULD ignore response codes that they do not recognize. + +7.1.1. OK Response + + Contents: OPTIONAL response code + human-readable text + + The OK response indicates an information message from the server. + When tagged, it indicates successful completion of the associated + command. The human-readable text MAY be presented to the user as + an information message. The untagged form indicates an + information-only message; the nature of the information MAY be + indicated by a response code. + + The untagged form is also used as one of three possible greetings + at connection startup. It indicates that the connection is not + yet authenticated and that a LOGIN command is needed. + + Example: S: * OK IMAP4rev1 server ready + C: A001 LOGIN fred blurdybloop + S: * OK [ALERT] System shutdown in 10 minutes + S: A001 OK LOGIN Completed + +7.1.2. NO Response + + Contents: OPTIONAL response code + human-readable text + + The NO response indicates an operational error message from the + server. When tagged, it indicates unsuccessful completion of the + associated command. The untagged form indicates a warning; the + command can still complete successfully. The human-readable text + describes the condition. + + + +Crispin Standards Track [Page 51] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A222 COPY 1:2 owatagusiam + S: * NO Disk is 98% full, please delete unnecessary data + S: A222 OK COPY completed + C: A223 COPY 3:200 blurdybloop + S: * NO Disk is 98% full, please delete unnecessary data + S: * NO Disk is 99% full, please delete unnecessary data + S: A223 NO COPY failed: disk is full + +7.1.3. BAD Response + + Contents: OPTIONAL response code + human-readable text + + The BAD response indicates an error message from the server. When + tagged, it reports a protocol-level error in the client's command; + the tag indicates the command that caused the error. The untagged + form indicates a protocol-level error for which the associated + command can not be determined; it can also indicate an internal + server failure. The human-readable text describes the condition. + + Example: C: ...very long command line... + S: * BAD Command line too long + C: ...empty line... + S: * BAD Empty command line + C: A443 EXPUNGE + S: * BAD Disk crash, attempting salvage to a new disk! + S: * OK Salvage successful, no data lost + S: A443 OK Expunge completed + +7.1.4. PREAUTH Response + + Contents: OPTIONAL response code + human-readable text + + The PREAUTH response is always untagged, and is one of three + possible greetings at connection startup. It indicates that the + connection has already been authenticated by external means and + thus no LOGIN command is needed. + + Example: S: * PREAUTH IMAP4rev1 server logged in as Smith + +7.1.5. BYE Response + + Contents: OPTIONAL response code + human-readable text + + + + + + +Crispin Standards Track [Page 52] + +RFC 2060 IMAP4rev1 December 1996 + + + The BYE response is always untagged, and indicates that the server + is about to close the connection. The human-readable text MAY be + displayed to the user in a status report by the client. The BYE + response is sent under one of four conditions: + + 1) as part of a normal logout sequence. The server will close + the connection after sending the tagged OK response to the + LOGOUT command. + + 2) as a panic shutdown announcement. The server closes the + connection immediately. + + 3) as an announcement of an inactivity autologout. The server + closes the connection immediately. + + 4) as one of three possible greetings at connection startup, + indicating that the server is not willing to accept a + connection from this client. The server closes the + connection immediately. + + The difference between a BYE that occurs as part of a normal + LOGOUT sequence (the first case) and a BYE that occurs because of + a failure (the other three cases) is that the connection closes + immediately in the failure case. + + Example: S: * BYE Autologout; idle for too long + +7.2. Server Responses - Server and Mailbox Status + + These responses are always untagged. This is how server and mailbox + status data are transmitted from the server to the client. Many of + these responses typically result from a command with the same name. + +7.2.1. CAPABILITY Response + + Contents: capability listing + + The CAPABILITY response occurs as a result of a CAPABILITY + command. The capability listing contains a space-separated + listing of capability names that the server supports. The + capability listing MUST include the atom "IMAP4rev1". + + A capability name which begins with "AUTH=" indicates that the + server supports that particular authentication mechanism. + + + + + + + +Crispin Standards Track [Page 53] + +RFC 2060 IMAP4rev1 December 1996 + + + Other capability names indicate that the server supports an + extension, revision, or amendment to the IMAP4rev1 protocol. + Server responses MUST conform to this document until the client + issues a command that uses the associated capability. + + Capability names MUST either begin with "X" or be standard or + standards-track IMAP4rev1 extensions, revisions, or amendments + registered with IANA. A server MUST NOT offer unregistered or + non-standard capability names, unless such names are prefixed with + an "X". + + Client implementations SHOULD NOT require any capability name + other than "IMAP4rev1", and MUST ignore any unknown capability + names. + + Example: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN + +7.2.2. LIST Response + + Contents: name attributes + hierarchy delimiter + name + + The LIST response occurs as a result of a LIST command. It + returns a single name that matches the LIST specification. There + can be multiple LIST responses for a single LIST command. + + Four name attributes are defined: + + \Noinferiors It is not possible for any child levels of + hierarchy to exist under this name; no child levels + exist now and none can be created in the future. + + \Noselect It is not possible to use this name as a selectable + mailbox. + + \Marked The mailbox has been marked "interesting" by the + server; the mailbox probably contains messages that + have been added since the last time the mailbox was + selected. + + \Unmarked The mailbox does not contain any additional + messages since the last time the mailbox was + selected. + + If it is not feasible for the server to determine whether the + mailbox is "interesting" or not, or if the name is a \Noselect + name, the server SHOULD NOT send either \Marked or \Unmarked. + + + +Crispin Standards Track [Page 54] + +RFC 2060 IMAP4rev1 December 1996 + + + The hierarchy delimiter is a character used to delimit levels of + hierarchy in a mailbox name. A client can use it to create child + mailboxes, and to search higher or lower levels of naming + hierarchy. All children of a top-level hierarchy node MUST use + the same separator character. A NIL hierarchy delimiter means + that no hierarchy exists; the name is a "flat" name. + + The name represents an unambiguous left-to-right hierarchy, and + MUST be valid for use as a reference in LIST and LSUB commands. + Unless \Noselect is indicated, the name MUST also be valid as an + argument for commands, such as SELECT, that accept mailbox + names. + + Example: S: * LIST (\Noselect) "/" ~/Mail/foo + +7.2.3. LSUB Response + + Contents: name attributes + hierarchy delimiter + name + + The LSUB response occurs as a result of an LSUB command. It + returns a single name that matches the LSUB specification. There + can be multiple LSUB responses for a single LSUB command. The + data is identical in format to the LIST response. + + Example: S: * LSUB () "." #news.comp.mail.misc + +7.2.4 STATUS Response + + Contents: name + status parenthesized list + + The STATUS response occurs as a result of an STATUS command. It + returns the mailbox name that matches the STATUS specification and + the requested mailbox status information. + + Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) + +7.2.5. SEARCH Response + + Contents: zero or more numbers + + + + + + + + + +Crispin Standards Track [Page 55] + +RFC 2060 IMAP4rev1 December 1996 + + + The SEARCH response occurs as a result of a SEARCH or UID SEARCH + command. The number(s) refer to those messages that match the + search criteria. For SEARCH, these are message sequence numbers; + for UID SEARCH, these are unique identifiers. Each number is + delimited by a space. + + Example: S: * SEARCH 2 3 6 + +7.2.6. FLAGS Response + + Contents: flag parenthesized list + + The FLAGS response occurs as a result of a SELECT or EXAMINE + command. The flag parenthesized list identifies the flags (at a + minimum, the system-defined flags) that are applicable for this + mailbox. Flags other than the system flags can also exist, + depending on server implementation. + + The update from the FLAGS response MUST be recorded by the client. + + Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + +7.3. Server Responses - Mailbox Size + + These responses are always untagged. This is how changes in the size + of the mailbox are trasnmitted from the server to the client. + Immediately following the "*" token is a number that represents a + message count. + +7.3.1. EXISTS Response + + Contents: none + + The EXISTS response reports the number of messages in the mailbox. + This response occurs as a result of a SELECT or EXAMINE command, + and if the size of the mailbox changes (e.g. new mail). + + The update from the EXISTS response MUST be recorded by the + client. + + Example: S: * 23 EXISTS + + + + + + + + + + +Crispin Standards Track [Page 56] + +RFC 2060 IMAP4rev1 December 1996 + + +7.3.2. RECENT Response + + Contents: none + + The RECENT response reports the number of messages with the + \Recent flag set. This response occurs as a result of a SELECT or + EXAMINE command, and if the size of the mailbox changes (e.g. new + mail). + + Note: It is not guaranteed that the message sequence numbers of + recent messages will be a contiguous range of the highest n + messages in the mailbox (where n is the value reported by the + RECENT response). Examples of situations in which this is not + the case are: multiple clients having the same mailbox open + (the first session to be notified will see it as recent, others + will probably see it as non-recent), and when the mailbox is + re-ordered by a non-IMAP agent. + + The only reliable way to identify recent messages is to look at + message flags to see which have the \Recent flag set, or to do + a SEARCH RECENT. + + The update from the RECENT response MUST be recorded by the + client. + + Example: S: * 5 RECENT + +7.4. Server Responses - Message Status + + These responses are always untagged. This is how message data are + transmitted from the server to the client, often as a result of a + command with the same name. Immediately following the "*" token is a + number that represents a message sequence number. + +7.4.1. EXPUNGE Response + + Contents: none + + The EXPUNGE response reports that the specified message sequence + number has been permanently removed from the mailbox. The message + sequence number for each successive message in the mailbox is + immediately decremented by 1, and this decrement is reflected in + message sequence numbers in subsequent responses (including other + untagged EXPUNGE responses). + + As a result of the immediate decrement rule, message sequence + numbers that appear in a set of successive EXPUNGE responses + depend upon whether the messages are removed starting from lower + + + +Crispin Standards Track [Page 57] + +RFC 2060 IMAP4rev1 December 1996 + + + numbers to higher numbers, or from higher numbers to lower + numbers. For example, if the last 5 messages in a 9-message + mailbox are expunged; a "lower to higher" server will send five + untagged EXPUNGE responses for message sequence number 5, whereas + a "higher to lower server" will send successive untagged EXPUNGE + responses for message sequence numbers 9, 8, 7, 6, and 5. + + An EXPUNGE response MUST NOT be sent when no command is in + progress; nor while responding to a FETCH, STORE, or SEARCH + command. This rule is necessary to prevent a loss of + synchronization of message sequence numbers between client and + server. + + The update from the EXPUNGE response MUST be recorded by the + client. + + Example: S: * 44 EXPUNGE + +7.4.2. FETCH Response + + Contents: message data + + The FETCH response returns data about a message to the client. + The data are pairs of data item names and their values in + parentheses. This response occurs as the result of a FETCH or + STORE command, as well as by unilateral server decision (e.g. flag + updates). + + The current data items are: + + BODY A form of BODYSTRUCTURE without extension data. + + BODY[
]<> + A string expressing the body contents of the + specified section. The string SHOULD be + interpreted by the client according to the content + transfer encoding, body type, and subtype. + + If the origin octet is specified, this string is a + substring of the entire body contents, starting at + that origin octet. This means that BODY[]<0> MAY + be truncated, but BODY[] is NEVER truncated. + + 8-bit textual data is permitted if a [CHARSET] + identifier is part of the body parameter + parenthesized list for this section. Note that + headers (part specifiers HEADER or MIME, or the + header portion of a MESSAGE/RFC822 part), MUST be + + + +Crispin Standards Track [Page 58] + +RFC 2060 IMAP4rev1 December 1996 + + + 7-bit; 8-bit characters are not permitted in + headers. Note also that the blank line at the end + of the header is always included in header data. + + Non-textual data such as binary data MUST be + transfer encoded into a textual form such as BASE64 + prior to being sent to the client. To derive the + original binary data, the client MUST decode the + transfer encoded string. + + BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB] + body structure of a message. This is computed by + the server by parsing the [MIME-IMB] header fields, + defaulting various fields as necessary. + + For example, a simple text message of 48 lines and + 2279 octets can have a body structure of: ("TEXT" + "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 + 48) + + Multiple parts are indicated by parenthesis + nesting. Instead of a body type as the first + element of the parenthesized list there is a nested + body. The second element of the parenthesized list + is the multipart subtype (mixed, digest, parallel, + alternative, etc.). + + For example, a two part message consisting of a + text and a BASE645-encoded text attachment can have + a body structure of: (("TEXT" "PLAIN" ("CHARSET" + "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" + ("CHARSET" "US-ASCII" "NAME" "cc.diff") + "<960723163407.20117h@cac.washington.edu>" + "Compiler diff" "BASE64" 4554 73) "MIXED")) + + Extension data follows the multipart subtype. + Extension data is never returned with the BODY + fetch, but can be returned with a BODYSTRUCTURE + fetch. Extension data, if present, MUST be in the + defined order. + + The extension data of a multipart body part are in + the following order: + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. ("foo" "bar" "baz" "rag") where "bar" is + the value of "foo" and "rag" is the value of + + + +Crispin Standards Track [Page 59] + +RFC 2060 IMAP4rev1 December 1996 + + + "baz"] as defined in [MIME-IMB]. + + body disposition + A parenthesized list, consisting of a + disposition type string followed by a + parenthesized list of disposition + attribute/value pairs. The disposition type and + attribute names will be defined in a future + standards-track revision to [DISPOSITION]. + + body language + A string or parenthesized list giving the body + language value as defined in [LANGUAGE-TAGS]. + + Any following extension data are not yet defined in + this version of the protocol. Such extension data + can consist of zero or more NILs, strings, numbers, + or potentially nested parenthesized lists of such + data. Client implementations that do a + BODYSTRUCTURE fetch MUST be prepared to accept such + extension data. Server implementations MUST NOT + send such extension data until it has been defined + by a revision of this protocol. + + The basic fields of a non-multipart body part are + in the following order: + + body type + A string giving the content media type name as + defined in [MIME-IMB]. + + body subtype + A string giving the content subtype name as + defined in [MIME-IMB]. + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. ("foo" "bar" "baz" "rag") where "bar" is + the value of "foo" and "rag" is the value of + "baz"] as defined in [MIME-IMB]. + + body id + A string giving the content id as defined in + [MIME-IMB]. + + body description + A string giving the content description as + defined in [MIME-IMB]. + + + +Crispin Standards Track [Page 60] + +RFC 2060 IMAP4rev1 December 1996 + + + body encoding + A string giving the content transfer encoding as + defined in [MIME-IMB]. + + body size + A number giving the size of the body in octets. + Note that this size is the size in its transfer + encoding and not the resulting size after any + decoding. + + A body type of type MESSAGE and subtype RFC822 + contains, immediately after the basic fields, the + envelope structure, body structure, and size in + text lines of the encapsulated message. + + A body type of type TEXT contains, immediately + after the basic fields, the size of the body in + text lines. Note that this size is the size in its + content transfer encoding and not the resulting + size after any decoding. + + Extension data follows the basic fields and the + type-specific fields listed above. Extension data + is never returned with the BODY fetch, but can be + returned with a BODYSTRUCTURE fetch. Extension + data, if present, MUST be in the defined order. + + The extension data of a non-multipart body part are + in the following order: + + body MD5 + A string giving the body MD5 value as defined in + [MD5]. + + body disposition + A parenthesized list with the same content and + function as the body disposition for a multipart + body part. + + body language + A string or parenthesized list giving the body + language value as defined in [LANGUAGE-TAGS]. + + Any following extension data are not yet defined in + this version of the protocol, and would be as + described above under multipart extension data. + + + + + +Crispin Standards Track [Page 61] + +RFC 2060 IMAP4rev1 December 1996 + + + ENVELOPE A parenthesized list that describes the envelope + structure of a message. This is computed by the + server by parsing the [RFC-822] header into the + component parts, defaulting various fields as + necessary. + + The fields of the envelope structure are in the + following order: date, subject, from, sender, + reply-to, to, cc, bcc, in-reply-to, and message-id. + The date, subject, in-reply-to, and message-id + fields are strings. The from, sender, reply-to, + to, cc, and bcc fields are parenthesized lists of + address structures. + + An address structure is a parenthesized list that + describes an electronic mail address. The fields + of an address structure are in the following order: + personal name, [SMTP] at-domain-list (source + route), mailbox name, and host name. + + [RFC-822] group syntax is indicated by a special + form of address structure in which the host name + field is NIL. If the mailbox name field is also + NIL, this is an end of group marker (semi-colon in + RFC 822 syntax). If the mailbox name field is + non-NIL, this is a start of group marker, and the + mailbox name field holds the group name phrase. + + Any field of an envelope or address structure that + is not applicable is presented as NIL. Note that + the server MUST default the reply-to and sender + fields from the from field; a client is not + expected to know to do this. + + FLAGS A parenthesized list of flags that are set for this + message. + + INTERNALDATE A string representing the internal date of the + message. + + RFC822 Equivalent to BODY[]. + + RFC822.HEADER Equivalent to BODY.PEEK[HEADER]. + + RFC822.SIZE A number expressing the [RFC-822] size of the + message. + + RFC822.TEXT Equivalent to BODY[TEXT]. + + + +Crispin Standards Track [Page 62] + +RFC 2060 IMAP4rev1 December 1996 + + + UID A number expressing the unique identifier of the + message. + + + Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) + +7.5. Server Responses - Command Continuation Request + + The command continuation request response is indicated by a "+" token + instead of a tag. This form of response indicates that the server is + ready to accept the continuation of a command from the client. The + remainder of this response is a line of text. + + This response is used in the AUTHORIZATION command to transmit server + data to the client, and request additional client data. This + response is also used if an argument to any command is a literal. + + The client is not permitted to send the octets of the literal unless + the server indicates that it expects it. This permits the server to + process commands and reject errors on a line-by-line basis. The + remainder of the command, including the CRLF that terminates a + command, follows the octets of the literal. If there are any + additional command arguments the literal octets are followed by a + space and those arguments. + + Example: C: A001 LOGIN {11} + S: + Ready for additional command text + C: FRED FOOBAR {7} + S: + Ready for additional command text + C: fat man + S: A001 OK LOGIN completed + C: A044 BLURDYBLOOP {102856} + S: A044 BAD No such command as "BLURDYBLOOP" + +8. Sample IMAP4rev1 connection + + The following is a transcript of an IMAP4rev1 connection. A long + line in this sample is broken for editorial clarity. + +S: * OK IMAP4rev1 Service Ready +C: a001 login mrc secret +S: a001 OK LOGIN completed +C: a002 select inbox +S: * 18 EXISTS +S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) +S: * 2 RECENT +S: * OK [UNSEEN 17] Message 17 is the first unseen message +S: * OK [UIDVALIDITY 3857529045] UIDs valid + + + +Crispin Standards Track [Page 63] + +RFC 2060 IMAP4rev1 December 1996 + + +S: a002 OK [READ-WRITE] SELECT completed +C: a003 fetch 12 full +S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" + RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" + "IMAP4rev1 WG mtg summary and minutes" + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + ((NIL NIL "imap" "cac.washington.edu")) + ((NIL NIL "minutes" "CNRI.Reston.VA.US") + ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL + "") + BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) +S: a003 OK FETCH completed +C: a004 fetch 12 body[header] +S: * 12 FETCH (BODY[HEADER] {350} +S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) +S: From: Terry Gray +S: Subject: IMAP4rev1 WG mtg summary and minutes +S: To: imap@cac.washington.edu +S: cc: minutes@CNRI.Reston.VA.US, John Klensin +S: Message-Id: +S: MIME-Version: 1.0 +S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII +S: +S: ) +S: a004 OK FETCH completed +C: a005 store 12 +flags \deleted +S: * 12 FETCH (FLAGS (\Seen \Deleted)) +S: a005 OK +FLAGS completed +C: a006 logout +S: * BYE IMAP4rev1 server terminating connection +S: a006 OK LOGOUT completed + +9. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] with one exception; the + delimiter used with the "#" construct is a single space (SPACE) and + not one or more commas. + + In the case of alternative or optional rules in which a later rule + overlaps an earlier rule, the rule which is listed earlier MUST take + priority. For example, "\Seen" when parsed as a flag is the \Seen + flag name and not a flag_extension, even though "\Seen" could be + parsed as a flag_extension. Some, but not all, instances of this + rule are noted below. + + + + +Crispin Standards Track [Page 64] + +RFC 2060 IMAP4rev1 December 1996 + + + Except as noted otherwise, all alphabetic characters are case- + insensitive. The use of upper or lower case characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + +address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox + SPACE addr_host ")" + +addr_adl ::= nstring + ;; Holds route from [RFC-822] route-addr if + ;; non-NIL + +addr_host ::= nstring + ;; NIL indicates [RFC-822] group syntax. + ;; Otherwise, holds [RFC-822] domain name + +addr_mailbox ::= nstring + ;; NIL indicates end of [RFC-822] group; if + ;; non-NIL and addr_host is NIL, holds + ;; [RFC-822] group name. + ;; Otherwise, holds [RFC-822] local-part + +addr_name ::= nstring + ;; Holds phrase from [RFC-822] mailbox if + ;; non-NIL + +alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / + "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / + "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / + "Y" / "Z" / + "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / + "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / + "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / + "y" / "z" + ;; Case-sensitive + +append ::= "APPEND" SPACE mailbox [SPACE flag_list] + [SPACE date_time] SPACE literal + +astring ::= atom / string + +atom ::= 1*ATOM_CHAR + +ATOM_CHAR ::= + +atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards / + quoted_specials + + + + +Crispin Standards Track [Page 65] + +RFC 2060 IMAP4rev1 December 1996 + + +authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) + +auth_type ::= atom + ;; Defined by [IMAP-AUTH] + +base64 ::= *(4base64_char) [base64_terminal] + +base64_char ::= alpha / digit / "+" / "/" + +base64_terminal ::= (2base64_char "==") / (3base64_char "=") + +body ::= "(" body_type_1part / body_type_mpart ")" + +body_extension ::= nstring / number / "(" 1#body_extension ")" + ;; Future expansion. Client implementations + ;; MUST accept body_extension fields. Server + ;; implementations MUST NOT generate + ;; body_extension fields except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + +body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp + [SPACE body_fld_lang + [SPACE 1#body_extension]]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + +body_ext_mpart ::= body_fld_param + [SPACE body_fld_dsp SPACE body_fld_lang + [SPACE 1#body_extension]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + +body_fields ::= body_fld_param SPACE body_fld_id SPACE + body_fld_desc SPACE body_fld_enc SPACE + body_fld_octets + +body_fld_desc ::= nstring + +body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil + +body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ + "QUOTED-PRINTABLE") <">) / string + +body_fld_id ::= nstring + +body_fld_lang ::= nstring / "(" 1#string ")" + + + + +Crispin Standards Track [Page 66] + +RFC 2060 IMAP4rev1 December 1996 + + +body_fld_lines ::= number + +body_fld_md5 ::= nstring + +body_fld_octets ::= number + +body_fld_param ::= "(" 1#(string SPACE string) ")" / nil + +body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) + [SPACE body_ext_1part] + +body_type_basic ::= media_basic SPACE body_fields + ;; MESSAGE subtype MUST NOT be "RFC822" + +body_type_mpart ::= 1*body SPACE media_subtype + [SPACE body_ext_mpart] + +body_type_msg ::= media_message SPACE body_fields SPACE envelope + SPACE body SPACE body_fld_lines + +body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines + +capability ::= "AUTH=" auth_type / atom + ;; New capabilities MUST begin with "X" or be + ;; registered with IANA as standard or + ;; standards-track + +capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1" + [SPACE 1#capability] + ;; IMAP4rev1 servers which offer RFC 1730 + ;; compatibility MUST list "IMAP4" as the first + ;; capability. + +CHAR ::= + +CHAR8 ::= + +command ::= tag SPACE (command_any / command_auth / + command_nonauth / command_select) CRLF + ;; Modal based on state + +command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command + ;; Valid in all states + +command_auth ::= append / create / delete / examine / list / lsub / + rename / select / status / subscribe / unsubscribe + ;; Valid only in Authenticated or Selected state + + + +Crispin Standards Track [Page 67] + +RFC 2060 IMAP4rev1 December 1996 + + +command_nonauth ::= login / authenticate + ;; Valid only when in Non-Authenticated state + +command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / + copy / fetch / store / uid / search + ;; Valid only when in Selected state + +continue_req ::= "+" SPACE (resp_text / base64) + +copy ::= "COPY" SPACE set SPACE mailbox + +CR ::= + +create ::= "CREATE" SPACE mailbox + ;; Use of INBOX gives a NO error + +CRLF ::= CR LF + +CTL ::= + +date ::= date_text / <"> date_text <"> + +date_day ::= 1*2digit + ;; Day of month + +date_day_fixed ::= (SPACE digit) / 2digit + ;; Fixed-format version of date_day + +date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / + "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" + +date_text ::= date_day "-" date_month "-" date_year + +date_year ::= 4digit + +date_time ::= <"> date_day_fixed "-" date_month "-" date_year + SPACE time SPACE zone <"> + +delete ::= "DELETE" SPACE mailbox + ;; Use of INBOX gives a NO error + +digit ::= "0" / digit_nz + +digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / + "9" + + + + + +Crispin Standards Track [Page 68] + +RFC 2060 IMAP4rev1 December 1996 + + +envelope ::= "(" env_date SPACE env_subject SPACE env_from + SPACE env_sender SPACE env_reply_to SPACE env_to + SPACE env_cc SPACE env_bcc SPACE env_in_reply_to + SPACE env_message_id ")" + +env_bcc ::= "(" 1*address ")" / nil + +env_cc ::= "(" 1*address ")" / nil + +env_date ::= nstring + +env_from ::= "(" 1*address ")" / nil + +env_in_reply_to ::= nstring + +env_message_id ::= nstring + +env_reply_to ::= "(" 1*address ")" / nil + +env_sender ::= "(" 1*address ")" / nil + +env_subject ::= nstring + +env_to ::= "(" 1*address ")" / nil + +examine ::= "EXAMINE" SPACE mailbox + +fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / + "FAST" / fetch_att / "(" 1#fetch_att ")") + +fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] / + "BODY" ["STRUCTURE"] / "UID" / + "BODY" [".PEEK"] section + ["<" number "." nz_number ">"] + +flag ::= "\Answered" / "\Flagged" / "\Deleted" / + "\Seen" / "\Draft" / flag_keyword / flag_extension + +flag_extension ::= "\" atom + ;; Future expansion. Client implementations + ;; MUST accept flag_extension flags. Server + ;; implementations MUST NOT generate + ;; flag_extension flags except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + +flag_keyword ::= atom + + + +Crispin Standards Track [Page 69] + +RFC 2060 IMAP4rev1 December 1996 + + +flag_list ::= "(" #flag ")" + +greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF + +header_fld_name ::= astring + +header_list ::= "(" 1#header_fld_name ")" + +LF ::= + +list ::= "LIST" SPACE mailbox SPACE list_mailbox + +list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string + +list_wildcards ::= "%" / "*" + +literal ::= "{" number "}" CRLF *CHAR8 + ;; Number represents the number of CHAR8 octets + +login ::= "LOGIN" SPACE userid SPACE password + +lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox + +mailbox ::= "INBOX" / astring + ;; INBOX is case-insensitive. All case variants of + ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX + ;; not as an astring. Refer to section 5.1 for + ;; further semantic details of mailbox names. + +mailbox_data ::= "FLAGS" SPACE flag_list / + "LIST" SPACE mailbox_list / + "LSUB" SPACE mailbox_list / + "MAILBOX" SPACE text / + "SEARCH" [SPACE 1#nz_number] / + "STATUS" SPACE mailbox SPACE + "(" # QUOTED_CHAR <"> / nil) SPACE mailbox + +media_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / + "MESSAGE" / "VIDEO") <">) / string) + SPACE media_subtype + ;; Defined in [MIME-IMT] + +media_message ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> + + + +Crispin Standards Track [Page 70] + +RFC 2060 IMAP4rev1 December 1996 + + + ;; Defined in [MIME-IMT] + +media_subtype ::= string + ;; Defined in [MIME-IMT] + +media_text ::= <"> "TEXT" <"> SPACE media_subtype + ;; Defined in [MIME-IMT] + +message_data ::= nz_number SPACE ("EXPUNGE" / + ("FETCH" SPACE msg_att)) + +msg_att ::= "(" 1#("ENVELOPE" SPACE envelope / + "FLAGS" SPACE "(" #(flag / "\Recent") ")" / + "INTERNALDATE" SPACE date_time / + "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / + "RFC822.SIZE" SPACE number / + "BODY" ["STRUCTURE"] SPACE body / + "BODY" section ["<" number ">"] SPACE nstring / + "UID" SPACE uniqueid) ")" + +nil ::= "NIL" + +nstring ::= string / nil + +number ::= 1*digit + ;; Unsigned 32-bit integer + ;; (0 <= n < 4,294,967,296) + +nz_number ::= digit_nz *digit + ;; Non-zero unsigned 32-bit integer + ;; (0 < n < 4,294,967,296) + +password ::= astring + +quoted ::= <"> *QUOTED_CHAR <"> + +QUOTED_CHAR ::= / + "\" quoted_specials + +quoted_specials ::= <"> / "\" + +rename ::= "RENAME" SPACE mailbox SPACE mailbox + ;; Use of INBOX as a destination gives a NO error + +response ::= *(continue_req / response_data) response_done + +response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / + mailbox_data / message_data / capability_data) + + + +Crispin Standards Track [Page 71] + +RFC 2060 IMAP4rev1 December 1996 + + + CRLF + +response_done ::= response_tagged / response_fatal + +response_fatal ::= "*" SPACE resp_cond_bye CRLF + ;; Server closes connection immediately + +response_tagged ::= tag SPACE resp_cond_state CRLF + +resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text + ;; Authentication condition + +resp_cond_bye ::= "BYE" SPACE resp_text + +resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text + ;; Status condition + +resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) + ;; text SHOULD NOT begin with "[" or "=" + +resp_text_code ::= "ALERT" / "PARSE" / + "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / + "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / + "UIDVALIDITY" SPACE nz_number / + "UNSEEN" SPACE nz_number / + atom [SPACE 1*] + +search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] + 1#search_key + ;; [CHARSET] MUST be registered with IANA + +search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / + "BEFORE" SPACE date / "BODY" SPACE astring / + "CC" SPACE astring / "DELETED" / "FLAGGED" / + "FROM" SPACE astring / + "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / + "ON" SPACE date / "RECENT" / "SEEN" / + "SINCE" SPACE date / "SUBJECT" SPACE astring / + "TEXT" SPACE astring / "TO" SPACE astring / + "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / + "UNKEYWORD" SPACE flag_keyword / "UNSEEN" / + ;; Above this line were in [IMAP2] + "DRAFT" / + "HEADER" SPACE header_fld_name SPACE astring / + "LARGER" SPACE number / "NOT" SPACE search_key / + "OR" SPACE search_key SPACE search_key / + "SENTBEFORE" SPACE date / "SENTON" SPACE date / + "SENTSINCE" SPACE date / "SMALLER" SPACE number / + + + +Crispin Standards Track [Page 72] + +RFC 2060 IMAP4rev1 December 1996 + + + "UID" SPACE set / "UNDRAFT" / set / + "(" 1#search_key ")" + +section ::= "[" [section_text / (nz_number *["." nz_number] + ["." (section_text / "MIME")])] "]" + +section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"] + SPACE header_list / "TEXT" + +select ::= "SELECT" SPACE mailbox + +sequence_num ::= nz_number / "*" + ;; * is the largest number in use. For message + ;; sequence numbers, it is the number of messages + ;; in the mailbox. For unique identifiers, it is + ;; the unique identifier of the last message in + ;; the mailbox. + +set ::= sequence_num / (sequence_num ":" sequence_num) / + (set "," set) + ;; Identifies a set of messages. For message + ;; sequence numbers, these are consecutive + ;; numbers from 1 to the number of messages in + ;; the mailbox + ;; Comma delimits individual numbers, colon + ;; delimits between two numbers inclusive. + ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, + ;; 14,15 for a mailbox with 15 messages. + +SPACE ::= + +status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")" + +status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / + "UNSEEN" + +store ::= "STORE" SPACE set SPACE store_att_flags + +store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE + (flag_list / #flag) + +string ::= quoted / literal + +subscribe ::= "SUBSCRIBE" SPACE mailbox + +tag ::= 1* + +text ::= 1*TEXT_CHAR + + + +Crispin Standards Track [Page 73] + +RFC 2060 IMAP4rev1 December 1996 + + +text_mime2 ::= "=?" "?" "?" + "?=" + ;; Syntax defined in [MIME-HDRS] + +TEXT_CHAR ::= + +time ::= 2digit ":" 2digit ":" 2digit + ;; Hours minutes seconds + +uid ::= "UID" SPACE (copy / fetch / search / store) + ;; Unique identifiers used instead of message + ;; sequence numbers + +uniqueid ::= nz_number + ;; Strictly ascending + +unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox + +userid ::= astring + +x_command ::= "X" atom + +zone ::= ("+" / "-") 4digit + ;; Signed four-digit value of hhmm representing + ;; hours and minutes west of Greenwich (that is, + ;; (the amount that the given time differs from + ;; Universal Time). Subtracting the timezone + ;; from the given time will give the UT form. + ;; The Universal Time zone is "+0000". + +10. Author's Note + + This document is a revision or rewrite of earlier documents, and + supercedes the protocol specification in those documents: RFC 1730, + unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064. + +11. Security Considerations + + IMAP4rev1 protocol transactions, including electronic mail data, are + sent in the clear over the network unless privacy protection is + negotiated in the AUTHENTICATE command. + + A server error message for an AUTHENTICATE command which fails due to + invalid credentials SHOULD NOT detail why the credentials are + invalid. + + Use of the LOGIN command sends passwords in the clear. This can be + avoided by using the AUTHENTICATE command instead. + + + +Crispin Standards Track [Page 74] + +RFC 2060 IMAP4rev1 December 1996 + + + A server error message for a failing LOGIN command SHOULD NOT specify + that the user name, as opposed to the password, is invalid. + + Additional security considerations are discussed in the section + discussing the AUTHENTICATE and LOGIN commands. + +12. Author's Address + + Mark R. Crispin + Networks and Distributed Computing + University of Washington + 4545 15th Aveneue NE + Seattle, WA 98105-4527 + + Phone: (206) 543-5762 + + EMail: MRC@CAC.Washington.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 75] + +RFC 2060 IMAP4rev1 December 1996 + + +Appendices + +A. References + +[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol", +Work in Progress. + +[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, +RFC 1700, USC/Information Sciences Institute, October 1994. + +[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation +Information in Internet Messages: The Content-Disposition Header", +RFC 1806, June 1995. + +[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. +Carnegie-Mellon University, December 1994. + +[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC +2061, University of Washington, November 1996. + +[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected +IMAP4 Clients", Work in Progress. + +[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and +IMAP2bis", RFC 1732, University of Washington, December 1994. + +[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in +IMAP4", RFC 1733, University of Washington, December 1994. + +[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - +Obsolete Syntax", RFC 2062, University of Washington, November 1996. + +[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", +RFC 1176, University of Washington, August 1990. + +[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of +Languages", RFC 1766, March 1995. + +[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC +1864, October 1995. + +[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet +Mail Extensions) Part One: Format of Internet Message Bodies", RFC +2045, November 1996. + +[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose +Internet Mail Extensions) Part Two: Media Types", RFC 2046, +November 1996. + + + +Crispin Standards Track [Page 76] + +RFC 2060 IMAP4rev1 December 1996 + + +[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) +Part Three: Message Header Extensions for Non-ASCII Text", RFC +2047, November 1996. + +[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text +Messages", STD 11, RFC 822, University of Delaware, August 1982. + +[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, +RFC 821, USC/Information Sciences Institute, August 1982. + +[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe +Transformation Format of Unicode", RFC 1642, July 1994. + +B. Changes from RFC 1730 + +1) The STATUS command has been added. + +2) Clarify in the formal syntax that the "#" construct can never +refer to multiple spaces. + +3) Obsolete syntax has been moved to a separate document. + +4) The PARTIAL command has been obsoleted. + +5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and +RFC822.TEXT.PEEK fetch attributes have been obsoleted. + +6) The "<" origin "." size ">" suffix for BODY text attributes has +been added. + +7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part +specifiers have been added. + +8) Support for Content-Disposition and Content-Language has been +added. + +9) The restriction on fetching nested MULTIPART parts has been +removed. + +10) Body part number 0 has been obsoleted. + +11) Server-supported authenticators are now identified by +capabilities. + + + + + + + + +Crispin Standards Track [Page 77] + +RFC 2060 IMAP4rev1 December 1996 + + +12) The capability that identifies this protocol is now called +"IMAP4rev1". A server that provides backwards support for RFC 1730 +SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its +CAPABILITY response. Because RFC-1730 required "IMAP4" to appear as +the first capability, it MUST listed first in the response. + +13) A description of the mailbox name namespace convention has been +added. + +14) A description of the international mailbox name convention has +been added. + +15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT +and UIDVALIDITY. This is a change from the IMAP STATUS +Work in Progress and not from RFC-1730 + +16) Add a clarification that a null mailbox name argument to the LIST +command returns an untagged LIST response with the hierarchy +delimiter and root of the reference argument. + +17) Define terms such as "MUST", "SHOULD", and "MUST NOT". + +18) Add a section which defines message attributes and more +thoroughly details the semantics of message sequence numbers, UIDs, +and flags. + +19) Add a clarification detailing the circumstances when a client may +send multiple commands without waiting for a response, and the +circumstances in which ambiguities may result. + +20) Add a recommendation on server behavior for DELETE and RENAME +when inferior hierarchical names of the given name exist. + +21) Add a clarification that a mailbox name may not be unilaterally +unsubscribed by the server, even if that mailbox name no longer +exists. + +22) Add a clarification that LIST should return its results quickly +without undue delay. + +23) Add a clarification that the date_time argument to APPEND sets +the internal date of the message. + +24) Add a clarification on APPEND behavior when the target mailbox is +the currently selected mailbox. + + + + + + +Crispin Standards Track [Page 78] + +RFC 2060 IMAP4rev1 December 1996 + + +25) Add a clarification that external changes to flags should be +always announced via an untagged FETCH even if the current command is +a STORE with the ".SILENT" suffix. + +26) Add a clarification that COPY appends to the target mailbox. + +27) Add the NEWNAME response code. + +28) Rewrite the description of the untagged BYE response to clarify +its semantics. + +29) Change the reference for the body MD5 to refer to the proper RFC. + +30) Clarify that the formal syntax contains rules which may overlap, +and that in the event of such an overlap the rule which occurs first +takes precedence. + +31) Correct the definition of body_fld_param. + +32) More formal syntax for capability_data. + +33) Clarify that any case variant of "INBOX" must be interpreted as +INBOX. + +34) Clarify that the human-readable text in resp_text should not +begin with "[" or "=". + +35) Change MIME references to Draft Standard documents. + +36) Clarify \Recent semantics. + +37) Additional examples. + +C. Key Word Index + + +FLAGS (store command data item) ............... 45 + +FLAGS.SILENT (store command data item) ........ 46 + -FLAGS (store command data item) ............... 46 + -FLAGS.SILENT (store command data item) ........ 46 + ALERT (response code) ...................................... 50 + ALL (fetch item) ........................................... 41 + ALL (search key) ........................................... 38 + ANSWERED (search key) ...................................... 38 + APPEND (command) ........................................... 34 + AUTHENTICATE (command) ..................................... 20 + BAD (response) ............................................. 52 + BCC (search key) .................................. 38 + BEFORE (search key) ................................. 39 + + + +Crispin Standards Track [Page 79] + +RFC 2060 IMAP4rev1 December 1996 + + + BODY (fetch item) .......................................... 41 + BODY (fetch result) ........................................ 58 + BODY (search key) ................................. 39 + BODY.PEEK[
]<> (fetch item) ............... 44 + BODYSTRUCTURE (fetch item) ................................. 44 + BODYSTRUCTURE (fetch result) ............................... 59 + BODY[
]<> (fetch result) ............. 58 + BODY[
]<> (fetch item) .................... 41 + BYE (response) ............................................. 52 + Body Structure (message attribute) ......................... 11 + CAPABILITY (command) ....................................... 18 + CAPABILITY (response) ...................................... 53 + CC (search key) ................................... 39 + CHECK (command) ............................................ 36 + CLOSE (command) ............................................ 36 + COPY (command) ............................................. 46 + CREATE (command) ........................................... 25 + DELETE (command) ........................................... 26 + DELETED (search key) ....................................... 39 + DRAFT (search key) ......................................... 39 + ENVELOPE (fetch item) ...................................... 44 + ENVELOPE (fetch result) .................................... 62 + EXAMINE (command) .......................................... 24 + EXISTS (response) .......................................... 56 + EXPUNGE (command) .......................................... 37 + EXPUNGE (response) ......................................... 57 + Envelope Structure (message attribute) ..................... 11 + FAST (fetch item) .......................................... 44 + FETCH (command) ............................................ 41 + FETCH (response) ........................................... 58 + FLAGGED (search key) ....................................... 39 + FLAGS (fetch item) ......................................... 44 + FLAGS (fetch result) ....................................... 62 + FLAGS (response) ........................................... 56 + FLAGS (store command data item) ................ 45 + FLAGS.SILENT (store command data item) ......... 45 + FROM (search key) ................................. 39 + FULL (fetch item) .......................................... 44 + Flags (message attribute) .................................. 9 + HEADER (part specifier) .................................... 41 + HEADER (search key) .................. 39 + HEADER.FIELDS (part specifier) ............... 41 + HEADER.FIELDS.NOT (part specifier) ........... 41 + INTERNALDATE (fetch item) .................................. 44 + INTERNALDATE (fetch result) ................................ 62 + Internal Date (message attribute) .......................... 10 + KEYWORD (search key) ................................ 39 + Keyword (type of flag) ..................................... 10 + + + +Crispin Standards Track [Page 80] + +RFC 2060 IMAP4rev1 December 1996 + + + LARGER (search key) .................................... 39 + LIST (command) ............................................. 30 + LIST (response) ............................................ 54 + LOGIN (command) ............................................ 22 + LOGOUT (command) ........................................... 20 + LSUB (command) ............................................. 32 + LSUB (response) ............................................ 55 + MAY (specification requirement term) ....................... 5 + MESSAGES (status item) ..................................... 33 + MIME (part specifier) ...................................... 42 + MUST (specification requirement term) ...................... 4 + MUST NOT (specification requirement term) .................. 4 + Message Sequence Number (message attribute) ................ 9 + NEW (search key) ........................................... 39 + NEWNAME (response code) .................................... 50 + NO (response) .............................................. 51 + NOOP (command) ............................................. 19 + NOT (search key) .............................. 39 + OK (response) .............................................. 51 + OLD (search key) ........................................... 39 + ON (search key) ..................................... 39 + OPTIONAL (specification requirement term) .................. 5 + OR (search key) ................ 39 + PARSE (response code) ...................................... 50 + PERMANENTFLAGS (response code) ............................. 50 + PREAUTH (response) ......................................... 52 + Permanent Flag (class of flag) ............................. 10 + READ-ONLY (response code) .................................. 50 + READ-WRITE (response code) ................................. 50 + RECENT (response) .......................................... 57 + RECENT (search key) ........................................ 39 + RECENT (status item) ....................................... 33 + RENAME (command) ........................................... 27 + REQUIRED (specification requirement term) .................. 4 + RFC822 (fetch item) ........................................ 44 + RFC822 (fetch result) ...................................... 63 + RFC822.HEADER (fetch item) ................................. 44 + RFC822.HEADER (fetch result) ............................... 62 + RFC822.SIZE (fetch item) ................................... 44 + RFC822.SIZE (fetch result) ................................. 62 + RFC822.TEXT (fetch item) ................................... 44 + RFC822.TEXT (fetch result) ................................. 62 + SEARCH (command) ........................................... 37 + SEARCH (response) .......................................... 55 + SEEN (search key) .......................................... 40 + SELECT (command) ........................................... 23 + SENTBEFORE (search key) ............................. 40 + SENTON (search key) ................................. 40 + + + +Crispin Standards Track [Page 81] + +RFC 2060 IMAP4rev1 December 1996 + + + SENTSINCE (search key) .............................. 40 + SHOULD (specification requirement term) .................... 5 + SHOULD NOT (specification requirement term) ................ 5 + SINCE (search key) .................................. 40 + SMALLER (search key) ................................... 40 + STATUS (command) ........................................... 33 + STATUS (response) .......................................... 55 + STORE (command) ............................................ 45 + SUBJECT (search key) .............................. 40 + SUBSCRIBE (command) ........................................ 29 + Session Flag (class of flag) ............................... 10 + System Flag (type of flag) ................................. 9 + TEXT (part specifier) ...................................... 42 + TEXT (search key) ................................. 40 + TO (search key) ................................... 40 + TRYCREATE (response code) .................................. 51 + UID (command) .............................................. 47 + UID (fetch item) ........................................... 44 + UID (fetch result) ......................................... 63 + UID (search key) ............................. 40 + UIDNEXT (status item) ...................................... 33 + UIDVALIDITY (response code) ................................ 51 + UIDVALIDITY (status item) .................................. 34 + UNANSWERED (search key) .................................... 40 + UNDELETED (search key) ..................................... 40 + UNDRAFT (search key) ....................................... 40 + UNFLAGGED (search key) ..................................... 40 + UNKEYWORD (search key) .............................. 40 + UNSEEN (response code) ..................................... 51 + UNSEEN (search key) ........................................ 40 + UNSEEN (status item) ....................................... 34 + UNSUBSCRIBE (command) ...................................... 30 + Unique Identifier (UID) (message attribute) ................ 7 + X (command) .......................................... 48 + [RFC-822] Size (message attribute) ......................... 11 + \Answered (system flag) .................................... 9 + \Deleted (system flag) ..................................... 9 + \Draft (system flag) ....................................... 9 + \Flagged (system flag) ..................................... 9 + \Marked (mailbox name attribute) ........................... 54 + \Noinferiors (mailbox name attribute) ...................... 54 + \Noselect (mailbox name attribute) ......................... 54 + \Recent (system flag) ...................................... 10 + \Seen (system flag) ........................................ 9 + \Unmarked (mailbox name attribute) ......................... 54 + + + + + + +Crispin Standards Track [Page 82] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2086.txt b/server/src/site/resources/rfclist/imap4/rfc2086.txt new file mode 100644 index 00000000000..7a58f0b06c1 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2086.txt @@ -0,0 +1,452 @@ + + + + + +Network Working Group J. Myers +Request for Comments: 2086 Carnegie Mellon +Category: Standards Track January 1997 + + + IMAP4 ACL extension + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The ACL extension of the Internet Message Access Protocol [IMAP4] + permits access control lists to be manipulated through the IMAP + protocol. + +Table of Contents + + 1. Abstract............................................... 1 + 2. Conventions Used in this Document...................... 1 + 3. Introduction and Overview.............................. 2 + 4. Commands............................................... 3 + 4.1. SETACL................................................. 3 + 4.2. DELETEACL.............................................. 4 + 4.3. GETACL................................................. 4 + 4.4. LISTRIGHTS............................................. 4 + 4.5. MYRIGHTS............................................... 5 + 5. Responses.............................................. 5 + 5.1. ACL.................................................... 5 + 5.2. LISTRIGHTS............................................. 6 + 5.3. MYRIGHTS............................................... 6 + 6. Formal Syntax.......................................... 6 + 7. References............................................. 7 + 8. Security Considerations................................ 7 + 9. Author's Address....................................... 8 + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + + + + + +Myers Standards Track [Page 1] + +RFC 2086 ACL extension January 1997 + + +3. Introduction and Overview + + The ACL extension is present in any IMAP4 implementation which + returns "ACL" as one of the supported capabilities to the CAPABILITY + command. + + An access control list is a set of pairs. + + Identifier is a US-ASCII string. The identifier anyone is reserved + to refer to the universal identity (all authentications, including + anonymous). All user name strings accepted by the LOGIN or + AUTHENTICATE commands to authenticate to the IMAP server are reserved + as identifiers for the corresponding user. Identifiers starting with + a dash ("-") are reserved for "negative rights", described below. + All other identifier strings are interpreted in an implementation- + defined manner. + + Rights is a string listing a (possibly empty) set of alphanumeric + characters, each character listing a set of operations which is being + controlled. Letters are reserved for ``standard'' rights, listed + below. The set of standard rights may only be extended by a + standards-track document. Digits are reserved for implementation or + site defined rights. The currently defined standard rights are: + + l - lookup (mailbox is visible to LIST/LSUB commands) + r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, + SEARCH, COPY from mailbox) + s - keep seen/unseen information across sessions (STORE SEEN flag) + w - write (STORE flags other than SEEN and DELETED) + i - insert (perform APPEND, COPY into mailbox) + p - post (send mail to submission address for mailbox, + not enforced by IMAP4 itself) + c - create (CREATE new sub-mailboxes in any implementation-defined + hierarchy) + d - delete (STORE DELETED flag, perform EXPUNGE) + a - administer (perform SETACL) + + An implementation may tie rights together or may force rights to + always or never be granted to particular identifiers. For example, + in an implementation that uses unix mode bits, the rights "wisd" are + tied, the "a" right is always granted to the owner of a mailbox and + is never granted to another user. If rights are tied in an + implementation, the implementation must be conservative in granting + rights in response to SETACL commands--unless all rights in a tied + set are specified, none of that set should be included in the ACL + entry for that identifier. A client may discover the set of rights + which may be granted to a given identifier in the ACL for a given + mailbox by using the LISTRIGHTS command. + + + +Myers Standards Track [Page 2] + +RFC 2086 ACL extension January 1997 + + + It is possible for multiple identifiers in an access control list to + apply to a given user (or other authentication identity). For + example, an ACL may include rights to be granted to the identifier + matching the user, one or more implementation-defined identifiers + matching groups which include the user, and/or the identifier + "anyone". How these rights are combined to determine the user's + access is implementation-defined. An implementation may choose, for + example, to use the union of the rights granted to the applicable + identifiers. An implementation may instead choose, for example, to + only use those rights granted to the most specific identifier present + in the ACL. A client may determine the set of rights granted to the + logged-in user for a given mailbox by using the MYRIGHTS command. + + When an identifier in an ACL starts with a dash ("-"), that indicates + that associated rights are to be removed from the identifier that is + prefixed by the dash. For example, if the identifier "-fred" is + granted the "w" right, that indicates that the "w" right is to be + removed from users matching the identifier "fred". Implementations + need not support having identifiers which start with a dash in ACLs. + +4. Commands + +4.1. SETACL + + Arguments: mailbox name + authentication identifier + access right modification + + Data: no specific data for this command + + Result: OK - setacl completed + NO - setacl failure: can't set acl + BAD - command unknown or arguments invalid + + The SETACL command changes the access control list on the + specified mailbox so that the specified identifier is granted + permissions as specified in the third argument. + + The third argument is a string containing an optional plus ("+") + or minus ("-") prefix, followed by zero or more rights characters. + If the string starts with a plus, the following rights are added + to any existing rights for the identifier. If the string starts + with a minus, the following rights are removed from any existing + rights for the identifier. If the string does not start with a + plus or minus, the rights replace any existing rights for the + identifier. + + + + + +Myers Standards Track [Page 3] + +RFC 2086 ACL extension January 1997 + + +4.2. DELETEACL + + Arguments: mailbox name + authentication identifier + + Data: no specific data for this command + + Result: OK - deleteacl completed + NO - deleteacl failure: can't delete acl + BAD - command unknown or arguments invalid + + The DELETEACL command removes any pair for the + specified identifier from the access control list for the specified + mailbox. + +4.3. GETACL + + Arguments: mailbox name + + Data: untagged responses: ACL + + Result: OK - getacl completed + NO - getacl failure: can't get acl + BAD - command unknown or arguments invalid + + The GETACL command returns the access control list for mailbox in + an untagged ACL reply. + + Example: C: A002 GETACL INBOX + S: * ACL INBOX Fred rwipslda + S: A002 OK Getacl complete + +4.4. LISTRIGHTS + + Arguments: mailbox name + authentication identifier + + Data: untagged responses: LISTRIGHTS + + Result: OK - listrights completed + NO - listrights failure: can't get rights list + BAD - command unknown or arguments invalid + + The LISTRIGHTS command takes a mailbox name and an identifier and + returns information about what rights may be granted to the identifier + in the ACL for the mailbox. + + + + + +Myers Standards Track [Page 4] + +RFC 2086 ACL extension January 1997 + + + Example: C: a001 LISTRIGHTS ~/Mail/saved smith + S: * LISTRIGHTS ~/Mail/saved smith la r swicd + S: a001 OK Listrights completed + + + C: a005 LISTRIGHTS archive.imap anyone + S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a + 0 1 2 3 4 5 6 7 8 9 + +4.5. MYRIGHTS + + Arguments: mailbox name + + Data: untagged responses: MYRIGHTS + + Result: OK - myrights completed + NO - myrights failure: can't get rights + BAD - command unknown or arguments invalid + + The MYRIGHTS command returns the set of rights that the user has + to mailbox in an untagged MYRIGHTS reply. + + Example: C: A003 MYRIGHTS INBOX + S: * MYRIGHTS INBOX rwipslda + S: A003 OK Myrights complete + +5. Responses + +5.1. ACL + + Data: mailbox name + zero or more identifier rights pairs + + The ACL response occurs as a result of a GETACL command. The first + string is the mailbox name for which this ACL applies. This is + followed by zero or more pairs of strings, each pair contains the + identifier for which the entry applies followed by the set of + rights that the identifier has. + + + + + + + + + + + + + +Myers Standards Track [Page 5] + +RFC 2086 ACL extension January 1997 + + +5.2. LISTRIGHTS + + Data: mailbox name + identifier + required rights + list of optional rights + + The LISTRIGHTS response occurs as a result of a LISTRIGHTS + command. The first two strings are the mailbox name and identifier + for which this rights list applies. Following the identifier is a + string containing the (possibly empty) set of rights the + identifier will always be granted in the mailbox. + + Following this are zero or more strings each containing a set of + rights the identifier may be granted in the mailbox. Rights + mentioned in the same string are tied together--either all must be + granted to the identifier in the mailbox or none may be granted. + + The same right may not be listed more than once in the LISTRIGHTS + command. + +5.3. MYRIGHTS + + Data: mailbox name + rights + + The MYRIGHTS response occurs as a result of a MYRIGHTS command. + The first string is the mailbox name for which these rights apply. + The second string is the set of rights that the client has. + +6. 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. + + + + + + + + + + +Myers Standards Track [Page 6] + +RFC 2086 ACL extension January 1997 + + + acl_data ::= "ACL" SPACE mailbox *(SPACE identifier SPACE + rights) + + deleteacl ::= "DELETEACL" SPACE mailbox SPACE identifier + + getacl ::= "GETACL" SPACE mailbox + + identifier ::= astring + + listrights ::= "LISTRIGHTS" SPACE mailbox SPACE identifier + + listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier + SPACE rights *(SPACE rights) + + mod_rights ::= astring + ;; +rights to add, -rights to remove + ;; rights to replace + + myrights ::= "MYRIGHTS" SPACE mailbox + + myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE rights + + rights ::= astring + + setacl ::= "SETACL" SPACE mailbox SPACE identifier + SPACE mod_rights + +7. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", + RFC 1730, University of Washington, December 1994. + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822. + +8. Security Considerations + + An implementation must make sure the ACL commands themselves do not + give information about mailboxes with appropriately restricted ACL's. + For example, a GETACL command on a mailbox for which the user has + insufficient rights should not admit the mailbox exists, much less + return the mailbox's ACL. + + + + + + + + + +Myers Standards Track [Page 7] + +RFC 2086 ACL extension January 1997 + + +9. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + Email: jgm+@cmu.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers Standards Track [Page 8] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2087.txt b/server/src/site/resources/rfclist/imap4/rfc2087.txt new file mode 100644 index 00000000000..979c8ecec87 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2087.txt @@ -0,0 +1,284 @@ + + + + + +Network Working Group J. Myers +Request for Comments: 2087 Carnegie Mellon +Category: Standards Track January 1997 + + + IMAP4 QUOTA extension + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The QUOTA extension of the Internet Message Access Protocol [IMAP4] + permits administrative limits on resource usage (quotas) to be + manipulated through the IMAP protocol. + +Table of Contents + + 1. Abstract........................................... 1 + 2. Conventions Used in this Document.................. 1 + 3. Introduction and Overview.......................... 2 + 4. Commands........................................... 2 + 4.1. SETQUOTA Command................................... 2 + 4.2. GETQUOTA Command................................... 2 + 4.3. GETQUOTAROOT Command............................... 3 + 5. Responses.......................................... 3 + 5.1. QUOTA Response..................................... 3 + 5.2. QUOTAROOT Response................................. 4 + 6. Formal syntax...................................... 4 + 7. References......................................... 5 + 8. Security Considerations............................ 5 + 9. Author's Address................................... 5 + + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + + + + + + + +Myers Standards Track [Page 1] + +RFC 2087 QUOTA January 1997 + + +3. Introduction and Overview + + The QUOTA extension is present in any IMAP4 implementation which + returns "QUOTA" as one of the supported capabilities to the + CAPABILITY command. + + An IMAP4 server which supports the QUOTA capability may support + limits on any number of resources. Each resource has an atom name + and an implementation-defined interpretation which evaluates to an + integer. Examples of such resources are: + + Name Interpretation + + STORAGE Sum of messages' RFC822.SIZE, in units of 1024 octets + MESSAGE Number of messages + + + Each mailbox has zero or more implementation-defined named "quota + roots". Each quota root has zero or more resource limits. All + mailboxes that share the same named quota root share the resource + limits of the quota root. + + Quota root names do not necessarily have to match the names of + existing mailboxes. + +4. Commands + +4.1. SETQUOTA Command + + Arguments: quota root + list of resource limits + + Data: untagged responses: QUOTA + + Result: OK - setquota completed + NO - setquota error: can't set that data + BAD - command unknown or arguments invalid + + The SETQUOTA command takes the name of a mailbox quota root and a + list of resource limits. The resource limits for the named quota root + are changed to be the specified limits. Any previous resource limits + for the named quota root are discarded. + + If the named quota root did not previously exist, an implementation + may optionally create it and change the quota roots for any number of + existing mailboxes in an implementation-defined manner. + + + + + +Myers Standards Track [Page 2] + +RFC 2087 QUOTA January 1997 + + + Example: C: A001 SETQUOTA "" (STORAGE 512) + S: * QUOTA "" (STORAGE 10 512) + S: A001 OK Setquota completed + +4.2. GETQUOTA Command + + Arguments: quota root + + Data: untagged responses: QUOTA + + Result: OK - getquota completed + NO - getquota error: no such quota root, permission + denied + BAD - command unknown or arguments invalid + + The GETQUOTA command takes the name of a quota root and returns the + quota root's resource usage and limits in an untagged QUOTA response. + + Example: C: A003 GETQUOTA "" + S: * QUOTA "" (STORAGE 10 512) + S: A003 OK Getquota completed + +4.3. GETQUOTAROOT Command + + Arguments: mailbox name + + Data: untagged responses: QUOTAROOT, QUOTA + + Result: OK - getquota completed + NO - getquota error: no such mailbox, permission denied + BAD - command unknown or arguments invalid + + The GETQUOTAROOT command takes the name of a mailbox and returns the + list of quota roots for the mailbox in an untagged QUOTAROOT + response. For each listed quota root, it also returns the quota + root's resource usage and limits in an untagged QUOTA response. + + Example: C: A003 GETQUOTAROOT INBOX + S: * QUOTAROOT INBOX "" + S: * QUOTA "" (STORAGE 10 512) + S: A003 OK Getquota completed + + + + + + + + + + +Myers Standards Track [Page 3] + +RFC 2087 QUOTA January 1997 + + +5. Responses + +5.1. QUOTA Response + + Data: quota root name + list of resource names, usages, and limits + + This response occurs as a result of a GETQUOTA or GETQUOTAROOT + command. The first string is the name of the quota root for which + this quota applies. + + The name is followed by a S-expression format list of the resource + usage and limits of the quota root. The list contains zero or + more triplets. Each triplet conatins a resource name, the current + usage of the resource, and the resource limit. + + Resources not named in the list are not limited in the quota root. + Thus, an empty list means there are no administrative resource + limits in the quota root. + + Example: S: * QUOTA "" (STORAGE 10 512) + +5.2. QUOTAROOT Response + + Data: mailbox name + zero or more quota root names + + This response occurs as a result of a GETQUOTAROOT command. The + first string is the mailbox and the remaining strings are the + names of the quota roots for the mailbox. + + Example: S: * QUOTAROOT INBOX "" + S: * QUOTAROOT comp.mail.mime + +6. Formal syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in RFC 822 with one exception; the + delimiter used with the "#" construct is a single space (SP) and not + one or more commas. + + Except as noted otherwise, all alphabetic characters are case- + insensitive. The use of upper or lower case characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + + + + + + +Myers Standards Track [Page 4] + +RFC 2087 QUOTA January 1997 + + + getquota ::= "GETQUOTA" SP astring + + getquotaroot ::= "GETQUOTAROOT" SP astring + + quota_list ::= "(" #quota_resource ")" + + quota_resource ::= atom SP number SP number + + quota_response ::= "QUOTA" SP astring SP quota_list + + quotaroot_response + ::= "QUOTAROOT" SP astring *(SP astring) + + setquota ::= "SETQUOTA" SP astring SP setquota_list + + setquota_list ::= "(" 0#setquota_resource ")" + + setquota_resource ::= atom SP number + +7. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", + RFC 1730, University of Washington, December 1994. + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822. + +8. Security Considerations + + Implementors should be careful to make sure the implementation of + these commands does not violate the site's security policy. The + resource usage of other users is likely to be considered confidential + information and should not be divulged to unauthorized persons. + +9. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + EMail: jgm+@cmu.edu + + + + + + + + + +Myers Standards Track [Page 5] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2088.txt b/server/src/site/resources/rfclist/imap4/rfc2088.txt new file mode 100644 index 00000000000..2cd02f561fe --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2088.txt @@ -0,0 +1,116 @@ + + + + + +Network Working Group J. Myers +Request for Comments: 2088 Carnegie Mellon +Cateogry: Standards Track January 1997 + + + IMAP4 non-synchronizing literals + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The Internet Message Access Protocol [IMAP4] contains the "literal" + syntactic construct for communicating strings. When sending a + literal from client to server, IMAP4 requires the client to wait for + the server to send a command continuation request between sending the + octet count and the string data. This document specifies an + alternate form of literal which does not require this network round + trip. + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + +3. Specification + + The non-synchronizing literal is added an alternate form of literal, + and may appear in communication from client to server instead of the + IMAP4 form of literal. The IMAP4 form of literal, used in + communication from client to server, is referred to as a + synchronizing literal. + + Non-synchronizing literals may be used with any IMAP4 server + implementation which returns "LITERAL+" as one of the supported + capabilities to the CAPABILITY command. If the server does not + advertise the LITERAL+ capability, the client must use synchronizing + literals instead. + + The non-synchronizing literal is distinguished from the original + synchronizing literal by having a plus ('+') between the octet count + and the closing brace ('}'). The server does not generate a command + continuation request in response to a non-synchronizing literal, and + + + +Myers Standards Track [Page 1] + +RFC 2088 LITERAL January 1997 + + + clients are not required to wait before sending the octets of a non- + synchronizing literal. + + The protocol receiver of an IMAP4 server must check the end of every + received line for an open brace ('{') followed by an octet count, a + plus ('+'), and a close brace ('}') immediately preceeding the CRLF. + If it finds this sequence, it is the octet count of a non- + synchronizing literal and the server MUST treat the specified number + of following octets and the following line as part of the same + command. A server MAY still process commands and reject errors on a + line-by-line basis, as long as it checks for non-synchronizing + literals at the end of each line. + + Example: C: A001 LOGIN {11+} + C: FRED FOOBAR {7+} + C: fat man + S: A001 OK LOGIN completed + +4. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. + Non-terminals referenced but not defined below are as defined by + [IMAP4]. + + literal ::= "{" number ["+"] "}" CRLF *CHAR8 + ;; Number represents the number of CHAR8 octets + +6. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", + draft-crispin-imap-base-XX.txt, University of Washington, April 1996. + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822. + +7. Security Considerations + + There are no known security issues with this extension. + +8. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + Email: jgm+@cmu.edu + + + +Myers Standards Track [Page 2] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2177.txt b/server/src/site/resources/rfclist/imap4/rfc2177.txt new file mode 100644 index 00000000000..80393f6f4e6 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2177.txt @@ -0,0 +1,228 @@ + + + + + +Network Working Group B. Leiba +Request for Comments: 2177 IBM T.J. Watson Research Center +Category: Standards Track June 1997 + + + IMAP4 IDLE command + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The Internet Message Access Protocol [IMAP4] requires a client to + poll the server for changes to the selected mailbox (new mail, + deletions). It's often more desirable to have the server transmit + updates to the client in real time. This allows a user to see new + mail immediately. It also helps some real-time applications based on + IMAP, which might otherwise need to poll extremely often (such as + every few seconds). (While the spec actually does allow a server to + push EXISTS responses aysynchronously, a client can't expect this + behaviour and must poll.) + + This document specifies the syntax of an IDLE command, which will + allow a client to tell the server that it's ready to accept such + real-time updates. + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as described in RFC 2060 + [IMAP4]. + +3. Specification + + IDLE Command + + Arguments: none + + Responses: continuation data will be requested; the client sends + the continuation data "DONE" to end the command + + + +Leiba Standards Track [Page 1] + +RFC 2177 IMAP4 IDLE command June 1997 + + + + Result: OK - IDLE completed after client sent "DONE" + NO - failure: the server will not allow the IDLE + command at this time + BAD - command unknown or arguments invalid + + The IDLE command may be used with any IMAP4 server implementation + that returns "IDLE" as one of the supported capabilities to the + CAPABILITY command. If the server does not advertise the IDLE + capability, the client MUST NOT use the IDLE command and must poll + for mailbox updates. In particular, the client MUST continue to be + able to accept unsolicited untagged responses to ANY command, as + specified in the base IMAP specification. + + The IDLE command is sent from the client to the server when the + client is ready to accept unsolicited mailbox update messages. The + server requests a response to the IDLE command using the continuation + ("+") response. The IDLE command remains active until the client + responds to the continuation, and as long as an IDLE command is + active, the server is now free to send untagged EXISTS, EXPUNGE, and + other messages at any time. + + The IDLE command is terminated by the receipt of a "DONE" + continuation from the client; such response satisfies the server's + continuation request. At that point, the server MAY send any + remaining queued untagged responses and then MUST immediately send + the tagged response to the IDLE command and prepare to process other + commands. As in the base specification, the processing of any new + command may cause the sending of unsolicited untagged responses, + subject to the ambiguity limitations. The client MUST NOT send a + command while the server is waiting for the DONE, since the server + will not be able to distinguish a command from a continuation. + + The server MAY consider a client inactive if it has an IDLE command + running, and if such a server has an inactivity timeout it MAY log + the client off implicitly at the end of its timeout period. Because + of that, clients using IDLE are advised to terminate the IDLE and + re-issue it at least every 29 minutes to avoid being logged off. + This still allows a client to receive immediate mailbox updates even + though it need only "poll" at half hour intervals. + + + + + + + + + + + +Leiba Standards Track [Page 2] + +RFC 2177 IMAP4 IDLE command June 1997 + + + Example: C: A001 SELECT INBOX + S: * FLAGS (Deleted Seen) + S: * 3 EXISTS + S: * 0 RECENT + S: * OK [UIDVALIDITY 1] + S: A001 OK SELECT completed + C: A002 IDLE + S: + idling + ...time passes; new mail arrives... + S: * 4 EXISTS + C: DONE + S: A002 OK IDLE terminated + ...another client expunges message 2 now... + C: A003 FETCH 4 ALL + S: * 4 FETCH (...) + S: A003 OK FETCH completed + C: A004 IDLE + S: * 2 EXPUNGE + S: * 3 EXISTS + S: + idling + ...time passes; another client expunges message 3... + S: * 3 EXPUNGE + S: * 2 EXISTS + ...time passes; new mail arrives... + S: * 3 EXISTS + C: DONE + S: A004 OK IDLE terminated + C: A005 FETCH 3 ALL + S: * 3 FETCH (...) + S: A005 OK FETCH completed + C: A006 IDLE + +4. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. + Non-terminals referenced but not defined below are as defined by + [IMAP4]. + + command_auth ::= append / create / delete / examine / list / lsub / + rename / select / status / subscribe / unsubscribe + / idle + ;; Valid only in Authenticated or Selected state + + idle ::= "IDLE" CRLF "DONE" + + + + + + +Leiba Standards Track [Page 3] + +RFC 2177 IMAP4 IDLE command June 1997 + + +5. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + +6. Security Considerations + + There are no known security issues with this extension. + +7. Author's Address + + Barry Leiba + IBM T.J. Watson Research Center + 30 Saw Mill River Road + Hawthorne, NY 10532 + + Email: leiba@watson.ibm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Leiba Standards Track [Page 4] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2180.txt b/server/src/site/resources/rfclist/imap4/rfc2180.txt new file mode 100644 index 00000000000..57607002fa3 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2180.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group M. Gahrns +Request for Comments: 2180 Microsoft +Category: Informational July 1997 + + + IMAP4 Multi-Accessed Mailbox Practice + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +1. Abstract + + IMAP4[RFC-2060] is rich client/server protocol that allows a client + to access and manipulate electronic mail messages on a server. + Within the protocol framework, it is possible to have differing + results for particular client/server interactions. If a protocol does + not allow for this, it is often unduly restrictive. + + For example, when multiple clients are accessing a mailbox and one + attempts to delete the mailbox, an IMAP4 server may choose to + implement a solution based upon server architectural constraints or + individual preference. + + With this flexibility comes greater client responsibility. It is not + sufficient for a client to be written based upon the behavior of a + particular IMAP server. Rather the client must be based upon the + behavior allowed by the protocol. + + By documenting common IMAP4 server practice for the case of + simultaneous client access to a mailbox, we hope to ensure the widest + amount of inter-operation between IMAP4 clients and servers. + + The behavior described in this document reflects the practice of some + existing servers or behavior that the consensus of the IMAP mailing + list has deemed to be reasonable. The behavior described within this + document is believed to be [RFC-2060] compliant. However, this + document is not meant to define IMAP4 compliance, nor is it an + exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be + consulted to determine IMAP4 compliance, especially for server + behavior not described within this document. + + + + + + + + +Gahrns Informational [Page 1] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +2. Conventions used in this document + + In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different + clients (client #1, client #2 and client #3) that are connected to a + server. "S1:", "S2:" and "S3:" indicated lines sent by the server to + client #1, client #2 and client #3 respectively. + + A shared mailbox, is a mailbox that can be used by multiple users. + + A multi-accessed mailbox, is a mailbox that has multiple clients + simultaneously accessing it. + + A client is said to have accessed a mailbox after a successful SELECT + or EXAMINE command. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + + +3. Deletion/Renaming of a multi-accessed mailbox + + If an external agent or multiple clients are accessing a mailbox, + care must be taken when handling the deletion or renaming of the + mailbox. Following are some strategies an IMAP server may choose to + use when dealing with this situation. + + +3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed + mailbox + + In some cases, this behavior may not be practical. For example, if a + large number of clients are accessing a shared mailbox, the window in + which no clients have the mailbox accessed may be small or non- + existent, effectively rendering the mailbox undeletable or + unrenamable. + + Example: + + + + C1: A001 DELETE FOO + S1: A001 NO Mailbox FOO is in use by another user. + + + + + + + +Gahrns Informational [Page 2] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +3.2. The server MAY allow the DELETE command of a multi-accessed + mailbox, but keep the information in the mailbox available for + those clients that currently have access to the mailbox. + + When all clients have finished accessing the mailbox, it is + permanently removed. For clients that do not already have access to + the mailbox, the 'ghosted' mailbox would not be available. For + example, it would not be returned to these clients in a subsequent + LIST or LSUB command and would not be a valid mailbox argument to any + other IMAP command until the reference count of clients accessing the + mailbox reached 0. + + In some cases, this behavior may not be desirable. For example if + someone created a mailbox with offensive or sensitive information, + one might prefer to have the mailbox deleted and all access to the + information contained within removed immediately, rather than + continuing to allow access until the client closes the mailbox. + + Furthermore, this behavior, may prevent 'recycling' of the same + mailbox name until all clients have finished accessing the original + mailbox. + + Example: + + + + C1: A001 DELETE FOO + S1: A001 OK Mailbox FOO is deleted. + + + + C2: B001 STORE 1 +FLAGS (\Seen) + S2: * 1 FETCH FLAGS (\Seen) + S2: B001 OK STORE completed + + + + C3: C001 STATUS FOO (MESSAGES) + S3: C001 NO Mailbox does not exist + + + + C3: C002 CREATE FOO + S3: C002 NO Mailbox FOO is still in use. Try again later. + + + + +Gahrns Informational [Page 3] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + + + + C2: B002 CLOSE + S2: B002 OK CLOSE Completed + + + + C3: C003 CREATE FOO + S3: C003 OK CREATE Completed + + +3.3. The server MAY allow the DELETE/RENAME of a multi-accessed + mailbox, but disconnect all other clients who have the mailbox + accessed by sending a untagged BYE response. + + A server may often choose to disconnect clients in the DELETE case, + but may choose to implement a "friendlier" method for the RENAME + case. + + Example: + + + + C1: A002 DELETE FOO + S1: A002 OK DELETE completed. + + + S2: * BYE Mailbox FOO has been deleted. + + +3.4. The server MAY allow the RENAME of a multi-accessed mailbox by + simply changing the name attribute on the mailbox. + + Other clients that have access to the mailbox can continue issuing + commands such as FETCH that do not reference the mailbox name. + Clients would discover the renaming the next time they referred to + the old mailbox name. Some servers MAY choose to include the + [NEWNAME] response code in their tagged NO response to a command that + contained the old mailbox name, as a hint to the client that the + operation can succeed if the command is issued with the new mailbox + name. + + + + + + + +Gahrns Informational [Page 4] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + + Example: + + + + C1: A001 RENAME FOO BAR + S1: A001 OK RENAME completed. + + + + C2: B001 FETCH 2:4 (FLAGS) + S2: * 2 FETCH . . . + S2: * 3 FETCH . . . + S2: * 4 FETCH . . . + S2: B001 OK FETCH completed + + + + C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994 + 21:52:25 0800 (PST) C2: . . . S2: B002 NO [NEWNAME FOO + BAR] Mailbox has been renamed + + +4. Expunging of messages on a multi-accessed mailbox + + If an external agent or multiple clients are accessing a mailbox, + care must be taken when handling the EXPUNGE of messages. Other + clients accessing the mailbox may be in the midst of issuing a + command that depends upon message sequence numbers. Because an + EXPUNGE response can not be sent while responding to a FETCH, STORE + or SEARCH command, it is not possible to immediately notify the + client of the EXPUNGE. This can result in ambiguity if the client + issues a FETCH, STORE or SEARCH operation on a message that has been + EXPUNGED. + + +4.1. Fetching of expunged messages + + Following are some strategies an IMAP server may choose to use when + dealing with a FETCH command on expunged messages. + + + + + + + + + +Gahrns Informational [Page 5] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + + Consider the following scenario: + + - Client #1 and Client #2 have mailbox FOO selected. + - There are 7 messages in the mailbox. + - Messages 4:7 are marked for deletion. + - Client #1 issues an EXPUNGE, to expunge messages 4:7 + + +4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but + keep the messages available to satisfy subsequent FETCH commands + until it is able to send an EXPUNGE response to each client. + + In some cases, the behavior of keeping "ghosted" messages may not be + desirable. For example if a message contained offensive or sensitive + information, one might prefer to instantaneously remove all access to + the information, regardless of whether another client is in the midst + of accessing it. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 FETCH 4:7 RFC822 + S2: * 4 FETCH RFC822 . . . (RFC822 info returned) + S2: * 5 FETCH RFC822 . . . (RFC822 info returned) + S2: * 6 FETCH RFC822 . . . (RFC822 info returned) + S2: * 7 FETCH RFC822 . . . (RFC822 info returned) + S2: B001 OK FETCH Completed + + + + C2: B002 NOOP + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 3 EXISTS + S2: B002 OK NOOP Complete + + + + C2: B003 FETCH 4:7 RFC822 + S2: B003 NO Messages 4:7 are no longer available. + + + + + + +Gahrns Informational [Page 6] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox, + and on subsequent FETCH commands return FETCH responses only for + non-expunged messages and a tagged NO. + + After receiving a tagged NO FETCH response, the client SHOULD issue a + NOOP command so that it will be informed of any pending EXPUNGE + responses. The client may then either reissue the failed FETCH + command, or by examining the EXPUNGE response from the NOOP and the + FETCH response from the FETCH, determine that the FETCH failed + because of pending expunges. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 FETCH 3:5 ENVELOPE + S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) + S2: B001 NO Some of the requested messages no longer exist + + + + C2: B002 NOOP + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 3 EXISTS + S2: B002 OK NOOP Completed. + + + + + + + + + + + + + + + + + + +Gahrns Informational [Page 7] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and + on subsequent FETCH commands return the usual FETCH responses for + non-expunged messages, "NIL FETCH Responses" for expunged + messages, and a tagged OK response. + + If all of the messages in the subsequent FETCH command have been + expunged, the server SHOULD return only a tagged NO. In this case, + the client SHOULD issue a NOOP command so that it will be informed of + any pending EXPUNGE responses. The client may then either reissue + the failed FETCH command, or by examining the EXPUNGE response from + the NOOP, determine that the FETCH failed because of pending + expunges. + + "NIL FETCH responses" are a representation of empty data as + appropriate for the FETCH argument specified. + + Example: + + * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL)) + * 1 FETCH (FLAGS ()) + * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000") + * 1 FETCH (RFC822 "") + * 1 FETCH (RFC822.HEADER "") + * 1 FETCH (RFC822.TEXT "") + * 1 FETCH (RFC822.SIZE 0) + * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) + * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) + * 1 FETCH (BODY[
] "") + * 1 FETCH (BODY[
] "") + + In some cases, a client may not be able to distinguish between "NIL + FETCH responses" received because a message was expunged and those + received because the data actually was NIL. For example, a * 5 + FETCH (FLAGS ()) response could be received if no flags were set on + message 5, or because message 5 was expunged. In a case of potential + ambiguity, the client SHOULD issue a command such as NOOP to force + the sending of the EXPUNGE responses to resolve any ambiguity. + + Example: (Building upon the scenario outlined in 4.1.) + + + + + + + + + + +Gahrns Informational [Page 8] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + + C2: B002 FETCH 3:5 ENVELOPE + S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) + S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL + NIL NIL) + S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL + NIL NIL) + S2: B002 OK FETCH Completed + + + + C2: B002 FETCH 4:7 ENVELOPE + S2: B002 NO Messages 4:7 have been expunged. + + +4.1.4 To avoid the situation altogether, the server MAY fail the + EXPUNGE of a multi-accessed mailbox + + In some cases, this behavior may not be practical. For example, if a + large number of clients are accessing a shared mailbox, the window in + which no clients have the mailbox accessed may be small or non- + existent, effectively rendering the message unexpungeable. + + +4.2. Storing of expunged messages + + Following are some strategies an IMAP server may choose to use when + dealing with a STORE command on expunged messages. + + +4.2.1 If the ".SILENT" suffix is used, and the STORE completed + successfully for all the non-expunged messages, the server SHOULD + return a tagged OK. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN) + S2: B001 OK + + + + + + + + + +Gahrns Informational [Page 9] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +4.2.2. If the ".SILENT" suffix is not used, and only expunged messages + are referenced, the server SHOULD return only a tagged NO. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 STORE 5:7 +FLAGS (\SEEN) + S2: B001 NO Messages have been expunged + + +4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged + and non-expunged messages are referenced, the server MAY set the + flags and return a FETCH response for the non-expunged messages + along with a tagged NO. + + After receiving a tagged NO STORE response, the client SHOULD issue a + NOOP command so that it will be informed of any pending EXPUNGE + responses. The client may then either reissue the failed STORE + command, or by examining the EXPUNGE responses from the NOOP and + FETCH responses from the STORE, determine that the STORE failed + because of pending expunges. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 STORE 1:7 +FLAGS (\SEEN) + S2: * FETCH 1 FLAGS (\SEEN) + S2: * FETCH 2 FLAGS (\SEEN) + S2: * FETCH 3 FLAGS (\SEEN) + S2: B001 NO Some of the messages no longer exist. + + C2: B002 NOOP + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 3 EXISTS + S2: B002 OK NOOP Completed. + + + + + + + + +Gahrns Informational [Page 10] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged + and non-expunged messages are referenced, the server MAY return + an untagged NO and not set any flags. + + After receiving a tagged NO STORE response, the client SHOULD issue a + NOOP command so that it will be informed of any pending EXPUNGE + responses. The client would then re-issue the STORE command after + updating its message list per any EXPUNGE response. + + If a large number of clients are accessing a shared mailbox, the + window in which there are no pending expunges may be small or non- + existent, effectively disallowing a client from setting the flags on + all messages at once. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 STORE 1:7 +FLAGS (\SEEN) + S2: B001 NO Some of the messages no longer exist. + + + + C2: B002 NOOP + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 3 EXISTS + S2: B002 OK NOOP Completed. + + + + C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS + (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS + (\SEEN) S2: B003 OK STORE Completed + + +4.3. Searching of expunged messages + + A server MAY simply not return a search response for messages that + have been expunged and it has not been able to inform the client + about. If a client was expecting a particular message to be returned + in a search result, and it was not, the client SHOULD issue a NOOP + command to see if the message was expunged by another client. + + + + +Gahrns Informational [Page 11] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +4.4 Copying of expunged messages + + COPY is the only IMAP4 sequence number command that is safe to allow + an EXPUNGE response on. This is because a client is not permitted to + cascade several COPY commands together. A client is required to wait + and confirm that the copy worked before issuing another one. + +4.4.1 The server MAY disallow the COPY of messages in a multi-access + mailbox that contains expunged messages. + + Pending EXPUNGE response(s) MUST be returned to the COPY command. + + Example: + + C: A001 COPY 2,4,6,8 FRED + S: * 4 EXPUNGE + S: A001 NO COPY rejected, because some of the requested + messages were expunged + + Note: Non of the above messages are copied because if a COPY command + is unsuccessful, the server MUST restore the destination mailbox to + its state before the COPY attempt. + + +4.4.2 The server MAY allow the COPY of messages in a multi-access + mailbox that contains expunged messages. + + Pending EXPUNGE response(s) MUST be returned to the COPY command. + Messages that are copied are messages corresponding to sequence + numbers before any EXPUNGE response. + + Example: + + C: A001 COPY 2,4,6,8 FRED + S: * 3 EXPUNGE + S: A001 OK COPY completed + + In the above example, the messages that are copied to FRED are + messages 2,4,6,8 at the start of the COPY command. These are + equivalent to messages 2,3,5,7 at the end of the COPY command. The + EXPUNGE response can't take place until after the messages from the + COPY command are identified (because of the "no expunge while no + commands in progress" rule). + + + + + + + + +Gahrns Informational [Page 12] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + + Example: + + C: A001 COPY 2,4,6,8 FRED + S: * 4 EXPUNGE + S: A001 OK COPY completed + + In the above example, message 4 was copied before it was expunged, + and MUST appear in the destination mailbox FRED. + + +5. Security Considerations + + This document describes behavior of servers that use the IMAP4 + protocol, and as such, has the same security considerations as + described in [RFC-2060]. + + In particular, some described server behavior does not allow for the + immediate deletion of information when a mailbox is accessed by + multiple clients. This may be a consideration when dealing with + sensitive information where immediate deletion would be preferred. + + +6. References + + [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, Harvard University, March 1997. + + +7. Acknowledgments + + This document is the result of discussions on the IMAP4 mailing list + and is meant to reflect consensus of this group. In particular, + Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole, + Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry + Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De + Winter were active participants in this discussion or made + suggestions to this document. + + + + + + + + + + + +Gahrns Informational [Page 13] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +8. Author's Address + + Mike Gahrns + Microsoft + One Microsoft Way + Redmond, WA, 98072 + + Phone: (206) 936-9833 + EMail: mikega@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gahrns Informational [Page 14] + diff --git a/server/src/site/resources/rfclist/imap4/rfc2192.txt b/server/src/site/resources/rfclist/imap4/rfc2192.txt new file mode 100644 index 00000000000..a8ac12d04a4 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2192.txt @@ -0,0 +1,900 @@ + + + + + +Network Working Group C. Newman +Request for Comments: 2192 Innosoft +Category: Standards Track September 1997 + + + IMAP URL Scheme + + +Status of this memo + + This document specifies an Internet standards track protocol for + the Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is + unlimited. + + +Abstract + + IMAP [IMAP4] is a rich protocol for accessing remote message + stores. It provides an ideal mechanism for accessing public + mailing list archives as well as private and shared message stores. + This document defines a URL scheme for referencing objects on an + IMAP server. + + +1. Conventions used in this document + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as defined in "Key words for + use in RFCs to Indicate Requirement Levels" [KEYWORDS]. + + +2. IMAP scheme + + The IMAP URL scheme is used to designate IMAP servers, mailboxes, + messages, MIME bodies [MIME], and search programs on Internet hosts + accessible using the IMAP protocol. + + The IMAP URL follows the common Internet scheme syntax as defined + in RFC 1738 [BASIC-URL] except that clear text passwords are not + permitted. If : is omitted, the port defaults to 143. + + + + + + + + +Newman Standards Track [Page 1] + +RFC 2192 IMAP URL Scheme September 1997 + + + An IMAP URL takes one of the following forms: + + imap:/// + imap:///;TYPE= + imap:///[uidvalidity][?] + imap:///[uidvalidity][isection] + + The first form is used to refer to an IMAP server, the second form + refers to a list of mailboxes, the third form refers to the + contents of a mailbox or a set of messages resulting from a search, + and the final form refers to a specific message or message part. + Note that the syntax here is informal. The authoritative formal + syntax for IMAP URLs is defined in section 11. + + +3. IMAP User Name and Authentication Mechanism + + A user name and/or authentication mechanism may be supplied. They + are used in the "LOGIN" or "AUTHENTICATE" commands after making the + connection to the IMAP server. If no user name or authentication + mechanism is supplied, the user name "anonymous" is used with the + "LOGIN" command and the password is supplied as the Internet e-mail + address of the end user accessing the resource. If the URL doesn't + supply a user name, the program interpreting the IMAP URL SHOULD + request one from the user if necessary. + + An authentication mechanism can be expressed by adding + ";AUTH=" to the end of the user name. When such an + is indicated, the client SHOULD request appropriate + credentials from that mechanism and use the "AUTHENTICATE" command + instead of the "LOGIN" command. If no user name is specified, one + SHOULD be obtained from the mechanism or requested from the user as + appropriate. + + The string ";AUTH=*" indicates that the client SHOULD select an + appropriate authentication mechanism. It MAY use any mechanism + listed in the CAPABILITY command or use an out of band security + service resulting in a PREAUTH connection. If no user name is + specified and no appropriate authentication mechanisms are + available, the client SHOULD fall back to anonymous login as + described above. This allows a URL which grants read-write access + to authorized users, and read-only anonymous access to other users. + + If a user name is included with no authentication mechanism, then + ";AUTH=*" is assumed. + + + + + + +Newman Standards Track [Page 2] + +RFC 2192 IMAP URL Scheme September 1997 + + + Since URLs can easily come from untrusted sources, care must be + taken when resolving a URL which requires or requests any sort of + authentication. If authentication credentials are supplied to the + wrong server, it may compromise the security of the user's account. + The program resolving the URL should make sure it meets at least + one of the following criteria in this case: + + (1) The URL comes from a trusted source, such as a referral server + which the client has validated and trusts according to site policy. + Note that user entry of the URL may or may not count as a trusted + source, depending on the experience level of the user and site + policy. + (2) Explicit local site policy permits the client to connect to the + server in the URL. For example, if the client knows the site + domain name, site policy may dictate that any hostname ending in + that domain is trusted. + (3) The user confirms that connecting to that domain name with the + specified credentials and/or mechanism is permitted. + (4) A mechanism is used which validates the server before passing + potentially compromising client credentials. + (5) An authentication mechanism is used which will not reveal + information to the server which could be used to compromise future + connections. + + URLs which do not include a user name must be treated with extra + care, since they are more likely to compromise the user's primary + account. A URL containing ";AUTH=*" must also be treated with + extra care since it might fall back on a weaker security mechanism. + Finally, clients are discouraged from using a plain text password + as a fallback with ";AUTH=*" unless the connection has strong + encryption (e.g. a key length of greater than 56 bits). + + A program interpreting IMAP URLs MAY cache open connections to an + IMAP server for later re-use. If a URL contains a user name, only + connections authenticated as that user may be re-used. If a URL + does not contain a user name or authentication mechanism, then only + an anonymous connection may be re-used. If a URL contains an + authentication mechanism without a user name, then any non- + anonymous connection may be re-used. + + Note that if unsafe or reserved characters such as " " or ";" are + present in the user name or authentication mechanism, they MUST be + encoded as described in RFC 1738 [BASIC-URL]. + + + + + + + + +Newman Standards Track [Page 3] + +RFC 2192 IMAP URL Scheme September 1997 + + +4. IMAP server + + An IMAP URL referring to an IMAP server has the following form: + + imap:/// + + A program interpreting this URL would issue the standard set of + commands it uses to present a view of the contents of an IMAP + server. This is likely to be semanticly equivalent to one of the + following URLs: + + imap:///;TYPE=LIST + imap:///;TYPE=LSUB + + The program interpreting this URL SHOULD use the LSUB form if it + supports mailbox subscriptions. + + +5. Lists of mailboxes + + An IMAP URL referring to a list of mailboxes has the following + form: + + imap:///;TYPE= + + The may be either "LIST" or "LSUB", and is case + insensitive. The field ";TYPE=" MUST be included. + + The is any argument suitable for the + list_mailbox field of the IMAP [IMAP4] LIST or LSUB commands. The + field may be omitted, in which case the program + interpreting the IMAP URL may use "*" or "%" as the + . The program SHOULD use "%" if it supports a + hierarchical view, otherwise it SHOULD use "*". + + Note that if unsafe or reserved characters such as " " or "%" are + present in they MUST be encoded as described in + RFC 1738 [BASIC-URL]. If the character "/" is present in + enc_list_mailbox, it SHOULD NOT be encoded. + + +6. Lists of messages + + An IMAP URL referring to a list of messages has the following form: + + imap:///[uidvalidity][?] + + + + + +Newman Standards Track [Page 4] + +RFC 2192 IMAP URL Scheme September 1997 + + + The field is used as the argument to the IMAP4 + "SELECT" command. Note that if unsafe or reserved characters such + as " ", ";", or "?" are present in they MUST be + encoded as described in RFC 1738 [BASIC-URL]. If the character "/" + is present in enc_mailbox, it SHOULD NOT be encoded. + + The [uidvalidity] field is optional. If it is present, it MUST be + the argument to the IMAP4 UIDVALIDITY status response at the time + the URL was created. This SHOULD be used by the program + interpreting the IMAP URL to determine if the URL is stale. + + The [?] field is optional. If it is not present, the + contents of the mailbox SHOULD be presented by the program + interpreting the URL. If it is present, it SHOULD be used as the + arguments following an IMAP4 SEARCH command with unsafe characters + such as " " (which are likely to be present in the ) + encoded as described in RFC 1738 [BASIC-URL]. + + +7. A specific message or message part + + An IMAP URL referring to a specific message or message part has the + following form: + + imap:///[uidvalidity][isection] + + The and [uidvalidity] are as defined above. + + If [uidvalidity] is present in this form, it SHOULD be used by the + program interpreting the URL to determine if the URL is stale. + + The refers to an IMAP4 message UID, and SHOULD be used as + the argument to the IMAP4 "UID FETCH" command. + + The [isection] field is optional. If not present, the URL refers + to the entire Internet message as returned by the IMAP command "UID + FETCH BODY.PEEK[]". If present, the URL refers to the object + returned by a "UID FETCH BODY.PEEK[
]" command. The + type of the object may be determined with a "UID FETCH + BODYSTRUCTURE" command and locating the appropriate part in the + resulting BODYSTRUCTURE. Note that unsafe characters in [isection] + MUST be encoded as described in [BASIC-URL]. + + + + + + + + + +Newman Standards Track [Page 5] + +RFC 2192 IMAP URL Scheme September 1997 + + +8. Relative IMAP URLs + + Relative IMAP URLs are permitted and are resolved according to the + rules defined in RFC 1808 [REL-URL] with one exception. In IMAP + URLs, parameters are treated as part of the normal path with + respect to relative URL resolution. This is believed to be the + behavior of the installed base and is likely to be documented in a + future revision of the relative URL specification. + + The following observations are also important: + + The grammar element is considered part of the user name for + purposes of resolving relative IMAP URLs. This means that unless a + new login/server specification is included in the relative URL, the + authentication mechanism is inherited from a base IMAP URL. + + URLs always use "/" as the hierarchy delimiter for the purpose of + resolving paths in relative URLs. IMAP4 permits the use of any + hierarchy delimiter in mailbox names. For this reason, relative + mailbox paths will only work if the mailbox uses "/" as the + hierarchy delimiter. Relative URLs may be used on mailboxes which + use other delimiters, but in that case, the entire mailbox name + MUST be specified in the relative URL or inherited as a whole from + the base URL. + + The base URL for a list of mailboxes or messages which was referred + to by an IMAP URL is always the referring IMAP URL itself. The + base URL for a message or message part which was referred to by an + IMAP URL may be more complicated to determine. The program + interpreting the relative URL will have to check the headers of the + MIME entity and any enclosing MIME entities in order to locate the + "Content-Base" and "Content-Location" headers. These headers are + used to determine the base URL as defined in [HTTP]. For example, + if the referring IMAP URL contains a "/;SECTION=1.2" parameter, + then the MIME headers for section 1.2, for section 1, and for the + enclosing message itself SHOULD be checked in that order for + "Content-Base" or "Content-Location" headers. + + +9. Multinational Considerations + + IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding + non-US-ASCII characters in IMAP mailbox names. Because this + convention is private to IMAP, it is necessary to convert IMAP's + encoding to one that can be more easily interpreted by a URL + display program. For this reason, IMAP's modified UTF-7 encoding + for mailboxes MUST be converted to UTF-8 [UTF8]. Since 8-bit + characters are not permitted in URLs, the UTF-8 characters are + + + +Newman Standards Track [Page 6] + +RFC 2192 IMAP URL Scheme September 1997 + + + encoded as required by the URL specification [BASIC-URL]. Sample + code is included in Appendix A to demonstrate this conversion. + + +10. Examples + + The following examples demonstrate how an IMAP4 client program + might translate various IMAP4 URLs into a series of IMAP4 commands. + Commands sent from the client to the server are prefixed with "C:", + and responses sent from the server to the client are prefixed with + "S:". + + The URL: + + + + Results in the following client commands: + + + C: A001 LOGIN ANONYMOUS sheridan@babylon5.org + C: A002 SELECT gray-council + + C: A003 UID FETCH 20 BODY.PEEK[] + + The URL: + + + + Results in the following client commands: + + + + C: A001 LOGIN MICHAEL zipper + C: A002 LIST "" users.* + + The URL: + + + + Results in the following client commands: + + + C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.org + C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw- + + + + + + +Newman Standards Track [Page 7] + +RFC 2192 IMAP URL Scheme September 1997 + + + The URL: + + + + Results in the following client commands: + + + C: A001 AUTHENTICATE KERBEROS_V4 + + C: A002 SELECT gray-council + C: A003 UID FETCH 20 BODY.PEEK[1.2] + + If the following relative URL is located in that body part: + + <;section=1.4> + + This could result in the following client commands: + + C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME] + BODY.PEEK[1.MIME] + BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)]) + + C: A005 UID FETCH 20 BODY.PEEK[1.4] + + The URL: + + + + Could result in the following: + + + C: A001 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI + S: A001 OK + C: A002 AUTHENTICATE GSSAPI + + S: A002 OK user lennier authenticated + C: A003 SELECT "gray council" + ... + C: A004 SEARCH SUBJECT shadows + S: * SEARCH 8 10 13 14 15 16 + S: A004 OK SEARCH completed + C: A005 FETCH 8,10,13:16 ALL + ... + + + + + +Newman Standards Track [Page 8] + +RFC 2192 IMAP URL Scheme September 1997 + + + NOTE: In this final example, the client has implementation + dependent choices. The authentication mechanism could be anything, + including PREAUTH. And the final FETCH command could fetch more or + less information about the messages, depending on what it wishes to + display to the user. + + +11. Security Considerations + + Security considerations discussed in the IMAP specification [IMAP4] + and the URL specification [BASIC-URL] are relevant. Security + considerations related to authenticated URLs are discussed in + section 3 of this document. + + Many email clients store the plain text password for later use + after logging into an IMAP server. Such clients MUST NOT use a + stored password in response to an IMAP URL without explicit + permission from the user to supply that password to the specified + host name. + + +12. ABNF for IMAP URL scheme + + This uses ABNF as defined in RFC 822 [IMAIL]. Terminals from the + BNF for IMAP [IMAP4] and URLs [BASIC-URL] are also used. Strings + are not case sensitive and free insertion of linear-white-space is + not permitted. + + achar = uchar / "&" / "=" / "~" + ; see [BASIC-URL] for "uchar" definition + + bchar = achar / ":" / "@" / "/" + + enc_auth_type = 1*achar + ; encoded version of [IMAP-AUTH] "auth_type" + + enc_list_mailbox = 1*bchar + ; encoded version of [IMAP4] "list_mailbox" + + enc_mailbox = 1*bchar + ; encoded version of [IMAP4] "mailbox" + + enc_search = 1*bchar + ; encoded version of search_program below + + enc_section = 1*bchar + ; encoded version of section below + + + + +Newman Standards Track [Page 9] + +RFC 2192 IMAP URL Scheme September 1997 + + + enc_user = 1*achar + ; encoded version of [IMAP4] "userid" + + imapurl = "imap://" iserver "/" [ icommand ] + + iauth = ";AUTH=" ( "*" / enc_auth_type ) + + icommand = imailboxlist / imessagelist / imessagepart + + imailboxlist = [enc_list_mailbox] ";TYPE=" list_type + + imessagelist = enc_mailbox [ "?" enc_search ] [uidvalidity] + + imessagepart = enc_mailbox [uidvalidity] iuid [isection] + + isection = "/;SECTION=" enc_section + + iserver = [iuserauth "@"] hostport + ; See [BASIC-URL] for "hostport" definition + + iuid = "/;UID=" nz_number + ; See [IMAP4] for "nz_number" definition + + iuserauth = enc_user [iauth] / [enc_user] iauth + + list_type = "LIST" / "LSUB" + + search_program = ["CHARSET" SPACE astring SPACE] + search_key *(SPACE search_key) + ; IMAP4 literals may not be used + ; See [IMAP4] for "astring" and "search_key" + + section = section_text / (nz_number *["." nz_number] + ["." (section_text / "MIME")]) + ; See [IMAP4] for "section_text" and "nz_number" + + uidvalidity = ";UIDVALIDITY=" nz_number + ; See [IMAP4] for "nz_number" definition + +13. References + + [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource + Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of + Minnesota, December 1994. + + + + + + + +Newman Standards Track [Page 10] + +RFC 2192 IMAP URL Scheme September 1997 + + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + + + [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, + Carnegie-Mellon University, December 1994. + + + + [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS, + January 1997. + + + + [IMAIL] Crocker, "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, University of Delaware, August 1982. + + + + [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, Harvard University, March 1997. + + + + [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail + Extensions", RFC 2045, Innosoft, First Virtual, November 1996. + + + + [REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808, + UC Irvine, June 1995. + + + + [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and + ISO 10646", RFC 2044, Alis Technologies, October 1996. + + + +14. Author's Address + + Chris Newman + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 USA + EMail: chris.newman@innosoft.com + + + +Newman Standards Track [Page 11] + +RFC 2192 IMAP URL Scheme September 1997 + + +Appendix A. Sample code + +Here is sample C source code to convert between URL paths and IMAP +mailbox names, taking into account mapping between IMAP's modified UTF-7 +[IMAP4] and hex-encoded UTF-8 which is more appropriate for URLs. This +code has not been rigorously tested nor does it necessarily behave +reasonably with invalid input, but it should serve as a useful example. +This code just converts the mailbox portion of the URL and does not deal +with parameters, query or server components of the URL. + +#include +#include + +/* hexadecimal lookup table */ +static char hex[] = "0123456789ABCDEF"; + +/* URL unsafe printable characters */ +static char urlunsafe[] = " \"#%&+:;<=>?@[\\]^`{|}"; + +/* UTF7 modified base64 alphabet */ +static char base64chars[] = + "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,"; +#define UNDEFINED 64 + +/* UTF16 definitions */ +#define UTF16MASK 0x03FFUL +#define UTF16SHIFT 10 +#define UTF16BASE 0x10000UL +#define UTF16HIGHSTART 0xD800UL +#define UTF16HIGHEND 0xDBFFUL +#define UTF16LOSTART 0xDC00UL +#define UTF16LOEND 0xDFFFUL + +/* Convert an IMAP mailbox to a URL path + * dst needs to have roughly 4 times the storage space of src + * Hex encoding can triple the size of the input + * UTF-7 can be slightly denser than UTF-8 + * (worst case: 8 octets UTF-7 becomes 9 octets UTF-8) + */ +void MailboxToURL(char *dst, char *src) +{ + unsigned char c, i, bitcount; + unsigned long ucs4, utf16, bitbuf; + unsigned char base64[256], utf8[6]; + + + + + + + +Newman Standards Track [Page 12] + +RFC 2192 IMAP URL Scheme September 1997 + + + /* initialize modified base64 decoding table */ + memset(base64, UNDEFINED, sizeof (base64)); + for (i = 0; i < sizeof (base64chars); ++i) { + base64[base64chars[i]] = i; + } + + /* loop until end of string */ + while (*src != '\0') { + c = *src++; + /* deal with literal characters and &- */ + if (c != '&' || *src == '-') { + if (c < ' ' || c > '~' || strchr(urlunsafe, c) != NULL) { + /* hex encode if necessary */ + dst[0] = '%'; + dst[1] = hex[c >> 4]; + dst[2] = hex[c & 0x0f]; + dst += 3; + } else { + /* encode literally */ + *dst++ = c; + } + /* skip over the '-' if this is an &- sequence */ + if (c == '&') ++src; + } else { + /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */ + bitbuf = 0; + bitcount = 0; + ucs4 = 0; + while ((c = base64[(unsigned char) *src]) != UNDEFINED) { + ++src; + bitbuf = (bitbuf << 6) | c; + bitcount += 6; + /* enough bits for a UTF-16 character? */ + if (bitcount >= 16) { + bitcount -= 16; + utf16 = (bitcount ? bitbuf >> bitcount + : bitbuf) & 0xffff; + /* convert UTF16 to UCS4 */ + if + (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) { + ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT; + continue; + } else if + (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) { + ucs4 += utf16 - UTF16LOSTART + UTF16BASE; + } else { + ucs4 = utf16; + } + + + +Newman Standards Track [Page 13] + +RFC 2192 IMAP URL Scheme September 1997 + + + /* convert UTF-16 range of UCS4 to UTF-8 */ + if (ucs4 <= 0x7fUL) { + utf8[0] = ucs4; + i = 1; + } else if (ucs4 <= 0x7ffUL) { + utf8[0] = 0xc0 | (ucs4 >> 6); + utf8[1] = 0x80 | (ucs4 & 0x3f); + i = 2; + } else if (ucs4 <= 0xffffUL) { + utf8[0] = 0xe0 | (ucs4 >> 12); + utf8[1] = 0x80 | ((ucs4 >> 6) & 0x3f); + utf8[2] = 0x80 | (ucs4 & 0x3f); + i = 3; + } else { + utf8[0] = 0xf0 | (ucs4 >> 18); + utf8[1] = 0x80 | ((ucs4 >> 12) & 0x3f); + utf8[2] = 0x80 | ((ucs4 >> 6) & 0x3f); + utf8[3] = 0x80 | (ucs4 & 0x3f); + i = 4; + } + /* convert utf8 to hex */ + for (c = 0; c < i; ++c) { + dst[0] = '%'; + dst[1] = hex[utf8[c] >> 4]; + dst[2] = hex[utf8[c] & 0x0f]; + dst += 3; + } + } + } + /* skip over trailing '-' in modified UTF-7 encoding */ + if (*src == '-') ++src; + } + } + /* terminate destination string */ + *dst = '\0'; +} + +/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox + * dst should be about twice the length of src to deal with non-hex + * coded URLs + */ +void URLtoMailbox(char *dst, char *src) +{ + unsigned int utf8pos, utf8total, i, c, utf7mode, bitstogo, utf16flag; + unsigned long ucs4, bitbuf; + unsigned char hextab[256]; + + /* initialize hex lookup table */ + + + +Newman Standards Track [Page 14] + +RFC 2192 IMAP URL Scheme September 1997 + + + memset(hextab, 0, sizeof (hextab)); + for (i = 0; i < sizeof (hex); ++i) { + hextab[hex[i]] = i; + if (isupper(hex[i])) hextab[tolower(hex[i])] = i; + } + + utf7mode = 0; + utf8total = 0; + bitstogo = 0; + while ((c = *src) != '\0') { + ++src; + /* undo hex-encoding */ + if (c == '%' && src[0] != '\0' && src[1] != '\0') { + c = (hextab[src[0]] << 4) | hextab[src[1]]; + src += 2; + } + /* normal character? */ + if (c >= ' ' && c <= '~') { + /* switch out of UTF-7 mode */ + if (utf7mode) { + if (bitstogo) { + *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; + } + *dst++ = '-'; + utf7mode = 0; + } + *dst++ = c; + /* encode '&' as '&-' */ + if (c == '&') { + *dst++ = '-'; + } + continue; + } + /* switch to UTF-7 mode */ + if (!utf7mode) { + *dst++ = '&'; + utf7mode = 1; + } + /* Encode US-ASCII characters as themselves */ + if (c < 0x80) { + ucs4 = c; + utf8total = 1; + } else if (utf8total) { + /* save UTF8 bits into UCS4 */ + ucs4 = (ucs4 << 6) | (c & 0x3FUL); + if (++utf8pos < utf8total) { + continue; + } + + + +Newman Standards Track [Page 15] + +RFC 2192 IMAP URL Scheme September 1997 + + + } else { + utf8pos = 1; + if (c < 0xE0) { + utf8total = 2; + ucs4 = c & 0x1F; + } else if (c < 0xF0) { + utf8total = 3; + ucs4 = c & 0x0F; + } else { + /* NOTE: can't convert UTF8 sequences longer than 4 */ + utf8total = 4; + ucs4 = c & 0x03; + } + continue; + } + /* loop to split ucs4 into two utf16 chars if necessary */ + utf8total = 0; + do { + if (ucs4 >= UTF16BASE) { + ucs4 -= UTF16BASE; + bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT) + + UTF16HIGHSTART); + ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART; + utf16flag = 1; + } else { + bitbuf = (bitbuf << 16) | ucs4; + utf16flag = 0; + } + bitstogo += 16; + /* spew out base64 */ + while (bitstogo >= 6) { + bitstogo -= 6; + *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo) + : bitbuf) + & 0x3F]; + } + } while (utf16flag); + } + /* if in UTF-7 mode, finish in ASCII */ + if (utf7mode) { + if (bitstogo) { + *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; + } + *dst++ = '-'; + } + /* tie off string */ + *dst = '\0'; +} + + + +Newman Standards Track [Page 16] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2193.txt b/server/src/site/resources/rfclist/imap4/rfc2193.txt new file mode 100644 index 00000000000..09dd90f79f1 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2193.txt @@ -0,0 +1,508 @@ + + + + + +Network Working Group M. Gahrns +Request for Comments: 2193 Microsoft +Category: Standards Track September 1997 + + + IMAP4 Mailbox Referrals + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + When dealing with large amounts of users, messages and geographically + dispersed IMAP4 [RFC-2060] servers, it is often desirable to + distribute messages amongst different servers within an organization. + For example an administrator may choose to store user's personal + mailboxes on a local IMAP4 server, while storing shared mailboxes + remotely on another server. This type of configuration is common + when it is uneconomical to store all data centrally due to limited + bandwidth or disk resources. + + Mailbox referrals allow clients to seamlessly access mailboxes that + are distributed across several IMAP4 servers. + + A referral mechanism can provide efficiencies over the alternative + "proxy method", in which the local IMAP4 server contacts the remote + server on behalf of the client, and then transfers the data from the + remote server to itself, and then on to the client. The referral + mechanism's direct client connection to the remote server is often a + more efficient use of bandwidth, and does not require the local + server to impersonate the client when authenticating to the remote + server. + +2. Conventions used in this document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + A home server, is an IMAP4 server that contains the user's inbox. + + A remote mailbox is a mailbox that is not hosted on the user's home + server. + + + + +Gahrns Standards Track [Page 1] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + A remote server is a server that contains remote mailboxes. + + A shared mailbox, is a mailbox that multiple users have access to. + + An IMAP mailbox referral is when the server directs the client to + another IMAP mailbox. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + +3. Introduction and Overview + + IMAP4 servers that support this extension MUST list the keyword + MAILBOX-REFERRALS in their CAPABILITY response. No client action is + needed to invoke the MAILBOX-REFERRALS capability in a server. + + A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals + that result in a referrals loop. + + A referral response consists of a tagged NO response and a REFERRAL + response code. The REFERRAL response code MUST contain as an + argument a one or more valid URLs separated by a space as defined in + [RFC-1738]. If a server replies with multiple URLs for a particular + object, they MUST all be of the same type. In this case, the URL MUST + be an IMAP URL as defined in [RFC-2192]. A client that supports the + REFERRALS extension MUST be prepared for a URL of any type, but it + need only be able to process IMAP URLs. + + A server MAY respond with multiple IMAP mailbox referrals if there is + more than one replica of the mailbox. This allows the implementation + of a load balancing or failover scheme. How a server keeps multiple + replicas of a mailbox in sync is not addressed by this document. + + If the server has a preferred order in which the client should + attempt to access the URLs, the preferred URL SHOULD be listed in the + first, with the remaining URLs presented in descending order of + preference. If multiple referrals are given for a mailbox, a server + should be aware that there are synchronization issues for a client if + the UIDVALIDITY of the referred mailboxes are different. + + An IMAP mailbox referral may be given in response to an IMAP command + that specifies a mailbox as an argument. + + + + + + + + +Gahrns Standards Track [Page 2] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + Example: + + A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox + + NOTE: user;AUTH=* is specified as required by [RFC-2192] to avoid a + client falling back to anonymous login. + + Remote mailboxes and their inferiors, that are accessible only via + referrals SHOULD NOT appear in LIST and LSUB responses issued against + the user's home server. They MUST appear in RLIST and RLSUB + responses issued against the user's home server. Hierarchy referrals, + in which a client would be required to connect to the remote server + to issue a LIST to discover the inferiors of a mailbox are not + addressed in this document. + + For example, if shared mailboxes were only accessible via referrals + on a remote server, a RLIST "" "#SHARED/%" command would return the + same response if issued against the user's home server or the remote + server. + + Note: Mailboxes that are available on the user's home server do not + need to be available on the remote server. In addition, there may be + additional mailboxes available on the remote server, but they will + not accessible to the client via referrals unless they appear in the + LIST response to the RLIST command against the user's home server. + + A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB + commands in lieu of LIST and LSUB. The RLIST and RLSUB commands + behave identically to their LIST and LSUB counterparts, except remote + mailboxes are returned in addition to local mailboxes in the LIST and + LSUB responses. This avoids displaying to a non MAILBOX-REFERRALS + enabled client inaccessible remote mailboxes. + +4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND + Referrals + + An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE, + SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more + IMAP mailbox referrals to indicate to the client that the mailbox is + hosted on a remote server. + + When a client processes an IMAP mailbox referral, it will open a new + connection or use an existing connection to the remote server so that + it is able to issue the commands necessary to process the remote + mailbox. + + + + + + +Gahrns Standards Track [Page 3] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + Example: + + C: A001 DELETE "SHARED/FOO" + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] + Remote mailbox. Try SERVER2. + + + + S: * OK IMAP4rev1 server ready + C: B001 AUTHENTICATE KERBEROS_V4 + + S: B001 OK user is authenticated + + C: B002 DELETE "SHARED/FOO" + S: B002 OK DELETE completed + + Example: + + C: A001 SELECT REMOTE + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE + IMAP://user;AUTH=*@SERVER3/REMOTE] Remote mailbox. + Try SERVER2 or SERVER3. + + + + S: * OK IMAP4rev1 server ready + C: B001 AUTHENTICATE KERBEROS_V4 + + S: B001 OK user is authenticated + + C: B002 SELECT REMOTE + S: * 12 EXISTS + S: * 1 RECENT + S: * OK [UNSEEN 10] Message 10 is first unseen + S: * OK [UIDVALIDITY 123456789] + S: * FLAGS (Answered Flagged Deleted Seen Draft) + S: * OK [PERMANENTFLAGS (Answered Deleted Seen ] + S: B002 OK [READ-WRITE] Selected completed + + C: B003 FETCH 10:12 RFC822 + S: * 10 FETCH . . . + S: * 11 FETCH . . . + S: * 12 FETCH . . . + S: B003 OK FETCH Completed + + + + +Gahrns Standards Track [Page 4] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + + + C: B004 LOGOUT + S: * BYE IMAP4rev1 server logging out + S: B004 OK LOGOUT Completed + + + + C: A002 SELECT INBOX + S: * 16 EXISTS + S: * 2 RECENT + S: * OK [UNSEEN 10] Message 10 is first unseen + S: * OK [UIDVALIDITY 123456789] + S: * FLAGS (Answered Flagged Deleted Seen Draft) + S: * OK [PERMANENTFLAGS (Answered Deleted Seen ] + S: A002 OK [READ-WRITE] Selected completed + +4.2. CREATE Referrals + + An IMAP4 server MAY respond to the CREATE command with one or more + IMAP mailbox referrals, if it wishes to direct the client to issue + the CREATE against another server. The server can employ any means, + such as examining the hierarchy of the specified mailbox name, in + determining which server the mailbox should be created on. + + Example: + + C: A001 CREATE "SHARED/FOO" + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] + Mailbox should be created on remote server + + Alternatively, because a home server is required to maintain a + listing of referred remote mailboxes, a server MAY allow the creation + of a mailbox that will ultimately reside on a remote server against + the home server, and provide referrals on subsequent commands that + manipulate the mailbox. + + Example: + + C: A001 CREATE "SHARED/FOO" + S: A001 OK CREATE succeeded + + C: A002 SELECT "SHARED/FOO" + S: A002 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] + Remote mailbox. Try SERVER2 + + + + + +Gahrns Standards Track [Page 5] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + +4.3. RENAME Referrals + + An IMAP4 server MAY respond to the RENAME command with one or more + pairs of IMAP mailbox referrals. In each pair of IMAP mailbox + referrals, the first one is an URL to the existing mailbox name and + the second is an URL to the requested new mailbox name. + + If within an IMAP mailbox referral pair, the existing and new mailbox + URLs are on different servers, the remote servers are unable to + perform the RENAME operation. To achieve the same behavior of + server RENAME, the client MAY issue the constituent CREATE, FETCH, + APPEND, and DELETE commands against both servers. + + If within an IMAP mailbox referral pair, the existing and new mailbox + URLs are on the same server it is an indication that the currently + connected server is unable to perform the operation. The client can + simply re-issue the RENAME command on the remote server. + + Example: + + C: A001 RENAME FOO BAR + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER1/FOO + IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox + across servers + + Since the existing and new mailbox names are on different servers, + the client would be required to make a connection to both servers and + issue the constituent commands require to achieve the RENAME. + + Example: + + C: A001 RENAME FOO BAR + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/FOO + IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox + located on SERVER2 + + Since both the existing and new mailbox are on the same remote + server, the client can simply make a connection to the remote server + and re-issue the RENAME command. + +4.4. COPY Referrals + + An IMAP4 server MAY respond to the COPY command with one or more IMAP + mailbox referrals. This indicates that the destination mailbox is on + a remote server. To achieve the same behavior of a server COPY, the + client MAY issue the constituent FETCH and APPEND commands against + both servers. + + + + +Gahrns Standards Track [Page 6] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + Example: + + C: A001 COPY 1 "SHARED/STUFF" + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/STUFF] + Unable to copy message(s) to SERVER2. + +5.1 RLIST command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LIST + + Result: OK - RLIST Completed + NO - RLIST Failure + BAD - command unknown or arguments invalid + + The RLIST command behaves identically to its LIST counterpart, except + remote mailboxes are returned in addition to local mailboxes in the + LIST responses. + +5.2 RLSUB Command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LSUB + + Result: OK - RLSUB Completed + NO - RLSUB Failure + BAD - command unknown or arguments invalid + + The RLSUB command behaves identically to its LSUB counterpart, except + remote mailboxes are returned in addition to local mailboxes in the + LSUB responses. + +6. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) as described in [ABNF]. + + list_mailbox = as defined in [RFC-2060] + + mailbox = as defined in [RFC-2060] + + mailbox_referral = SPACE "NO" SPACE + (text / text_mime2) + ; See [RFC-2060] for , text and text_mime2 definition + + + +Gahrns Standards Track [Page 7] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + referral_response_code = "[" "REFERRAL" 1*(SPACE ) "]" + ; See [RFC-1738] for definition + + rlist = "RLIST" SPACE mailbox SPACE list_mailbox + + rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox + +6. Security Considerations + + The IMAP4 referral mechanism makes use of IMAP URLs, and as such, + have the same security considerations as general internet URLs [RFC- + 1738], and in particular IMAP URLs [RFC-2192]. + + With the MAILBOX-REFERRALS capability, it is potentially easier to + write a rogue server that injects a bogus referral response that + directs a user to an incorrect mailbox. Although referrals reduce + the effort to write such a server, the referral response makes + detection of the intrusion easier. + +7. References + + [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + [RFC-2192], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, + September 1997. + + [RFC-1738], Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform + Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, + University of Minnesota, December 1994. + + [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, Harvard University, March 1997. + + [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for + Syntax Specifications: ABNF", Work in Progress, Internet Mail + Consortium, April 1997. + +8. Acknowledgments + + Many valuable suggestions were received from private discussions and + the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin, + Mark Keasling, Chris Newman and Larry Osterman made significant + contributions to this document. + + + + + + + +Gahrns Standards Track [Page 8] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + +9. Author's Address + + Mike Gahrns + Microsoft + One Microsoft Way + Redmond, WA, 98072 + + Phone: (206) 936-9833 + EMail: mikega@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gahrns Standards Track [Page 9] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2195.txt b/server/src/site/resources/rfclist/imap4/rfc2195.txt new file mode 100644 index 00000000000..479fa28f674 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2195.txt @@ -0,0 +1,284 @@ + + + + + +Network Working Group J. Klensin +Request for Comments: 2195 R. Catoe +Category: Standards Track P. Krumviede +Obsoletes: 2095 MCI + September 1997 + + + IMAP/POP AUTHorize Extension for Simple Challenge/Response + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + While IMAP4 supports a number of strong authentication mechanisms as + described in RFC 1731, it lacks any mechanism that neither passes + cleartext, reusable passwords across the network nor requires either + a significant security infrastructure or that the mail server update + a mail-system-wide user authentication file on each mail access. + This specification provides a simple challenge-response + authentication protocol that is suitable for use with IMAP4. Since + it utilizes Keyed-MD5 digests and does not require that the secret be + stored in the clear on the server, it may also constitute an + improvement on APOP for POP3 use as specified in RFC 1734. + +1. Introduction + + Existing Proposed Standards specify an AUTHENTICATE mechanism for the + IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for + the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is + intended to be extensible; the four methods specified in [IMAP-AUTH] + are all fairly powerful and require some security infrastructure to + support. The base POP3 specification [POP3] also contains a + lightweight challenge-response mechanism called APOP. APOP is + associated with most of the risks associated with such protocols: in + particular, it requires that both the client and server machines have + access to the shared secret in cleartext form. CRAM offers a method + for avoiding such cleartext storage while retaining the algorithmic + simplicity of APOP in using only MD5, though in a "keyed" method. + + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 1] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + + At present, IMAP [IMAP] lacks any facility corresponding to APOP. + The only alternative to the strong mechanisms identified in [IMAP- + AUTH] is a presumably cleartext username and password, supported + through the LOGIN command in [IMAP]. This document describes a + simple challenge-response mechanism, similar to APOP and PPP CHAP + [PPP], that can be used with IMAP (and, in principle, with POP3). + + This mechanism also has the advantage over some possible alternatives + of not requiring that the server maintain information about email + "logins" on a per-login basis. While mechanisms that do require such + per-login history records may offer enhanced security, protocols such + as IMAP, which may have several connections between a given client + and server open more or less simultaneous, may make their + implementation particularly challenging. + +2. Challenge-Response Authentication Mechanism (CRAM) + + The authentication type associated with CRAM is "CRAM-MD5". + + The data encoded in the first ready response contains an + presumptively arbitrary string of random digits, a timestamp, and the + fully-qualified primary host name of the server. The syntax of the + unencoded form must correspond to that of an RFC 822 'msg-id' + [RFC822] as described in [POP3]. + + The client makes note of the data and then responds with a string + consisting of the user name, a space, and a 'digest'. The latter is + computed by applying the keyed MD5 algorithm from [KEYED-MD5] where + the key is a shared secret and the digested text is the timestamp + (including angle-brackets). + + This shared secret is a string known only to the client and server. + The `digest' parameter itself is a 16-octet value which is sent in + hexadecimal format, using lower-case ASCII characters. + + When the server receives this client response, it verifies the digest + provided. If the digest is correct, the server should consider the + client authenticated and respond appropriately. + + Keyed MD5 is chosen for this application because of the greater + security imparted to authentication of short messages. In addition, + the use of the techniques described in [KEYED-MD5] for precomputation + of intermediate results make it possible to avoid explicit cleartext + storage of the shared secret on the server system by instead storing + the intermediate results which are known as "contexts". + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 2] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + + CRAM does not support a protection mechanism. + + Example: + + The examples in this document show the use of the CRAM mechanism with + the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of + the challenges and responses is part of the IMAP4 AUTHENTICATE + command, not part of the CRAM specification itself. + + S: * OK IMAP4 Server + C: A0001 AUTHENTICATE CRAM-MD5 + S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ + C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw + S: A0001 OK CRAM authentication successful + + In this example, the shared secret is the string + 'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by + calculating + + MD5((tanstaaftanstaaf XOR opad), + MD5((tanstaaftanstaaf XOR ipad), + <1896.697170952@postoffice.reston.mci.net>)) + + where ipad and opad are as defined in the keyed-MD5 Work in + Progress [KEYED-MD5] and the string shown in the challenge is the + base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The + shared secret is null-padded to a length of 64 bytes. If the + shared secret is longer than 64 bytes, the MD5 digest of the + shared secret is used as a 16 byte input to the keyed MD5 + calculation. + + This produces a digest value (in hexadecimal) of + + b913a602c7eda7a495b4e6e7334d3890 + + The user name is then prepended to it, forming + + tim b913a602c7eda7a495b4e6e7334d3890 + + Which is then base64 encoded to meet the requirements of the IMAP4 + AUTHENTICATE command (or the similar POP3 AUTH command), yielding + + dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw + + + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 3] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + +3. References + + [CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", + RFC 1334, October 1992. + + [IMAP] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", + RFC 1731, Carnegie Mellon, December 1994. + + [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for + Message Authentication", RFC 2104, February 1997. + + [MD5] Rivest, R., "The MD5 Message Digest Algorithm", + RFC 1321, MIT Laboratory for Computer Science, April 1992. + + [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, Carnegie Mellon, May 1996. + + [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, + Carnegie Mellon, December, 1994. + +4. Security Considerations + + It is conjectured that use of the CRAM authentication mechanism + provides origin identification and replay protection for a session. + Accordingly, a server that implements both a cleartext password + command and this authentication type should not allow both methods of + access for a given user. + + While the saving, on the server, of "contexts" (see section 2) is + marginally better than saving the shared secrets in cleartext as is + required by CHAP [CHAP] and APOP [POP3], it is not sufficient to + protect the secrets if the server itself is compromised. + Consequently, servers that store the secrets or contexts must both be + protected to a level appropriate to the potential information value + in user mailboxes and identities. + + As the length of the shared secret increases, so does the difficulty + of deriving it. + + While there are now suggestions in the literature that the use of MD5 + and keyed MD5 in authentication procedures probably has a limited + effective lifetime, the technique is now widely deployed and widely + understood. It is believed that this general understanding may + assist with the rapid replacement, by CRAM-MD5, of the current uses + of permanent cleartext passwords in IMAP. This document has been + + + +Klensin, Catoe & Krumviede Standards Track [Page 4] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + + deliberately written to permit easy upgrading to use SHA (or whatever + alternatives emerge) when they are considered to be widely available + and adequately safe. + + Even with the use of CRAM, users are still vulnerable to active + attacks. An example of an increasingly common active attack is 'TCP + Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95]. + + See section 1 above for additional discussion. + +5. Acknowledgements + + This memo borrows ideas and some text liberally from [POP3] and + [RFC-1731] and thanks are due the authors of those documents. Ran + Atkinson made a number of valuable technical and editorial + contributions to the document. + +6. Authors' Addresses + + John C. Klensin + MCI Telecommunications + 800 Boylston St, 7th floor + Boston, MA 02199 + USA + + EMail: klensin@mci.net + Phone: +1 617 960 1011 + + Randy Catoe + MCI Telecommunications + 2100 Reston Parkway + Reston, VA 22091 + USA + + EMail: randy@mci.net + Phone: +1 703 715 7366 + + Paul Krumviede + MCI Telecommunications + 2100 Reston Parkway + Reston, VA 22091 + USA + + EMail: paul@mci.net + Phone: +1 703 715 7251 + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 5] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2221.txt b/server/src/site/resources/rfclist/imap4/rfc2221.txt new file mode 100644 index 00000000000..78f73c90289 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2221.txt @@ -0,0 +1,284 @@ + + + + + +Network Working Group M. Gahrns +Request for Comments: 2221 Microsoft +Category: Standards Track October 1997 + + + IMAP4 Login Referrals + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1997). All Rights Reserved. + +1. Abstract + + When dealing with large amounts of users and many IMAP4 [RFC-2060] + servers, it is often necessary to move users from one IMAP4 server to + another. For example, hardware failures or organizational changes + may dictate such a move. + + Login referrals allow clients to transparently connect to an + alternate IMAP4 server, if their home IMAP4 server has changed. + + A referral mechanism can provide efficiencies over the alternative + 'proxy method', in which the local IMAP4 server contacts the remote + server on behalf of the client, and then transfers the data from the + remote server to itself, and then on to the client. The referral + mechanism's direct client connection to the remote server is often a + more efficient use of bandwidth, and does not require the local + server to impersonate the client when authenticating to the remote + server. + +2. Conventions used in this document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + A home server, is an IMAP4 server that contains the user's inbox. + + A remote server is a server that contains remote mailboxes. + + + + + +Gahrns Standards Track [Page 1] + +RFC 2221 IMAP4 Login Referrals October 1997 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + +3. Introduction and Overview + + IMAP4 servers that support this extension MUST list the keyword + LOGIN-REFERRALS in their CAPABILITY response. No client action is + needed to invoke the LOGIN-REFERRALS capability in a server. + + A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral + to a server that will return a referral. A client MUST NOT follow + more than 10 levels of referral without consulting the user. + + A LOGIN-REFERRALS response code MUST contain as an argument a valid + IMAP server URL as defined in [IMAP-URL]. + + A home server referral consists of either a tagged NO or OK, or an + untagged BYE response that contains a LOGIN-REFERRALS response code. + + Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server + + NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a + client falling back to anonymous login. + +4. Home Server Referrals + + A home server referral may be returned in response to an AUTHENTICATE + or LOGIN command, or it may appear in the connection startup banner. + If a server returns a home server referral in a tagged NO response, + that server does not contain any mailboxes that are accessible to the + user. If a server returns a home server referral in a tagged OK + response, it indicates that the user's personal mailboxes are + elsewhere, but the server contains public mailboxes which are + readable by the user. After receiving a home server referral, the + client can not make any assumptions as to whether this was a + permanent or temporary move of the user. + +4.1. LOGIN and AUTHENTICATE Referrals + + An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a + home server referral if it wishes to direct the user to another IMAP4 + server. + + Example: C: A001 LOGIN MIKE PASSWORD + S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user + is invalid on this server. Try SERVER2. + + + + +Gahrns Standards Track [Page 2] + +RFC 2221 IMAP4 Login Referrals October 1997 + + + Example: C: A001 LOGIN MATTHEW PASSWORD + S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified + user's personal mailboxes located on Server2, but + public mailboxes are available. + + Example: C: A001 AUTHENTICATE GSSAPI + + S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/] + Specified user is invalid on this server. Try + SERVER2. + +4.2. BYE at connection startup referral + + An IMAP4 server MAY respond with an untagged BYE and a REFERRAL + response code that contains an IMAP URL to a home server if it is not + willing to accept connections and wishes to direct the client to + another IMAP4 server. + + Example: S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not + accepting connections. Try SERVER2 + +5. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) as described in [ABNF]. + + This amends the "resp_text_code" element of the IMAP4 grammar + described in [RFC-2060] + + resp_text_code =/ "REFERRAL" SPACE + ; See [IMAP-URL] for definition of + ; See [RFC-2060] for base definition of resp_text_code + +6. Security Considerations + + The IMAP4 login referral mechanism makes use of IMAP URLs, and as + such, have the same security considerations as general internet URLs + [RFC-1738], and in particular IMAP URLs [IMAP-URL]. + + A server MUST NOT give a login referral if authentication for that + user fails. This is to avoid revealing information about the user's + account to an unauthorized user. + + With the LOGIN-REFERRALS capability, it is potentially easier to + write a rogue 'password catching' server that collects login data and + then refers the client to their actual IMAP4 server. Although + referrals reduce the effort to write such a server, the referral + response makes detection of the intrusion easier. + + + +Gahrns Standards Track [Page 3] + +RFC 2221 IMAP4 Login Referrals October 1997 + + +7. References + + [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, + September 1997. + + [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform + Resource Locators (URL)", RFC 1738, December 1994. + + [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for + Syntax Specifications: ABNF", Work in Progress. + +8. Acknowledgments + + Many valuable suggestions were received from private discussions and + the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin, + Mark Keasling Chris Newman and Larry Osterman made significant + contributions to this document. + +9. Author's Address + + Mike Gahrns + Microsoft + One Microsoft Way + Redmond, WA, 98072 + + Phone: (206) 936-9833 + EMail: mikega@microsoft.com + + + + + + + + + + + + + + + + + + +Gahrns Standards Track [Page 4] + +RFC 2221 IMAP4 Login Referrals October 1997 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (1997). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implmentation may be prepared, copied, published + andand distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + + + + + + + + + + + + + + + + + + + + + + + + +Gahrns Standards Track [Page 5] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2342.txt b/server/src/site/resources/rfclist/imap4/rfc2342.txt new file mode 100644 index 00000000000..f1c8c409412 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2342.txt @@ -0,0 +1,564 @@ + + + + + +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 , where 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 , + where 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 = + ; 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 = + ; as defined in [RFC-2060] + + QUOTED_CHAR = + ; as defined in [RFC-2060] + + 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/server/src/site/resources/rfclist/imap4/rfc2359.txt b/server/src/site/resources/rfclist/imap4/rfc2359.txt new file mode 100644 index 00000000000..ad938a42c5a --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2359.txt @@ -0,0 +1,340 @@ + + + + + +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 + C: Subject: afternoon meeting + C: To: mooch@owatagu.siam.edu + C: Message-Id: + C: MIME-Version: 1.0 + C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + C: + C: Hello Joe, do you think we can meet at 3:30 tomorrow? + C: + S: A003 OK [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/server/src/site/resources/rfclist/imap4/rfc2595.txt b/server/src/site/resources/rfclist/imap4/rfc2595.txt new file mode 100644 index 00000000000..66897cd6c97 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2595.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group C. Newman +Request for Comments: 2595 Innosoft +Category: Standards Track June 1999 + + + Using TLS with IMAP, POP3 and ACAP + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Motivation + + The TLS protocol (formerly known as SSL) provides a way to secure an + application protocol from tampering and eavesdropping. The option of + using such security is desirable for IMAP, POP and ACAP due to common + connection eavesdropping and hijacking attacks [AUTH]. Although + advanced SASL authentication mechanisms can provide a lightweight + version of this service, TLS is complimentary to simple + authentication-only SASL mechanisms or deployed clear-text password + login commands. + + Many sites have a high investment in authentication infrastructure + (e.g., a large database of a one-way-function applied to user + passwords), so a privacy layer which is not tightly bound to user + authentication can protect against network eavesdropping attacks + without requiring a new authentication infrastructure and/or forcing + all users to change their password. Recognizing that such sites will + desire simple password authentication in combination with TLS + encryption, this specification defines the PLAIN SASL mechanism for + use with protocols which lack a simple password authentication + command such as ACAP and SMTP. (Note there is a separate RFC for the + STARTTLS command in SMTP [SMTPTLS].) + + There is a strong desire in the IETF to eliminate the transmission of + clear-text passwords over unencrypted channels. While SASL can be + used for this purpose, TLS provides an additional tool with different + deployability characteristics. A server supporting both TLS with + + + + +Newman Standards Track [Page 1] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + simple passwords and a challenge/response SASL mechanism is likely to + interoperate with a wide variety of clients without resorting to + unencrypted clear-text passwords. + + The STARTTLS command rectifies a number of the problems with using a + separate port for a "secure" protocol variant. Some of these are + mentioned in section 7. + +1.1. Conventions Used in this Document + + The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", + "MAY", and "OPTIONAL" in this document are to be interpreted as + described in "Key words for use in RFCs to Indicate Requirement + Levels" [KEYWORDS]. + + Terms related to authentication are defined in "On Internet + Authentication" [AUTH]. + + Formal syntax is defined using ABNF [ABNF]. + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + +2. Basic Interoperability and Security Requirements + + The following requirements apply to all implementations of the + STARTTLS extension for IMAP, POP3 and ACAP. + +2.1. Cipher Suite Requirements + + Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher + suite is REQUIRED. This is important as it assures that any two + compliant implementations can be configured to interoperate. + + All other cipher suites are OPTIONAL. + +2.2. Privacy Operational Mode Security Requirements + + Both clients and servers SHOULD have a privacy operational mode which + refuses authentication unless successful activation of an encryption + layer (such as that provided by TLS) occurs prior to or at the time + of authentication and which will terminate the connection if that + encryption layer is deactivated. Implementations are encouraged to + have flexability with respect to the minimal encryption strength or + cipher suites permitted. A minimalist approach to this + recommendation would be an operational mode where the + TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to + permitting authentication. + + + +Newman Standards Track [Page 2] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + Clients MAY have an operational mode which uses encryption only when + it is advertised by the server, but authentication continues + regardless. For backwards compatibility, servers SHOULD have an + operational mode where only the authentication mechanisms required by + the relevant base protocol specification are needed to successfully + authenticate. + +2.3. Clear-Text Password Requirements + + Clients and servers which implement STARTTLS MUST be configurable to + refuse all clear-text login commands or mechanisms (including both + standards-track and nonstandard mechanisms) unless an encryption + layer of adequate strength is active. Servers which allow + unencrypted clear-text logins SHOULD be configurable to refuse + clear-text logins both for the entire server, and on a per-user + basis. + +2.4. Server Identity Check + + During the TLS negotiation, the client MUST check its understanding + of the server hostname against the server's identity as presented in + the server Certificate message, in order to prevent man-in-the-middle + attacks. Matching is performed according to these rules: + + - The client MUST use the server hostname it used to open the + connection as the value to compare against the server name as + expressed in the server certificate. The client MUST NOT use any + form of the server hostname derived from an insecure remote source + (e.g., insecure DNS lookup). CNAME canonicalization is not done. + + - If a subjectAltName extension of type dNSName is present in the + certificate, it SHOULD be used as the source of the server's + identity. + + - Matching is case-insensitive. + + - A "*" wildcard character MAY be used as the left-most name + component in the certificate. For example, *.example.com would + match a.example.com, foo.example.com, etc. but would not match + example.com. + + - If the certificate contains multiple names (e.g. more than one + dNSName field), then a match with any one of the fields is + considered acceptable. + + If the match fails, the client SHOULD either ask for explicit user + confirmation, or terminate the connection and indicate the server's + identity is suspect. + + + +Newman Standards Track [Page 3] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +2.5. TLS Security Policy Check + + Both the client and server MUST check the result of the STARTTLS + command and subsequent TLS negotiation to see whether acceptable + authentication or privacy was achieved. Ignoring this step + completely invalidates using TLS for security. The decision about + whether acceptable authentication or privacy was achieved is made + locally, is implementation-dependent, and is beyond the scope of this + document. + +3. IMAP STARTTLS extension + + When the TLS extension is present in IMAP, "STARTTLS" is listed as a + capability in response to the CAPABILITY command. This extension + adds a single command, "STARTTLS" to the IMAP protocol which is used + to begin a TLS negotiation. + +3.1. STARTTLS Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - begin TLS negotiation + BAD - command unknown or arguments invalid + + A TLS negotiation begins immediately after the CRLF at the end of + the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. + The server remains in non-authenticated state, even if client + credentials are supplied during the TLS negotiation. The SASL + [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS + client credentials are successfully exchanged, but servers + supporting the STARTTLS command are not required to support the + EXTERNAL mechanism. + + Once TLS has been started, the client MUST discard cached + information about server capabilities and SHOULD re-issue the + CAPABILITY command. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list prior + to STARTTLS. The server MAY advertise different capabilities + after STARTTLS. + + The formal syntax for IMAP is amended as follows: + + + + +Newman Standards Track [Page 4] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + command_any =/ "STARTTLS" + + Example: C: a001 CAPABILITY + S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED + S: a001 OK CAPABILITY completed + C: a002 STARTTLS + S: a002 OK Begin TLS negotiation now + + C: a003 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL + S: a003 OK CAPABILITY completed + C: a004 LOGIN joe password + S: a004 OK LOGIN completed + +3.2. IMAP LOGINDISABLED capability + + The current IMAP protocol specification (RFC 2060) requires the + implementation of the LOGIN command which uses clear-text passwords. + Many sites may choose to disable this command unless encryption is + active for security reasons. An IMAP server MAY advertise that the + LOGIN command is disabled by including the LOGINDISABLED capability + in the capability response. Such a server will respond with a tagged + "NO" response to any attempt to use the LOGIN command. + + An IMAP server which implements STARTTLS MUST implement support for + the LOGINDISABLED capability on unencrypted connections. + + An IMAP client which complies with this specification MUST NOT issue + the LOGIN command if this capability is present. + + This capability is useful to prevent clients compliant with this + specification from sending an unencrypted password in an environment + subject to passive attacks. It has no impact on an environment + subject to active attacks as a man-in-the-middle attacker can remove + this capability. Therefore this does not relieve clients of the need + to follow the privacy mode recommendation in section 2.2. + + Servers advertising this capability will fail to interoperate with + many existing compliant IMAP clients and will be unable to prevent + those clients from disclosing the user's password. + +4. POP3 STARTTLS extension + + The POP3 STARTTLS extension adds the STLS command to POP3 servers. + If this is implemented, the POP3 extension mechanism [POP3EXT] MUST + also be implemented to avoid the need for client probing of multiple + commands. The capability name "STLS" indicates this command is + present and permitted in the current state. + + + +Newman Standards Track [Page 5] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + STLS + + Arguments: none + + Restrictions: + Only permitted in AUTHORIZATION state. + + Discussion: + A TLS negotiation begins immediately after the CRLF at the + end of the +OK response from the server. A -ERR response + MAY result if a security layer is already active. Once a + client issues a STLS command, it MUST NOT issue further + commands until a server response is seen and the TLS + negotiation is complete. + + The STLS command is only permitted in AUTHORIZATION state + and the server remains in AUTHORIZATION state, even if + client credentials are supplied during the TLS negotiation. + The AUTH command [POP-AUTH] with the EXTERNAL mechanism + [SASL] MAY be used to authenticate once TLS client + credentials are successfully exchanged, but servers + supporting the STLS command are not required to support the + EXTERNAL mechanism. + + Once TLS has been started, the client MUST discard cached + information about server capabilities and SHOULD re-issue + the CAPA command. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list + prior to STLS. The server MAY advertise different + capabilities after STLS. + + Possible Responses: + +OK -ERR + + Examples: + C: STLS + S: +OK Begin TLS negotiation + + ... + C: STLS + S: -ERR Command not permitted when TLS active + + + + + + + + + + +Newman Standards Track [Page 6] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +5. ACAP STARTTLS extension + + When the TLS extension is present in ACAP, "STARTTLS" is listed as a + capability in the ACAP greeting. No arguments to this capability are + defined at this time. This extension adds a single command, + "STARTTLS" to the ACAP protocol which is used to begin a TLS + negotiation. + +5.1. STARTTLS Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - begin TLS negotiation + BAD - command unknown or arguments invalid + + A TLS negotiation begins immediately after the CRLF at the end of + the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. + The server remains in non-authenticated state, even if client + credentials are supplied during the TLS negotiation. The SASL + [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS + client credentials are successfully exchanged, but servers + supporting the STARTTLS command are not required to support the + EXTERNAL mechanism. + + After the TLS layer is established, the server MUST re-issue an + untagged ACAP greeting. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list prior + to STARTTLS. The client MUST discard cached capability + information and replace it with the information from the new ACAP + greeting. The server MAY advertise different capabilities after + STARTTLS. + + The formal syntax for ACAP is amended as follows: + + command_any =/ "STARTTLS" + + Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) + C: a002 STARTTLS + S: a002 OK "Begin TLS negotiation now" + + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + + + + +Newman Standards Track [Page 7] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +6. PLAIN SASL mechanism + + Clear-text passwords are simple, interoperate with almost all + existing operating system authentication databases, and are useful + for a smooth transition to a more secure password-based + authentication mechanism. The drawback is that they are unacceptable + for use over an unencrypted network connection. + + This defines the "PLAIN" SASL mechanism for use with ACAP and other + protocols with no clear-text login command. The PLAIN SASL mechanism + MUST NOT be advertised or used unless a strong encryption layer (such + as the provided by TLS) is active or backwards compatibility dictates + otherwise. + + The mechanism consists of a single message from the client to the + server. The client sends the authorization identity (identity to + login as), followed by a US-ASCII NUL character, followed by the + authentication identity (identity whose password will be used), + followed by a US-ASCII NUL character, followed by the clear-text + password. The client may leave the authorization identity empty to + indicate that it is the same as the authentication identity. + + The server will verify the authentication identity and password with + the system authentication database and verify that the authentication + credentials permit the client to login as the authorization identity. + If both steps succeed, the user is logged in. + + The server MAY also use the password to initialize any new + authentication database, such as one suitable for CRAM-MD5 + [CRAM-MD5]. + + Non-US-ASCII characters are permitted as long as they are represented + in UTF-8 [UTF-8]. Use of non-visible characters or characters which + a user may be unable to enter on some keyboards is discouraged. + + The formal grammar for the client message using Augmented BNF [ABNF] + follows. + + message = [authorize-id] NUL authenticate-id NUL password + authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets + authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets + password = 1*UTF8-SAFE ; MUST accept up to 255 octets + NUL = %x00 + UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / + UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 + UTF8-1 = %x80-BF + UTF8-2 = %xC0-DF UTF8-1 + UTF8-3 = %xE0-EF 2UTF8-1 + + + +Newman Standards Track [Page 8] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + UTF8-4 = %xF0-F7 3UTF8-1 + UTF8-5 = %xF8-FB 4UTF8-1 + UTF8-6 = %xFC-FD 5UTF8-1 + + Here is an example of how this might be used to initialize a CRAM-MD5 + authentication database for ACAP: + + Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) + C: a001 AUTHENTICATE "CRAM-MD5" + S: + "<1896.697170952@postoffice.reston.mci.net>" + C: "tim b913a602c7eda7a495b4e6e7334d3890" + S: a001 NO (TRANSITION-NEEDED) + "Please change your password, or use TLS to login" + C: a002 STARTTLS + S: a002 OK "Begin TLS negotiation now" + + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + C: a003 AUTHENTICATE "PLAIN" {21+} + C: timtanstaaftanstaaf + S: a003 OK CRAM-MD5 password initialized + + Note: In this example, represents a single ASCII NUL octet. + +7. imaps and pop3s ports + + Separate "imaps" and "pop3s" ports were registered for use with SSL. + Use of these ports is discouraged in favor of the STARTTLS or STLS + commands. + + A number of problems have been observed with separate ports for + "secure" variants of protocols. This is an attempt to enumerate some + of those problems. + + - Separate ports lead to a separate URL scheme which intrudes into + the user interface in inappropriate ways. For example, many web + pages use language like "click here if your browser supports SSL." + This is a decision the browser is often more capable of making than + the user. + + - Separate ports imply a model of either "secure" or "not secure." + This can be misleading in a number of ways. First, the "secure" + port may not in fact be acceptably secure as an export-crippled + cipher suite might be in use. This can mislead users into a false + sense of security. Second, the normal port might in fact be + secured by using a SASL mechanism which includes a security layer. + Thus the separate port distinction makes the complex topic of + security policy even more confusing. One common result of this + confusion is that firewall administrators are often misled into + + + +Newman Standards Track [Page 9] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + permitting the "secure" port and blocking the standard port. This + could be a poor choice given the common use of SSL with a 40-bit + key encryption layer and plain-text password authentication is less + secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. + + - Use of separate ports for SSL has caused clients to implement only + two security policies: use SSL or don't use SSL. The desirable + security policy "use TLS when available" would be cumbersome with + the separate port model, but is simple with STARTTLS. + + - Port numbers are a limited resource. While they are not yet in + short supply, it is unwise to set a precedent that could double (or + worse) the speed of their consumption. + + +8. IANA Considerations + + This constitutes registration of the "STARTTLS" and "LOGINDISABLED" + IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP]. + + The registration for the POP3 "STLS" capability follows: + + CAPA tag: STLS + Arguments: none + Added commands: STLS + Standard commands affected: May enable USER/PASS as a side-effect. + CAPA command SHOULD be re-issued after successful completion. + Announced states/Valid states: AUTHORIZATION state only. + Specification reference: this memo + + The registration for the ACAP "STARTTLS" capability follows: + + Capability name: STARTTLS + Capability keyword: STARTTLS + Capability arguments: none + Published Specification(s): this memo + Person and email address for further information: + see author's address section below + + The registration for the PLAIN SASL mechanism follows: + + SASL mechanism name: PLAIN + Security Considerations: See section 9 of this memo + Published specification: this memo + Person & email address to contact for further information: + see author's address section below + Intended usage: COMMON + Author/Change controller: see author's address section below + + + +Newman Standards Track [Page 10] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +9. Security Considerations + + TLS only provides protection for data sent over a network connection. + Messages transferred over IMAP or POP3 are still available to server + administrators and usually subject to eavesdropping, tampering and + forgery when transmitted through SMTP or NNTP. TLS is no substitute + for an end-to-end message security mechanism using MIME security + multiparts [MIME-SEC]. + + A man-in-the-middle attacker can remove STARTTLS from the capability + list or generate a failure response to the STARTTLS command. In + order to detect such an attack, clients SHOULD warn the user when + session privacy is not active and/or be configurable to refuse to + proceed without an acceptable level of security. + + A man-in-the-middle attacker can always cause a down-negotiation to + the weakest authentication mechanism or cipher suite available. For + this reason, implementations SHOULD be configurable to refuse weak + mechanisms or cipher suites. + + Any protocol interactions prior to the TLS handshake are performed in + the clear and can be modified by a man-in-the-middle attacker. For + this reason, clients MUST discard cached information about server + capabilities advertised prior to the start of the TLS handshake. + + Clients are encouraged to clearly indicate when the level of + encryption active is known to be vulnerable to attack using modern + hardware (such as encryption keys with 56 bits of entropy or less). + + The LOGINDISABLED IMAP capability (discussed in section 3.2) only + reduces the potential for passive attacks, it provides no protection + against active attacks. The responsibility remains with the client + to avoid sending a password over a vulnerable channel. + + The PLAIN mechanism relies on the TLS encryption layer for security. + When used without TLS, it is vulnerable to a common network + eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used + unless a suitable TLS encryption layer is active or backwards + compatibility dictates otherwise. + + When the PLAIN mechanism is used, the server gains the ability to + impersonate the user to all services with the same password + regardless of any encryption provided by TLS or other network privacy + mechanisms. While many other authentication mechanisms have similar + weaknesses, stronger SASL mechanisms such as Kerberos address this + issue. Clients are encouraged to have an operational mode where all + mechanisms which are likely to reveal the user's password to the + server are disabled. + + + +Newman Standards Track [Page 11] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + The security considerations for TLS apply to STARTTLS and the + security considerations for SASL apply to the PLAIN mechanism. + Additional security requirements are discussed in section 2. + +10. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [ACAP] Newman, C. and J. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, November 1997. + + [AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", + RFC 1704, October 1994. + + [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP + AUTHorize Extension for Simple Challenge/Response", RFC + 2195, September 1997. + + [IMAP] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed, + "Security Multiparts for MIME: Multipart/Signed and + Multipart/Encrypted", RFC 1847, October 1995. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, May 1996. + + [POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension + Mechanism", RFC 2449, November 1998. + + [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, + December 1994. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over + TLS", RFC 2487, January 1999. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + + + + +Newman Standards Track [Page 12] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + +11. Author's Address + + Chris Newman + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 USA + + EMail: chris.newman@innosoft.com + + +A. Appendix -- Compliance Checklist + + An implementation is not compliant if it fails to satisfy one or more + of the MUST requirements for the protocols it implements. An + implementation that satisfies all the MUST and all the SHOULD + requirements for its protocols is said to be "unconditionally + compliant"; one that satisfies all the MUST requirements but not all + the SHOULD requirements for its protocols is said to be + "conditionally compliant". + + Rules Section + ----- ------- + Mandatory-to-implement Cipher Suite 2.1 + SHOULD have mode where encryption required 2.2 + server SHOULD have mode where TLS not required 2.2 + MUST be configurable to refuse all clear-text login + commands or mechanisms 2.3 + server SHOULD be configurable to refuse clear-text + login commands on entire server and on per-user basis 2.3 + client MUST check server identity 2.4 + client MUST use hostname used to open connection 2.4 + client MUST NOT use hostname from insecure remote lookup 2.4 + client SHOULD support subjectAltName of dNSName type 2.4 + client SHOULD ask for confirmation or terminate on fail 2.4 + MUST check result of STARTTLS for acceptable privacy 2.5 + client MUST NOT issue commands after STARTTLS + until server response and negotiation done 3.1,4,5.1 + client MUST discard cached information 3.1,4,5.1,9 + client SHOULD re-issue CAPABILITY/CAPA command 3.1,4 + IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2 + IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2 + POP server MUST implement POP3 extensions 4 + ACAP server MUST re-issue ACAP greeting 5.1 + + + + +Newman Standards Track [Page 13] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + client SHOULD warn when session privacy not active and/or + refuse to proceed without acceptable security level 9 + SHOULD be configurable to refuse weak mechanisms or + cipher suites 9 + + The PLAIN mechanism is an optional part of this specification. + However if it is implemented the following rules apply: + + Rules Section + ----- ------- + MUST NOT use PLAIN unless strong encryption active + or backwards compatibility dictates otherwise 6,9 + MUST use UTF-8 encoding for characters in PLAIN 6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 14] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 15] + diff --git a/server/src/site/resources/rfclist/imap4/rfc2683.txt b/server/src/site/resources/rfclist/imap4/rfc2683.txt new file mode 100644 index 00000000000..d92e3405651 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2683.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group B. Leiba +Request for Comments: 2683 IBM T.J. Watson Research Center +Category: Informational September 1999 + + + IMAP4 Implementation Recommendations + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Abstract + + The IMAP4 specification [RFC-2060] describes a rich protocol for use + in building clients and servers for storage, retrieval, and + manipulation of electronic mail. Because the protocol is so rich and + has so many implementation choices, there are often trade-offs that + must be made and issues that must be considered when designing such + clients and servers. This document attempts to outline these issues + and to make recommendations in order to make the end products as + interoperable as possible. + +2. Conventions used in this document + + In examples, "C:" indicates lines sent by a client that is connected + to a server. "S:" indicates lines sent by the server to the client. + + The words "must", "must not", "should", "should not", and "may" are + used with specific meaning in this document; since their meaning is + somewhat different from that specified in RFC 2119, we do not put + them in all caps here. Their meaning is as follows: + + must -- This word means that the action described is necessary + to ensure interoperability. The recommendation should + not be ignored. + must not -- This phrase means that the action described will be + almost certain to hurt interoperability. The + recommendation should not be ignored. + + + + + + + +Leiba Informational [Page 1] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + should -- This word means that the action described is strongly + recommended and will enhance interoperability or + usability. The recommendation should not be ignored + without careful consideration. + should not -- This phrase means that the action described is strongly + recommended against, and might hurt interoperability or + usability. The recommendation should not be ignored + without careful consideration. + may -- This word means that the action described is an + acceptable implementation choice. No specific + recommendation is implied; this word is used to point + out a choice that might not be obvious, or to let + implementors know what choices have been made by + existing implementations. + +3. Interoperability Issues and Recommendations + +3.1. Accessibility + + This section describes the issues related to access to servers and + server resources. Concerns here include data sharing and maintenance + of client/server connections. + +3.1.1. Multiple Accesses of the Same Mailbox + + One strong point of IMAP4 is that, unlike POP3, it allows for + multiple simultaneous access to a single mailbox. A user can, thus, + read mail from a client at home while the client in the office is + still connected; or the help desk staff can all work out of the same + inbox, all seeing the same pool of questions. An important point + about this capability, though is that NO SERVER IS GUARANTEED TO + SUPPORT THIS. If you are selecting an IMAP server and this facility + is important to you, be sure that the server you choose to install, + in the configuration you choose to use, supports it. + + If you are designing a client, you must not assume that you can + access the same mailbox more than once at a time. That means + + 1. you must handle gracefully the failure of a SELECT command if the + server refuses the second SELECT, + 2. you must handle reasonably the severing of your connection (see + "Severed Connections", below) if the server chooses to allow the + second SELECT by forcing the first off, + 3. you must avoid making multiple connections to the same mailbox in + your own client (for load balancing or other such reasons), and + 4. you must avoid using the STATUS command on a mailbox that you have + selected (with some server implementations the STATUS command has + the same problems with multiple access as do the SELECT and + + + +Leiba Informational [Page 2] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + EXAMINE commands). + + A further note about STATUS: The STATUS command is sometimes used to + check a non-selected mailbox for new mail. This mechanism must not + be used to check for new mail in the selected mailbox; section 5.2 of + [RFC-2060] specifically forbids this in its last paragraph. Further, + since STATUS takes a mailbox name it is an independent operation, not + operating on the selected mailbox. Because of this, the information + it returns is not necessarily in synchronization with the selected + mailbox state. + +3.1.2. Severed Connections + + The client/server connection may be severed for one of three reasons: + the client severs the connection, the server severs the connection, + or the connection is severed by outside forces beyond the control of + the client and the server (a telephone line drops, for example). + Clients and servers must both deal with these situations. + + When the client wants to sever a connection, it's usually because it + has finished the work it needed to do on that connection. The client + should send a LOGOUT command, wait for the tagged response, and then + close the socket. But note that, while this is what's intended in + the protocol design, there isn't universal agreement here. Some + contend that sending the LOGOUT and waiting for the two responses + (untagged BYE and tagged OK) is wasteful and unnecessary, and that + the client can simply close the socket. The server should interpret + the closed socket as a log out by the client. The counterargument is + that it's useful from the standpoint of cleanup, problem + determination, and the like, to have an explicit client log out, + because otherwise there is no way for the server to tell the + difference between "closed socket because of log out" and "closed + socket because communication was disrupted". If there is a + client/server interaction problem, a client which routinely + terminates a session by breaking the connection without a LOGOUT will + make it much more difficult to determine the problem. + + Because of this disagreement, server designers must be aware that + some clients might close the socket without sending a LOGOUT. In any + case, whether or not a LOGOUT was sent, the server should not + implicitly expunge any messages from the selected mailbox. If a + client wants the server to do so, it must send a CLOSE or EXPUNGE + command explicitly. + + When the server wants to sever a connection it's usually due to an + inactivity timeout or is because a situation has arisen that has + changed the state of the mail store in a way that the server can not + communicate to the client. The server should send an untagged BYE + + + +Leiba Informational [Page 3] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + response to the client and then close the socket. Sending an + untagged BYE response before severing allows the server to send a + human-readable explanation of the problem to the client, which the + client may then log, display to the user, or both (see section 7.1.5 + of [RFC-2060]). + + Regarding inactivity timeouts, there is some controversy. Unlike + POP, for which the design is for a client to connect, retrieve mail, + and log out, IMAP's design encourages long-lived (and mostly + inactive) client/server sessions. As the number of users grows, this + can use up a lot of server resources, especially with clients that + are designed to maintain sessions for mailboxes that the user has + finished accessing. To alleviate this, a server may implement an + inactivity timeout, unilaterally closing a session (after first + sending an untagged BYE, as noted above). Some server operators have + reported dramatic improvements in server performance after doing + this. As specified in [RFC-2060], if such a timeout is done it must + not be until at least 30 minutes of inactivity. The reason for this + specification is to prevent clients from sending commands (such as + NOOP) to the server at frequent intervals simply to avert a too-early + timeout. If the client knows that the server may not time out the + session for at least 30 minutes, then the client need not poll at + intervals more frequent than, say, 25 minutes. + +3.2. Scaling + + IMAP4 has many features that allow for scalability, as mail stores + become larger and more numerous. Large numbers of users, mailboxes, + and messages, and very large messages require thought to handle + efficiently. This document will not address the administrative + issues involved in large numbers of users, but we will look at the + other items. + +3.2.1. Flood Control + + There are three situations when a client can make a request that will + result in a very large response - too large for the client reasonably + to deal with: there are a great many mailboxes available, there are a + great many messages in the selected mailbox, or there is a very large + message part. The danger here is that the end user will be stuck + waiting while the server sends (and the client processes) an enormous + response. In all of these cases there are things a client can do to + reduce that danger. + + There is also the case where a client can flood a server, by sending + an arbitratily long command. We'll discuss that issue, too, in this + section. + + + + +Leiba Informational [Page 4] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.2.1.1. Listing Mailboxes + + Some servers present Usenet newsgroups to IMAP users. Newsgroups, + and other such hierarchical mailbox structures, can be very numerous + but may have only a few entries at the top level of hierarchy. Also, + some servers are built against mail stores that can, unbeknownst to + the server, have circular hierarchies - that is, it's possible for + "a/b/c/d" to resolve to the same file structure as "a", which would + then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy + will never end. The LIST response in this case will be unlimited. + + Clients that will have trouble with this are those that use + + C: 001 LIST "" * + + to determine the mailbox list. Because of this, clients should not + use an unqualified "*" that way in the LIST command. A safer + approach is to list each level of hierarchy individually, allowing + the user to traverse the tree one limb at a time, thus: + + C: 001 LIST "" % + S: * LIST () "/" Banana + S: * LIST ...etc... + S: 001 OK done + + and then + + C: 002 LIST "" Banana/% + S: * LIST () "/" Banana/Apple + S: * LIST ...etc... + S: 002 OK done + + Using this technique the client's user interface can give the user + full flexibility without choking on the voluminous reply to "LIST *". + + Of course, it is still possible that the reply to + + C: 005 LIST "" alt.fan.celebrity.% + + may be thousands of entries long, and there is, unfortunately, + nothing the client can do to protect itself from that. This has not + yet been a notable problem. + + Servers that may export circular hierarchies (any server that + directly presents a UNIX file system, for instance) should limit the + hierarchy depth to prevent unlimited LIST responses. A suggested + depth limit is 20 hierarchy levels. + + + + +Leiba Informational [Page 5] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.2.1.2. Fetching the List of Messages + + When a client selects a mailbox, it is given a count, in the untagged + EXISTS response, of the messages in the mailbox. This number can be + very large. In such a case it might be unwise to use + + C: 004 FETCH 1:* ALL + + to populate the user's view of the mailbox. One good method to avoid + problems with this is to batch the requests, thus: + + C: 004 FETCH 1:50 ALL + S: * 1 FETCH ...etc... + S: 004 OK done + C: 005 FETCH 51:100 ALL + S: * 51 FETCH ...etc... + S: 005 OK done + C: 006 FETCH 101:150 ALL + ...etc... + + Using this method, another command, such as "FETCH 6 BODY[1]" can be + inserted as necessary, and the client will not have its access to the + server blocked by a storm of FETCH replies. (Such a method could be + reversed to fetch the LAST 50 messages first, then the 50 prior to + that, and so on.) + + As a smart extension of this, a well designed client, prepared for + very large mailboxes, will not automatically fetch data for all + messages AT ALL. Rather, the client will populate the user's view + only as the user sees it, possibly pre-fetching selected information, + and only fetching other information as the user scrolls to it. For + example, to select only those messages beginning with the first + unseen one: + + C: 003 SELECT INBOX + S: * 10000 EXISTS + S: * 80 RECENT + S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) + S: * OK [UIDVALIDITY 824708485] UID validity status + S: * OK [UNSEEN 9921] First unseen message + S: 003 OK [READ-WRITE] SELECT completed + C: 004 FETCH 9921:* ALL + ... etc... + + If the server does not return an OK [UNSEEN] response, the client may + use SEARCH UNSEEN to obtain that value. + + + + + +Leiba Informational [Page 6] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + This mechanism is good as a default presentation method, but only + works well if the default message order is acceptable. A client may + want to present various sort orders to the user (by subject, by date + sent, by sender, and so on) and in that case (lacking a SORT + extension on the server side) the client WILL have to retrieve all + message descriptors. A client that provides this service should not + do it by default and should inform the user of the costs of choosing + this option for large mailboxes. + +3.2.1.3. Fetching a Large Body Part + + The issue here is similar to the one for a list of messages. In the + BODYSTRUCTURE response the client knows the size, in bytes, of the + body part it plans to fetch. Suppose this is a 70 MB video clip. The + client can use partial fetches to retrieve the body part in pieces, + avoiding the problem of an uninterruptible 70 MB literal coming back + from the server: + + C: 022 FETCH 3 BODY[1]<0.20000> + S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000} + S: ...data...) + S: 022 OK done + C: 023 FETCH 3 BODY[1]<20001.20000> + S: * 3 FETCH (BODY[1]<20001> {20000} + S: ...data...) + S: 023 OK done + C: 024 FETCH 3 BODY[1]<40001.20000> + ...etc... + +3.2.1.4. BODYSTRUCTURE vs. Entire Messages + + Because FETCH BODYSTRUCTURE is necessary in order to determine the + number of body parts, and, thus, whether a message has "attachments", + clients often use FETCH FULL as their normal method of populating the + user's view of a mailbox. The benefit is that the client can display + a paperclip icon or some such indication along with the normal + message summary. However, this comes at a significant cost with some + server configurations. The parsing needed to generate the FETCH + BODYSTRUCTURE response may be time-consuming compared with that + needed for FETCH ENVELOPE. The client developer should consider this + issue when deciding whether the ability to add a paperclip icon is + worth the tradeoff in performance, especially with large mailboxes. + + Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[] + (or the equivalent FETCH RFC822) to retrieve the entire message. + They then do the MIME parsing in the client. This may give the + client slightly more flexibility in some areas (access, for instance, + to header fields that aren't returned in the BODYSTRUCTURE and + + + +Leiba Informational [Page 7] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + ENVELOPE responses), but it can cause severe performance problems by + forcing the transfer of all body parts when the user might only want + to see some of them - a user logged on by modem and reading a small + text message with a large ZIP file attached may prefer to read the + text only and save the ZIP file for later. Therefore, a client + should not normally retrieve entire messages and should retrieve + message body parts selectively. + +3.2.1.5. Long Command Lines + + A client can wind up building a very long command line in an effort to + try to be efficient about requesting information from a server. This + can typically happen when a client builds a message set from selected + messages and doesn't recognise that contiguous blocks of messages may + be group in a range. Suppose a user selects all 10,000 messages in a + large mailbox and then unselects message 287. The client could build + that message set as "1:286,288:10000", but a client that doesn't + handle that might try to enumerate each message individually and build + "1,2,3,4, [and so on] ,9999,10000". Adding that to the fetch command + results in a command line that's almost 49,000 octets long, and, + clearly, one can construct a command line that's even longer. + + A client should limit the length of the command lines it generates to + approximately 1000 octets (including all quoted strings but not + including literals). If the client is unable to group things into + ranges so that the command line is within that length, it should + split the request into multiple commands. The client should use + literals instead of long quoted strings, in order to keep the command + length down. + + For its part, a server should allow for a command line of at least + 8000 octets. This provides plenty of leeway for accepting reasonable + length commands from clients. The server should send a BAD response + to a command that does not end within the server's maximum accepted + command length. + +3.2.2. Subscriptions + + The client isn't the only entity that can get flooded: the end user, + too, may need some flood control. The IMAP4 protocol provides such + control in the form of subscriptions. Most servers support the + SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to + narrow down a large list of available mailboxes by subscribing to the + ones that they usually want to see. Clients, with this in mind, + should give the user a way to see only subscribed mailboxes. A + client that never uses the LSUB command takes a significant usability + feature away from the user. Of course, the client would not want to + hide the LIST command completely; the user needs to have a way to + + + +Leiba Informational [Page 8] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + choose between LIST and LSUB. The usual way to do this is to provide + a setting like "show which mailboxes?: [] all [] subscribed only". + +3.2.3. Searching + + IMAP SEARCH commands can become particularly troublesome (that is, + slow) on mailboxes containing a large number of messages. So let's + put a few things in perspective in that regard. + + The flag searches should be fast. The flag searches (ALL, [UN]SEEN, + [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT) + are known to be used by clients for the client's own use (for + instance, some clients use "SEARCH UNSEEN" to find unseen mail and + "SEARCH DELETED" to warn the user before expunging messages). + + Other searches, particularly the text searches (HEADER, TEXT, BODY) + are initiated by the user, rather than by the client itself, and + somewhat slower performance can be tolerated, since the user is aware + that the search is being done (and is probably aware that it might be + time-consuming). A smart server might use dynamic indexing to speed + commonly used text searches. + + The client may allow other commands to be sent to the server while a + SEARCH is in progress, but at the time of this writing there is + little or no server support for parallel processing of multiple + commands in the same session (and see "Multiple Accesses of the Same + Mailbox" above for a description of the dangers of trying to work + around this by doing your SEARCH in another session). + + Another word about text searches: some servers, built on database + back-ends with indexed search capabilities, may return search results + that do not match the IMAP spec's "case-insensitive substring" + requirements. While these servers are in violation of the protocol, + there is little harm in the violation as long as the search results + are used only in response to a user's request. Still, developers of + such servers should be aware that they ARE violating the protocol, + should think carefully about that behaviour, and must be certain that + their servers respond accurately to the flag searches for the reasons + outlined above. + + In addition, servers should support CHARSET UTF-8 [UTF-8] in + searches. + + + + + + + + + +Leiba Informational [Page 9] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.3 Avoiding Invalid Requests + + IMAP4 provides ways for a server to tell a client in advance what is + and isn't permitted in some circumstances. Clients should use these + features to avoid sending requests that a well designed client would + know to be invalid. This section explains this in more detail. + +3.3.1. The CAPABILITY Command + + All IMAP4 clients should use the CAPABILITY command to determine what + version of IMAP and what optional features a server supports. The + client should not send IMAP4rev1 commands and arguments to a server + that does not advertize IMAP4rev1 in its CAPABILITY response. + Similarly, the client should not send IMAP4 commands that no longer + exist in IMAP4rev1 to a server that does not advertize IMAP4 in its + CAPABILITY response. An IMAP4rev1 server is NOT required to support + obsolete IMAP4 or IMAP2bis commands (though some do; do not let this + fact lull you into thinking that it's valid to send such commands to + an IMAP4rev1 server). + + A client should not send commands to probe for the existance of + certain extensions. All standard and standards-track extensions + include CAPABILITY tokens indicating their presense. All private and + experimental extensions should do the same, and clients that take + advantage of them should use the CAPABILITY response to determine + whether they may be used or not. + +3.3.2. Don't Do What the Server Says You Can't + + In many cases, the server, in response to a command, will tell the + client something about what can and can't be done with a particular + mailbox. The client should pay attention to this information and + should not try to do things that it's been told it can't do. + + Examples: + + * Do not try to SELECT a mailbox that has the \Noselect flag set. + * Do not try to CREATE a sub-mailbox in a mailbox that has the + \Noinferiors flag set. + * Do not respond to a failing COPY or APPEND command by trying to + CREATE the target mailbox if the server does not respond with a + [TRYCREATE] response code. + * Do not try to expunge a mailbox that has been selected with the + [READ-ONLY] response code. + + + + + + + +Leiba Informational [Page 10] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.4. Miscellaneous Protocol Considerations + + We describe here a number of important protocol-related issues, the + misunderstanding of which has caused significant interoperability + problems in IMAP4 implementations. One general item is that every + implementer should be certain to take note of and to understand + section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec + [RFC-2060]. + +3.4.1. Well Formed Protocol + + We cannot stress enough the importance of adhering strictly to the + protocol grammar. The specification of the protocol is quite rigid; + do not assume that you can insert blank space for "readability" if + none is called for. Keep in mind that there are parsers out there + that will crash if there are protocol errors. There are clients that + will report every parser burp to the user. And in any case, + information that cannot be parsed is information that is lost. Be + careful in your protocol generation. And see "A Word About Testing", + below. + + In particular, note that the string in the INTERNALDATE response is + NOT an RFC-822 date string - that is, it is not in the same format as + the first string in the ENVELOPE response. Since most clients will, + in fact, accept an RFC-822 date string in the INTERNALDATE response, + it's easy to miss this in your interoperability testing. But it will + cause a problem with some client, so be sure to generate the correct + string for this field. + +3.4.2. Special Characters + + Certain characters, currently the double-quote and the backslash, may + not be sent as-is inside a quoted string. These characters must be + preceded by the escape character if they are in a quoted string, or + else the string must be sent as a literal. Both clients and servers + must handle this, both on output (they must send these characters + properly) and on input (they must be able to receive escaped + characters in quoted strings). Example: + + C: 001 LIST "" % + S: * LIST () "" INBOX + S: * LIST () "\\" TEST + S: * LIST () "\\" {12} + S: "My" mailbox + S: 001 OK done + C: 002 LIST "" "\"My\" mailbox\\%" + S: * LIST () "\\" {17} + S: "My" mailbox\Junk + + + +Leiba Informational [Page 11] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + S: 002 OK done + + Note that in the example the server sent the hierarchy delimiter as + an escaped character in the quoted string and sent the mailbox name + containing imbedded double-quotes as a literal. The client used only + quoted strings, escaping both the backslash and the double-quote + characters. + + The CR and LF characters may be sent ONLY in literals; they are not + allowed, even if escaped, inside quoted strings. + + And while we're talking about special characters: the IMAP spec, in + the section titled "Mailbox International Naming Convention", + describes how to encode mailbox names in modified UTF-7 [UTF-7 and + RFC-2060]. Implementations must adhere to this in order to be + interoperable in the international market, and servers should + validate mailbox names sent by client and reject names that do not + conform. + + As to special characters in userids and passwords: clients must not + restrict what a user may type in for a userid or a password. The + formal grammar specifies that these are "astrings", and an astring + can be a literal. A literal, in turn can contain any 8-bit + character, and clients must allow users to enter all 8-bit characters + here, and must pass them, unchanged, to the server (being careful to + send them as literals when necessary). In particular, some server + configurations use "@" in user names, and some clients do not allow + that character to be entered; this creates a severe interoperability + problem. + +3.4.3. UIDs and UIDVALIDITY + + Servers that support existing back-end mail stores often have no good + place to save UIDs for messages. Often the existing mail store will + not have the concept of UIDs in the sense that IMAP has: strictly + increasing, never re-issued, 32-bit integers. Some servers solve + this by storing the UIDs in a place that's accessible to end users, + allowing for the possibility that the users will delete them. Others + solve it by re-assigning UIDs every time a mailbox is selected. + + The server should maintain UIDs permanently for all messages if it + can. If that's not possible, the server must change the UIDVALIDITY + value for the mailbox whenever any of the UIDs may have become + invalid. Clients must recognize that the UIDVALIDITY has changed and + must respond to that condition by throwing away any information that + they have saved about UIDs in that mailbox. There have been many + problems in this area when clients have failed to do this; in the + worst case it will result in loss of mail when a client deletes the + + + +Leiba Informational [Page 12] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + wrong piece of mail by using a stale UID. + + It seems to be a common misunderstanding that "the UIDVALIDITY and + the UID, taken together, form a 64-bit identifier that uniquely + identifies a message on a server". This is absolutely NOT TRUE. + There is no assurance that the UIDVALIDITY values of two mailboxes be + different, so the UIDVALIDITY in no way identifies a mailbox. The + ONLY purpose of UIDVALIDITY is, as its name indicates, to give the + client a way to check the validity of the UIDs it has cached. While + it is a valid implementation choice to put these values together to + make a 64-bit identifier for the message, the important concept here + is that UIDs are not unique between mailboxes; they are only unique + WITHIN a given mailbox. + + Some server implementations have attempted to make UIDs unique across + the entire server. This is inadvisable, in that it limits the life + of UIDs unnecessarily. The UID is a 32-bit number and will run out + in reasonably finite time if it's global across the server. If you + assign UIDs sequentially in one mailbox, you will not have to start + re-using them until you have had, at one time or another, 2**32 + different messages in that mailbox. In the global case, you will + have to reuse them once you have had, at one time or another, 2**32 + different messages in the entire mail store. Suppose your server has + around 8000 users registered (2**13). That gives an average of 2**19 + UIDs per user. Suppose each user gets 32 messages (2**5) per day. + That gives you 2**14 days (16000+ days = about 45 years) before you + run out. That may seem like enough, but multiply the usage just a + little (a lot of spam, a lot of mailing list subscriptions, more + users) and you limit yourself too much. + + What's worse is that if you have to wrap the UIDs, and, thus, you + have to change UIDVALIDITY and invalidate the UIDs in the mailbox, + you have to do it for EVERY mailbox in the system, since they all + share the same UID pool. If you assign UIDs per mailbox and you have + a problem, you only have to kill the UIDs for that one mailbox. + + Under extreme circumstances (and this is extreme, indeed), the server + may have to invalidate UIDs while a mailbox is in use by a client - + that is, the UIDs that the client knows about in its active mailbox + are no longer valid. In that case, the server must immediately + change the UIDVALIDITY and must communicate this to the client. The + server may do this by sending an unsolicited UIDVALIDITY message, in + the same form as in response to the SELECT command. Clients must be + prepared to handle such a message and the possibly coincident failure + of the command in process. For example: + + + + + + +Leiba Informational [Page 13] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + C: 032 UID STORE 382 +Flags.silent \Deleted + S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value! + S: 032 NO UID command rejected because UIDVALIDITY changed! + C: ...invalidates local information and re-fetches... + C: 033 FETCH 1:* UID + ...etc... + + At the time of the writing of this document, the only server known to + do this does so only under the following condition: the client + selects INBOX, but there is not yet a physical INBOX file created. + Nonetheless, the SELECT succeeds, exporting an empty INBOX with a + temporary UIDVALIDITY of 1. While the INBOX remains selected, mail + is delivered to the user, which creates the real INBOX file and + assigns a permanent UIDVALIDITY (that is likely not to be 1). The + server reports the change of UIDVALIDITY, but as there were no + messages before, so no UIDs have actually changed, all the client + must do is accept the change in UIDVALIDITY. + + Alternatively, a server may force the client to re-select the + mailbox, at which time it will obtain a new UIDVALIDITY value. To do + this, the server closes this client session (see "Severed + Connections" above) and the client then reconnects and gets back in + synch. Clients must be prepared for either of these behaviours. + + We do not know of, nor do we anticipate the future existance of, a + server that changes UIDVALIDITY while there are existing messages, + but clients must be prepared to handle this eventuality. + +3.4.4. FETCH Responses + + When a client asks for certain information in a FETCH command, the + server may return the requested information in any order, not + necessarily in the order that it was requested. Further, the server + may return the information in separate FETCH responses and may also + return information that was not explicitly requested (to reflect to + the client changes in the state of the subject message). Some + examples: + + C: 001 FETCH 1 UID FLAGS INTERNALDATE + S: * 5 FETCH (FLAGS (\Deleted)) + S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345) + S: 001 OK done + + (In this case, the responses are in a different order. Also, the + server returned a flag update for message 5, which wasn't part of the + client's request.) + + + + + +Leiba Informational [Page 14] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + C: 002 FETCH 2 UID FLAGS INTERNALDATE + S: * 2 FETCH (INTERNALDATE "...") + S: * 2 FETCH (UID 399) + S: * 2 FETCH (FLAGS ()) + S: 002 OK done + + (In this case, the responses are in a different order and were + returned in separate responses.) + + C: 003 FETCH 2 BODY[1] + S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14} + S: Hello world! + S: ) + S: 003 OK done + + (In this case, the FLAGS response was added by the server, since + fetching the body part caused the server to set the \Seen flag.) + + Because of this characteristic a client must be ready to receive any + FETCH response at any time and should use that information to update + its local information about the message to which the FETCH response + refers. A client must not assume that any FETCH responses will come + in any particular order, or even that any will come at all. If after + receiving the tagged response for a FETCH command the client finds + that it did not get all of the information requested, the client + should send a NOOP command to the server to ensure that the server + has an opportunity to send any pending EXPUNGE responses to the + client (see [RFC-2180]). + +3.4.5. RFC822.SIZE + + Some back-end mail stores keep the mail in a canonical form, rather + than retaining the original MIME format of the messages. This means + that the server must reassemble the message to produce a MIME stream + when a client does a fetch such as RFC822 or BODY[], requesting the + entire message. It also may mean that the server has no convenient + way to know the RFC822.SIZE of the message. Often, such a server + will actually have to build the MIME stream to compute the size, only + to throw the stream away and report the size to the client. + + When this is the case, some servers have chosen to estimate the size, + rather than to compute it precisely. Such an estimate allows the + client to display an approximate size to the user and to use the + estimate in flood control considerations (q.v.), but requires that + the client not use the size for things such as allocation of buffers, + because those buffers might then be too small to hold the actual MIME + stream. Instead, a client should use the size that's returned in the + literal when you fetch the data. + + + +Leiba Informational [Page 15] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + The protocol requires that the RFC822.SIZE value returned by the + server be EXACT. Estimating the size is a protocol violation, and + server designers must be aware that, despite the performance savings + they might realize in using an estimate, this practice will cause + some clients to fail in various ways. If possible, the server should + compute the RFC822.SIZE for a particular message once, and then save + it for later retrieval. If that's not possible, the server must + compute the value exactly every time. Incorrect estimates do cause + severe interoperability problems with some clients. + +3.4.6. Expunged Messages + + If the server allows multiple connections to the same mailbox, it is + often possible for messages to be expunged in one client unbeknownst + to another client. Since the server is not allowed to tell the + client about these expunged messages in response to a FETCH command, + the server may have to deal with the issue of how to return + information about an expunged message. There was extensive + discussion about this issue, and the results of that discussion are + summarized in [RFC-2180]. See that reference for a detailed + explanation and for recommendations. + +3.4.7. The Namespace Issue + + Namespaces are a very muddy area in IMAP4 implementation right now + (see [NAMESPACE] for a proposal to clear the water a bit). Until the + issue is resolved, the important thing for client developers to + understand is that some servers provide access through IMAP to more + than just the user's personal mailboxes, and, in fact, the user's + personal mailboxes may be "hidden" somewhere in the user's default + hierarchy. The client, therefore, should provide a setting wherein + the user can specify a prefix to be used when accessing mailboxes. If + the user's mailboxes are all in "~/mail/", for instance, then the + user can put that string in the prefix. The client would then put + the prefix in front of any name pattern in the LIST and LSUB + commands: + + C: 001 LIST "" ~/mail/% + + (See also "Reference Names in the LIST Command" below.) + +3.4.8. Creating Special-Use Mailboxes + + It may seem at first that this is part of the namespace issue; it is + not, and is only indirectly related to it. A number of clients like + to create special-use mailboxes with particular names. Most + commonly, clients with a "trash folder" model of message deletion + want to create a mailbox with the name "Trash" or "Deleted". Some + + + +Leiba Informational [Page 16] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a + "Sent Mail" mailbox. And so on. There are two major + interoperability problems with this practice: + + 1. different clients may use different names for mailboxes with + similar functions (such as "Trash" and "Deleted"), or may manage + the same mailboxes in different ways, causing problems if a user + switches between clients and + 2. there is no guarantee that the server will allow the creation of + the desired mailbox. + + The client developer is, therefore, well advised to consider + carefully the creation of any special-use mailboxes on the server, + and, further, the client must not require such mailbox creation - + that is, if you do decide to do this, you must handle gracefully the + failure of the CREATE command and behave reasonably when your + special-use mailboxes do not exist and can not be created. + + In addition, the client developer should provide a convenient way for + the user to select the names for any special-use mailboxes, allowing + the user to make these names the same in all clients used and to put + them where the user wants them. + +3.4.9. Reference Names in the LIST Command + + Many implementers of both clients and servers are confused by the + "reference name" on the LIST command. The reference name is intended + to be used in much the way a "cd" (change directory) command is used + on Unix, PC DOS, Windows, and OS/2 systems. That is, the mailbox + name is interpreted in much the same way as a file of that name would + be found if one had done a "cd" command into the directory specified + by the reference name. For example, in Unix we have the following: + + > cd /u/jones/junk + > vi banana [file is "/u/jones/junk/banana"] + > vi stuff/banana [file is "/u/jones/junk/stuff/banana"] + > vi /etc/hosts [file is "/etc/hosts"] + + In the past, there have been several interoperability problems with + this. First, while some IMAP servers are built on Unix or PC file + systems, many others are not, and the file system semantics do not + make sense in those configurations. Second, while some IMAP servers + expose the underlying file system to the clients, others allow access + only to the user's personal mailboxes, or to some other limited set + of files, making such file-system-like semantics less meaningful. + Third, because the IMAP spec leaves the interpretation of the + reference name as "implementation-dependent", in the past the various + server implementations handled it in vastly differing ways. + + + +Leiba Informational [Page 17] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + The following recommendations are the result of significant + operational experience, and are intended to maximize + interoperability. + + Server implementations must implement the reference argument in a way + that matches the intended "change directory" operation as closely as + possible. As a minimum implementation, the reference argument may be + prepended to the mailbox name (while suppressing double delimiters; + see the next paragraph). Even servers that do not provide a way to + break out of the current hierarchy (see "breakout facility" below) + must provide a reasonable implementation of the reference argument, + as described here, so that they will interoperate with clients that + use it. + + Server implementations that prepend the reference argument to the + mailbox name should insert a hierarchy delimiter between them, and + must not insert a second if one is already present: + + C: A001 LIST ABC DEF + S: * LIST () "/" ABC/DEF <=== should do this + S: A001 OK done + + C: A002 LIST ABC/ /DEF + S: * LIST () "/" ABC//DEF <=== must not do this + S: A002 OK done + + On clients, the reference argument is chiefly used to implement a + "breakout facility", wherein the user may directly access a mailbox + outside the "current directory" hierarchy. Client implementations + should have an operational mode that does not use the reference + argument. This is to interoperate with older servers that did not + implement the reference argument properly. While it's a good idea to + give the user access to a breakout facility, clients that do not + intend to do so should not use the reference argument at all. + + Client implementations should always place a trailing hierarchy + delimiter on the reference argument. This is because some servers + prepend the reference argument to the mailbox name without inserting + a hierarchy delimiter, while others do insert a hierarchy delimiter + if one is not already present. A client that puts the delimiter in + will work with both varieties of server. + + Client implementations that implement a breakout facility should + allow the user to choose whether or not to use a leading hierarchy + delimiter on the mailbox argument. This is because the handling of a + leading mailbox hierarchy delimiter also varies from server to + server, and even between different mailstores on the same server. In + some cases, a leading hierarchy delimiter means "discard the + + + +Leiba Informational [Page 18] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + reference argument" (implementing the intended breakout facility), + thus: + + C: A001 LIST ABC/ /DEF + S: * LIST () "/" /DEF + S: A001 OK done + + In other cases, however, the two are catenated and the extra + hierarchy delimiter is discarded, thus: + + C: A001 LIST ABC/ /DEF + S: * LIST () "/" ABC/DEF + S: A001 OK done + + Client implementations must not assume that the server supports a + breakout facility, but may provide a way for the user to use one if + it is available. Any breakout facility should be exported to the + user interface. Note that there may be other "breakout" characters + besides the hierarchy delimiter (for instance, UNIX filesystem + servers are likely to use a leading "~" as well), and that their + interpretation is server-dependent. + +3.4.10. Mailbox Hierarchy Delimiters + + The server's selection of what to use as a mailbox hierarchy + delimiter is a difficult one, involving several issues: What + characters do users expect to see? What characters can they enter + for a hierarchy delimiter if it is desired (or required) that the + user enter it? What character can be used for the hierarchy + delimiter, noting that the chosen character can not otherwise be used + in the mailbox name? + + Because some interfaces show users the hierarchy delimiters or allow + users to enter qualified mailbox names containing them, server + implementations should use delimiter characters that users generally + expect to see as name separators. The most common characters used + for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows + file names), and "." (as in news groups). There is little to choose + among these apart from what users may expect or what is dictated by + the underlying file system, if any. One consideration about using + "\" is that it's also a special character in the IMAP protocol. While + the use of other hierarchy delimiter characters is permissible, A + DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the + server is intended for special purposes only. Implementers might be + thinking about using characters such as "-", "_", ";", "&", "#", "@", + and "!", but they should be aware of the surprise to the user as well + as of the effect on URLs and other external specifications (since + some of these characters have special meanings there). Also, a + + + +Leiba Informational [Page 19] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + server that uses "\" (and clients of such a server) must remember to + escape that character in quoted strings or to send literals instead. + Literals are recommended over escaped characters in quoted strings in + order to maintain compatibility with older IMAP versions that did not + allow escaped characters in quoted strings (but check the grammar to + see where literals are allowed): + + C: 001 LIST "" {13} + S: + send literal + C: this\%\%\%\h* + S: * LIST () "\\" {27} + S: this\is\a\mailbox\hierarchy + S: 001 OK LIST complete + + In any case, a server should not use normal alpha-numeric characters + (such as "X" or "0") as delimiters; a user would be very surprised to + find that "EXPENDITURES" actually represented a two-level hierarchy. + And a server should not use characters that are non-printable or + difficult or impossible to enter on a standard US keyboard. Control + characters, box-drawing characters, and characters from non-US + alphabets fit into this category. Their use presents + interoperability problems that are best avoided. + + The UTF-7 encoding of mailbox names also raises questions about what + to do with the hierarchy delimiters in encoded names: do we encode + each hierarchy level and separate them with delimiters, or do we + encode the fully qualified name, delimiters and all? The answer for + IMAP is the former: encode each hierarchy level separately, and + insert delimiters between. This makes it particularly important not + to use as a hierarchy delimiter a character that might cause + confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding. + + To repeat: a server should use "/", "\", or "." as its hierarchy + delimiter. The use of any other character is likely to cause + problems and is STRONGLY DISCOURAGED. + +3.4.11. ALERT Response Codes + + The protocol spec is very clear on the matter of what to do with + ALERT response codes, and yet there are many clients that violate it + so it needs to be said anyway: "The human-readable text contains a + special alert that must be presented to the user in a fashion that + calls the user's attention to the message." That should be clear + enough, but I'll repeat it here: Clients must present ALERT text + clearly to the user. + + + + + + +Leiba Informational [Page 20] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.4.12. Deleting Mailboxes + + The protocol does not guarantee that a client may delete a mailbox + that is not empty, though on some servers it is permissible and is, + in fact, much faster than the alternative or deleting all the + messages from the client. If the client chooses to try to take + advantage of this possibility it must be prepared to use the other + method in the even that the more convenient one fails. Further, a + client should not try to delete the mailbox that it has selected, but + should first close that mailbox; some servers do not permit the + deletion of the selected mailbox. + + That said, a server should permit the deletion of a non-empty + mailbox; there's little reason to pass this work on to the client. + Moreover, forbidding this prevents the deletion of a mailbox that for + some reason can not be opened or expunged, leading to possible + denial-of-service problems. + + Example: + + [User tells the client to delete mailbox BANANA, which is + currently selected...] + C: 008 CLOSE + S: 008 OK done + C: 009 DELETE BANANA + S: 009 NO Delete failed; mailbox is not empty. + C: 010 SELECT BANANA + S: * ... untagged SELECT responses + S: 010 OK done + C: 011 STORE 1:* +FLAGS.SILENT \DELETED + S: 011 OK done + C: 012 CLOSE + S: 012 OK done + C: 013 DELETE BANANA + S: 013 OK done + +3.5. A Word About Testing + + Since the whole point of IMAP is interoperability, and since + interoperability can not be tested in a vacuum, the final + recommendation of this treatise is, "Test against EVERYTHING." Test + your client against every server you can get an account on. Test + your server with every client you can get your hands on. Many + clients make limited test versions available on the Web for the + downloading. Many server owners will give serious client developers + guest accounts for testing. Contact them and ask. NEVER assume that + because your client works with one or two servers, or because your + server does fine with one or two clients, you will interoperate well + + + +Leiba Informational [Page 21] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + in general. + + In particular, in addition to everything else, be sure to test + against the reference implementations: the PINE client, the + University of Washington server, and the Cyrus server. + + See the following URLs on the web for more information here: + + IMAP Products and Sources: http://www.imap.org/products.html + IMC MailConnect: http://www.imc.org/imc-mailconnect + +4. Security Considerations + + This document describes behaviour of clients and servers that use the + IMAP4 protocol, and as such, has the same security considerations as + described in [RFC-2060]. + +5. References + + [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC + 2180, July 1997. + + [UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode + and ISO 10646", RFC 2044, October 1996. + + [UTF-7] Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe + Transformation Format of Unicode", RFC 2152, May 1997. + + [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in + Progress. + +6. Author's Address + + Barry Leiba + IBM T.J. Watson Research Center + 30 Saw Mill River Road + Hawthorne, NY 10532 + + Phone: 1-914-784-7941 + EMail: leiba@watson.ibm.com + + + + + +Leiba Informational [Page 22] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +7. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Leiba Informational [Page 23] + diff --git a/server/src/site/resources/rfclist/ldap/rfc2251.txt b/server/src/site/resources/rfclist/ldap/rfc2251.txt new file mode 100644 index 00000000000..88844cbf38b --- /dev/null +++ b/server/src/site/resources/rfclist/ldap/rfc2251.txt @@ -0,0 +1,2803 @@ + + + + + + +Network Working Group M. Wahl +Request for Comments: 2251 Critical Angle Inc. +Category: Standards Track T. Howes + Netscape Communications Corp. + S. Kille + Isode Limited + December 1997 + + + Lightweight Directory Access Protocol (v3) + +1. 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. + +IESG Note + + This document describes a directory access protocol that provides + both read and update access. Update access requires secure + authentication, but this document does not mandate implementation of + any satisfactory authentication mechanisms. + + In accordance with RFC 2026, section 4.4.1, this specification is + being approved by IESG as a Proposed Standard despite this + limitation, for the following reasons: + + a. to encourage implementation and interoperability testing of + these protocols (with or without update access) before they + are deployed, and + + b. to encourage deployment and use of these protocols in read-only + applications. (e.g. applications where LDAPv3 is used as + a query language for directories which are updated by some + secure mechanism other than LDAP), and + + c. to avoid delaying the advancement and deployment of other Internet + standards-track protocols which require the ability to query, but + not update, LDAPv3 directory servers. + + + + + +Wahl, et. al. Standards Track [Page 1] + +RFC 2251 LDAPv3 December 1997 + + + Readers are hereby warned that until mandatory authentication + mechanisms are standardized, clients and servers written according to + this specification which make use of update functionality are + UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION + IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. + + Implementors are hereby discouraged from deploying LDAPv3 clients or + servers which implement the update functionality, until a Proposed + Standard for mandatory authentication in LDAPv3 has been approved and + published as an RFC. + +Table of Contents + + 1. Status of this Memo .................................... 1 + Copyright Notice ....................................... 1 + IESG Note .............................................. 1 + 2. Abstract ............................................... 3 + 3. Models ................................................. 4 + 3.1. Protocol Model ........................................ 4 + 3.2. Data Model ............................................ 5 + 3.2.1. Attributes of Entries ............................... 5 + 3.2.2. Subschema Entries and Subentries .................... 7 + 3.3. Relationship to X.500 ................................. 8 + 3.4. Server-specific Data Requirements ..................... 8 + 4. Elements of Protocol ................................... 9 + 4.1. Common Elements ....................................... 9 + 4.1.1. Message Envelope .................................... 9 + 4.1.1.1. Message ID ........................................ 11 + 4.1.2. String Types ........................................ 11 + 4.1.3. Distinguished Name and Relative Distinguished Name .. 11 + 4.1.4. Attribute Type ...................................... 12 + 4.1.5. Attribute Description ............................... 13 + 4.1.5.1. Binary Option ..................................... 14 + 4.1.6. Attribute Value ..................................... 14 + 4.1.7. Attribute Value Assertion ........................... 15 + 4.1.8. Attribute ........................................... 15 + 4.1.9. Matching Rule Identifier ............................ 15 + 4.1.10. Result Message ..................................... 16 + 4.1.11. Referral ........................................... 18 + 4.1.12. Controls ........................................... 19 + 4.2. Bind Operation ........................................ 20 + 4.2.1. Sequencing of the Bind Request ...................... 21 + 4.2.2. Authentication and Other Security Services .......... 22 + 4.2.3. Bind Response ....................................... 23 + 4.3. Unbind Operation ...................................... 24 + 4.4. Unsolicited Notification .............................. 24 + 4.4.1. Notice of Disconnection ............................. 24 + 4.5. Search Operation ...................................... 25 + + + +Wahl, et. al. Standards Track [Page 2] + +RFC 2251 LDAPv3 December 1997 + + + 4.5.1. Search Request ...................................... 25 + 4.5.2. Search Result ....................................... 29 + 4.5.3. Continuation References in the Search Result ........ 31 + 4.5.3.1. Example ........................................... 31 + 4.6. Modify Operation ...................................... 32 + 4.7. Add Operation ......................................... 34 + 4.8. Delete Operation ...................................... 35 + 4.9. Modify DN Operation ................................... 36 + 4.10. Compare Operation .................................... 37 + 4.11. Abandon Operation .................................... 38 + 4.12. Extended Operation ................................... 38 + 5. Protocol Element Encodings and Transfer ................ 39 + 5.1. Mapping Onto BER-based Transport Services ............. 39 + 5.2. Transfer Protocols .................................... 40 + 5.2.1. Transmission Control Protocol (TCP) ................. 40 + 6. Implementation Guidelines .............................. 40 + 6.1. Server Implementations ................................ 40 + 6.2. Client Implementations ................................ 40 + 7. Security Considerations ................................ 41 + 8. Acknowledgements ....................................... 41 + 9. Bibliography ........................................... 41 + 10. Authors' Addresses ..................................... 42 + Appendix A - Complete ASN.1 Definition ..................... 44 + Full Copyright Statement ................................... 50 + +2. Abstract + + The protocol described in this document is designed to provide access + to directories supporting the X.500 models, while not incurring the + resource requirements of the X.500 Directory Access Protocol (DAP). + This protocol is specifically targeted at management applications and + browser applications that provide read/write interactive access to + directories. When used with a directory supporting the X.500 + protocols, it is intended to be a complement to the X.500 DAP. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document + are to be interpreted as described in RFC 2119 [10]. + + Key aspects of this version of LDAP are: + + - All protocol elements of LDAPv2 (RFC 1777) are supported. The + protocol is carried directly over TCP or other transport, bypassing + much of the session/presentation overhead of X.500 DAP. + + - Most protocol data elements can be encoded as ordinary strings + (e.g., Distinguished Names). + + + + +Wahl, et. al. Standards Track [Page 3] + +RFC 2251 LDAPv3 December 1997 + + + - Referrals to other servers may be returned. + + - SASL mechanisms may be used with LDAP to provide association + security services. + + - Attribute values and Distinguished Names have been + internationalized through the use of the ISO 10646 character set. + + - The protocol can be extended to support new operations, and + controls may be used to extend existing operations. + + - Schema is published in the directory for use by clients. + +3. Models + + Interest in X.500 [1] directory technologies in the Internet has led + to efforts to reduce the high cost of entry associated with use of + these technologies. This document continues the efforts to define + directory protocol alternatives, updating the LDAP [2] protocol + specification. + +3.1. Protocol Model + + The general model adopted by this protocol is one of clients + performing protocol operations against servers. In this model, a + client transmits a protocol request describing the operation to be + performed to a server. The server is then responsible for performing + the necessary operation(s) in the directory. Upon completion of the + operation(s), the server returns a response containing any results or + errors to the requesting client. + + In keeping with the goal of easing the costs associated with use of + the directory, it is an objective of this protocol to minimize the + complexity of clients so as to facilitate widespread deployment of + applications capable of using the directory. + + Note that although servers are required to return responses whenever + such responses are defined in the protocol, there is no requirement + for synchronous behavior on the part of either clients or servers. + Requests and responses for multiple operations may be exchanged + between a client and server in any order, provided the client + eventually receives a response for every request that requires one. + + In LDAP versions 1 and 2, no provision was made for protocol servers + returning referrals to clients. However, for improved performance + and distribution this version of the protocol permits servers to + return to clients referrals to other servers. This allows servers to + offload the work of contacting other servers to progress operations. + + + +Wahl, et. al. Standards Track [Page 4] + +RFC 2251 LDAPv3 December 1997 + + + Note that the core protocol operations defined in this document can + be mapped to a strict subset of the X.500(1997) directory abstract + service, so it can be cleanly provided by the DAP. However there is + not a one-to-one mapping between LDAP protocol operations and DAP + operations: server implementations acting as a gateway to X.500 + directories may need to make multiple DAP requests. + +3.2. Data Model + + This section provides a brief introduction to the X.500 data model, + as used by LDAP. + + The LDAP protocol assumes there are one or more servers which jointly + provide access to a Directory Information Tree (DIT). The tree is + made up of entries. Entries have names: one or more attribute values + from the entry form its relative distinguished name (RDN), which MUST + be unique among all its siblings. The concatenation of the relative + distinguished names of the sequence of entries from a particular + entry to an immediate subordinate of the root of the tree forms that + entry's Distinguished Name (DN), which is unique in the tree. An + example of a Distinguished Name is + + CN=Steve Kille, O=Isode Limited, C=GB + + Some servers may hold cache or shadow copies of entries, which can be + used to answer search and comparison queries, but will return + referrals or contact other servers if modification operations are + requested. + + Servers which perform caching or shadowing MUST ensure that they do + not violate any access control constraints placed on the data by the + originating server. + + The largest collection of entries, starting at an entry that is + mastered by a particular server, and including all its subordinates + and their subordinates, down to the entries which are mastered by + different servers, is termed a naming context. The root of the DIT + is a DSA-specific Entry (DSE) and not part of any naming context: + each server has different attribute values in the root DSE. (DSA is + an X.500 term for the directory server). + +3.2.1. Attributes of Entries + + Entries consist of a set of attributes. An attribute is a type with + one or more associated values. The attribute type is identified by a + short descriptive name and an OID (object identifier). The attribute + + + + + +Wahl, et. al. Standards Track [Page 5] + +RFC 2251 LDAPv3 December 1997 + + + type governs whether there can be more than one value of an attribute + of that type in an entry, the syntax to which the values must + conform, the kinds of matching which can be performed on values of + that attribute, and other functions. + + An example of an attribute is "mail". There may be one or more values + of this attribute, they must be IA5 (ASCII) strings, and they are + case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM"). + + Schema is the collection of attribute type definitions, object class + definitions and other information which a server uses to determine + how to match a filter or attribute value assertion (in a compare + operation) against the attributes of an entry, and whether to permit + add and modify operations. The definition of schema for use with + LDAP is given in [5] and [6]. Additional schema elements may be + defined in other documents. + + Each entry MUST have an objectClass attribute. The objectClass + attribute specifies the object classes of an entry, which along with + the system and user schema determine the permitted attributes of an + entry. Values of this attribute may be modified by clients, but the + objectClass attribute cannot be removed. Servers may restrict the + modifications of this attribute to prevent the basic structural class + of the entry from being changed (e.g. one cannot change a person into + a country). When creating an entry or adding an objectClass value to + an entry, all superclasses of the named classes are implicitly added + as well if not already present, and the client must supply values for + any mandatory attributes of new superclasses. + + Some attributes, termed operational attributes, are used by servers + for administering the directory system itself. They are not returned + in search results unless explicitly requested by name. Attributes + which are not operational, such as "mail", will have their schema and + syntax constraints enforced by servers, but servers will generally + not make use of their values. + + Servers MUST NOT permit clients to add attributes to an entry unless + those attributes are permitted by the object class definitions, the + schema controlling that entry (specified in the subschema - see + below), or are operational attributes known to that server and used + for administrative purposes. Note that there is a particular + objectClass 'extensibleObject' defined in [5] which permits all user + attributes to be present in an entry. + + Entries MAY contain, among others, the following operational + attributes, defined in [5]. These attributes are maintained + automatically by the server and are not modifiable by clients: + + + + +Wahl, et. al. Standards Track [Page 6] + +RFC 2251 LDAPv3 December 1997 + + + - creatorsName: the Distinguished Name of the user who added this + entry to the directory. + + - createTimestamp: the time this entry was added to the directory. + + - modifiersName: the Distinguished Name of the user who last modified + this entry. + + - modifyTimestamp: the time this entry was last modified. + + - subschemaSubentry: the Distinguished Name of the subschema entry + (or subentry) which controls the schema for this entry. + +3.2.2. Subschema Entries and Subentries + + Subschema entries are used for administering information about the + directory schema, in particular the object classes and attribute + types supported by directory servers. A single subschema entry + contains all schema definitions used by entries in a particular part + of the directory tree. + + Servers which follow X.500(93) models SHOULD implement subschema + using the X.500 subschema mechanisms, and so these subschemas are not + ordinary entries. LDAP clients SHOULD NOT assume that servers + implement any of the other aspects of X.500 subschema. A server + which masters entries and permits clients to modify these entries + MUST implement and provide access to these subschema entries, so that + its clients may discover the attributes and object classes which are + permitted to be present. It is strongly recommended that all other + servers implement this as well. + + The following four attributes MUST be present in all subschema + entries: + + - cn: this attribute MUST be used to form the RDN of the subschema + entry. + + - objectClass: the attribute MUST have at least the values "top" and + "subschema". + + - objectClasses: each value of this attribute specifies an object + class known to the server. + + - attributeTypes: each value of this attribute specifies an attribute + type known to the server. + + These are defined in [5]. Other attributes MAY be present in + subschema entries, to reflect additional supported capabilities. + + + +Wahl, et. al. Standards Track [Page 7] + +RFC 2251 LDAPv3 December 1997 + + + These include matchingRules, matchingRuleUse, dITStructureRules, + dITContentRules, nameForms and ldapSyntaxes. + + Servers SHOULD provide the attributes createTimestamp and + modifyTimestamp in subschema entries, in order to allow clients to + maintain their caches of schema information. + + Clients MUST only retrieve attributes from a subschema entry by + requesting a base object search of the entry, where the search filter + is "(objectClass=subschema)". (This will allow LDAPv3 servers which + gateway to X.500(93) to detect that subentry information is being + requested.) + +3.3. Relationship to X.500 + + This document defines LDAP in terms of X.500 as an X.500 access + mechanism. An LDAP server MUST act in accordance with the + X.500(1993) series of ITU recommendations when providing the service. + However, it is not required that an LDAP server make use of any X.500 + protocols in providing this service, e.g. LDAP can be mapped onto any + other directory system so long as the X.500 data and service model as + used in LDAP is not violated in the LDAP interface. + +3.4. Server-specific Data Requirements + + An LDAP server MUST provide information about itself and other + information that is specific to each server. This is represented as + a group of attributes located in the root DSE (DSA-Specific Entry), + which is named with the zero-length LDAPDN. These attributes are + retrievable if a client performs a base object search of the root + with filter "(objectClass=*)", however they are subject to access + control restrictions. The root DSE MUST NOT be included if the + client performs a subtree search starting from the root. + + Servers may allow clients to modify these attributes. + + The following attributes of the root DSE are defined in section 5 of + [5]. Additional attributes may be defined in other documents. + + - namingContexts: naming contexts held in the server. Naming contexts + are defined in section 17 of X.501 [6]. + + - subschemaSubentry: subschema entries (or subentries) known by this + server. + + - altServer: alternative servers in case this one is later + unavailable. + + + + +Wahl, et. al. Standards Track [Page 8] + +RFC 2251 LDAPv3 December 1997 + + + - supportedExtension: list of supported extended operations. + + - supportedControl: list of supported controls. + + - supportedSASLMechanisms: list of supported SASL security features. + + - supportedLDAPVersion: LDAP versions implemented by the server. + + If the server does not master entries and does not know the locations + of schema information, the subschemaSubentry attribute is not present + in the root DSE. If the server masters directory entries under one + or more schema rules, there may be any number of values of the + subschemaSubentry attribute in the root DSE. + +4. Elements of Protocol + + The LDAP protocol is described using Abstract Syntax Notation 1 + (ASN.1) [3], and is typically transferred using a subset of ASN.1 + Basic Encoding Rules [11]. In order to support future extensions to + this protocol, clients and servers MUST ignore elements of SEQUENCE + encodings whose tags they do not recognize. + + Note that unlike X.500, each change to the LDAP protocol other than + through the extension mechanisms will have a different version + number. A client will indicate the version it supports as part of + the bind request, described in section 4.2. If a client has not sent + a bind, the server MUST assume that version 3 is supported in the + client (since version 2 required that the client bind first). + + Clients may determine the protocol version a server supports by + reading the supportedLDAPVersion attribute from the root DSE. Servers + which implement version 3 or later versions MUST provide this + attribute. Servers which only implement version 2 may not provide + this attribute. + +4.1. Common Elements + + This section describes the LDAPMessage envelope PDU (Protocol Data + Unit) format, as well as data type definitions which are used in the + protocol operations. + +4.1.1. Message Envelope + + For the purposes of protocol exchanges, all protocol operations are + encapsulated in a common envelope, the LDAPMessage, which is defined + as follows: + + LDAPMessage ::= SEQUENCE { + + + +Wahl, et. al. Standards Track [Page 9] + +RFC 2251 LDAPv3 December 1997 + + + messageID MessageID, + protocolOp CHOICE { + bindRequest BindRequest, + bindResponse BindResponse, + unbindRequest UnbindRequest, + searchRequest SearchRequest, + searchResEntry SearchResultEntry, + searchResDone SearchResultDone, + searchResRef SearchResultReference, + modifyRequest ModifyRequest, + modifyResponse ModifyResponse, + addRequest AddRequest, + addResponse AddResponse, + delRequest DelRequest, + delResponse DelResponse, + modDNRequest ModifyDNRequest, + modDNResponse ModifyDNResponse, + compareRequest CompareRequest, + compareResponse CompareResponse, + abandonRequest AbandonRequest, + extendedReq ExtendedRequest, + extendedResp ExtendedResponse }, + controls [0] Controls OPTIONAL } + + MessageID ::= INTEGER (0 .. maxInt) + + maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- + + The function of the LDAPMessage is to provide an envelope containing + common fields required in all protocol exchanges. At this time the + only common fields are the message ID and the controls. + + If the server receives a PDU from the client in which the LDAPMessage + SEQUENCE tag cannot be recognized, the messageID cannot be parsed, + the tag of the protocolOp is not recognized as a request, or the + encoding structures or lengths of data fields are found to be + incorrect, then the server MUST return the notice of disconnection + described in section 4.4.1, with resultCode protocolError, and + immediately close the connection. In other cases that the server + cannot parse the request received by the client, the server MUST + return an appropriate response to the request, with the resultCode + set to protocolError. + + If the client receives a PDU from the server which cannot be parsed, + the client may discard the PDU, or may abruptly close the connection. + + The ASN.1 type Controls is defined in section 4.1.12. + + + + +Wahl, et. al. Standards Track [Page 10] + +RFC 2251 LDAPv3 December 1997 + + +4.1.1.1. Message ID + + All LDAPMessage envelopes encapsulating responses contain the + messageID value of the corresponding request LDAPMessage. + + The message ID of a request MUST have a value different from the + values of any other requests outstanding in the LDAP session of which + this message is a part. + + A client MUST NOT send a second request with the same message ID as + an earlier request on the same connection if the client has not + received the final response from the earlier request. Otherwise the + behavior is undefined. Typical clients increment a counter for each + request. + + A client MUST NOT reuse the message id of an abandonRequest or of the + abandoned operation until it has received a response from the server + for another request invoked subsequent to the abandonRequest, as the + abandonRequest itself does not have a response. + +4.1.2. String Types + + The LDAPString is a notational convenience to indicate that, although + strings of LDAPString type encode as OCTET STRING types, the ISO + 10646 [13] character set (a superset of Unicode) is used, encoded + following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm + characters which are the same as ASCII (0x0000 through 0x007F) are + represented as that same ASCII character in a single byte. The other + byte values are used to form a variable-length encoding of an + arbitrary character. + + LDAPString ::= OCTET STRING + + The LDAPOID is a notational convenience to indicate that the + permitted value of this string is a (UTF-8 encoded) dotted-decimal + representation of an OBJECT IDENTIFIER. + + LDAPOID ::= OCTET STRING + + For example, + + 1.3.6.1.4.1.1466.1.2.3 + +4.1.3. Distinguished Name and Relative Distinguished Name + + An LDAPDN and a RelativeLDAPDN are respectively defined to be the + representation of a Distinguished Name and a Relative Distinguished + Name after encoding according to the specification in [4], such that + + + +Wahl, et. al. Standards Track [Page 11] + +RFC 2251 LDAPv3 December 1997 + + + ::= + + ::= + + where and are as defined in [4]. + + LDAPDN ::= LDAPString + + RelativeLDAPDN ::= LDAPString + + Only Attribute Types can be present in a relative distinguished name + component; the options of Attribute Descriptions (next section) MUST + NOT be used in specifying distinguished names. + +4.1.4. Attribute Type + + An AttributeType takes on as its value the textual string associated + with that AttributeType in its specification. + + AttributeType ::= LDAPString + + Each attribute type has a unique OBJECT IDENTIFIER which has been + assigned to it. This identifier may be written as decimal digits + with components separated by periods, e.g. "2.5.4.10". + + A specification may also assign one or more textual names for an + attribute type. These names MUST begin with a letter, and only + contain ASCII letters, digit characters and hyphens. They are case + insensitive. (These ASCII characters are identical to ISO 10646 + characters whose UTF-8 encoding is a single byte between 0x00 and + 0x7F.) + + If the server has a textual name for an attribute type, it MUST use a + textual name for attributes returned in search results. The dotted- + decimal OBJECT IDENTIFIER is only used if there is no textual name + for an attribute type. + + Attribute type textual names are non-unique, as two different + specifications (neither in standards track RFCs) may choose the same + name. + + A server which masters or shadows entries SHOULD list all the + attribute types it supports in the subschema entries, using the + attributeTypes attribute. Servers which support an open-ended set of + attributes SHOULD include at least the attributeTypes value for the + 'objectClass' attribute. Clients MAY retrieve the attributeTypes + value from subschema entries in order to obtain the OBJECT IDENTIFIER + and other information associated with attribute types. + + + +Wahl, et. al. Standards Track [Page 12] + +RFC 2251 LDAPv3 December 1997 + + + Some attribute type names which are used in this version of LDAP are + described in [5]. Servers may implement additional attribute types. + +4.1.5. Attribute Description + + An AttributeDescription is a superset of the definition of the + AttributeType. It has the same ASN.1 definition, but allows + additional options to be specified. They are also case insensitive. + + AttributeDescription ::= LDAPString + + A value of AttributeDescription is based on the following BNF: + + ::= [ ";" ] + + ::=
::= the one or two decimal integer day of the month in + the range 1 to 31. + + ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | + "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" + + ::= the two decimal integer year of the century in the + range 00 to 99. + + + + + +[Page 32] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ::= the two decimal integer hour of the day in the + range 00 to 24. + + ::= the two decimal integer minute of the hour in the + range 00 to 59. + + ::= the two decimal integer second of the minute in the + range 00 to 59. + + ::= "UT" for Universal Time (the default) or other + time zone designator (as in [2]). + + + + ------------------------------------------------------------- + + Return Path Example + + Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA> + + Example 9 + + ------------------------------------------------------------- + + ------------------------------------------------------------- + + Time Stamp Line Example + + Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT + + Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25 + id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT + + Example 10 + + ------------------------------------------------------------- + + + + + + + + + + + + + +Postel [Page 33] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 4.2. SMTP REPLIES + + Replies to SMTP commands are devised to ensure the synchronization + of requests and actions in the process of mail transfer, and to + guarantee that the sender-SMTP always knows the state of the + receiver-SMTP. Every command must generate exactly one reply. + + The details of the command-reply sequence are made explicit in + Section 5.3 on Sequencing and Section 5.4 State Diagrams. + + An SMTP reply consists of a three digit number (transmitted as + three alphanumeric characters) followed by some text. The number + is intended for use by automata to determine what state to enter + next; the text is meant for the human user. It is intended that + the three digits contain enough encoded information that the + sender-SMTP need not examine the text and may either discard it or + pass it on to the user, as appropriate. In particular, the text + may be receiver-dependent and context dependent, so there are + likely to be varying texts for each reply code. A discussion of + the theory of reply codes is given in Appendix E. Formally, a + reply is defined to be the sequence: a three-digit code, , + one line of text, and , or a multiline reply (as defined in + Appendix E). Only the EXPN and HELP commands are expected to + result in multiline replies in normal circumstances, however + multiline replies are allowed for any command. + + + + + + + + + + + + + + + + + + + + + + + + +[Page 34] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.2.1. REPLY CODES BY FUNCTION GROUPS + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + + 220 Service ready + 221 Service closing transmission channel + 421 Service not available, + closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + + 250 Requested mail action okay, completed + 251 User not local; will forward to + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 451 Requested action aborted: error in processing + 551 User not local; please try + 452 Requested action not taken: insufficient system storage + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 354 Start mail input; end with . + 554 Transaction failed + + + + + + + + + + + + + +Postel [Page 35] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 4.2.2. NUMERIC ORDER LIST OF REPLY CODES + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + 220 Service ready + 221 Service closing transmission channel + 250 Requested mail action okay, completed + 251 User not local; will forward to + + 354 Start mail input; end with . + + 421 Service not available, + closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 551 User not local; please try + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 554 Transaction failed + + + + + + + + + + + + + +[Page 36] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.3. SEQUENCING OF COMMANDS AND REPLIES + + The communication between the sender and receiver is intended to + be an alternating dialogue, controlled by the sender. As such, + the sender issues a command and the receiver responds with a + reply. The sender must wait for this response before sending + further commands. + + One important reply is the connection greeting. Normally, a + receiver will send a 220 "Service ready" reply when the connection + is completed. The sender should wait for this greeting message + before sending any commands. + + Note: all the greeting type replies have the official name of + the server host as the first word following the reply code. + + For example, + + 220 USC-ISIF.ARPA Service ready + + The table below lists alternative success and failure replies for + each command. These must be strictly adhered to; a receiver may + substitute text in the replies, but the meaning and action implied + by the code numbers and by the specific command reply sequence + cannot be altered. + + COMMAND-REPLY SEQUENCES + + Each command is listed with its possible replies. The prefixes + used before the possible replies are "P" for preliminary (not + used in SMTP), "I" for intermediate, "S" for success, "F" for + failure, and "E" for error. The 421 reply (service not + available, closing transmission channel) may be given to any + command if the SMTP-receiver knows it must shut down. This + listing forms the basis for the State Diagrams in Section 4.4. + + CONNECTION ESTABLISHMENT + S: 220 + F: 421 + HELO + S: 250 + E: 500, 501, 504, 421 + MAIL + S: 250 + F: 552, 451, 452 + E: 500, 501, 421 + + + +Postel [Page 37] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + RCPT + S: 250, 251 + F: 550, 551, 552, 553, 450, 451, 452 + E: 500, 501, 503, 421 + DATA + I: 354 -> data -> S: 250 + F: 552, 554, 451, 452 + F: 451, 554 + E: 500, 501, 503, 421 + RSET + S: 250 + E: 500, 501, 504, 421 + SEND + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SOML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SAML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + VRFY + S: 250, 251 + F: 550, 551, 553 + E: 500, 501, 502, 504, 421 + EXPN + S: 250 + F: 550 + E: 500, 501, 502, 504, 421 + HELP + S: 211, 214 + E: 500, 501, 502, 504, 421 + NOOP + S: 250 + E: 500, 421 + QUIT + S: 221 + E: 500 + TURN + S: 250 + F: 502 + E: 500, 503 + + + + +[Page 38] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.4. STATE DIAGRAMS + + Following are state diagrams for a simple-minded SMTP + implementation. Only the first digit of the reply codes is used. + There is one state diagram for each group of SMTP commands. The + command groupings were determined by constructing a model for each + command and then collecting together the commands with + structurally identical models. + + For each command there are three possible outcomes: "success" + (S), "failure" (F), and "error" (E). In the state diagrams below + we use the symbol B for "begin", and the symbol W for "wait for + reply". + + First, the diagram that represents most of the SMTP commands: + + + 1,3 +---+ + ----------->| E | + | +---+ + | + +---+ cmd +---+ 2 +---+ + | B |---------->| W |---------->| S | + +---+ +---+ +---+ + | + | 4,5 +---+ + ----------->| F | + +---+ + + + This diagram models the commands: + + HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, + NOOP, QUIT, TURN. + + + + + + + + + + + + + + + +Postel [Page 39] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + A more complex diagram models the DATA command: + + + +---+ DATA +---+ 1,2 +---+ + | B |---------->| W |-------------------->| E | + +---+ +---+ ------------>+---+ + 3| |4,5 | + | | | + -------------- ----- | + | | | +---+ + | ---------- -------->| S | + | | | | +---+ + | | ------------ + | | | | + V 1,3| |2 | + +---+ data +---+ --------------->+---+ + | |---------->| W | | F | + +---+ +---+-------------------->+---+ + 4,5 + + + Note that the "data" here is a series of lines sent from the + sender to the receiver with no response expected until the last + line is sent. + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 40] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.5. DETAILS + + 4.5.1. MINIMUM IMPLEMENTATION + + In order to make SMTP workable, the following minimum + implementation is required for all receivers: + + COMMANDS -- HELO + MAIL + RCPT + DATA + RSET + NOOP + QUIT + + 4.5.2. TRANSPARENCY + + Without some provision for data transparency the character + sequence "." ends the mail text and cannot be sent + by the user. In general, users are not aware of such + "forbidden" sequences. To allow all user composed text to be + transmitted transparently the following procedures are used. + + 1. Before sending a line of mail text the sender-SMTP checks + the first character of the line. If it is a period, one + additional period is inserted at the beginning of the line. + + 2. When a line of mail text is received by the receiver-SMTP + it checks the line. If the line is composed of a single + period it is the end of mail. If the first character is a + period and there are other characters on the line, the first + character is deleted. + + The mail data may contain any of the 128 ASCII characters. All + characters are to be delivered to the recipient's mailbox + including format effectors and other control characters. If + the transmission channel provides an 8-bit byte (octets) data + stream, the 7-bit ASCII codes are transmitted right justified + in the octets with the high order bits cleared to zero. + + In some systems it may be necessary to transform the data as + it is received and stored. This may be necessary for hosts + that use a different character set than ASCII as their local + character set, or that store data in records rather than + + + + + +Postel [Page 41] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + strings. If such transforms are necessary, they must be + reversible -- especially if such transforms are applied to + mail being relayed. + + 4.5.3. SIZES + + There are several objects that have required minimum maximum + sizes. That is, every implementation must be able to receive + objects of at least these sizes, but must not send objects + larger than these sizes. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + user + + The maximum total length of a user name is 64 characters. + + domain + + The maximum total length of a domain name or number is 64 + characters. + + path + + The maximum total length of a reverse-path or + forward-path is 256 characters (including the punctuation + and element separators). + + command line + + The maximum total length of a command line including the + command word and the is 512 characters. + + reply line + + The maximum total length of a reply line including the + reply code and the is 512 characters. + + + + + +[Page 42] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + text line + + The maximum total length of a text line including the + is 1000 characters (but not counting the leading + dot duplicated for transparency). + + recipients buffer + + The maximum total number of recipients that must be + buffered is 100 recipients. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + Errors due to exceeding these limits may be reported by using + the reply codes, for example: + + 500 Line too long. + + 501 Path too long + + 552 Too many recipients. + + 552 Too much mail data. + + + + + + + + + + + + + + + + + + + +Postel [Page 43] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX A + + TCP Transport service + + The Transmission Control Protocol [3] is used in the ARPA + Internet, and in any network following the US DoD standards for + internetwork protocols. + + Connection Establishment + + The SMTP transmission channel is a TCP connection established + between the sender process port U and the receiver process port + L. This single full duplex connection is used as the + transmission channel. This protocol is assigned the service + port 25 (31 octal), that is L=25. + + Data Transfer + + The TCP connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 44] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX B + + NCP Transport service + + The ARPANET Host-to-Host Protocol [4] (implemented by the Network + Control Program) may be used in the ARPANET. + + Connection Establishment + + The SMTP transmission channel is established via NCP between + the sender process socket U and receiver process socket L. The + Initial Connection Protocol [5] is followed resulting in a pair + of simplex connections. This pair of connections is used as + the transmission channel. This protocol is assigned the + contact socket 25 (31 octal), that is L=25. + + Data Transfer + + The NCP data connections are established in 8-bit byte mode. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 45] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX C + + NITS + + The Network Independent Transport Service [6] may be used. + + Connection Establishment + + The SMTP transmission channel is established via NITS between + the sender process and receiver process. The sender process + executes the CONNECT primitive, and the waiting receiver + process executes the ACCEPT primitive. + + Data Transfer + + The NITS connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 46] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX D + + X.25 Transport service + + It may be possible to use the X.25 service [7] as provided by the + Public Data Networks directly, however, it is suggested that a + reliable end-to-end protocol such as TCP be used on top of X.25 + connections. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 47] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX E + + Theory of Reply Codes + + The three digits of the reply each have a special significance. + The first digit denotes whether the response is good, bad or + incomplete. An unsophisticated sender-SMTP will be able to + determine its next action (proceed as planned, redo, retrench, + etc.) by simply examining this first digit. A sender-SMTP that + wants to know approximately what kind of error occurred (e.g., + mail system error, command syntax error) may examine the second + digit, reserving the third digit for the finest gradation of + information. + + There are five values for the first digit of the reply code: + + 1yz Positive Preliminary reply + + The command has been accepted, but the requested action + is being held in abeyance, pending confirmation of the + information in this reply. The sender-SMTP should send + another command specifying whether to continue or abort + the action. + + [Note: SMTP does not have any commands that allow this + type of reply, and so does not have the continue or + abort commands.] + + 2yz Positive Completion reply + + The requested action has been successfully completed. A + new request may be initiated. + + 3yz Positive Intermediate reply + + The command has been accepted, but the requested action + is being held in abeyance, pending receipt of further + information. The sender-SMTP should send another command + specifying this information. This reply is used in + command sequence groups. + + 4yz Transient Negative Completion reply + + The command was not accepted and the requested action did + not occur. However, the error condition is temporary and + the action may be requested again. The sender should + + + +[Page 48] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + return to the beginning of the command sequence (if any). + It is difficult to assign a meaning to "transient" when + two different sites (receiver- and sender- SMTPs) must + agree on the interpretation. Each reply in this category + might have a different time value, but the sender-SMTP is + encouraged to try again. A rule of thumb to determine if + a reply fits into the 4yz or the 5yz category (see below) + is that replies are 4yz if they can be repeated without + any change in command form or in properties of the sender + or receiver. (E.g., the command is repeated identically + and the receiver does not put up a new implementation.) + + 5yz Permanent Negative Completion reply + + The command was not accepted and the requested action did + not occur. The sender-SMTP is discouraged from repeating + the exact request (in the same sequence). Even some + "permanent" error conditions can be corrected, so the + human user may want to direct the sender-SMTP to + reinitiate the command sequence by direct action at some + point in the future (e.g., after the spelling has been + changed, or the user has altered the account status). + + The second digit encodes responses in specific categories: + + x0z Syntax -- These replies refer to syntax errors, + syntactically correct commands that don't fit any + functional category, and unimplemented or superfluous + commands. + + x1z Information -- These are replies to requests for + information, such as status or help. + + x2z Connections -- These are replies referring to the + transmission channel. + + x3z Unspecified as yet. + + x4z Unspecified as yet. + + x5z Mail system -- These replies indicate the status of + the receiver mail system vis-a-vis the requested + transfer or other mail system action. + + The third digit gives a finer gradation of meaning in each + category specified by the second digit. The list of replies + + + +Postel [Page 49] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + illustrates this. Each reply text is recommended rather than + mandatory, and may even change according to the command with + which it is associated. On the other hand, the reply codes + must strictly follow the specifications in this section. + Receiver implementations should not invent new codes for + slightly different situations from the ones described here, but + rather adapt codes already defined. + + For example, a command such as NOOP whose successful execution + does not offer the sender-SMTP any new information will return + a 250 reply. The response is 502 when the command requests an + unimplemented non-site-specific action. A refinement of that + is the 504 reply for a command that is implemented, but that + requests an unimplemented parameter. + + The reply text may be longer than a single line; in these cases + the complete text must be marked so the sender-SMTP knows when it + can stop reading the reply. This requires a special format to + indicate a multiple line reply. + + The format for multiline replies requires that every line, + except the last, begin with the reply code, followed + immediately by a hyphen, "-" (also known as minus), followed by + text. The last line will begin with the reply code, followed + immediately by , optionally some text, and . + + For example: + 123-First line + 123-Second line + 123-234 text beginning with numbers + 123 The last line + + In many cases the sender-SMTP then simply needs to search for + the reply code followed by at the beginning of a line, and + ignore all preceding lines. In a few cases, there is important + data for the sender in the reply "text". The sender will know + these cases from the current context. + + + + + + + + + + + + +[Page 50] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX F + + Scenarios + + This section presents complete scenarios of several types of SMTP + sessions. + + A Typical SMTP Transaction Scenario + + This SMTP example shows mail sent by Smith at host USC-ISIF, to + Jones, Green, and Brown at host BBN-UNIX. Here we assume that + host USC-ISIF contacts host BBN-UNIX directly. The mail is + accepted for Jones and Brown. Green does not have a mailbox at + host BBN-UNIX. + + ------------------------------------------------------------- + + R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BBN-UNIX.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BBN-UNIX.ARPA Service closing transmission channel + + Scenario 1 + + ------------------------------------------------------------- + + + +Postel [Page 51] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Aborted SMTP Transaction Scenario + + ------------------------------------------------------------- + + R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready + S: HELO ISI-VAXA.ARPA + R: 250 MIT-Multics.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RSET + R: 250 OK + + S: QUIT + R: 221 MIT-Multics.ARPA Service closing transmission channel + + Scenario 2 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + +[Page 52] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Relayed Mail Scenario + + ------------------------------------------------------------- + + Step 1 -- Source Host to Relay Host + + R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-AI.ARPA + R: 250 USC-ISIE.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public + S: Subject: The Next Meeting of the Board + S: To: Jones@BBN-Vax.ARPA + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + +Postel [Page 53] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Step 2 -- Relay Host to Destination Host + + R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIE.ARPA + R: 250 BBN-VAX.ARPA + + S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA> + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; + 2 Nov 81 22:40:10 UT + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public + S: Subject: The Next Meeting of the Board + S: To: Jones@BBN-Vax.ARPA + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + Scenario 3 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + +[Page 54] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Verifying and Sending Scenario + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 4 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 55] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Sending and Mailing Scenarios + + First the user's name is verified, then an attempt is made to + send to the user's terminal. When that fails, the messages is + mailed to the user's mailbox. + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 450 User not active now + + S: RSET + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 5 + + ------------------------------------------------------------- + + + + + + +[Page 56] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Doing the preceding scenario more efficiently. + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SOML FROM: + R: 250 OK + + S: RCPT TO: + R: 250 User not active now, so will do mail. + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 6 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 57] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Mailing List Scenario + + First each of two mailing lists are expanded in separate sessions + with different hosts. Then the message is sent to everyone that + appeared on either list (but no duplicates) via a relay host. + + ------------------------------------------------------------- + + Step 1 -- Expanding the First List + + R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 MIT-AI.ARPA + + S: EXPN Example-People + R: 250- + R: 250-Fred Fonebone + R: 250-Xenon Y. Zither + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + S: QUIT + R: 221 MIT-AI.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 58] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Step 2 -- Expanding the Second List + + R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 MIT-MC.ARPA + + S: EXPN Interested-Parties + R: 250-Al Calico + R: 250- + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + S: QUIT + R: 221 MIT-MC.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 59] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Step 3 -- Mailing to All via a Relay Host + + R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 USC-ISIE.ARPA + + S: MAIL FROM: + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA> + R: 250 OK + S: RCPT + TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + Scenario 7 + + ------------------------------------------------------------- + + + + + + + + + + + + +[Page 60] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Forwarding Scenarios + + ------------------------------------------------------------- + + R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISIF.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 251 User not local; will forward to + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIF.ARPA Service closing transmission channel + + Scenario 8 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 61] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Step 1 -- Trying the Mailbox at the First Host + + R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISIF.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 251 User not local; will forward to + + S: RSET + R: 250 OK + + S: QUIT + R: 221 USC-ISIF.ARPA Service closing transmission channel + + Step 2 -- Delivering the Mail at the Second Host + + R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISI.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISI.ARPA Service closing transmission channel + + Scenario 9 + + ------------------------------------------------------------- + + + + +[Page 62] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Too Many Recipients Scenario + + ------------------------------------------------------------- + + R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BERKELEY.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 552 Recipient storage full, try again in another transaction + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BERKELEY.ARPA Service closing transmission channel + + Scenario 10 + + ------------------------------------------------------------- + + Note that a real implementation must handle many recipients as + specified in Section 4.5.3. + + + +Postel [Page 63] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +GLOSSARY + + ASCII + + American Standard Code for Information Interchange [1]. + + command + + A request for a mail service action sent by the sender-SMTP to the + receiver-SMTP. + + domain + + The hierarchially structured global character string address of a + host computer in the mail system. + + end of mail data indication + + A special sequence of characters that indicates the end of the + mail data. In particular, the five characters carriage return, + line feed, period, carriage return, line feed, in that order. + + host + + A computer in the internetwork environment on which mailboxes or + SMTP processes reside. + + line + + A a sequence of ASCII characters ending with a . + + mail data + + A sequence of ASCII characters of arbitrary length, which conforms + to the standard set in the Standard for the Format of ARPA + Internet Text Messages (RFC 822 [2]). + + mailbox + + A character string (address) which identifies a user to whom mail + is to be sent. Mailbox normally consists of the host and user + specifications. The standard mailbox naming convention is defined + to be "user@domain". Additionally, the "container" in which mail + is stored. + + + + + +[Page 64] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + receiver-SMTP process + + A process which transfers mail in cooperation with a sender-SMTP + process. It waits for a connection to be established via the + transport service. It receives SMTP commands from the + sender-SMTP, sends replies, and performs the specified operations. + + reply + + A reply is an acknowledgment (positive or negative) sent from + receiver to sender via the transmission channel in response to a + command. The general form of a reply is a completion code + (including error codes) followed by a text string. The codes are + for use by programs and the text is usually intended for human + users. + + sender-SMTP process + + A process which transfers mail in cooperation with a receiver-SMTP + process. A local language may be used in the user interface + command/reply dialogue. The sender-SMTP initiates the transport + service connection. It initiates SMTP commands, receives replies, + and governs the transfer of mail. + + session + + The set of exchanges that occur while the transmission channel is + open. + + transaction + + The set of exchanges required for one message to be transmitted + for one or more recipients. + + transmission channel + + A full-duplex communication path between a sender-SMTP and a + receiver-SMTP for the exchange of commands, replies, and mail + text. + + transport service + + Any reliable stream-oriented data communication services. For + example, NCP, TCP, NITS. + + + + + +Postel [Page 65] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + user + + A human being (or a process on behalf of a human being) wishing to + obtain mail transfer service. In addition, a recipient of + computer mail. + + word + + A sequence of printing characters. + + + + The characters carriage return and line feed (in that order). + + + + The space character. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 66] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +REFERENCES + + [1] ASCII + + ASCII, "USA Code for Information Interchange", United States of + America Standards Institute, X3.4, 1968. Also in: Feinler, E. + and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for + the Defense Communications Agency by SRI International, Menlo + Park, California, Revised January 1978. + + [2] RFC 822 + + Crocker, D., "Standard for the Format of ARPA Internet Text + Messages," RFC 822, Department of Electrical Engineering, + University of Delaware, August 1982. + + [3] TCP + + Postel, J., ed., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", RFC 793, USC/Information Sciences + Institute, NTIS AD Number A111091, September 1981. Also in: + Feinler, E. and J. Postel, eds., "Internet Protocol Transition + Workbook", SRI International, Menlo Park, California, March 1982. + + [4] NCP + + McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, + January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [5] Initial Connection Protocol + + Postel, J., "Official Initial Connection Protocol", NIC 7101, + 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [6] NITS + + PSS/SG3, "A Network Independent Transport Service", Study Group 3, + The Post Office PSS Users Group, February 1980. Available from + the DCPU, National Physical Laboratory, Teddington, UK. + + + + +Postel [Page 67] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + [7] X.25 + + CCITT, "Recommendation X.25 - Interface Between Data Terminal + Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for + Terminals Operating in the Packet Mode on Public Data Networks," + CCITT Orange Book, Vol. VIII.2, International Telephone and + Telegraph Consultative Committee, Geneva, 1976. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 68] Postel + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc0974.txt b/server/src/site/resources/rfclist/smtp/rfc0974.txt new file mode 100644 index 00000000000..912ba11d3fd --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc0974.txt @@ -0,0 +1,365 @@ + +Network Working Group Craig Partridge +Request for Comments: 974 CSNET CIC BBN Laboratories Inc + January 1986 + + MAIL ROUTING AND THE DOMAIN SYSTEM + + +Status of this Memo + + This RFC presents a description of how mail systems on the Internet + are expected to route messages based on information from the domain + system described in RFCs 882, 883 and 973. Distribution of this memo + is unlimited. + +Introduction + + The purpose of this memo is to explain how mailers are to decide how + to route a message addressed to a given Internet domain name. This + involves a discussion of how mailers interpret MX RRs, which are used + for message routing. Note that this memo makes no statement about + how mailers are to deal with MB and MG RRs, which are used for + interpreting mailbox names. + + Under RFC-882 and RFC-883 certain assumptions about mail addresses + have been changed. Up to now, one could usually assume that if a + message was addressed to a mailbox, for example, at LOKI.BBN.COM, + that one could just open an SMTP connection to LOKI.BBN.COM and pass + the message along. This system broke down in certain situations, + such as for certain UUCP and CSNET hosts which were not directly + attached to the Internet, but these hosts could be handled as special + cases in configuration files (for example, most mailers were set up + to automatically forward mail addressed to a CSNET host to + CSNET-RELAY.ARPA). + + Under domains, one cannot simply open a connection to LOKI.BBN.COM, + but must instead ask the domain system where messages to LOKI.BBN.COM + are to be delivered. And the domain system may direct a mailer to + deliver messages to an entirely different host, such as SH.CS.NET. + Or, in a more complicated case, the mailer may learn that it has a + choice of routes to LOKI.BBN.COM. This memo is essentially a set of + guidelines on how mailers should behave in this more complex world. + + Readers are expected to be familiar with RFCs 882, 883, and the + updates to them (e.g., RFC-973). + + + + + + + + + +Partridge [Page 1] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + +What the Domain Servers Know + + The domain servers store information as a series of resource records + (RRs), each of which contains a particular piece of information about + a given domain name (which is usually, but not always, a host). The + simplest way to think of a RR is as a typed pair of datum, a domain + name matched with relevant data, and stored with some additional type + information to help systems determine when the RR is relevant. For + the purposes of message routing, the system stores RRs known as MX + RRs. Each MX matches a domain name with two pieces of data, a + preference value (an unsigned 16-bit integer), and the name of a + host. The preference number is used to indicate in what order the + mailer should attempt deliver to the MX hosts, with the lowest + numbered MX being the one to try first. Multiple MXs with the same + preference are permitted and have the same priority. + + In addition to mail information, the servers store certain other + types of RR's which mailers may encounter or choose to use. These + are: the canonical name (CNAME) RR, which simply states that the + domain name queried for is actually an alias for another domain name, + which is the proper, or canonical, name; and the Well Known Service + (WKS) RR, which stores information about network services (such as + SMTP) a given domain name supports. + +General Routing Guidelines + + Before delving into a detailed discussion of how mailers are expected + to do mail routing, it would seem to make sense to give a brief + overview of how this memo is approaching the problems that routing + poses. + + The first major principle is derived from the definition of the + preference field in MX records, and is intended to prevent mail + looping. If the mailer is on a host which is listed as an MX for the + destination host, the mailer may only deliver to an MX which has a + lower preference count than its own host. + + It is also possible to cause mail looping because routing information + is out of date or incomplete. Out of date information is only a + problem when domain tables are changed. The changes will not be + known to all affected hosts until their resolver caches time out. + There is no way to ensure that this will not happen short of + requiring mailers and their resolvers to always send their queries to + an authoritative server, and never use data stored in a cache. This + is an impractical solution, since eliminating resolver caching would + make mailing inordinately expensive. What is more, the out-of-date + RR problem should not happen if, when a domain table is changed, + + +Partridge [Page 2] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + + affected hosts (those in the list of MXs) have their resolver caches + flushed. In other words, given proper precautions, mail looping as a + result of domain information should be avoidable, without requiring + mailers to query authoritative servers. (The appropriate precaution + is to check with a host's administrator before adding that host to a + list of MXs). + + The incomplete data problem also requires some care when handling + domain queries. If the answer section of a query is incomplete + critical MX RRs may be left out. This may result in mail looping, or + in a message being mistakenly labelled undeliverable. As a result, + mailers may only accept responses from the domain system which have + complete answer sections. Note that this entire problem can be + avoided by only using virtual circuits for queries, but since this + situation is likely to be very rare and datagrams are the preferred + way to interact with the domain system, implementors should probably + just ensure that their mailer will repeat a query with virtual + circuits should the truncation bit ever be set. + +Determining Where to Send a Message + + The explanation of how mailers should decide how to route a message + is discussed in terms of the problem of a mailer on a host with + domain name LOCAL trying to deliver a message addressed to the domain + name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically + correct domain names. Furthermore, LOCAL is assumed to be the + official name for the host on which the mailer resides (i.e., it is + not a alias). + +Issuing a Query + + The first step for the mailer at LOCAL is to issue a query for MX RRs + for REMOTE. It is strongly urged that this step be taken every time + a mailer attempts to send the message. The hope is that changes in + the domain database will rapidly be used by mailers, and thus domain + administrators will be able to re-route in-transit messages for + defective hosts by simply changing their domain databases. + + Certain responses to the query are considered errors: + + Getting no response to the query. The domain server the mailer + queried never sends anything back. (This is distinct from an + answer which contains no answers to the query, which is not an + error). + + Getting a response in which the truncation field of the header is + + + +Partridge [Page 3] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + + set. (Recall discussion of incomplete queries above). Mailers + may not use responses of this type, and should repeat the query + using virtual circuits instead of datagrams. + + Getting a response in which the response code is non-zero. + + Mailers are expected to do something reasonable in the face of an + error. The behaviour for each type of error is not specified here, + but implementors should note that different types of errors should + probably be treated differently. For example, a response code of + "non-existent domain" should probably cause the message to be + returned to the sender as invalid, while a response code of "server + failure" should probably cause the message to be retried later. + + There is one other special case. If the response contains an answer + which is a CNAME RR, it indicates that REMOTE is actually an alias + for some other domain name. The query should be repeated with the + canonical domain name. + + If the response does not contain an error response, and does not + contain aliases, its answer section should be a (possibly zero + length) list of MX RRs for domain name REMOTE (or REMOTE's true + domain name if REMOTE was a alias). The next section describes how + this list is interpreted. + +Interpreting the List of MX RRs + + NOTE: This section only discusses how mailers choose which names to + try to deliver a message to, working from a list of RR's. It does + not discuss how the mailers actually make delivery. Where ever + delivering a message is mentioned, all that is meant is that the + mailer should do whatever it needs to do to transfer a message to a + remote site, given a domain name for that site. (For example, an + SMTP mailer will try to get an address for the domain name, which + involves another query to the domain system, and then, if it gets an + address, connect to the SMTP TCP port). The mechanics of actually + transferring the message over the network to the address associated + with a given domain name is not within the scope of this memo. + + It is possible that the list of MXs in the response to the query will + be empty. This is a special case. If the list is empty, mailers + should treat it as if it contained one RR, an MX RR with a preference + value of 0, and a host name of REMOTE. (I.e., REMOTE is its only + MX). In addition, the mailer should do no further processing on the + list, but should attempt to deliver the message to REMOTE. The idea + + + + +Partridge [Page 4] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + + here is that if a domain fails to advertise any information about a + particular name we will give it the benefit of the doubt and attempt + delivery. + + If the list is not empty, the mailer should remove irrelevant RR's + from the list according to the following steps. Note that the order + is significant. + + For each MX, a WKS query should be issued to see if the domain + name listed actually supports the mail service desired. MX RRs + which list domain names which do not support the service should be + discarded. This step is optional, but strongly encouraged. + + If the domain name LOCAL is listed as an MX RR, all MX RRs with a + preference value greater than or equal to that of LOCAL's must be + discarded. + + After removing irrelevant RRs, the list can again be empty. This is + now an error condition and can occur in several ways. The simplest + case is that the WKS queries have discovered that none of the hosts + listed supports the mail service desired. The message is thus deemed + undeliverable, though extremely persistent mail systems might want to + try a delivery to REMOTE's address (if it exists) before returning + the message. Another, more dangerous, possibility is that the domain + system believes that LOCAL is handling message for REMOTE, but the + mailer on LOCAL is not set up to handle mail for REMOTE. For + example, if the domain system lists LOCAL as the only MX for REMOTE, + LOCAL will delete all the entries in the list. But LOCAL is + presumably querying the domain system because it didn't know what to + do with a message addressed to REMOTE. Clearly something is wrong. + How a mailer chooses to handle these situations is to some extent + implementation dependent, and is thus left to the implementor's + discretion. + + If the list of MX RRs is not empty, the mailer should try to deliver + the message to the MXs in order (lowest preference value tried + first). The mailer is required to attempt delivery to the lowest + valued MX. Implementors are encouraged to write mailers so that they + try the MXs in order until one of the MXs accepts the message, or all + the MXs have been tried. A somewhat less demanding system, in which + a fixed number of MXs is tried, is also reasonable. Note that + multiple MXs may have the same preference value. In this case, all + MXs at with a given value must be tried before any of a higher value + are tried. In addition, in the special case in which there are + several MXs with the lowest preference value, all of them should be + tried before a message is deemed undeliverable. + + + +Partridge [Page 5] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + +Minor Special Issues + + There are a couple of special issues left out of the preceding + section because they complicated the discussion. They are treated + here in no particular order. + + Wildcard names, those containing the character '*' in them, may be + used for mail routing. There are likely to be servers on the network + which simply state that any mail to a domain is to be routed through + a relay. For example, at the time that this RFC is being written, all + mail to hosts in the domain IL is routed through RELAY.CS.NET. This + is done by creating a wildcard RR, which states that *.IL has an MX + of RELAY.CS.NET. This should be transparent to the mailer since the + domain servers will hide this wildcard match. (If it matches *.IL + with HUJI.IL for example, a domain server will return an RR + containing HUJI.IL, not *.IL). If by some accident a mailer receives + an RR with a wildcard domain name in its name or data section it + should discard the RR. + + Note that the algorithm to delete irrelevant RRs breaks if LOCAL has + a alias and the alias is listed in the MX records for REMOTE. (E.g. + REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This + can be avoided if aliases are never used in the data section of MX + RRs. + + Implementors should understand that the query and interpretation of + the query is only performed for REMOTE. It is not repeated for the + MX RRs listed for REMOTE. You cannot try to support more extravagant + mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an MX + for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL, + but this does not mean that UNIX.BBN.COM accepts any responsibility + for mail for .IL). + + Finally, it should be noted that this is a standard for routing on + the Internet. Mailers serving hosts which lie on multiple networks + will presumably have to make some decisions about which network to + route through. This decision making is outside the scope of this + memo, although mailers may well use the domain system to help them + decide. However, once a mailer decides to deliver a message via the + Internet it must apply these rules to route the message. + + + + + + + + + +Partridge [Page 6] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + +Examples + + To illustrate the discussion above, here are three examples of how + mailers should route messages. All examples work with the following + database: + + A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG + A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG + A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG + A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP + + B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG + B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG + B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP + + C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG + C.EXAMP + diff --git a/server/src/site/resources/rfclist/smtp/rfc1652.txt b/server/src/site/resources/rfclist/smtp/rfc1652.txt new file mode 100644 index 00000000000..4700eb5c950 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1652.txt @@ -0,0 +1,340 @@ + + + + + +Network Working Group J. Klensin, WG Chair +Request for Comments: 1652 MCI +Obsoletes: 1426 N. Freed, Editor +Category: Standards Track Innosoft + M. Rose + Dover Beach Consulting, Inc. + E. Stefferud + Network Management Associates, Inc. + D. Crocker + Silicon Graphics, Inc. + July 1994 + + + SMTP Service Extension for 8bit-MIMEtransport + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines an extension to the SMTP service whereby an SMTP + content body consisting of text containing octets outside of the US- + ASCII octet range (hex 00-7F) may be relayed using SMTP. + +1. Introduction + + Although SMTP is widely and robustly deployed, various extensions + have been requested by parts of the Internet community. In + particular, a significant portion of the Internet community wishes to + exchange messages in which the content body consists of a MIME + message [3] containing arbitrary octet-aligned material. This memo + uses the mechanism described in [5] to define an extension to the + SMTP service whereby such contents may be exchanged. Note that this + extension does NOT eliminate the possibility of an SMTP server + limiting line length; servers are free to implement this extension + but nevertheless set a line length limit no lower than 1000 octets. + Given that this restriction still applies, this extension does NOT + provide a means for transferring unencoded binary via SMTP. + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 1] + +RFC 1652 SMTP 8bit-MIMEtransport July 1994 + + +2. Framework for the 8bit MIME Transport Extension + + The 8bit MIME transport extension is laid out as follows: + + (1) the name of the SMTP service extension defined here is + 8bit-MIMEtransport; + + (2) the EHLO keyword value associated with the extension is + 8BITMIME; + + (3) no parameter is used with the 8BITMIME EHLO keyword; + + (4) one optional parameter using the keyword BODY is added to + the MAIL FROM command. The value associated with this + parameter is a keyword indicating whether a 7bit message + (in strict compliance with [1]) or a MIME message (in + strict compliance with [3]) with arbitrary octet content + is being sent. The syntax of the value is as follows, + using the ABNF notation of [2]: + + body-value ::= "7BIT" / "8BITMIME" + + (5) no additional SMTP verbs are defined by this extension; + and, + + (6) the next section specifies how support for the extension + affects the behavior of a server and client SMTP. + +3. The 8bit-MIMEtransport service extension + + When a client SMTP wishes to submit (using the MAIL command) a + content body consisting of a MIME message containing arbitrary lines + of octet-aligned material, it first issues the EHLO command to the + server SMTP. If the server SMTP responds with code 250 to the EHLO + command, and the response includes the EHLO keyword value 8BITMIME, + then the server SMTP is indicating that it supports the extended MAIL + command and will accept MIME messages containing arbitrary octet- + aligned material. + + The extended MAIL command is issued by a client SMTP when it wishes + to transmit a content body consisting of a MIME message containing + arbitrary lines of octet-aligned material. The syntax for this + command is identical to the MAIL command in [1], except that a BODY + parameter must appear after the address. Only one BODY parameter may + be used in a single MAIL command. + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 2] + +RFC 1652 SMTP 8bit-MIMEtransport July 1994 + + + The complete syntax of this extended command is defined in [5]. The + esmtp-keyword is BODY and the syntax for esmtp-value is given by the + syntax for body-value shown above. + + The value associated with the BODY parameter indicates whether the + content body which will be passed using the DATA command consists of + a MIME message containing some arbitrary octet-aligned material + ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT"). + + A server which supports the 8-bit MIME transport service extension + shall preserve all bits in each octet passed using the DATA command. + + Naturally, the usual SMTP data-stuffing algorithm applies so that a + content which contains the five-character sequence of + + + + or a content that begins with the three-character sequence of + + + + does not prematurely terminate the transfer of the content. Further, + it should be noted that the CR-LF pair immediately preceeding the + final dot is considered part of the content. Finally, although the + content body contains arbitrary lines of octet-aligned material, the + length of each line (number of octets between two CR-LF pairs), is + still subject to SMTP server line length restrictions (which may + allow as few as 1000 octets on a single line). This restriction means + that this extension MAY provide the necessary facilities for + transferring a MIME object with the 8BIT content-transfer-encoding, + it DOES NOT provide a means of transferring an object with the BINARY + content-transfer-encoding. + + Once a server SMTP supporting the 8bit-MIMEtransport service + extension accepts a content body containing octets with the high- + order (8th) bit set, the server SMTP must deliver or relay the + content in such a way as to preserve all bits in each octet. + + If a server SMTP does not support the 8-bit MIME transport extension + (either by not responding with code 250 to the EHLO command, or by + not including the EHLO keyword value 8BITMIME in its response), then + the client SMTP must not, under any circumstances, attempt to + transfer a content which contains characters outside the US-ASCII + octet range (hex 00-7F). + + A client SMTP has two options in this case: first, it may implement a + gateway transformation to convert the message into valid 7bit MIME, + or second, or may treat this as a permanent error and handle it in + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 3] + +RFC 1652 SMTP 8bit-MIMEtransport July 1994 + + + the usual manner for delivery failures. The specifics of the + transformation from 8bit MIME to 7bit MIME are not described by this + RFC; the conversion is nevertheless constrained in the following + ways: + + (1) it must cause no loss of information; MIME transport + encodings must be employed as needed to insure this is + the case, and + + (2) the resulting message must be valid 7bit MIME. + +4. Usage Example + + The following dialogue illustrates the use of the 8bit-MIMEtransport + service extension: + + S: + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250-dbc.mtview.ca.us says hello + S: 250 8BITMIME + C: MAIL FROM: BODY=8BITMIME + S: 250 ... Sender and 8BITMIME ok + C: RCPT TO: + S: 250 ... Recipient ok + C: DATA + S: 354 Send 8BITMIME message, ending in CRLF.CRLF. + ... + C: . + S: 250 OK + C: QUIT + S: 250 Goodbye + +5. 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 [1]. + +6. Acknowledgements + + This document represents a synthesis of the ideas of many people and + reactions to the ideas and proposals of others. Randall Atkinson, + Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas + and text sufficient to be considered co-authors. Other important + suggestions, text, or encouragement came from Harald Alvestrand, Jim + Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 4] + +RFC 1652 SMTP 8bit-MIMEtransport July 1994 + + + Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. + Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John + Wagner, Rayan Zachariassen, and the contributions of the entire IETF + SMTP Working Group. Of course, none of the individuals are + necessarily responsible for the combination of ideas represented + here. Indeed, in some cases, the response to a particular criticism + was to accept the problem identification but to include an entirely + different solution from the one originally proposed. + +7. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, September 1993. + + [4] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1522, University of Tennessee, September 1993. + + [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, + "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach + Consulting, Inc., Network Management Associates, Inc., Silicon + Graphics, Inc., July 1994. + + [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC + 974, BBN, January 1986. + +8. Chair, Editor, and Authors' Addresses + + John Klensin, WG Chair + MCI Data Services Division + 2100 Reston Parkway, 6th floor + Reston, VA 22091 + USA + + Phone:: 1 703 715 7361 + Fax: +1 703 715 7435 + EMail: klensin@mci.net + + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 5] + +RFC 1652 SMTP 8bit-MIMEtransport July 1994 + + + Ned Freed, Editor + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone:: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Moutain View, CA 94043-2186 + USA + + Phone: +1 415 968 1052 + Fax: +1 415 968 2510 + EMail: mrose@dbc.mtview.ca.us + + + Einar A. Stefferud + Network Management Associates, Inc. + 17301 Drey Lane + Huntington Beach, CA, 92647-5615 + USA + + Phone: +1 714 842 3711 + Fax: +1 714 848 2091 + EMail: stef@nma.com + + + Dave Crocker + Silicon Graphics, Inc. + 2011 N. Shoreline Blvd. + P.O. Box 7311 + Mountain View, CA 94039 + USA + + Phone: +1 415 390 1804 + Fax: +1 415 962 8404 + EMail: dcrocker@sgi.com + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 6] + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc1830.txt b/server/src/site/resources/rfclist/smtp/rfc1830.txt new file mode 100644 index 00000000000..dab73522c16 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1830.txt @@ -0,0 +1,452 @@ + + + + + +Network Working Group G. Vaudreuil +Request for Comments: 1830 Octel Network Services +Category: Experimental August 1995 + + + SMTP Service Extensions + for Transmission of Large + and Binary MIME Messages + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +1. Abstract + + This memo defines two extensions to the SMTP service. The first + service enables a SMTP client and server to negotiate the use of an + alternate DATA command "BDAT" for efficiently sending large MIME + messages. The second extension takes advantage of the BDAT command + to permit the negotiated sending of unencoded binary data. + +2. Introduction + + The MIME extensions to the Internet message protocol provides for the + transmission of many kinds of data which were previously unsupported + in Internet mail. Anticipating the need to more efficiently + transport the new media made possible with MIME, the SMTP protocol + has been extended to provide transport for new message types. RFC + 1426 defines one such extension for the transmission of unencoded 8 + bit MIME messages [8BIT]. This service extension permits the + receiver SMTP to declare support for 8 bit body parts and the sender + to request 8 bit transmission of a particular message. + + One expected result of the use of MIME is that the Internet mail + system will be expected to carry very large mail messages. In such + transactions, there is a need to eliminate the requirement that the + message be scanned for "CR LF . CR LF" sequences upon sending and + receiving to detect the end of message. + + Independent of the need to send large messages, Internet mail is + increasingly multi-media there is a need to avoid the overhead of + base64 and quoted-printable encoding of binary objects sent using the + MIME message format over SMTP between hosts which support binary + message processing. + + + + +Vaudreuil Experimental [Page 1] + +RFC 1830 Binary and Large Message Transport August 1995 + + + This memo uses the mechanism defined in [ESMTP] to define two + extensions to the SMTP service whereby a client ("sender-SMTP") may + declare support for the message chunking transmission mode using the + BDAT command and support for the sending of Binary messages. + +3. Framework for the Large Message Extensions + + The following service extension is hereby defined: + + 1) The name of the data chunking service extension is + "CHUNKING". + + 2) The EHLO keyword value associated with this extension is + "CHUNKING". + + 3) A new SMTP verb is defined "BDAT" as an alternative to + the "DATA" command of [RFC821]. The BDAT verb takes two + arguments. The first argument indicates the length of the + binary data packet. The second optional argument indicates + that the data packet is the last. + + bdat-cmd ::= "BDAT" SP chunk-size + [ SP end-marker ] CR LF + chunk-size ::= 1*DIGIT + end-marker ::= "LAST" + + + The CHUNKING service extension enables the use of the BDAT + alternative to the DATA command. This extension can be used for any + message, whether 7 bit, 8BITMIME or BINARYMIME. + + When a client SMTP wishes to submit (using the MAIL command) a large + message using the CHUNKING extension, it first issues the EHLO + command to the server SMTP. If the server SMTP responds with code + 250 to the EHLO command, and the response includes the EHLO keyword + value CHUNKING, then the server SMTP is indicating that it supports + the BDAT command and will accept the sending of messages in chunks. + + After all MAIL FROM and RCPT TO responses are collected and + processed, the message is sent using a series of BDAT commands. The + BDAT command takes one argument, the exact length of the data segment + in octets. The message data is sent immediately after the BDAT + command. Once the receiver-SMTP receives the specified number of + octets, it will return a 250 reply code. + + The LAST parameter on the BDAT command indicates that this is the + last chunk of message data to be sent. Any BDAT command sent after + the BDAT LAST is illegal and must be replied to with a 503 "Bad + + + +Vaudreuil Experimental [Page 2] + +RFC 1830 Binary and Large Message Transport August 1995 + + + sequence of commands" reply code. The state resulting from this error + is indeterminate. A RSET command must be sent to clear the + transaction before continuing. + + A 250 response should be sent to each BDAT data block. If a 5XX code + is sent in response to a BDAT chunk the message should be considered + failed and, the sender SMTP must not send any additional BDAT + segments. If using the ESMTP pipelining extensions [PIPE], the + sender SMTP must complete the sending of the current segment and not + send any more BDATs. When streaming, the receiver SMTP must accept + and discard additional BDAT chunks after the failed BDAT. After + receiving a 5XX error in response to a BDAT command, the resulting + state is indeterminate. A RSET command must be issued to clear the + transaction before additional commands may be sent. + + Note that an error on the receiver SMTP such as disk full or + imminent shutdown can only be reported after the BDAT segment has + been sent. It is therefore important to choose a reasonable chunk + size given the expected end to end bandwidth. + + The RSET command when issued during after the first BDAT and before + the BDAT LAST clears all segments sent during that transaction and + resets the session. + + DATA and BDAT commands cannot be used in the same transaction. If a + DATA statement is issued after a BDAT for the current transaction, a + 503 "Bad sequence of commands" must be issued. The state resulting + from this error is indeterminate. A RSET command must be sent to + clear the transaction before continuing. There is no prohibition on + using DATA and BDAT in the same session, so long as they are not + mixed in the same transaction. + + The local storage size of a message may not accurately reflect the + actual size of the message sent due to local storage conventions. In + particular, text messages sent with the BDAT command must be sent in + the canonical MIME format with lines delimited with a . It + may not be possible to convert the entire message to the canonical + format at once. Chunking provides a mechanism to convert the message + to canonical form, accurately count the bytes, and send the message a + single chunk at a time. + + Note that correct byte counting is essential. If too many bytes + are indicated by the sender SMTP, the receiver SMTP will continue + to wait for the remainder of the data or will read the subsequent + command as additional message data. In the case where a portion + of the previous command was read as data, the parser will return a + syntax error when the incomplete command is read. + + + + +Vaudreuil Experimental [Page 3] + +RFC 1830 Binary and Large Message Transport August 1995 + + + If too few bytes are indicated by the sender SMTP, the receiver + SMTP will interpret the remainder of the message data as invalid + commands. Note that the remainder of the message data may be + binary and as such lexigraphical parsers must be prepared to + receive, process, and reject lines of arbitrary octets. + +4. Framework for the Binary Service Extension + + The following service extension is hereby defined: + + 1) The name of the binary service extension is "BINARYMIME". + + 2) The EHLO keyword value associated with this extension is + "BINARYMIME". + + 3) The BINARYMIME service extension can only be used with + the "CHUNKING" service extension. + + 4) No parameter is used with the BINARYMIME keyword. + + 5) One additional parameter to the BODY keyword defined + [8BIT] for the MAIL FROM command is defined, "BINARYMIME". + The value "BINARYMIME" associated with this parameter + indicates that this message is a Binary MIME message (in + strict compliance with [MIME]) with arbitrary octet content + being sent. The revised syntax of the value is as follows, + using the ABNF notation of [RFC822]: + + body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME" + + 6) No new verbs are defined for the BINARYMIME extension. + + A sender SMTP may request that a binary MIME message be sent without + transport encoding by sending a BINARYMIME parameter with the MAIL + FROM command. When the receiver SMTP accepts a MAIL FROM command + with the BINARYMIME body type requested, it agrees to preserve all + bits in each octet passed using the BDAT command. + + BINARYMIME cannot be used with the DATA command. If a DATA command + is issued after a MAIL FROM command containing the body-value of + "BINARYMIME", a 501 response should be sent. The resulting state + from this error condition is indeterminate and the transaction should + be reset with the RSET command. + + It is important to note that when using BINARYMIME, it is + especially important to ensure that the MIME message itself is + properly formed. In particular, it is essential that text be + canonically encoded with each line properly terminated with + + + +Vaudreuil Experimental [Page 4] + +RFC 1830 Binary and Large Message Transport August 1995 + + + . Any transformation of text into non-canonical MIME to + observe local storage conventions must be reversed before sending + as BINARYMIME. The usual line-oriented shortcuts will break if + used with BINARYMIME. + + The syntax of the extended MAIL command is identical to the MAIL + command in [RFC821], except that a BODY parameter must appear after + the address. The complete syntax of this extended command is defined + in [ESMTP]. The ESMTP-keyword is BODY and the syntax for ESMTP-value + is given by the syntax for body-value in [ESMTP]. + + If a receiver SMTP does not support the BINARYMIME message format + (either by not responding with code 250 to the EHLO command, or by + rejecting the BINARYMIME parameter to the MAIL FROM command, then the + client SMTP must not, under any circumstances, send binary data using + the DATA or BDAT commands. + + If the receiver-SMTP does not support BINARYMIME and the message + content is a MIME object with a binary encoding, a client SMTP has + two options in this case: first, it may implement a gateway + transformation to convert the message into valid 7bit encoded MIME, + or second, it may treat this as a permanent error and handle it in + the usual manner for delivery failures. The specifics of the + transformation from Binary MIME to 7bit MIME are not described by + this RFC; the conversion is nevertheless constrained in the following + ways: + + o The conversion must cause no loss of information; MIME + transport encodings must be employed as needed to insure this + is the case. + + o The resulting message must be valid 7bit MIME. + + As of present there are no mechanisms for converting a binary MIME + object into a 8 bit-MIME object. Such a transformation will require + the specification of a new MIME content-transfer-encoding, the + standardization of which is discouraged by [MIME]. + + + + + + + + + + + + + + +Vaudreuil Experimental [Page 5] + +RFC 1830 Binary and Large Message Transport August 1995 + + +5. Examples + +5.1 Simple Chunking + + The following simple dialogue illustrates the use of the large + message extension to send a short psudo-RFC822 message to one + recipient using the CHUNKING extension: + + + R: + S: + R: 220 cnri.reston.va.us SMTP service ready + S: EHLO ymir.claremont.edu + R: 250-cnri.reston.va.us says hello + R: 250 CHUNKING + S: MAIL FROM: + R: 250 ... Sender ok + S: RCPT TO: + R: 250 ... Recipient ok + S: BDAT 69 LAST + S: To: Susan@random.com + S: From: Sam@random.com + S: Subject: This is a bodyless test message + R: 250 Message OK, 69 octets received + S: QUIT + R: 221 Goodbye + +5.2 Pipelining Binarymime + + The following dialogue illustrates the use of the large message + extension to send a BINARYMIME object to two recipients using the + CHUNKING and PIPELINING extensions: + + R: + S: + R: 220 cnri.reston.va.us SMTP service ready + S: EHLO ymir.claremont.edu + R: 250-cnri.reston.va.us says hello + R: 250-PIPELINING + R: 250-BINARYMIME + R: 250 CHUNKING + S: MAIL FROM: BODY=BINARYMIME + S: RCPT TO: + S: RCPT TO: + R: 250 ... Sender and BINARYMIME ok + R: 250 ... Recipient ok + R: 250 ... Recipient ok + S: BDAT 100000 + + + +Vaudreuil Experimental [Page 6] + +RFC 1830 Binary and Large Message Transport August 1995 + + + S: (First 10000 octets of canonical MIME message data) + S: BDAT 324 LAST + S: (Remaining 324 octets of canonical MIME message data) + R: 250 100000 bytes received + R: 250 Message OK, 100324 octets received + S: QUIT + R: 221 Goodbye + +6. 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 [RFC821], or otherwise + made possible by [MIME]. + +7. Acknowledgments + + This document is the result of numerous discussions in the IETF SMTP + Extensions Working Group and in particular due to the continued + advocacy of "chunking" by Neil Katin. + +8. 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, UDEL, August 1982. + + [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, June 1992. + + [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., + Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC + 1425, United Nations University, Innosoft International, + Inc., Dover Beach Consulting, Inc., Network Management + Associates, Inc., The Branch Office, February 1993. + + [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., + Stefferud, E., and D. Crocker, "SMTP Service Extension for + 8bit-MIMEtransport" RFC 1426, United Nations University, + Innosoft International, Inc., Dover Beach Consulting, Inc., + Network Management Associates, Inc., The Branch Office, + February 1993. + + [PIPE] Freed, N., "SMTP Service Extensions for Command + Pipelining", Innosoft International, Work in Progress. + + + + +Vaudreuil Experimental [Page 7] + +RFC 1830 Binary and Large Message Transport August 1995 + + +9. Author's Address + + Gregory M. Vaudreuil + Octel Network Services + 17060 Dallas Parkway + Suite 214 + Dallas, TX 75248-1905 + + Voice/Fax: 214-733-2722 + EMail: Greg.Vaudreuil@Octel.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Experimental [Page 8] + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc1869.txt b/server/src/site/resources/rfclist/smtp/rfc1869.txt new file mode 100644 index 00000000000..64e84a70424 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1869.txt @@ -0,0 +1,620 @@ + + + + + +Network Working Group J. Klensin, WG Chair +Request For Comments: 1869 MCI +STD: 10 N. Freed, Editor +Obsoletes: 1651 Innosoft International, Inc. +Category: Standards Track M. Rose + Dover Beach Consulting, Inc. + E. Stefferud + Network Management Associates, Inc. + D. Crocker + Brandenburg Consulting + November 1995 + + + SMTP Service Extensions + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This memo defines a framework for extending the SMTP service by + defining a means whereby a server SMTP can inform a client SMTP as to + the service extensions it supports. Extensions to the SMTP service + are registered with the IANA. This framework does not require + modification of existing SMTP clients or servers unless the features + of the service extensions are to be requested or provided. + +2. Introduction + + The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable, + effective basis for the relay function of message transfer agents. + Although a decade old, SMTP has proven remarkably resilient. + Nevertheless, the need for a number of protocol extensions has become + evident. Rather than describing these extensions as separate and + haphazard entities, this document enhances SMTP in a straightforward + fashion that provides a framework in which all future extensions can + be built in a single consistent way. + +3. Framework for SMTP Extensions + + For the purpose of service extensions to SMTP, SMTP relays a mail + object containing an envelope and a content. + + + + +Klensin, et al Standards Track [Page 1] + +RFC 1869 SMTP Service Extensions November 1995 + + + (1) The SMTP envelope is straightforward, and is sent as a + series of SMTP protocol units: it consists of an + originator address (to which error reports should be + directed); a delivery mode (e.g., deliver to recipient + mailboxes); and, one or more recipient addresses. + + (2) The SMTP content is sent in the SMTP DATA protocol unit + and has two parts: the headers and the body. The + headers form a collection of field/value pairs + structured according to RFC 822 [2], whilst the body, + if structured, is defined according to MIME [3]. The + content is textual in nature, expressed using the US + ASCII repertoire (ANSI X3.4-1986). Although extensions + (such as MIME) may relax this restriction for the + content body, the content headers are always encoded + using the US ASCII repertoire. The algorithm defined in + [4] is used to represent header values outside the US + ASCII repertoire, whilst still encoding them using the + US ASCII repertoire. + + Although SMTP is widely and robustly deployed, some parts of the + Internet community might wish to extend the SMTP service. This memo + defines a means whereby both an extended SMTP client and server may + recognize each other as such and the server can inform the client as + to the service extensions that it supports. + + It must be emphasized that any extension to the SMTP service should + not be considered lightly. SMTP's strength comes primarily from its + simplicity. Experience with many protocols has shown that: + + protocols with few options tend towards ubiquity, whilst + protocols with many options tend towards obscurity. + + This means that 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. + + Given this environment, the framework for the extensions described in + this memo consists of: + + (1) a new SMTP command (section 4) + + (2) a registry of SMTP service extensions (section 5) + + (3) additional parameters to the SMTP MAIL FROM and RCPT TO + commands (section 6). + + + + +Klensin, et al Standards Track [Page 2] + +RFC 1869 SMTP Service Extensions November 1995 + + +4. The EHLO command + + A client SMTP supporting SMTP service extensions should start an SMTP + session by issuing the EHLO command instead of the HELO command. If + the SMTP server supports the SMTP service extensions it will give a + successful response (see section 4.3), a failure response (see 4.4), + or an error response (4.5). If the SMTP server does not support any + SMTP service extensions it will generate an error response (see + section 4.5). + +4.1. Changes to STD 10, RFC 821 + + This specification is intended to extend STD 10, RFC 821 without + impacting existing services in any way. The minor changes needed are + enumerated below. + +4.1.1. First command + + RFC 821 states that the first command in an SMTP session must be the + HELO command. This requirement is hereby amended to allow a session + to start with either EHLO or HELO. + +4.1.2. Maximum command line length + + This specification extends the SMTP MAIL FROM and RCPT TO to allow + additional parameters and parameter values. It is possible that the + MAIL FROM and RCPT TO lines that result will exceed the 512 character + limit on command line length imposed by RFC 821. This limit is + hereby amended to only apply to command lines without any parameters. + Each specification that defines new MAIL FROM or RCPT TO parameters + must also specify maximum parameter value lengths for each parameter + so that implementors of some set of extensions know how much buffer + space must be allocated. The maximum command length that must be + supported by an SMTP implementation with extensions is 512 plus the + sum of all the maximum parameter lengths for all the extensions + supported. + +4.2. Command syntax + + The syntax for this command, using the ABNF notation of [2], is: + + ehlo-cmd ::= "EHLO" SP domain CR LF + + If successful, the server SMTP responds with code 250. On failure, + the server SMTP responds with code 550. On error, the server SMTP + responds with one of codes 500, 501, 502, 504, or 421. + + + + + +Klensin, et al Standards Track [Page 3] + +RFC 1869 SMTP Service Extensions November 1995 + + + This command is issued instead of the HELO command, and may be issued + at any time that a HELO command would be appropriate. That is, if + the EHLO command is issued, and a successful response is returned, + then a subsequent HELO or EHLO command will result in the server SMTP + replying with code 503. A client SMTP must not cache any information + returned if the EHLO command succeeds. That is, a client SMTP must + issue the EHLO command at the start of each SMTP session if + information about extended facilities is needed. + +4.3. Successful response + + If the server SMTP implements and is able to perform the EHLO + command, it will return code 250. This indicates that both the + server and client SMTP are in the initial state, that is, there is no + transaction in progress and all state tables and buffers are cleared. + + Normally, this response will be a multiline reply. Each line of the + response contains a keyword and, optionally, one or more parameters. + The syntax for a positive response, using the ABNF notation of [2], + is: + + ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF + / ( "250-" domain [ SP greeting ] CR LF + *( "250-" ehlo-line CR LF ) + "250" SP ehlo-line CR LF ) + + ; the usual HELO chit-chat + greeting ::= 1* + + ehlo-line ::= ehlo-keyword *( SP ehlo-param ) + + ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on ehlo-keyword + ehlo-param ::= 1* + + ALPHA ::= + DIGIT ::= + + CR ::= + LF ::= + + + +Klensin, et al Standards Track [Page 4] + +RFC 1869 SMTP Service Extensions November 1995 + + + SP ::= + + 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 begun in + RFC 821. + + The IANA maintains a registry of SMTP service extensions. Associated + with each such extension is a corresponding EHLO keyword value. Each + service extension registered with the IANA must be defined in an RFC. + Such RFCs must either be on the standards-track or must define an + IESG-approved experimental protocol. The definition must include: + + (1) the textual name of the SMTP service extension; + + (2) the EHLO keyword value associated with the extension; + + (3) the syntax and possible values of parameters associated + with the EHLO keyword value; + + (4) 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); + + (5) any new parameters the extension associates with the + MAIL FROM or RCPT TO verbs; + + (6) how support for the extension affects the behavior of a + server and client SMTP; and, + + (7) the increment by which the extension is increasing the + maximum length of the commands MAIL FROM, RCPT TO, or + both, over that specified in RFC 821. + + In addition, any EHLO keyword value that starts with an upper or + lower case "X" refers to a local SMTP service extension, which is + used through bilateral, rather than standardized, agreement. Keywords + beginning with "X" may not be used in a registered service extension. + + Any 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. + + + + + + +Klensin, et al Standards Track [Page 5] + +RFC 1869 SMTP Service Extensions November 1995 + + + Additional verbs are bound by the same rules as EHLO keywords; + specifically, verbs begining with "X" are local extensions that may + not be registered or standardized and verbs not beginning with "X" + must always be registered. + +4.4. Failure response + + If for some reason the server SMTP is unable to list the service + extensions it supports, it will return code 554. + + In the case of a failure response, the client SMTP should issue + either the HELO or QUIT command. + +4.5. Error responses from extended servers + + If the server SMTP recognizes the EHLO command, but the command + argument is unacceptable, it will return code 501. + + If the server SMTP recognizes, but does not implement, the EHLO + command, it will return code 502. + + If the server SMTP determines that the SMTP service is no longer + available (e.g., due to imminent system shutdown), it will return + code 421. + + In the case of any error response, the client SMTP should issue + either the HELO or QUIT command. + +4.6. Responses from servers without extensions + + A server SMTP that conforms to RFC 821 but does not support the + extensions specified here will not recognize the EHLO command and + will consequently return code 500, as specified in RFC 821. The + server SMTP should stay in the same state after returning this code + (see section 4.1.1 of RFC 821). The client SMTP may then issue + either a HELO or a QUIT command. + +4.7. Responses from improperly implemented servers + + Some SMTP servers are known to disconnect the SMTP transmission + channel upon receipt of the EHLO command. The disconnect can occur + immediately or after sending a response. Such behavior violates + section 4.1.1 of RFC 821, which explicitly states that disconnection + should only occur after a QUIT command is issued. + + Nevertheless, in order to achieve maxmimum interoperablity it is + suggested that extended SMTP clients using EHLO be coded to check for + server connection closure after EHLO is sent, either before or after + + + +Klensin, et al Standards Track [Page 6] + +RFC 1869 SMTP Service Extensions November 1995 + + + returning a reply. If this happens the client must decide if the + operation can be successfully completed without using any SMTP + extensions. If it can a new connection can be opened and the HELO + command can be used. + + Other improperly-implemented servers will not accept a HELO command + after EHLO has been sent and rejected. In some cases, this problem + can be worked around by sending a RSET after the failure response to + EHLO, then sending the HELO. Clients that do this should be aware + that many implementations will return a failure code (e.g., 503 Bad + sequence of commands) in response to the RSET. This code can be + safely ignored. + +5. Initial IANA Registry + + The IANA's initial registry of SMTP service extensions consists of + these entries: + + Service Ext EHLO Keyword Parameters Verb Added Behavior + ------------- ------------ ---------- ---------- ------------------ + Send SEND none SEND defined in RFC 821 + Send or Mail SOML none SOML defined in RFC 821 + Send and Mail SAML none SAML defined in RFC 821 + Expand EXPN none EXPN defined in RFC 821 + Help HELP none HELP defined in RFC 821 + Turn TURN none TURN defined in RFC 821 + + which correspond to those SMTP commands which are defined as optional + in [5]. (The mandatory SMTP commands, according to [5], are HELO, + MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.) + +6. MAIL FROM and RCPT TO Parameters + + It is recognized that several of the extensions planned for SMTP will + make use of additional parameters associated with the MAIL FROM and + RCPT TO command. The syntax for these commands, again using the ABNF + notation of [2] as well as underlying definitions from [1], is: + + esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF + esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) + esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] + esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on esmtp-keyword + esmtp-value ::= 1* + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250 dbc.mtview.ca.us says hello + ... + + indicates that the server SMTP implements only those + SMTP commands which are defined as mandatory in [5]. + + + + + + +Klensin, et al Standards Track [Page 8] + +RFC 1869 SMTP Service Extensions November 1995 + + + (2) In contrast, an interaction of the form: + + S: + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250-dbc.mtview.ca.us says hello + S: 250-EXPN + S: 250-HELP + S: 250-8BITMIME + S: 250-XONE + S: 250 XVRB + ... + + indicates that the server SMTP also implements the SMTP + EXPN and HELP commands, one standard service extension + (8BITMIME), and two nonstandard and unregistered + service extensions (XONE and XVRB). + + (3) Finally, a server that does not support SMTP service + extensions would act as follows: + + S: + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 500 Command not recognized: EHLO + ... + + The 500 response indicates that the server SMTP does + not implement the extensions specified here. The + client would normally send a HELO command and proceed + as specified in RFC 821. See section 4.7 for + additional discussion. + +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 RFC-821. It does + provide an announcement of server mail capabilities via the response + to the EHLO verb. However, all information provided by announcement + of any of the initial set of service extensions defined by this RFC + can be readily deduced by selective probing of the verbs required to + transport and deliver mail. The security implications of service + extensions described in other RFCs should be dealt with in those + RFCs. + + + + +Klensin, et al Standards Track [Page 9] + +RFC 1869 SMTP Service Extensions November 1995 + + +10. Acknowledgements + + This document represents a synthesis of the ideas of many people and + reactions to the ideas and proposals of others. Randall Atkinson, + Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas + and text sufficient to be considered co-authors. Other important + suggestions, text, or encouragement came from Harald Alvestrand, Jim + Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per + Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. + Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan + Zachariassen, and the contributions of the entire IETF SMTP Working + Group. Of course, none of the individuals are necessarily responsible + for the combination of ideas represented here. Indeed, in some cases, + the response to a particular criticism was to accept the problem + identification but to include an entirely different solution from the + one originally proposed. + +11. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, September 1993. + + [4] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1522, University of Tennessee, September 1993. + + [5] Braden, R., "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, USC/Information Sciences Institute, + October 1989. + +12. Chair, Editor, and Author Addresses + + John Klensin, WG Chair + MCI + 2100 Reston Parkway + Reston, VA 22091 + + Phone: +1 703 715-7361 + Fax: +1 703 715-7436 + EMail: klensin@mci.net + + + + + + +Klensin, et al Standards Track [Page 10] + +RFC 1869 SMTP Service Extensions November 1995 + + + Ned Freed, Editor + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Moutain View, CA 94043-2186 + USA + + Phone: +1 415 968 1052 + Fax: +1 415 968 2510 + EMail: mrose@dbc.mtview.ca.us + + + Einar A. Stefferud + Network Management Associates, Inc. + 17301 Drey Lane + Huntington Beach, CA, 92647-5615 + USA + + Phone: +1 714 842 3711 + Fax: +1 714 848 2091 + EMail: stef@nma.com + + + Dave Crocker + Brandenburg Consulting + 675 Spruce Dr. + Sunnyvale, CA 94086 USA + USA + + Phone: +1 408 246 8253 + Fax: +1 408 249 6205 + EMail: dcrocker@mordor.stanford.edu + + + + + + + + + +Klensin, et al Standards Track [Page 11] + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc1870.txt b/server/src/site/resources/rfclist/smtp/rfc1870.txt new file mode 100644 index 00000000000..30d32082009 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1870.txt @@ -0,0 +1,508 @@ + + + + + +Network Working Group J. Klensin, WG Chair +Request For Comments: 1870 MCI +STD: 10 N. Freed, Editor +Obsoletes: 1653 Innosoft International, Inc. +Category: Standards Track K. Moore + University of Tennessee + November 1995 + + + SMTP Service Extension + for Message Size Declaration + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This memo defines an extension to the SMTP service whereby an SMTP + client and server may interact to give the server an opportunity to + decline to accept a message (perhaps temporarily) based on the + client's estimate of the message size. + +2. Introduction + + The MIME extensions to the Internet message protocol provide for the + transmission of many kinds of data which were previously unsupported + in Internet mail. One expected result of the use of MIME is that + SMTP will be expected to carry a much wider range of message sizes + than was previously the case. This has an impact on the amount of + resources (e.g. disk space) required by a system acting as a server. + + This memo uses the mechanism defined in [5] to define extensions to + the SMTP service whereby a client ("sender-SMTP") may declare the + size of a particular message to a server ("receiver-SMTP"), after + which the server may indicate to the client that it is or is not + willing to accept the message based on the declared message size and + whereby a server ("receiver-SMTP") may declare the maximum message + size it is willing to accept to a client ("sender-SMTP"). + + + + + + + + +Klensin, et al Standards Track [Page 1] + +RFC 1870 SMTP Size Declaration November 1995 + + +3. Framework for the Size Declaration Extension + + The following service extension is therefore defined: + + (1) the name of the SMTP service extension is "Message Size + Declaration"; + + (2) the EHLO keyword value associated with this extension is "SIZE"; + + (3) one optional parameter is allowed with this EHLO keyword value, a + decimal number indicating the fixed maximum message size in bytes + that the server will accept. The syntax of the parameter is as + follows, using the augmented BNF notation of [2]: + + size-param ::= [1*DIGIT] + + A parameter value of 0 (zero) indicates that no fixed maximum + message size is in force. If the parameter is omitted no + information is conveyed about the server's fixed maximum message + size; + + (4) one optional parameter using the keyword "SIZE" is added to the + MAIL FROM command. The value associated with this parameter is a + decimal number indicating the size of the message that is to be + transmitted. The syntax of the value is as follows, using the + augmented BNF notation of [2]: + + size-value ::= 1*20DIGIT + + (5) the maximum length of a MAIL FROM command line is increased by 26 + characters by the possible addition of the SIZE keyword and + value; + + (6) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + affects the behavior of an SMTP client and server. + +4. The Message Size Declaration service extension + + An SMTP server may have a fixed upper limit on message size. Any + attempt by a client to transfer a message which is larger than this + fixed upper limit will fail. In addition, a server normally has + limited space with which to store incoming messages. Transfer of a + message may therefore also fail due to a lack of storage space, but + might succeed at a later time. + + + + + +Klensin, et al Standards Track [Page 2] + +RFC 1870 SMTP Size Declaration November 1995 + + + A client using the unextended SMTP protocol defined in [1], can only + be informed of such failures after transmitting the entire message to + the server (which discards the transferred message). If, however, + both client and server support the Message Size Declaration service + extension, such conditions may be detected before any transfer is + attempted. + + An SMTP client wishing to relay a large content may issue the EHLO + command to start an SMTP session, to determine if the server supports + any of several service extensions. If the server responds with code + 250 to the EHLO command, and the response includes the EHLO keyword + value SIZE, then the Message Size Declaration extension is supported. + + If a numeric parameter follows the SIZE keyword value of the EHLO + response, it indicates the size of the largest message that the + server is willing to accept. Any attempt by a client to transfer a + message which is larger than this limit will be rejected with a + permanent failure (552) reply code. + + A server that supports the Message Size Declaration extension will + accept the extended version of the MAIL command described below. + When supported by the server, a client may use the extended MAIL + command (instead of the MAIL command as defined in [1]) to declare an + estimate of the size of a message it wishes to transfer. The server + may then return an appropriate error code if it determines that an + attempt to transfer a message of that size would fail. + +5. Definitions + + The message size is defined as the number of octets, including CR-LF + pairs, but not the SMTP DATA command's terminating dot or doubled + quoting dots, to be transmitted by the SMTP client after receiving + reply code 354 to the DATA command. + + The fixed maximum message size is defined as the message size of the + largest message that a server is ever willing to accept. An attempt + to transfer any message larger than the fixed maximum message size + will always fail. The fixed maximum message size may be an + implementation artifact of the SMTP server, or it may be chosen by + the administrator of the server. + + The declared message size is defined as a client's estimate of the + message size for a particular message. + + + + + + + + +Klensin, et al Standards Track [Page 3] + +RFC 1870 SMTP Size Declaration November 1995 + + +6. The extended MAIL command + + The extended MAIL command is issued by a client when it wishes to + inform a server of the size of the message to be sent. The extended + MAIL command is identical to the MAIL command as defined in [1], + except that a SIZE parameter appears after the address. + + The complete syntax of this extended command is defined in [5]. The + esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by + the syntax for size-value shown above. + + The value associated with the SIZE parameter is a decimal + representation of the declared message size in octets. This number + should include the message header, body, and the CR-LF sequences + between lines, but not the SMTP DATA command's terminating dot or + doubled quoting dots. Only one SIZE parameter may be specified in a + single MAIL command. + + Ideally, the declared message size is equal to the true message size. + However, since exact computation of the message size may be + infeasable, the client may use a heuristically-derived estimate. + Such heuristics should be chosen so that the declared message size is + usually larger than the actual message size. (This has the effect of + making the counting or non-counting of SMTP DATA dots largely an + academic point.) + + NOTE: Servers MUST NOT use the SIZE parameter to determine end of + content in the DATA command. + +6.1 Server action on receipt of the extended MAIL command + + Upon receipt of an extended MAIL command containing a SIZE parameter, + a server should determine whether the declared message size exceeds + its fixed maximum message size. If the declared message size is + smaller than the fixed maximum message size, the server may also wish + to determine whether sufficient resources are available to buffer a + message of the declared message size and to maintain it in stable + storage, until the message can be delivered or relayed to each of its + recipients. + + A server may respond to the extended MAIL command with any of the + error codes defined in [1] for the MAIL command. In addition, one of + the following error codes may be returned: + + (1) If the server currently lacks sufficient resources to accept a + message of the indicated size, but may be able to accept the + message at a later time, it responds with code "452 insufficient + system storage". + + + +Klensin, et al Standards Track [Page 4] + +RFC 1870 SMTP Size Declaration November 1995 + + + (2) If the indicated size is larger than the server's fixed maximum + message size, the server responds with code "552 message size + exceeds fixed maximium message size". + + A server is permitted, but not required, to accept a message which + is, in fact, larger than declared in the extended MAIL command, such + as might occur if the client employed a size-estimation heuristic + which was inaccurate. + +6.2 Client action on receiving response to extended MAIL command + + The client, upon receiving the server's response to the extended MAIL + command, acts as follows: + + (1) If the code "452 insufficient system storage" is returned, the + client should next send either a RSET command (if it wishes to + attempt to send other messages) or a QUIT command. The client + should then repeat the attempt to send the message to the server + at a later time. + + (2) If the code "552 message exceeds fixed maximum message size" is + received, the client should immediately send either a RSET command + (if it wishes to attempt to send additional messages), or a QUIT + command. The client should then declare the message undeliverable + and return appropriate notification to the sender (if a sender + address was present in the MAIL command). + + A successful (250) reply code in response to the extended MAIL + command does not constitute an absolute guarantee that the message + transfer will succeed. SMTP clients using the extended MAIL command + must still be prepared to handle both temporary and permanent error + reply codes (including codes 452 and 552), either immediately after + issuing the DATA command, or after transfer of the message. + +6.3 Messages larger than the declared size. + + Once a server has agreed (via the extended MAIL command) to accept a + message of a particular size, it should not return a 552 reply code + after the transfer phase of the DATA command, unless the actual size + of the message transferred is greater than the declared message size. + A server may also choose to accept a message which is somewhat larger + than the declared message size. + + A client is permitted to declare a message to be smaller than its + actual size. However, in this case, a successful (250) reply code is + no assurance that the server will accept the message or has + sufficient resources to do so. The server may reject such a message + after its DATA transfer. + + + +Klensin, et al Standards Track [Page 5] + +RFC 1870 SMTP Size Declaration November 1995 + + +6.4 Per-recipient rejection based on message size. + + A server that implements this extension may return a 452 or 552 reply + code in response to a RCPT command, based on its unwillingness to + accept a message of the declared size for a particular recipient. + + (1) If a 452 code is returned, the client may requeue the message for + later delivery to the same recipient. + + (2) If a 552 code is returned, the client may not requeue the message + for later delivery to the same recipient. + +7. Minimal usage + + A "minimal" client may use this extension to simply compare its + (perhaps estimated) size of the message that it wishes to relay, with + the server's fixed maximum message size (from the parameter to the + SIZE keyword in the EHLO response), to determine whether the server + will ever accept the message. Such an implementation need not + declare message sizes via the extended MAIL command. However, + neither will it be able to discover temporary limits on message size + due to server resource limitations, nor per-recipient limitations on + message size. + + A minimal server that employs this service extension may simply use + the SIZE keyword value to inform the client of the size of the + largest message it will accept, or to inform the client that there is + no fixed limit on message size. Such a server must accept the + extended MAIL command and return a 552 reply code if the client's + declared size exceeds its fixed size limit (if any), but it need not + detect "temporary" limitations on message size. + + The numeric parameter to the EHLO SIZE keyword is optional. If the + parameter is omitted entirely it indicates that the server does not + advertise a fixed maximum message size. A server that returns the + SIZE keyword with no parameter in response to the EHLO command may + not issue a positive (250) response to an extended MAIL command + containing a SIZE specification without first checking to see if + sufficient resources are available to transfer a message of the + declared size, and to retain it in stable storage until it can be + relayed or delivered to its recipients. If possible, the server + should actually reserve sufficient storage space to transfer the + message. + + + + + + + + +Klensin, et al Standards Track [Page 6] + +RFC 1870 SMTP Size Declaration November 1995 + + +8. Example + + The following example illustrates the use of size declaration with + some permanent and temporary failures. + + S: + C: + S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992) + C: EHLO ymir.claremont.edu + S: 250-sigurd.innosoft.com + S: 250-EXPN + S: 250-HELP + S: 250 SIZE 1000000 + C: MAIL FROM: SIZE=500000 + S: 250 Address Ok. + C: RCPT TO: + S: 250 ned@innosoft.com OK; can accomodate 500000 byte message + C: RCPT TO: + S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU + C: RCPT TO: + S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU + C: DATA + S: 354 Send message, ending in CRLF.CRLF. + ... + C: . + S: 250 Some recipients OK + C: QUIT + S: 221 Goodbye + +9. Security Considerations + + The size declaration extensions described in this memo can + conceivably be used to facilitate crude service denial attacks. + Specifically, both the information contained in the SIZE parameter + and use of the extended MAIL command make it somewhat quicker and + easier to devise an efficacious service denial attack. However, + unless implementations are very weak, these extensions do not create + any vulnerability that has not always existed with SMTP. In addition, + no issues are addressed involving trusted systems and possible + release of information via the mechanisms described in this RFC. + +10. Acknowledgements + + This document was derived from an earlier Working Group work in + progess contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot + Lear, Marshall T. Rose, and Einar Stefferud provided extensive + comments in response to earlier works in progress of both this and + the previous memo. + + + +Klensin, et al Standards Track [Page 7] + +RFC 1870 SMTP Size Declaration November 1995 + + +11. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, September 1993. + + [4] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1522, University of Tennessee, September 1993. + + [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, + "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft + International, Inc., Dover Beach Consulting, Inc., Network + Management Associates, Inc., Brandenburg Consulting, November + 1995. + + [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC + 974, BBN, January 1986. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Klensin, et al Standards Track [Page 8] + +RFC 1870 SMTP Size Declaration November 1995 + + +12. Chair, Editor, and Author Addresses + + John Klensin, WG Chair + MCI + 2100 Reston Parkway + Reston, VA 22091 + + Phone: +1 703 715-7361 + Fax: +1 703 715-7436 + EMail: klensin@mci.net + + + Ned Freed, Editor + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + Keith Moore + Computer Science Dept. + University of Tennessee + 107 Ayres Hall + Knoxville, TN 37996-1301 + USA + + EMail: moore@cs.utk.edu + + + + + + + + + + + + + + + + + + + + +Klensin, et al Standards Track [Page 9] + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc1891.txt b/server/src/site/resources/rfclist/smtp/rfc1891.txt new file mode 100644 index 00000000000..578cb00d464 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1891.txt @@ -0,0 +1,521 @@ + + + + + +Network Working Group K. Moore +Request for Comments: 1891 University of Tennessee +Category: Standards Track January 1996 + + + SMTP Service Extension + for Delivery Status Notifications + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This memo defines an extension to the SMTP service, which allows an + SMTP client to specify (a) that delivery status notifications (DSNs) + should be generated under certain conditions, (b) whether such + notifications should return the contents of the message, and (c) + additional information, to be returned with a DSN, that allows the + sender to identify both the recipient(s) for which the DSN was + issued, and the transaction in which the original message was sent. + + Any questions, comments, and reports of defects or ambiguities in + this specification may be sent to the mailing list for the NOTARY + working group of the IETF, using the address + . Requests to subscribe to the mailing + list should be addressed to . + Implementors of this specification are encouraged to subscribe to the + mailing list, so that they will quickly be informed of any problems + which might hinder interoperability. + + NOTE: This document is a Proposed Standard. If and when this + protocol is submitted for Draft Standard status, any normative text + (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in + this document will be re-evaluated in light of implementation + experience, and are thus subject to change. + +2. Introduction + + The SMTP protocol [1] requires that an SMTP server provide + notification of delivery failure, if it determines that a message + cannot be delivered to one or more recipients. Traditionally, such + notification consists of an ordinary Internet mail message (format + defined by [2]), sent to the envelope sender address (the argument of + + + +Moore Standards Track [Page 1] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + the SMTP MAIL command), containing an explanation of the error and at + least the headers of the failed message. + + Experience with large mail distribution lists [3] indicates that such + messages are often insufficient to diagnose problems, or even to + determine at which host or for which recipients a problem occurred. + In addition, the lack of a standardized format for delivery + notifications in Internet mail makes it difficult to exchange such + notifications with other message handling systems. + + Such experience has demonstrated a need for a delivery status + notification service for Internet electronic mail, which: + +(a) is reliable, in the sense that any DSN request will either be + honored at the time of final delivery, or result in a response + that indicates that the request cannot be honored, + +(b) when both success and failure notifications are requested, + provides an unambiguous and nonconflicting indication of whether + delivery of a message to a recipient succeeded or failed, + +(c) is stable, in that a failed attempt to deliver a DSN should never + result in the transmission of another DSN over the network, + +(d) preserves sufficient information to allow the sender to identify + both the mail transaction and the recipient address which caused + the notification, even when mail is forwarded or gatewayed to + foreign environments, and + +(e) interfaces acceptably with non-SMTP and non-822-based mail + systems, both so that notifications returned from foreign mail + systems may be useful to Internet users, and so that the + notification requests from foreign environments may be honored. + Among the requirements implied by this goal are the ability to + request non-return-of-content, and the ability to specify whether + positive delivery notifications, negative delivery notifications, + both, or neither, should be issued. + + In an attempt to provide such a service, this memo uses the mechanism + defined in [4] to define an extension to the SMTP protocol. Using + this mechanism, an SMTP client may request that an SMTP server issue + or not issue a delivery status notification (DSN) under certain + conditions. The format of a DSN is defined in [5]. + + + + + + + + +Moore Standards Track [Page 2] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +3. Framework for the Delivery Status Notification Extension + + The following service extension is therefore defined: + +(1) The name of the SMTP service extension is "Delivery Status + Notification"; + +(2) the EHLO keyword value associated with this extension is "DSN", + the meaning of which is defined in section 4 of this memo; + +(3) no parameters are allowed with this EHLO keyword value; + +(4) two optional parameters are added to the RCPT command, and two + optional parameters are added to the MAIL command: + + An optional parameter for the RCPT command, using the + esmtp-keyword "NOTIFY", (to specify the conditions under which a + delivery status notification should be generated), is defined in + section 5.1, + + An optional parameter for the RCPT command, using the + esmtp-keyword "ORCPT", (used to convey the "original" + (sender-specified) recipient address), is defined in section 5.2, + and + + An optional parameter for the MAIL command, using the + esmtp-keyword "RET", (to request that DSNs containing an + indication of delivery failure either return the entire contents + of a message or only the message headers), is defined in section + 5.3, + + An optional parameter for the MAIL command, using the + esmtp-keyword "ENVID", (used to propagate an identifier for this + message transmission envelope, which is also known to the sender + and will, if present, be returned in any DSNs issued for this + transmission), is defined in section 5.4; + +(5) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + effects the behavior of a message transfer agent. + +4. The Delivery Status Notification service extension + + An SMTP client wishing to request a DSN for a message may issue the + EHLO command to start an SMTP session, to determine if the server + supports any of several service extensions. If the server responds + with code 250 to the EHLO command, and the response includes the EHLO + + + +Moore Standards Track [Page 3] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + keyword DSN, then the Delivery Status Notification extension (as + described in this memo) is supported. + + Ordinarily, when an SMTP server returns a positive (2xx) reply code + in response to a RCPT command, it agrees to accept responsibility for + either delivering the message to the named recipient, or sending a + notification to the sender of the message indicating that delivery + has failed. However, an extended SMTP ("ESMTP") server which + implements this service extension will accept an optional NOTIFY + parameter with the RCPT command. If present, the NOTIFY parameter + alters the conditions for generation of delivery status notifications + from the default (issue notifications only on failure) specified in + [1]. The ESMTP client may also request (via the RET parameter) + whether the entire contents of the original message should be + returned (as opposed to just the headers of that message), along with + the DSN. + + In general, an ESMTP server which implements this service extension + will propagate delivery status notification requests when relaying + mail to other SMTP-based MTAs which also support this extension, and + make a "best effort" to ensure that such requests are honored when + messages are passed into other environments. + + In order that any delivery status notifications thus generated will + be meaningful to the sender, any ESMTP server which supports this + extension will attempt to propagate the following information to any + other MTAs that are used to relay the message, for use in generating + DSNs: + +(a) for each recipient, a copy of the original recipient address, as + used by the sender of the message. + + This address need not be the same as the mailbox specified in the + RCPT command. For example, if a message was originally addressed + to A@B.C and later forwarded to A@D.E, after such forwarding has + taken place, the RCPT command will specify a mailbox of A@D.E. + However, the original recipient address remains A@B.C. + + Also, if the message originated from an environment which does not + use Internet-style user@domain addresses, and was gatewayed into + SMTP, the original recipient address will preserve the original + form of the recipient address. + +(b) for the entire SMTP transaction, an envelope identification + string, which may be used by the sender to associate any delivery + status notifications with the transaction used to send the + original message. + + + + +Moore Standards Track [Page 4] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +5. Additional parameters for RCPT and MAIL commands + + The extended RCPT and MAIL commands are issued by a client when it + wishes to request a DSN from the server, under certain conditions, + for a particular recipient. The extended RCPT and MAIL commands are + identical to the RCPT and MAIL commands defined in [1], except that + one or more of the following parameters appear after the sender or + recipient address, respectively. The general syntax for extended + SMTP commands is defined in [4]. + + NOTE: Although RFC 822 ABNF is used to describe the syntax of these + parameters, they are not, in the language of that document, + "structured field bodies". Therefore, while parentheses MAY appear + within an emstp-value, they are not recognized as comment delimiters. + + The syntax for "esmtp-value" in [4] does not allow SP, "=", control + characters, or characters outside the traditional ASCII range of 1- + 127 decimal to be transmitted in an esmtp-value. Because the ENVID + and ORCPT parameters may need to convey values outside this range, + the esmtp-values for these parameters are encoded as "xtext". + "xtext" is formally defined as follows: + + xtext = *( xchar / hexchar ) + + xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, + except for "+" and "=". + +; "hexchar"s are intended to encode octets that cannot appear +; as ASCII characters within an esmtp-value. + + hexchar = ASCII "+" immediately followed by two upper case + hexadecimal digits + +When encoding an octet sequence as xtext: + ++ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", + MAY be encoded as itself. (A CHAR in this range MAY instead be + encoded as a "hexchar", at the implementor's discretion.) + ++ ASCII CHARs that fall outside the range above must be encoded as + "hexchar". + +5.1 The NOTIFY parameter of the ESMTP RCPT command + + A RCPT command issued by a client may contain the optional esmtp- + keyword "NOTIFY", to specify the conditions under which the SMTP + server should generate DSNs for that recipient. If the NOTIFY + esmtp-keyword is used, it MUST have an associated esmtp-value, + + + +Moore Standards Track [Page 5] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + formatted according to the following rules, using the ABNF of RFC + 822: + + notify-esmtp-value = "NEVER" / 1#notify-list-element + + notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" + +Notes: + +a. Multiple notify-list-elements, separated by commas, MAY appear in a + NOTIFY parameter; however, the NEVER keyword MUST appear by itself. + +b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled + in any combination of upper and lower case letters. + +The meaning of the NOTIFY parameter values is generally as follows: + ++ A NOTIFY parameter value of "NEVER" requests that a DSN not be + returned to the sender under any conditions. + ++ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" + keywords requests that a DSN be issued on successful delivery or + delivery failure, respectively. + ++ A NOTIFY parameter value containing the keyword "DELAY" indicates the + sender's willingness to receive "delayed" DSNs. Delayed DSNs may be + issued if delivery of a message has been delayed for an unusual amount + of time (as determined by the MTA at which the message is delayed), + but the final delivery status (whether successful or failure) cannot + be determined. The absence of the DELAY keyword in a NOTIFY parameter + requests that a "delayed" DSN NOT be issued under any conditions. + + The actual rules governing interpretation of the NOTIFY parameter are + given in section 6. + + For compatibility with SMTP clients that do not use the NOTIFY + facility, the absence of a NOTIFY parameter in a RCPT command may be + interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. + +5.2 The ORCPT parameter to the ESMTP RCPT command + + The ORCPT esmtp-keyword of the RCPT command is used to specify an + "original" recipient address that corresponds to the actual recipient + to which the message is to be delivered. If the ORCPT esmtp-keyword + is used, it MUST have an associated esmtp-value, which consists of + the original recipient address, encoded according to the rules below. + The ABNF for the ORCPT parameter is: + + + + +Moore Standards Track [Page 6] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + orcpt-parameter = "ORCPT=" original-recipient-address + + original-recipient-address = addr-type ";" xtext + + addr-type = atom + + The "addr-type" portion MUST be an IANA-registered electronic mail + address-type (as defined in [5]), while the "xtext" portion contains + an encoded representation of the original recipient address using the + rules in section 5 of this document. The entire ORCPT parameter MAY + be up to 500 characters in length. + + When initially submitting a message via SMTP, if the ORCPT parameter + is used, it MUST contain the same address as the RCPT TO address + (unlike the RCPT TO address, the ORCPT parameter will be encoded as + xtext). Likewise, when a mailing list submits a message via SMTP to + be distributed to the list subscribers, if ORCPT is used, the ORCPT + parameter MUST match the new RCPT TO address of each recipient, not + the address specified by the original sender of the message.) + + The "addr-type" portion of the original-recipient-address is used to + indicate the "type" of the address which appears in the ORCPT + parameter value. However, the address associated with the ORCPT + keyword is NOT constrained to conform to the syntax rules for that + "addr-type". + + Ideally, the "xtext" portion of the original-recipient-address should + contain, in encoded form, the same sequence of characters that the + sender used to specify the recipient. However, for a message + gatewayed from an environment (such as X.400) in which a recipient + address is not a simple string of printable characters, the + representation of recipient address must be defined by a + specification for gatewaying between DSNs and that environment. + +5.3 The RET parameter of the ESMTP MAIL command + + The RET esmtp-keyword on the extended MAIL command specifies whether + or not the message should be included in any failed DSN issued for + this message transmission. If the RET esmtp-keyword is used, it MUST + have an associated esmtp-value, which is one of the following + keywords: + + FULL requests that the entire message be returned in any "failed" + delivery status notification issued for this recipient. + + HDRS requests that only the headers of the message be returned. + + + + + +Moore Standards Track [Page 7] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + The FULL and HDRS keywords may be spelled in any combination of upper + and lower case letters. + + If no RET parameter is supplied, the MTA MAY return either the + headers of the message or the entire message for any DSN containing + indication of failed deliveries. + + Note that the RET parameter only applies to DSNs that indicate + delivery failure for at least one recipient. If a DSN contains no + indications of delivery failure, only the headers of the message + should be returned. + +5.4 The ENVID parameter to the ESMTP MAIL command + + The ENVID esmtp-keyword of the SMTP MAIL command is used to specify + an "envelope identifier" to be transmitted along with the message and + included in any DSNs issued for any of the recipients named in this + SMTP transaction. The purpose of the envelope identifier is to allow + the sender of a message to identify the transaction for which the DSN + was issued. + + The ABNF for the ENVID parameter is: + + envid-parameter = "ENVID=" xtext + + The ENVID esmtp-keyword MUST have an associated esmtp-value. No + meaning is assigned by the mail system to the presence or absence of + this parameter or to any esmtp-value associated with this parameter; + the information is used only by the sender or his user agent. The + ENVID parameter MAY be up to 100 characters in length. + +5.5 Restrictions on the use of Delivery Status Notification parameters + + The RET and ENVID parameters MUST NOT appear more than once each in + any single MAIL command. If more than one of either of these + parameters appears in a MAIL command, the ESMTP server SHOULD respond + with "501 syntax error in parameters or arguments". + + The NOTIFY and ORCPT parameters MUST NOT appear more than once in any + RCPT command. If more than one of either of these parameters appears + in a RCPT command, the ESMTP server SHOULD respond with "501 syntax + error in parameters or arguments". + +6. Conformance requirements + + The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer + Agents (MTAs) when accepting, relaying, or gatewaying mail, as well + as User Agents (UAs) when submitting mail to the mail transport + + + +Moore Standards Track [Page 8] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + system. The DSN extension to SMTP may be used to allow UAs to convey + the sender's requests as to when DSNs should be issued. A UA which + claims to conform to this specification must meet certain + requirements as described below. + + Typically, a message transfer agent (MTA) which supports SMTP will + assume, at different times, both the role of a SMTP client and an + SMTP server, and may also provide local delivery, gatewaying to + foreign environments, forwarding, and mailing list expansion. An MTA + which, when acting as an SMTP server, issues the DSN keyword in + response to the EHLO command, MUST obey the rules below for a + "conforming SMTP client" when acting as a client, and a "conforming + SMTP server" when acting as a server. The term "conforming MTA" + refers to an MTA which conforms to this specification, independent of + its role of client or server. + +6.1 SMTP protocol interactions + + The following rules apply to SMTP transactions in which any of the + ENVID, NOTIFY, RET, or ORCPT keywords are used: + +(a) If an SMTP client issues a MAIL command containing a valid ENVID + parameter and associated esmtp-value and/or a valid RET parameter + and associated esmtp-value, a conforming SMTP server MUST return + the same reply-code as it would to the same MAIL command without + the ENVID and/or RET parameters. A conforming SMTP server MUST + NOT refuse a MAIL command based on the absence or presence of + valid ENVID or RET parameters, or on their associated + esmtp-values. + + However, if the associated esmtp-value is not valid (i.e. contains + illegal characters), or if there is more than one ENVID or RET + parameter in a particular MAIL command, the server MUST issue the + reply-code 501 with an appropriate message (e.g. "syntax error in + parameter"). + +(b) If an SMTP client issues a RCPT command containing any valid + NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST + return the same response as it would to the same RCPT command + without those NOTIFY and/or ORCPT parameters. A conforming SMTP + server MUST NOT refuse a RCPT command based on the presence or + absence of any of these parameters. + + However, if any of the associated esmtp-values are not valid, or + if there is more than one of any of these parameters in a + particular RCPT command, the server SHOULD issue the response "501 + syntax error in parameter". + + + + +Moore Standards Track [Page 9] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2 Handling of messages received via SMTP + + This section describes how a conforming MTA should handle any + messages received via SMTP. + + NOTE: A DSN MUST NOT be returned to the sender for any message for + which the return address from the SMTP MAIL command was NULL ("<>"), + even if the sender's address is available from other sources (e.g. + the message header). However, the MTA which would otherwise issue a + DSN SHOULD inform the local postmaster of delivery failures through + some appropriate mechanism that will not itself + diff --git a/server/src/site/resources/rfclist/smtp/rfc1893.txt b/server/src/site/resources/rfclist/smtp/rfc1893.txt new file mode 100644 index 00000000000..47454b8811a --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1893.txt @@ -0,0 +1,844 @@ + + + + + +Network Working Group G. Vaudreuil +Request for Comments: 1893 Octel Network Services +Category: Standards Track January 1996 + + + Enhanced Mail System Status Codes + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Overview + + There currently is not a standard mechanism for the reporting of mail + system errors except for the limited set offered by SMTP and the + system specific text descriptions sent in mail messages. There is a + pressing need for a rich machine readable status code for use in + delivery status notifications [DSN]. This document proposes a new + set of status codes for this purpose. + + SMTP [SMTP] error codes have historically been used for reporting + mail system errors. Because of limitations in the SMTP code design, + these are not suitable for use in delivery status notifications. + SMTP provides about 12 useful codes for delivery reports. The + majority of the codes are protocol specific response codes such as + the 354 response to the SMTP data command. Each of the 12 useful + codes are each overloaded to indicate several error conditions each. + SMTP suffers some scars from history, most notably the unfortunate + damage to the reply code extension mechanism by uncontrolled use. + This proposal facilitates future extensibility by requiring the + client to interpret unknown error codes according to the theory of + codes while requiring servers to register new response codes. + + The SMTP theory of reply codes partitioned in the number space such a + manner that the remaining available codes will not provide the space + needed. The most critical example is the existence of only 5 + remaining codes for mail system errors. The mail system + classification includes both host and mailbox error conditions. The + remaining third digit space would be completely consumed as needed to + indicate MIME and media conversion errors and security system errors. + + A revision to the SMTP theory of reply codes to better distribute the + error conditions in the number space will necessarily be incompatible + with SMTP. Further, consumption of the remaining reply-code number + + + +Vaudreuil Standards Track [Page 1] + +RFC 1893 Mail System Status Codes January 1996 + + + space for delivery notification reporting will reduce the available + codes for new ESMTP extensions. + + The following proposal is based on the SMTP theory of reply codes. + It adopts the success, permanent error, and transient error semantics + of the first value, with a further description and classification in + the second. This proposal re-distributes the classifications to + better distribute the error conditions, such as separating mailbox + from host errors. + +2. Status Codes + + This document defines a new set of status codes to report mail system + conditions. These status codes are intended to be used for media and + language independent status reporting. They are not intended for + system specific diagnostics. + + The syntax of the new status codes is defined as: + + status-code = class "." subject "." detail + class = "2"/"4"/"5" + subject = 1*3digit + detail = 1*3digit + + White-space characters and comments are NOT allowed within a status- + code. Each numeric sub-code within the status-code MUST be expressed + without leading zero digits. + + Status codes consist of three numerical fields separated by ".". The + first sub-code indicates whether the delivery attempt was successful. + The second sub-code indicates the probable source of any delivery + anomalies, and the third sub-code indicates a precise error + condition. + + The codes space defined is intended to be extensible only by + standards track documents. Mail system specific status codes should + be mapped as close as possible to the standard status codes. Servers + should send only defined, registered status codes. System specific + errors and diagnostics should be carried by means other than status + codes. + + New subject and detail codes will be added over time. Because the + number space is large, it is not intended that published status codes + will ever be redefined or eliminated. Clients should preserve the + extensibility of the code space by reporting the general error + described in the subject sub-code when the specific detail is + unrecognized. + + + + +Vaudreuil Standards Track [Page 2] + +RFC 1893 Mail System Status Codes January 1996 + + + The class sub-code provides a broad classification of the status. + The enumerated values the class are defined as: + + 2.X.X Success + + Success specifies that the DSN is reporting a positive delivery + action. Detail sub-codes may provide notification of + transformations required for delivery. + + 4.X.X Persistent Transient Failure + + A persistent transient failure is one in which the message as + sent is valid, but some temporary event prevents the successful + sending of the message. Sending in the future may be successful. + + 5.X.X Permanent Failure + + A permanent failure is one which is not likely to be resolved by + resending the message in the current form. Some change to the + message or the destination must be made for successful delivery. + + A client must recognize and report class sub-code even where + subsequent subject sub-codes are unrecognized. + + The subject sub-code classifies the status. This value applies to + each of the three classifications. The subject sub-code, if + recognized, must be reported even if the additional detail provided + by the detail sub-code is not recognized. The enumerated values for + the subject sub-code are: + + X.0.X Other or Undefined Status + + There is no additional subject information available. + + X.1.X Addressing Status + + The address status reports on the originator or destination + address. It may include address syntax or validity. These + errors can generally be corrected by the sender and retried. + + X.2.X Mailbox Status + + Mailbox status indicates that something having to do with the + mailbox has cause this DSN. Mailbox issues are assumed to be + under the general control of the recipient. + + + + + + +Vaudreuil Standards Track [Page 3] + +RFC 1893 Mail System Status Codes January 1996 + + + X.3.X Mail System Status + + Mail system status indicates that something having to do + with the destination system has caused this DSN. System + issues are assumed to be under the general control of the + destination system administrator. + + X.4.X Network and Routing Status + + The networking or routing codes report status about the + delivery system itself. These system components include any + necessary infrastructure such as directory and routing + services. Network issues are assumed to be under the + control of the destination or intermediate system + administrator. + + X.5.X Mail Delivery Protocol Status + + The mail delivery protocol status codes report failures + involving the message delivery protocol. These failures + include the full range of problems resulting from + implementation errors or an unreliable connection. Mail + delivery protocol issues may be controlled by many parties + including the originating system, destination system, or + intermediate system administrators. + + X.6.X Message Content or Media Status + + The message content or media status codes report failures + involving the content of the message. These codes report + failures due to translation, transcoding, or otherwise + unsupported message media. Message content or media issues + are under the control of both the sender and the receiver, + both of whom must support a common set of supported + content-types. + + X.7.X Security or Policy Status + + The security or policy status codes report failures + involving policies such as per-recipient or per-host + filtering and cryptographic operations. Security and policy + status issues are assumed to be under the control of either + or both the sender and recipient. Both the sender and + recipient must permit the exchange of messages and arrange + the exchange of necessary keys and certificates for + cryptographic operations. + + + + + +Vaudreuil Standards Track [Page 4] + +RFC 1893 Mail System Status Codes January 1996 + + +3. Enumerated Status Codes + + The following section defines and describes the detail sub-code. The + detail value provides more information about the status and is + defined relative to the subject of the status. + + 3.1 Other or Undefined Status + + X.0.0 Other undefined Status + + Other undefined status is the only undefined error code. It + should be used for all errors for which only the class of the + error is known. + + 3.2 Address Status + + X.1.0 Other address status + + Something about the address specified in the message caused + this DSN. + + X.1.1 Bad destination mailbox address + + The mailbox specified in the address does not exist. For + Internet mail names, this means the address portion to the + left of the "@" sign is invalid. This code is only useful + for permanent failures. + + X.1.2 Bad destination system address + + The destination system specified in the address does not + exist or is incapable of accepting mail. For Internet mail + names, this means the address portion to the right of the + "@" is invalid for mail. This codes is only useful for + permanent failures. + + X.1.3 Bad destination mailbox address syntax + + The destination address was syntactically invalid. This can + apply to any field in the address. This code is only useful + for permanent failures. + + X.1.4 Destination mailbox address ambiguous + + The mailbox address as specified matches one or more + recipients on the destination system. This may result if a + heuristic address mapping algorithm is used to map the + specified address to a local mailbox name. + + + +Vaudreuil Standards Track [Page 5] + +RFC 1893 Mail System Status Codes January 1996 + + + X.1.5 Destination address valid + + This mailbox address as specified was valid. This status + code should be used for positive delivery reports. + + X.1.6 Destination mailbox has moved, No forwarding address + + The mailbox address provided was at one time valid, but mail + is no longer being accepted for that address. This code is + only useful for permanent failures. + + X.1.7 Bad sender's mailbox address syntax + + The sender's address was syntactically invalid. This can + apply to any field in the address. + + X.1.8 Bad sender's system address + + The sender's system specified in the address does not exist + or is incapable of accepting return mail. For domain names, + this means the address portion to the right of the "@" is + invalid for mail. + + 3.3 Mailbox Status + + X.2.0 Other or undefined mailbox status + + The mailbox exists, but something about the destination + mailbox has caused the sending of this DSN. + + X.2.1 Mailbox disabled, not accepting messages + + The mailbox exists, but is not accepting messages. This may + be a permanent error if the mailbox will never be re-enabled + or a transient error if the mailbox is only temporarily + disabled. + + X.2.2 Mailbox full + + The mailbox is full because the user has exceeded a + per-mailbox administrative quota or physical capacity. The + general semantics implies that the recipient can delete + messages to make more space available. This code should be + used as a persistent transient failure. + + + + + + + +Vaudreuil Standards Track [Page 6] + +RFC 1893 Mail System Status Codes January 1996 + + + X.2.3 Message length exceeds administrative limit + + A per-mailbox administrative message length limit has been + exceeded. This status code should be used when the + per-mailbox message length limit is less than the general + system limit. This code should be used as a permanent + failure. + + X.2.4 Mailing list expansion problem + + The mailbox is a mailing list address and the mailing list + was unable to be expanded. This code may represent a + permanent failure or a persistent transient failure. + + 3.4 Mail system status + + X.3.0 Other or undefined mail system status + + The destination system exists and normally accepts mail, but + something about the system has caused the generation of this + DSN. + + X.3.1 Mail system full + + Mail system storage has been exceeded. The general + semantics imply that the individual recipient may not be + able to delete material to make room for additional + messages. This is useful only as a persistent transient + error. + + X.3.2 System not accepting network messages + + The host on which the mailbox is resident is not accepting + messages. Examples of such conditions include an immanent + shutdown, excessive load, or system maintenance. This is + useful for both permanent and permanent transient errors. + + X.3.3 System not capable of selected features + + Selected features specified for the message are not + supported by the destination system. This can occur in + gateways when features from one domain cannot be mapped onto + the supported feature in another. + + + + + + + + +Vaudreuil Standards Track [Page 7] + +RFC 1893 Mail System Status Codes January 1996 + + + X.3.4 Message too big for system + + The message is larger than per-message size limit. This + limit may either be for physical or administrative reasons. + This is useful only as a permanent error. + + X.3.5 System incorrectly configured + + The system is not configured in a manner which will permit + it to accept this message. + + 3.5 Network and Routing Status + + X.4.0 Other or undefined network or routing status + + Something went wrong with the networking, but it is not + clear what the problem is, or the problem cannot be well + expressed with any of the other provided detail codes. + + X.4.1 No answer from host + + The outbound connection attempt was not answered, either + because the remote system was busy, or otherwise unable to + take a call. This is useful only as a persistent transient + error. + + X.4.2 Bad connection + + The outbound connection was established, but was otherwise + unable to complete the message transaction, either because + of time-out, or inadequate connection quality. This is + useful only as a persistent transient error. + + X.4.3 Directory server failure + + The network system was unable to forward the message, + because a directory server was unavailable. This is useful + only as a persistent transient error. + + The inability to connect to an Internet DNS server is one + example of the directory server failure error. + + X.4.4 Unable to route + + The mail system was unable to determine the next hop for the + message because the necessary routing information was + unavailable from the directory server. This is useful for + both permanent and persistent transient errors. + + + +Vaudreuil Standards Track [Page 8] + +RFC 1893 Mail System Status Codes January 1996 + + + A DNS lookup returning only an SOA (Start of Administration) + record for a domain name is one example of the unable to + route error. + + X.4.5 Mail system congestion + + The mail system was unable to deliver the message because + the mail system was congested. This is useful only as a + persistent transient error. + + X.4.6 Routing loop detected + + A routing loop caused the message to be forwarded too many + times, either because of incorrect routing tables or a user + forwarding loop. This is useful only as a persistent + transient error. + + X.4.7 Delivery time expired + + The message was considered too old by the rejecting system, + either because it remained on that host too long or because + the time-to-live value specified by the sender of the + message was exceeded. If possible, the code for the actual + problem found when delivery was attempted should be returned + rather than this code. This is useful only as a persistent + transient error. + + 3.6 Mail Delivery Protocol Status + + X.5.0 Other or undefined protocol status + + Something was wrong with the protocol necessary to deliver + the message to the next hop and the problem cannot be well + expressed with any of the other provided detail codes. + + X.5.1 Invalid command + + A mail transaction protocol command was issued which was + either out of sequence or unsupported. This is useful only + as a permanent error. + + X.5.2 Syntax error + + A mail transaction protocol command was issued which could + not be interpreted, either because the syntax was wrong or + the command is unrecognized. This is useful only as a + permanent error. + + + + +Vaudreuil Standards Track [Page 9] + +RFC 1893 Mail System Status Codes January 1996 + + + X.5.3 Too many recipients + + More recipients were specified for the message than could + have been delivered by the protocol. This error should + normally result in the segmentation of the message into two, + the remainder of the recipients to be delivered on a + subsequent delivery attempt. It is included in this list in + the event that such segmentation is not possible. + + X.5.4 Invalid command arguments + + A valid mail transaction protocol command was issued with + invalid arguments, either because the arguments were out of + range or represented unrecognized features. This is useful + only as a permanent error. + + X.5.5 Wrong protocol version + + A protocol version mis-match existed which could not be + automatically resolved by the communicating parties. + + 3.7 Message Content or Message Media Status + + X.6.0 Other or undefined media error + + Something about the content of a message caused it to be + considered undeliverable and the problem cannot be well + expressed with any of the other provided detail codes. + + X.6.1 Media not supported + + The media of the message is not supported by either the + delivery protocol or the next system in the forwarding path. + This is useful only as a permanent error. + + X.6.2 Conversion required and prohibited + + The content of the message must be converted before it can + be delivered and such conversion is not permitted. Such + prohibitions may be the expression of the sender in the + message itself or the policy of the sending host. + + X.6.3 Conversion required but not supported + + The message content must be converted to be forwarded but + such conversion is not possible or is not practical by a + host in the forwarding path. This condition may result when + an ESMTP gateway supports 8bit transport but is not able to + + + +Vaudreuil Standards Track [Page 10] + +RFC 1893 Mail System Status Codes January 1996 + + + downgrade the message to 7 bit as required for the next hop. + + X.6.4 Conversion with loss performed + + This is a warning sent to the sender when message delivery + was successfully but when the delivery required a conversion + in which some data was lost. This may also be a permanant + error if the sender has indicated that conversion with loss + is prohibited for the message. + + X.6.5 Conversion Failed + + A conversion was required but was unsuccessful. This may be + useful as a permanent or persistent temporary notification. + + 3.8 Security or Policy Status + + X.7.0 Other or undefined security status + + Something related to security caused the message to be + returned, and the problem cannot be well expressed with any + of the other provided detail codes. This status code may + also be used when the condition cannot be further described + because of security policies in force. + + X.7.1 Delivery not authorized, message refused + + The sender is not authorized to send to the destination. + This can be the result of per-host or per-recipient + filtering. This memo does not discuss the merits of any + such filtering, but provides a mechanism to report such. + This is useful only as a permanent error. + + X.7.2 Mailing list expansion prohibited + + The sender is not authorized to send a message to the + intended mailing list. This is useful only as a permanent + error. + + X.7.3 Security conversion required but not possible + + A conversion from one secure messaging protocol to another + was required for delivery and such conversion was not + possible. This is useful only as a permanent error. + + + + + + + +Vaudreuil Standards Track [Page 11] + +RFC 1893 Mail System Status Codes January 1996 + + + X.7.4 Security features not supported + + A message contained security features such as secure + authentication which could not be supported on the delivery + protocol. This is useful only as a permanent error. + + X.7.5 Cryptographic failure + + A transport system otherwise authorized to validate or + decrypt a message in transport was unable to do so because + necessary information such as key was not available or such + information was invalid. + + X.7.6 Cryptographic algorithm not supported + + A transport system otherwise authorized to validate or + decrypt a message was unable to do so because the necessary + algorithm was not supported. + + X.7.7 Message integrity failure + + A transport system otherwise authorized to validate a + message was unable to do so because the message was + corrupted or altered. This may be useful as a permanent, + transient persistent, or successful delivery code. + +4. References + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, University of + Tennessee, Octel Network Services, January 1996. + +5. Security Considerations + + This document describes a status code system with increased + precision. Use of these status codes may disclose additional + information about how an internal mail system is implemented beyond + that currently available. + +6. Acknowledgments + + The author wishes to offer special thanks to Harald Alvestrand, Marko + Kaittola, and Keith Moore for their extensive review and constructive + suggestions. + + + + +Vaudreuil Standards Track [Page 12] + +RFC 1893 Mail System Status Codes January 1996 + + +7. Author's Address + + Gregory M. Vaudreuil + Octel Network Services + 17060 Dallas Parkway + Suite 214 + Dallas, TX 75248-1905 + + Voice/Fax: +1-214-733-2722 + EMail: Greg.Vaudreuil@Octel.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 13] + +RFC 1893 Mail System Status Codes January 1996 + + +8. Appendix - Collected Status Codes + + X.1.0 Other address status + X.1.1 Bad destination mailbox address + X.1.2 Bad destination system address + X.1.3 Bad destination mailbox address syntax + X.1.4 Destination mailbox address ambiguous + X.1.5 Destination mailbox address valid + X.1.6 Mailbox has moved + X.1.7 Bad sender's mailbox address syntax + X.1.8 Bad sender's system address + + X.2.0 Other or undefined mailbox status + X.2.1 Mailbox disabled, not accepting messages + X.2.2 Mailbox full + X.2.3 Message length exceeds administrative limit. + X.2.4 Mailing list expansion problem + + X.3.0 Other or undefined mail system status + X.3.1 Mail system full + X.3.2 System not accepting network messages + X.3.3 System not capable of selected features + X.3.4 Message too big for system + + X.4.0 Other or undefined network or routing status + X.4.1 No answer from host + X.4.2 Bad connection + X.4.3 Routing server failure + X.4.4 Unable to route + X.4.5 Network congestion + X.4.6 Routing loop detected + X.4.7 Delivery time expired + + X.5.0 Other or undefined protocol status + X.5.1 Invalid command + X.5.2 Syntax error + X.5.3 Too many recipients + X.5.4 Invalid command arguments + X.5.5 Wrong protocol version + + X.6.0 Other or undefined media error + X.6.1 Media not supported + X.6.2 Conversion required and prohibited + X.6.3 Conversion required but not supported + X.6.4 Conversion with loss performed + X.6.5 Conversion failed + + + + + +Vaudreuil Standards Track [Page 14] + +RFC 1893 Mail System Status Codes January 1996 + + + X.7.0 Other or undefined security status + X.7.1 Delivery not authorized, message refused + X.7.2 Mailing list expansion prohibited + X.7.3 Security conversion required but not possible + X.7.4 Security features not supported + X.7.5 Cryptographic failure + X.7.6 Cryptographic algorithm not supported + X.7.7 Message integrity failure + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 15] + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc1985.txt b/server/src/site/resources/rfclist/smtp/rfc1985.txt new file mode 100644 index 00000000000..a604b425ea1 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1985.txt @@ -0,0 +1,396 @@ + + + + + +Network Working Group J. De Winter +Request for Comments: 1985 Wildbear Consulting, Inc. +Category: Standards Track August 1996 + + + SMTP Service Extension + for Remote Message Queue Starting + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines an extension to the SMTP service whereby an SMTP + client and server may interact to give the server an opportunity to + start the processing of its queues for messages to go to a given + host. This extension is meant to be used in startup conditions as + well as for mail nodes that have transient connections to their + service providers. + +1. Introduction + + The TURN command was a valid attempt to address the problem of having + to start the processing for the mail queue on a remote machine. + However, the TURN command presents a large security loophole. As + there is no verification of the remote host name, the TURN command + could be used by a rogue system to download the mail for a site other + than itself. + + Therefore, this memo introduces the ETRN command. This command uses + the mechanism defined in [4] to define extensions to the SMTP service + whereby a client ("sender-SMTP") may request that the server + ("receiver-SMTP") start the processing of its mail queues for + messages that are waiting at the server for the client machine. If + any messages are at the server for the client, then the server should + create a new SMTP session and send the messages at that time. + + + + + + + + + + +De Winter Standards Track [Page 1] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + +2. Framework for the ETRN Extension + + The following service extension is therefore defined: + + (1) the name of the SMTP service extension is "Remote Queue + Processing Declaration"; + + (2) the EHLO keyword value associated with this extension is "ETRN", + with no associated parameters; + + (3) one additional verb, ETRN, with a single parameter that + specifies the name of the client(s) to start processing for; + + (4) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + affects the behavior of an SMTP client and server. + +3. The Remote Queue Processing Declaration service extension + + To save money, many small companies want to only maintain transient + connections to their service providers. In addition, there are some + situations where the client sites depend on their mail arriving + quickly, so forcing the queues on the server belonging to their + service provider may be more desirable than waiting for the retry + timeout to occur. + + Both of these situations could currently be fixed using the TURN + command defined in [1], if it were not for a large security loophole + in the TURN command. As it stands, the TURN command will reverse the + direction of the SMTP connection and assume that the remote host is + being honest about what its name is. The security loophole is that + there is no documented stipulation for checking the authenticity of + the remote host name, as given in the HELO or EHLO command. As such, + most SMTP and ESMTP implementations do not implement the TURN command + to avoid this security loophole. + + This has been addressed in the design of the ETRN command. This + extended turn command was written with the points in the first + paragraph in mind, yet paying attention to the problems that + currently exist with the TURN command. The security loophole is + avoided by asking the server to start a new connection aimed at the + specified client. + + In this manner, the server has a lot more certainty that it is + talking to the correct SMTP client. This mechanism can just be seen + as a more immediate version of the retry queues that appear in most + SMTP implementations. In addition, as this command will take a + + + +De Winter Standards Track [Page 2] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + + single parameter, the name of the remote host(s) to start the queues + for, the server can decide whether it wishes to respect the request + or deny it for any local administrative reasons. + +4. Definitions + + Remote queue processing means that using an SMTP or ESMTP connection, + the client may request that the server start to process parts of its + messaging queue. This processing is performed using the existing + SMTP infrastructure and will occur at some point after the processing + is initiated. + + The server host is the node that is responding to the ETRN + command. + + The client host is the node that is initiating the ETRN command. + + The remote host name is defined to be a plain-text field that + specifies a name for the remote host(s). This remote host name may + also include an alias for the specified remote host or special + commands to identify other types of queues. + +5. The extended ETRN command + + The extended ETRN command is issued by the client host when it wishes + to start the SMTP queue processing of a given server host. The + syntax of this command is as follows: + + ETRN [
+

+

+

+
+
+ + +

James currently (v2.1) includes only the most basic list functionality, users can subscribe and unsubscribe, but there is no moderation of messages or subscriptions

+

To enable a list you need the following in config.xml in the root processor block and above the final mailet block -

+ +<mailet match="CommandForListserv=james@localhost" + class="AvalonListservManager"> + <repositoryName>list-james</repositoryName> +</mailet> + +

that will intercept the command emails sent to +

    +
  • james-on@localhost to subscribe the sender
    • +
  • james-off@localhost to unsubscribe the sender
    • +
+

+

and-

+ +<mailet match="RecipientIs=james@localhost" class="AvalonListserv"> + <membersonly> false </membersonly> + <attachmentsallowed> true </attachmentsallowed> + <replytolist> true </replytolist> + <repositoryName>list-james</repositoryName> + <subjectprefix>JamesList</subjectprefix> +</mailet> + +

Which will distribute the mail to the current subscribers

+

in addition to the above you need to have a repository configured in the users-store block(usually near the bottom of config.xml) like so (database)-

+ +<repository name="list-james" + class="org.apache.james.userrepository.ListUsersJdbcRepository" + destinationURL="db://maildb/lists/list-james"> + <sqlFile>file://conf/sqlResources.xml</sqlFile> +</repository> + +

Database users will also need to ensure that they have configured a data-source named to match the destination URL

+

Using the filesystem:-

+ +<repository name="list-james" + class="org.apache.james.userrepository.UsersFileRepository"> + <destination URL="file://var/lists/list-james/"/> +</repository> + +

Restart James, send a mail to james-on@localhost and you should be subscribed.

+

The repository, be it a database table or directory in the filesystem will be created automatically.

+

Database users can manipulate the users repository using SQL, and hence any application capable of running SQL queries against it.

+ + + +

In some simple tests of mail relays James appears to be an open relay, properly configured it is not.

+

Because James is an email application platform it currently accepts all mail delivered to it via SMTP for processing. Only after the mail has been recieved does this processing begin.

+

This means that James accepts Spam. However the default configuration, and any sensible re-configuration has a number of anti-spam measures which will prevent the re-transmisson of spam from James. This makes it a blackhole for spam.

+

This also means that James will not verify addresses, but of course this means that valid addresses can't be harvested from James by spammers either.

+ + + +

Check that you've added valid DNS servers to your James installation. Email delivery requires the use of special mail related DNS information (MX records), so James needs to explicitly be given DNS servers. Look at your config.xml file for a <dnsserver> section and add one or more DNS servers.

+

Additionally, check the RemoteAddrNotInNetwork matcher under<processor name="transport">. By default it looks like this:

+ +<mailet match="RemoteAddrNotInNetwork=127.0.0.1" class="ToProcessor"> + <processor> spam </processor> +</mailet> + +

because most mail programs will use the external IP address (as opposed to 127.0.0.1) when processing mail, you need to add your internal network and/or your static IP address to this list. You may also use a DNS domain name in this list. The resulting entry would look something like this:

+ +<mailet match="RemoteAddrNotInNetwork=127.0.0.1,192.168.1.*" + class="ToProcessor"> + <processor> spam </processor> +</mailet> + +

This tells the processor that anything not in this address list should go to the spam processor.

+

Please note that if you wish to configure James to allow users to send email from any domain or IP address you will need to disable this matcher. In this situation you must use SMTP AUTH to ensure that your server does not act as an open relay. For more on open relays, please see the Open Relay Database.

+ + + +

You need to do one of two things: +

    +
  1. Update your domain's DNS entries so there are MX records that point to the machine that is running James. Note that it is illegal for MX records to point to IP addresses. You need to point MX records to a valid CNAME or A name entry, and then map that eventually to an IP address.
    2. +
  2. You could alternatively give people an email address with IP addresses. Most people will think it's a very strange email address, but hello@[192.168.0.1] is a valid email address. Note that you need to wrap the IP address in brackets.
    3. +
+

+ + + +

First step is to look in the log directory at the mailet.log file. Look for entries that include the text "RemoteDelivery". This should provide some high-level debug information of James' attempt to delivery mail remotely.

+

If you want to delve into the code, look at the RemoteDelivery mailet. You may also want to review the mail repository source code for the repository type you are using (file, db, etc...).

+ + + +

IMAP development had been stalled, but has recently attracted new activity. IMAP support is scheduled for inclusion in James v3. In the meantime, there is experimental code in the repository. If you are interested in working on or trying the IMAP prototype code, join the james-dev mailing list and let us know.

+ + + +

James v2.1 includes a new mailet for database users, JDBCVirtualUserTable, that mimics some of the sendmail capabilities of the same name.

+

JDBCVirtualUserTable does not provide any administation tools. +You'll have to create and maintain the database table yourself. The +standard configuration is as follows:

+ +CREATE TABLE VirtualUserTable +( + user varchar(64) NOT NULL default '', + domain varchar(255) NOT NULL default '', + target_address varchar(255) NOT NULL default '', + PRIMARY KEY (user,domain) +); + +

The standard query used with VirtualUserTable is:

+ +select VirtualUserTable.target_address from VirtualUserTable, VirtualUserTable as VUTDomains +where (VirtualUserTable.user like ? or VirtualUserTable.user like "\%") +and (VirtualUserTable.domain like ? +or (VirtualUserTable.domain like "\%" and VUTDomains.domain like ?)) +order by concat(VirtualUserTable.user,'@',VirtualUserTable.domain) desc limit 1 + +

For a given [user, domain, domain] used with the query, this will +match as follows (in precedence order): +

    +
  1. user@domain - explicit mapping for user@domain
    2. +
  2. user@% - catchall mapping for user anywhere
    3. +
  3. %@domain - catchall mapping for anyone at domain
    4. +
  4. null - no valid mapping
    5. +
+

+

A sample mailet looks like:

+ +<mailet match="All" class="JDBCVirtualUserTable"> + <table>db://maildb/VirtualUserTable</table> +</mailet> + +

More generalized viirtual hosting is something the developers are still discussing. One issue is that POP3 does not support virtual hosting in that it does not have a command to indicate what domain the user is in. What this means is the mail server needs to support a 'mapping' or 'translation' convention, e.g., 'user1@domaina.com' gets a username 'domaina.user1'. This allows the mail server to have a single username namespace. We have seen a few good proposals put forward, but nothing that seemed the clear solution, as ideally we could have this part solve the next issue.

+

Beyond that, James needs to refine virtual hosting for mailet processing. With the current user model, the mailet API has a Mail.getUser() method that no longer would be useable as a reliable indicator of whether they were in the local username namespace. To date we are unclear of the best way to bring this translation into the mailet processing. Similarly, it would be nice to support different mailet processing based on the domain, although this is somewhat feasible using the limited processing flow offered with a HostIs matcher.

+

Virtual hosting is one of the most requested features, and additional work is scheduled for the 3.0 release.

+ + + +

We are largely reliant on what Avalon is doing in terms of classloading, but here are a few tips and suggestions: +

+ Eventually we hope to support mailet reloading and a special lib and classes directory within the james directory that custom mailets can load from, but for now these are hopefully some useful tips.

+ + + +

+

    +
  1. Rename the previous james directory into a james.old
    2. +
  2. Run phoenix to let the new james.sar be deployed.
    3. +
  3. Edit the newly deployed config.xml to reflect your customizations from the previous config.xml.
    4. +
  4. If using JDBC, see necessary table changes. +
    5. +
  5. Replace the var directory by the previous var directory. This will copy over user accounts, inboxes, spools, and whatever else.
    6. +
  6. Restart James.
    7. +
+

+ + + +

The version of Avalon Phoenix distributed with James v2.1 and later includes a wrapper that lets you run James as a service. An alternative strategy is to install the JavaService from Alexandia Software.

+ + + +

Check the JavaMail docs. Per the API, when you call MimeMessage.setContent(blah), you have to call saveChanges() to apply your changes. James tries to automatically call this method so you don't have to, but in certain cases you'll still have to call saveChanges().

+ + + +

The following information is based on James 2.0a3, but the + upcoming 2.1 version should be similar.

+

NNTP and other underlying services are called "blocks" in the + Avalon Phoenix terminology. Blocks are specified in the + assembly.xml file which is located in the apps/james/SAR-INF directory (2.1) + or apps/james/conf directory (2.0a3). Note: this file is created + during the first startup of James.

+

There are dependencies between the blocks, which you can read from + the file. For example the SMTP Server block depends on the + users-store block, so if you want SMTP then you cannot remove the + users-store block even if you only want to relay messages.

+

To remove the NNTP Server comment out the following blocks: + NNTP server, NNTP Authentication Service, NNTP repository. + To remove the POP3 Server comment out the POP3 Server block.

+

If you remove a block it wont't be loaded next time you restart + James. You must also remove all sections related to the removed + blocks from the James configuration file - config.xml - otherwise + you will get error messages, saying that there is no corresponding + block.

+ + + +

Read the "Contributors How To" here +

+ + + +

Read the "sendmail How To" here +

+ + + +

I am using Microsoft's SQL Type 4 JDBC Driver, why do I get the following exception?
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Can't start manual transaction mode because there are cloned connections.

+

This seems to be a problem with the Microsoft Type 4 JDBC Driver and concurrent statements/transactions/resultsets on the same database conntection.

+

To solve this you need to add ;SelectMethod=cursor to the end of your dburl string. Your dburl string would then look something like this
<dburl>jdbc:microsoft:sqlserver://dbserver.host.name:1433;SelectMethod=cursor</dburl>

+

NOTE: some people have complained about performance when using this option, the alternative is a 3rd party JDBC driver but these are often not free.

+ + + +

When a user tries to send a large message that is close to but not quite at the max message limit the send fails and an exception similar to the following appears in the log:

+

Sent: 451 Error processing message:
+ Exception spooling message: Exception caught while storing mail Container:
+ java.lang.IllegalArgumentException: Packet is larger than max_allowed_packet
+ from server configuration of 4193280 bytes;
+ nested exception is:
+ java.lang.RuntimeException: Exception caught while storing mail
+ Container: java.lang.IllegalArgumentException: Packet is larger than
+ max_allowed_packet from server configuration of 4193280 bytes
+

+

Because of how the JDBC driver is written, a 25% + factor is necessary between the maximum message size and the max_packet_size + to prevent the driver from throwing an exception. So if you want a 4MB + maximum message size, you need a 5MB max_packet size. Or a 4MB + max_packet_size allows only a 3.2MB max message. +

+ + + +

First of all read this: ASF Source Code. +
Now go to http://subversion.tigris.org/ and download a subversion client. +
James subversion repository is at http://svn.apache.org/repos/asf/james/server. Commiters use "https". +
You may want to search the web, our dev and user mail archives or our wiki for more information.

+ +
+ + diff --git a/server/src/site/xdoc/archive/announcement_2_1.xml b/server/src/site/xdoc/archive/announcement_2_1.xml new file mode 100755 index 00000000000..9c94d0384bb --- /dev/null +++ b/server/src/site/xdoc/archive/announcement_2_1.xml @@ -0,0 +1,57 @@ + + + + + James 2.1 - Release Announcement + + +
+

The Java Apache Mail Enterprise Server (a.k.a. Apache James) Project is happy to announce the release +of version 2.1 of the Apache James server.

+ +

James is a 100% pure Java Mail and News server designed to be a complete and portable enterprise +mail engine solution. James supports currently available IETF protocols, including SMTP and POP3 +(NNTP is experimental in v2.1, and it and IMAP are targeted for full functionality in v3). James +is able to store user and message data either in a file-system or a JDBC-compatible database, +allowing fast, reliable, even real-time replicated storage.

+ +

James provides a powerful, flexible mail application engine through support for the Apache Mailet +API. With its Mailet pipeline architecture, James can be used not only to provide standard e-mail +services, but also to implement custom e-mail applications.

+ +

The James mail server is deployed in production environments and has proven itself to be a robust +and high performance mail solution. Tests indicate that version 2.1 is able to maintain a constant +mail throughput rate of thousands of messages/minute for continuous periods.

+ +

The James Community is also happy to announce the beginning of the design phase for James version +3.0. Features tentatively slated for that version include enhancements to nearly every area of +functionality, including full IMAP support, improved mailing list capabilities, and the next revision +of the Mailet API. This is expected to be an exciting time in James development. We are actively +looking for eager, capable developers to contribute to James. If you're interesting in contributing +to the James project, please subscribe to the James developer mailing list.

+ +

Information about James can be found at the James web site +at http://james.apache.org/. Users interested in subscribing to the James +user and +developer mailings lists should send emails +to server-user-subscribe@james.apache.org and server-dev-subscribe@james.apache.org, respectively

+
+ + diff --git a/server/src/site/xdoc/archive/architecture_v1_2.xml b/server/src/site/xdoc/archive/architecture_v1_2.xml new file mode 100644 index 00000000000..42e1bbf1f1f --- /dev/null +++ b/server/src/site/xdoc/archive/architecture_v1_2.xml @@ -0,0 +1,51 @@ + + + + + + James 1.2 - Architecture + + + +
+ +

+ JAMES is a multi-protocol message processing and storage engine. JAMES + currently consists of: +

+
    +
  • two mail prototcol servers (SMTP and POP3),
    • +
  • a remote administration server,
    • +
  • a mail processing engine that supports the Mailet API
    • +
  • file-system message storage and a message storage interface to RDBMS's
    • +
  • file-system user record storage and an experimental interface to LDAP directories
    • +
  • beta support for TLS (SSL) for POP3 and remote administration
    • +
+

+ JAMES is built on top of Avalon, the Java Apache Server Framework. + Versions 1.1 and 1.2 of James use a slightly older version of Avalon, + specifically the avalon-james-1-1b1 branch. We intend to + migrate to the new Avalon in the near future. +

+ +
+ + + diff --git a/server/src/site/xdoc/archive/architecture_v2_0.xml b/server/src/site/xdoc/archive/architecture_v2_0.xml new file mode 100644 index 00000000000..a47c631ef61 --- /dev/null +++ b/server/src/site/xdoc/archive/architecture_v2_0.xml @@ -0,0 +1,55 @@ + + + + + + Notes for developers + Serge Knystautas + + + + +
+ +

+ James is a multi-protocol message processing and storage engine. James + currently consists of: +

    +
  • two mail prototcol servers (SMTP and POP3),
    • +
  • a remote administration server,
    • +
  • an NNTP server,
    • +
  • a mail processing engine that supports the Mailet API
    • +
  • file-system message storage and a message storage interface to RDBMS's
    • +
  • file-system user record storage and an experimental interface to LDAP directories
    • +
  • support for TLS (SSL) for POP3 and remote administration
    • +
  • support for SMTP auth
    • +
+

+ +

+ James is built on top of Avalon, the Java Apache Server Framework. + Versions 2.0 of James use a date-snapshot of Avalon code as of November 2001. + The lib directory includes date-stamped jars of the various Avalon libraries. + We intend to stay current with new versions of Avalon as they are released.

+ +
+ + + diff --git a/server/src/site/xdoc/archive/configuration_v2_0.xml b/server/src/site/xdoc/archive/configuration_v2_0.xml new file mode 100644 index 00000000000..7020fabc809 --- /dev/null +++ b/server/src/site/xdoc/archive/configuration_v2_0.xml @@ -0,0 +1,716 @@ + + + + + + Configuration + Serge Knystautas + + + + +
+ +

+

+

This document explains the JAMES.conf.xml file for James 2.0 +
JAMES 2.0 uses a date-stamped version of Avalon from late September 2001. + The lib directory includes jars with date-stamped names for the Avalon libraries. +
+

+
+

+ +
+ +
+ +

+ These tag elements control the JAMES spooling and identification + settings. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
<name>default valuemeaning
postmaster Postmaster@localhost Is the source of error replies and the email users will mail to for any problem. You + should change this to an address that can receive incoming messages.
helloName attribute autodetect=TRUE and value of 'myMailServer' The name by which James will identify itself in SMTP and POP3 + greetings. If autodetect is TRUE James will attempt to detect + automatically the name, failing which it will use 'localhost'. If + autodetect is not TRUE, James will use the specified name or + 'localhost' if none is specified. Look in jamesinfo.log for + lines like "[...] Local host is: [servername] and [...] Hello Name is: [machine name]"
servernames/servername attribute autodetect=TRUE and last value of 'localhost' A list of host names James will consider as local. Any user [user]@[servername] + will be considered to be local. If autodetect is TRUE James will attempt to detect + automatically the name and use any names specified. Look in jamesinfo.log for a line like "[...] Handling mail for:: [domain/host]"
spoolRepository file://var/mail/spool/ This is the path where incoming messages are stored before beeing processed.
inboxRepository file://var/mail/localinbox/ This is the root for local users inbox. Each user will have a personal folder + [inboxRepository]/[user]
spoolmanagerthreads 5 This is the number of thread that work polling mails from the spool and take care + of processing them.
+ + + +

+ These tag elements affect the SMTP listener (for incoming messages). +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
<name>default valuemeaning
port 25 The port we are listening to.
bind N.A. Specific IP addresses that you wish to bind this service to.
smtphandler N.A. Parent for all SMTPHandler configuations.
connectiontimeout 120000 If nothing is received from an open connection for more than {timeout] mills + the connection is closed.
+ + + +

+ These tag elements affect the POP3 server (for message retrieval) +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
<name>default valuemeaning
port 110 The port we are listening to.
bind N.A. Specific IP addresses that you wish to bind this service to.
useTLS false Whether you wish to require/use TLS (SSL) on this port.
pop3handler N.A. Parent for all POP3Handler configuations.
connectiontimeout 120000 If nothing is received from an open connection for more than {timeout] mills + the connection is closed.
+ + + +

+ These tag elements affect the configuration of the list of local users. +

+ + + + + + + + + + + +
<name>default valuemeaning
repository file://var/users/ The path where local mail account informations are stored.
+ + + +

+ These tag elements affect the remote manager, a telnet based utility + to manage the User Manager. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
<name>default valuemeaning
port 4555 The port we are listening to.
bind N.A. Specific IP addresses that you wish to bind this service to.
useTLS false Whether you wish to require/use TLS (SSL) on this port.
administrator_accounts N.A. The parent of <account>
account login="root" password="root" A list of root account to administer JAMES.
connectiontimeout 120000 If nothing is received from an open connection for more than {timeout] mills
+ + + +

+ These tag elements affect SMTP remote delivery, specifically, DNS + lookup functionality. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
<name>default valuemeaning
dnsServer/servers/server N.A. This is a list of DNS to resolve external address.
authoritative false Whether to require authoritative (non-cached) DNS records. Should always be false + unless you understand the implications.
repository file://var/mail/delayed/ This is a temp repository path shared with the name of "TMP_REPOSITORY". + It is used by the RemoteDelivery Mailet to store mail for futher delivery. + (Note: this is not very elegant and will probally change soon)
mailets rootpath="org.apache.james.transport.mailets." This is the parent node for all mailet configurations. The rootpath specify + where mailet repository is. (Note: need to plug more than one repository)
+ +
+ +
+

+ This is James sitemap. It defines how each incoming mail will be + processed. Incoming mails begins their process at the first mailet in the + pipe. Each step is described by a <servet> tag with some attributes: + <mailet match="[matchClass]=[matchParameters]" + class="[mailetClass]">. + The Matcher class split the mail into two Collections: one with all recipients + matching conditions and the other with all recipient not matching. All information + in the mail except recipients cloned so the message that both matching and not matching + are identical (again except recipients). The matching recipients and mail will be passed to + the specified mailet for processing. After processing both mails, the + untouched not-matching mail and the processed matching mail, each go to next step in + the processor. Some mailets will indicate the mail should be consumed and no continue processing. + The Null mailet for example will simply consume any incoming mail as will the RemoteDelivery + since after delivery the mail needs no more processing. +

+ + +

+ The Matcher interface defines how match class should work. Their work is + to split a Vector of recipients into two: the ones matching a specified + condition and all others. + Currently implemented matchers: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
class nameparameteractionexample
All none match all recipients. match="All"
HasAttachment none match all recipients if the message has an attachment (if content type is multipart/mixed). match="All"
HostIs comma separated list of hosts names match all recipients belonging to one of the specified hosts match="HostIs=myHost.mydom.org,yourHost"
HostIsLocal none check recipients's hosts against the list of host names set in configuration for localhost + (see <servername>). match="HostIsLocal"
InSpammerBlacklist DNS zone with blacklist match all recipients if mail received from an IP address on the blacklist. match="InSpammerBlacklist=blackholes.mail-abuse.org"
IsSingleRecipient none match mail if only has 1 recipient. match="IsSingleRecipient"
NESSpamCheck none match all recipients if mail matches various spam detection rules. match="NESSpamCheck"
RecipientIs comma separated list of recipients match all recipients defined in condition. match="RecipientIs=root@localhost,admin@localhost"
RecipientIsLocal none match recipient which host is local (see HostIsLocal) and that are recognized by the + Users Manager to be local accounts. match="RecipientIsLocal"
RelayLimit Maximum number of hops. match all recipients if the message has more than the specified number of SMTP hops. + Important to prevent race conditions in SMTP delivery. + match="RelayLimit=30"
RemoteAddrInNetwork comma separated list of network addresses match all recipients if the message was received from an IP address that matches the + comma separated list. Wildcards are supposed, e.g., 192.168.0.* is a valid option. + match="RemoteAddrInNetwork=127.0.0.1,192.168.*"
RemoteAddrNotInNetwork comma separated list of network addresses match all recipients if the message was not received from an IP address that matches + the comma separated list. Wildcards are supposed, e.g., 192.168.0.* is a valid option. + match="RemoteAddrNotInNetwork=127.0.0.1,192.168.*"
SenderInFakeDomain none match recipients who's domain name portion of their email address is invalid. Queries + for A, CNAME, and MX record entries. match="SenderInFakeDomain"
SenderIs comma separated list of address. match all recipients if sender is in the condition string, else match none. match="SenderIs=badBay@badhost"
SizeGreaterThan number of bytes. supports 'k' and 'm' suffixes. match all recipients if message is larger than the given number of bytes, kilobytes, or megabytes. match="SizeGreaterThan=1m"
SubjectIs comma separated list of address. match all recipients if the subject is equal to the condition string, else match none. match="SubjectIs=REMOVE"
SubjectStartsWith comma separated list of address. match all recipients if the subject starts with the condition string, else match none. match="SubjectStartsWith: [ADV]"
UserIs comma separated list of accounts match all recipients defined in condition regardless of host. match="UserIs=root,admin"
+

+ Some examples: +
+ - <mailet match="RecipientIsLocal" + class="LocalDelivery"> +
+
+ - <mailet match="UserIs=root" + class="Forward"> +
+
+ - <mailet match="SenderIs=badBoy@myhost,badGirl@yourhost" + class="Null"> +
+

+ + + +

+ Mailet are classes that process a message. They are + passed a Mail object on which they can perform any kind of task. + Clever use of mailets allow you to write an email-based application. + Simple mailets provide basic mail functionality like mail forwarding, + mailing list, "I'm on vacation" message, mail logging etc. As simply as + these mailet, you can write and deploy your own mailet to perform any kind of task. +
+ Here you are some of the mailets bundled with James along with their configuration: +
+

+ Null +
+ Consume any incoming mail. No configuration needed. +
+ <mailet match="SenderIs=badBoy@badhost" class="Null"> + </mailet> +
+
+ debug.Identity +
+ Leave any incoming mail untouched. A debug mailet + (not really useful). + No configuration needed. +
+ <mailet match="All" class="Identity"> + </mailet>
+
+ Forward +
+
+ Replace the recipient list with recipient specified in + configurations.
+
+ <mailet match="RecipientIs=root@localhost" + class="Forward">
+
+
+ <forwardto> green@blue.org </forwardto> + <forwardto> red@yellow.com </forwardto> +
+
+ </mailet> +
+ + ToProcessor +
+ Sends the incoming mail object to a new processor pipeline. + root and error are special processors that + should always be defined. +
+ <mailet match="RecipientIsLocal" class="ToProcessor"> +
+
+ <processor> localdelivery </processor> +
+ </mailet> +
+ + ServerTime +
+ Replies to the sender with a short message with the current time. + No configuration needed. +
+ <mailet match="RecipientIs=time@localhost" class="ServerTime"> +
+ </mailet> +
+ + ToRepository +
+ Stores mails in the specified MailRepository. Useful for mail logging + etc. If the passThrough parameter is false the mail will be consumed, if true + it will be returned untouched to the pipe. +
+ <mailet match="RecipientIs=root@localhost" + class="ToRepository"> +
+
+
+ <repositoryPath> file://var/mail/logAdmin + </repositoryPath> +
+
+ <passThrough> true </passThrough> (default false) +
+
+ </mailet> +
+ + LocalDelivery +
+ Store mail in the local inbox, one folder for each user. +
+ <mailet match="RecipientIsLocal" class="LocalDelivery"> +
+ </mailet> +
+ + RemoteDelivery + + Relays mails to remote hosts. "delayTime" is the time in mills the + mailet will wait before retrying sending a mail which fail at first time. "maxRetries" + is the number of retries before sending back to sender the mail.
+ <mailet match="!RecipientIsLocal" class="RemoteDelivery"> +
+
+
+ <delayTime> 21600000 </delayTime> +
+
+ <maxRetries> 5 </maxRetries> +
+
+ +

</mailet>

+ + Redirect +
A mailet providing configurable redirection services

+ This mailet can produce listserver, forward and notify behaviour, with the + original message intact, attached, appended or left out altogether.

+ This built in functionality is controlled by the configuration as laid out + below.
+
+

However it is also designed to be easily subclassed to make authoring redirection + mailets simple.

+ By extending it and overriding one or more of its methods new behaviour can + be quickly created without the author having to address any other issue than + the relevant one. For more information see the javadocs

+

The configuration parameters are:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
paramdesc
<recipients>A comma delimited list of email addresses for recipients of this message, + it will use the "to" list if not specified. These addresses + will only appear in the To: header if no "to" list is supplied.
<to>A comma delimited list of addresses to appear in the To: header, the + email will only be delivered to these addresses if they are in the recipients + list.
+
+ The recipients list will be used if this is not supplied
<sender>A single email address to appear in the From: header
+
+ It can include constants "sender" and "postmaster"
<message>A text message to be the body of the email. Can be omitted.
<inline> +

One of the following items:

+
    +
  • unaltered The original message is the new + message, for forwarding/aliasing
    • +
  • heads The + headers of the original message are appended to the message
    • +
  • body The + body of the original is appended to the new message
    • +
  • all Both + headers and body are appended
    • +
  • none Neither + body nor headers are appended
    • +
+
<attachment> +

One of the following items:

+
    +
  • heads The headers of the original + are attached as text
    • +
  • body The body of the original + is attached as text
    • +
  • all Both + headers and body are attached as a single text file
    • +
  • none Nothing is attached
    • +
  • message The original message is attached as type message/rfc822, + this means that it can, in many cases, be opened, resent, fw'd, replied + to etc by email client software.
    • +
+
<passThrough>TRUE or FALSE, if true the original message continues in the mailet + processor after this mailet is finished. False causes the original to + be stopped.
<attachError>TRUE or FALSE, if true any error message available to the mailet is + appended to the message body (except in the case of inline == unaltered)
<replyto>A single email address to appear in the Rely-To: header, can also be + "sender" or "postmaster", this header is not set if + this is omited.
<prefix>An optional subject prefix prepended to the original message subject, + for example..
+
+ Undeliverable mail:
<static> +

TRUE or FALSE, if this is true it hints to the mailet that none of + the parameters are set dynamically, and therefore they can be set once + in the init method.

+ False tells the mailet to call all the "getters" for every + mail processed.

+

This defaults to false.

+ It should be TRUE in all cases, except where one of the getter methods + has been overriden to provide dynamic values, such as a listserve which + might override getRecipients() to get a list from a users repository.

+
+ +
+

Example, creates a distribution list:

+

<mailet match="RecipientIs=test@localhost" class="Redirect">

+ <recipients>x@localhost, y@localhost, z@localhost</recipients>

+ <to>list@localhost</to>

+ <sender>owner@localhost</sender>

+ <message>sent on from James</message>

+ <inline>unaltered</inline>

+ <passThrough>FALSE</passThrough>

+ <replyto>postmaster</replyto>

+ <prefix>[test mailing]</prefix>

+ <static>TRUE</static>

+ <passThrough>FALSE</passThrough>

+ </mailet>

+

+ +
+ +

and this sends a spam notification to the postmaster

with the original message + attached as a message, and a subject prefix:

+

<mailet match="All" class="Redirect">

+ <recipients>x@localhost</recipients>

+ <sender>postmaster</sender>

+ <message>Message marked as spam:

+ </message>

+ <inline>heads</inline>

+ <attachment>message</attachment>

+ <passThrough>FALSE</passThrough>

+ <attachError>TRUE</attachError>

+ <replyto>postmaster</replyto>

+ <prefix>[spam notification]</prefix>

+ <static>TRUE</static>

+ <passThrough>FALSE</passThrough>

+ </mailet>

+
+ +
+ + + diff --git a/server/src/site/xdoc/archive/document_archive.xml b/server/src/site/xdoc/archive/document_archive.xml new file mode 100644 index 00000000000..7fa00ab636a --- /dev/null +++ b/server/src/site/xdoc/archive/document_archive.xml @@ -0,0 +1,54 @@ + + + + + + James Document Archive - Table of Contents + + + +
+ +

The Java Apache Mail Enterprise Server (a.k.a. Apache James) is a +100% pure Java SMTP and POP3 Mail server and NNTP News server designed +to be a complete and portable enterprise mail engine solution. James +is based on currently available open protocols.

+ +

The documentation for obsolete versions of James is preserved here +for users who still have need of it. The James project urges all +users to upgrade to the current Release Build of James.

+ + +

+

+

+ +
+ + diff --git a/server/src/site/xdoc/archive/install.xml b/server/src/site/xdoc/archive/install.xml new file mode 100644 index 00000000000..0aeddbf1170 --- /dev/null +++ b/server/src/site/xdoc/archive/install.xml @@ -0,0 +1,113 @@ + + + + + + Installation +Serge Knystautas +
+

If you have downloaded a binary distribution, you do not need to build James. + Proceed directory to Step 1.

+

To compile James from the source code you need Ant. + This is a Java-tailored, XML-configured, extensible build or make system. We + are currently using Ant 1.4, which is included in the source distribution.

+

If you have downloaded a daily snapshot, you need to build a distribution. + James includes Ant to compile and package its distribution. Extract the snapshot + to your favorite directory, cd to that directory and run the build by calling "build" + or "./build.sh" which will create an unpacked binary distribution + in the dist directory, but no archives.

+

This "./dist" directory is the distribution directory used in Step 1 and beyond. + You may either cd to ./dist, or you may copy and rename the dist directory to your + installation directory.

+

If you prefer you can run build with the "dist" task "build dist" + (or "./build.sh dist"). This will create the distribution in the "./dist" + directory as well as create .tgz and .zip copies of this directory, however it may + require other resources to build the documentation.

+

Warning! Any changes you've made in the 'dist' directory + will be lost after a recompilation. If you are making changes to the conf.xml + or other files, we recommend you backup and then change the copies in src to + avoid losing work.

+
+

Download distibution. Extract or copy all the files in the archive or dist + directory intto your installation directory.

+
+ +
+

+ Read the short and snappy documentation at docs/index.html for a proper + overview of configuring the system. +

+

+ Summary (for impatient people) +

+ +

M$ users should just run /bin/run.bat. Unix users will find run.sh under the + same directory. A JVM must be present and its location specified in the JAVA_HOME + environment variable. Set this on windows at the command prompt with something + similar to "set JAVA_HOME=\jdk1.3\bin" on *nix with JAVA_HOME=/jdk1.3/

+

Running [run* --help] will provide a simple command line help.

+

+ Most UNIX systems require superuser privileges to open sockets below 1024, + which includes the IANA-standard SMTP (on port 25) and POP3 (on port 110). + These default ports can be changed in the conf.xml file. (Obviously, you + would then need to reconfigure your clients. This may not be an option if + you want to receive mail from external mailservers.) +

+ +

The Avalon framework will unpack the necessary configuration files you will + need to start the server. Wait until it is running, stop it again (ctrl-c), and + edit the configuration (thereafter *nix users can run the server in the background + using ./run.sh &). For basic use, you only need to set two items in the + JAMES.conf.xml file: a root password for the remote administration facility + and the IP address of a DNS server. Once you have edited the configuration files, + press 'Enter' on the terminal where Avalon is waiting.

+
+ +
+

+ Once started you'll see a message saying Avalon is running. This means that + Avalon has loaded JAMES and every other needed Block (see /logs/avalon.log) + and is now waiting for a socket request. + Since at the beginning James is empty, it will not have any local users + registered. + To register a local user open a telnet session with localhost on port 4555, + log in as root ("root[enter] <password-you-set-in-conf.xml>[enter]") and + type "help" for a list of available commands in the "JAMES remote + administrator tool". It is really a basic set but should allow you to test + installation. +

+

+ Once you have some local users registered, try sending mail to one of them + @localhost with SMTP (port 25) (assuming you have not changed the default + server names in the conf.xml file). You'll see the mail appear under + ../var/mail/localinbox/[user]. + Try now to retrieve that mail using POP3 (port 110). + Trace out JAMES actions in /logs/*info.log. + Actions that will be taken by JAMES on incoming mail are configured in + the mailet pipe line (/conf/JAMES.conf.xml). Look at it if you want to + understand what's happening. +

+

+ Good luck :) +

+
+ + + diff --git a/server/src/site/xdoc/archive/usingJDBC_v2.0.xml b/server/src/site/xdoc/archive/usingJDBC_v2.0.xml new file mode 100644 index 00000000000..541c85f3bea --- /dev/null +++ b/server/src/site/xdoc/archive/usingJDBC_v2.0.xml @@ -0,0 +1,174 @@ + + + + + + Using JDBC + Charles Benett + + + + +
+ +

+ This document explains how to enable JAMES 2.0 to use database storage via JDBC. Based on ReadMe notes by Darrell DeBoer and ??. +

+
+ +
+ +

Main Goals. +

    +
  • use Avalon and Cornerstone DataSource components for connection serving and pooling (done)
    • +
  • Remove hard-coded SQL statements from UsersJdbcRepository (done)
    • +
  • 'SqlResources.java' - detect db product from jdbc connection and select appropriate SQL statements from SQL definition file for specific product (done)
    • +
  • Simpler to create database-backed UserRepository implementations for different User implementations (done)
    • +
  • Simplify UserRepository specification in config - make it URL:// based, like MailRepository. (done)
    • +
  • Consolidate existing UserRepository implementations - refactor out common functionality (TODO)
    • +
  • Have UserStore serve up repository implementations based on: storage, User implementation, and location. (TODO)
    • +
+

+

Other Goals (reuse development in JdbcMailRepository): +

    +
  • use Avalon and Cornerstone DataSource components in JdbcMailRepository (done)
    • +
  • Use SqlResources.java to provide db-specific SQL to JdbcMailRepository (done)
    • +
  • Automatic table generation for JdbcMailRepository (done)
    • +
  • Get rid of the separate database .properties files. (done)
    • +
+

+ +
+ +
+ +

+ The main configuration is setting up the "database-connections" section of the +config file. There's an example there using MySql - I haven't yet tested on +other databases (although the SQL statements haven't changed much, so I +imagine it will still work on other platforms). +

+

+The only config properties you should need to set are: +

    +
  • <driver> Class name of database driver to use </driver>
    • +
  • <dburl> the jdbc connection string for your database </dburl>
    • +
  • <user> database user </user>
    • +
  • <password> database password </password>
    • +
+

+
+ +
+

+

    +
  • Telnet to the remote manager: "telnet localhost 4555".
    • +
  • Do some user management - type "help" for options.
    • +
  • type "use list-james", to switch to the repository for this list.
    • +
  • list the users
    • +
  • send an email to "james-on@localhost"
    • +
  • list the users again
    • +
+(note: some user management commands fail for repositories other than "LocalUsers"). +

+ +
+ +
+

+Mail repositories are now configured primarily by their "destinationURL" +property. This has the format "db://datasource/table[/repository]". Other +config such as the "sqlFile" (where to find sqlResources.xml, and the "filestore" +for mixed storage, can also be included, or can be left to defaults (see below). +

+

+Each repository registered in the MailStore can now take a "config" section, +which is the default configuration used by the MailStore when creating a repository +of that class. This allows us to have a configurable JDBCMailRepository, without +needing to specify config everywhere it's used. I've set up the SPOOL repository +to use mixed storage (a filestore in addition to the database), but the MAIL +repository to use pure db storage. +

+

+The new config has been tested with "inbox" and "spool" repositories, but it's not +yet tested with the "error", "spam" and "outgoing" repositories. +

+

+The statements in the SqlResources.xml file have been tested on MySQL and M$SQL. +Only M$ has the optimised "getMessageSize" SQL, but this is optional. +

+

+You no longer have to manually create the tables required - this is automatic. +Create Table statements are included for M$SQL and MySQL; we'll need to add others +for other db products. +

+ +
+ +
+

+I've added an "AbstractJdbcUsersRepository", which takes care of most of the work +of a JdbcUsersRepository, making it pretty easy to add new ones. The abstract +implementation doesn't have knowledge of User implementations, this is restricted to +overridden methods in concrete UsersRepository implementations. +

+

+The AbstractJdbcUsersRepository obtains SQL statements via an "SqlResources" object, +which reads an sql definition file, finds the appropriate <sqlDefs> element, and +provides the sql strings contained. In addition, the SqlResources class handles +2 other things: +

    +
  • + a) Parameter replacement in SQL (eg replace all occurances of ${table} within + an sql statement with the parameter value for "table". Currently, all + parameters are taken from the configuration <sqlParameters> element. It + is also possible to define parameters (defaults, if you like) within the + sql definition file itself (a <parameters> element).
    • +
  • b) Examines the Jdbc Connection to determine what database product is being + used. SQL statements specific to a db product (eg mysql) can then be used + automatically. (Detection is done by regexp matches on + Connection.getMetaData.getDatabaseProductName())
    • +
+I've added 3 concrete subclasses of AbstractJdbcUserRepository: for DefaultUser, +DefaultJamesUser, and "ListUser" (which for now is nothing more than a name). These +give an example of how little work there is to implement a new repository. The +ListUsersJdbcRepository can store multiple lists of names in a single table. +

+

+I've made a simple modification to "RemoteManagerHandler", to allow testing. The +"use [userRepositoryName]" command will switch the Remote manager to manage the +named repository. This isn't really intended for production, makes for easier testing. +The "james-config.xml" included in the proposal sets up 4 JDBC repositories: +

    +
  • "localUsers" - a JamesUsersJdbcRepository.
    • +
  • "list-james" - a ListUsersJdbcRepository, used by the ListServ mailet.
    • +
  • "list-test" - another ListUsersJdbcRepositor, for testing.
    • +
  • "default-users" - a DefaultUsersJdbcRepository, for testing.
    • +
+

+

+Note that in order for the Avalon DataSource components to work, I've included +an upgraded "avalon-excalibur.jar" in the proposal. + +

+ +
+ + diff --git a/server/src/site/xdoc/archive/usingLDAP_v1_2.xml b/server/src/site/xdoc/archive/usingLDAP_v1_2.xml new file mode 100644 index 00000000000..6f57bf2f933 --- /dev/null +++ b/server/src/site/xdoc/archive/usingLDAP_v1_2.xml @@ -0,0 +1,185 @@ + + + + + + Using LDAP + Charles Benett + + + + +
+ +

+ This document explains how to enable JAMES to use an LDAP directory as a + Users Repository. +

+
+ +
+ +

+ We have tried to make the LDAP implementation of UsersRepository as + flexible a possible, recognising that each installation will have a unique + directory schema. +
We assume that all users that a James Mailserver will handle fall + within one single-rooted tree. The root of this tree, ie the lowest node + in the directory which is an ancestor for all users served by this + mailserver and the mailserver, is called the LDAPRoot. (See diagram) +
+
It is entirely possible that an organization may have more than one + mail server. Consequently, the fact that a user is in the Directory does + not imply that this mailserver should handle mail for them. +
+
This implementation of UsersRepository creates one node (object) for + each set of mail users. The set called 'LocalUsers' is the set of users + whose mail is handled by this server. Other sets include any mail-lists + handled by the server. Each member of a set is recorded as an attribute + of these objects. These nodes are child nodes of the mailserver. +
+
The mailserver will accept mail for local delivery if the user part of + the email address matches a member of LocalUsers and if the domain/host + part of the email address matches the first servername . + (Set servernames autodetect to false and enter the domain served as the + first servername, e.g. apache.org). +
+
For POP3 authentication, the mailserver first finds the user entry in + the directory, underLDAPRoot, whose attribute, specified as + MailAttribute in conf, matches user@domain. The mailserver authenticates + the POP3 user if it can bind to the directory as that user entry with + the offered password. +
+
+ This implementation does not set passwords in the directory. Use a dummy + password when invoking adduser in RemoteManger. +
+
+ If ManageGroupAttribute is set to TRUE (as it is by default), then the + RemoteManger will add/remove the full DN of the email group to/from the + user entry. This facilty allows users to ask the directory what is my + mailserver and what email lists am I subscribed to? +
+ +

+ + + + + + + + + + + + + + + + + + + + + +
Root of Directory +
Example: dc=org
+
May not be referenced in conf.xml
+
|
+
|
+
-------------------------------------------------------------------------------------------------
| +
Subtree not served by James
+
e.g.: dc=w3c, dc=org
+ 		| +
Subtree served by James
+
e.g.: dc=apache, dc=org
+
"LDAPRoot"
+
|
+ 		| +
Subtree not served by James
+
e.g.: dc=xml, dc=org
+
+ + + + + + + + + + + + + + + + +
----------------------------------------------------
| +
This mailserver
+
cn=mailserver.apache.org
+
|
+
---------------
+ 		| +
A user
+
cn=King Arthur
+
memberOfGroup=
+
cn=LocalUsers etc
+ 		| +
A user
+
cn=Morgan LeFay
+ 		| +
Another mailserver
+
cn=oldmail.apache.org
+
+ + + + + +
| +
LocalUsers
+
member=Arthur
+ 		| +
list-james
+
member=Arthur
+
+
+
+
+ +
+ +

+ Six entries in JAMES.conf.xml must be set for this to work: +

    +
  • change usersManager - type to ldap.
    • +
  • Set the ldapServer element to point to the correct host and port
    • +
  • Set LDAPRoot and ThsServerRDN.
    • +
  • Set the direcory FDN and password that should be used to write to the directory.
    • +
  • Unless all your users have email addresses of the form, name@the-machine-running-James, set servernames-autodetect to false and apecify the your email domain as the first servername.
    • +
+

+ +
+ + + diff --git a/server/src/site/xdoc/archive/usingTLS_v1_2.xml b/server/src/site/xdoc/archive/usingTLS_v1_2.xml new file mode 100644 index 00000000000..0e6c13053fc --- /dev/null +++ b/server/src/site/xdoc/archive/usingTLS_v1_2.xml @@ -0,0 +1,96 @@ + + + + + + Using TLS + Charles Benett + + + + +
+ +

+ This document explains how to enable JAMES 1.2.1 to use Transport Layer + Security (TLS) (ie SSL). +

+
+ +
+ +

+ Obtain JSSE source from java.sun.com. Follow their installation directions. + We assume that you install JSSE as a standard extension, with a static + provider definition. (See notes with JSSE distribution) +

+

+ Note that the US export restrictions still apply to JSSE + (at version 1.0.2), so while both the international and domestic versions + offer the same level of crypto, the international version does not take + alternative providers. +

+ +
+ +
+ +

+ Using JAMES with TLS. You need to do three things over and above the + normal operation of James: +

    +
  • In Avalon.conf.xml, uncomment the TLS listener defintion.
    • +
  • In JAMES.conf.xml, uncomment the <useTLS>TRUE</useTLS> element + for the service you want to use TLS. It is currently available for + remote manager and POP3. (If using POP3 over TLS, it is probably best + to change port to 995, which is the IANA designated POP3S port).
    • +
  • Ensure that avalonTestKeys is in the conf directory. You may need + to manually extract this from the Avalon.jar (with: jar xvf Avalon.jar + conf/avalonTestKeys). Note that this is a self-signed certificate for + test purposes only. You can specify a different server certificate in + the Avalon.conf.xml file.
    • +
+

+

+ Start James +

+
+ +
+

+ (Positive Test) Use an SSL client to open a socket to the appropriate port. + I used openssl from www.openssl.org to test this. + E.g. openssl s_client -connect localhost:4555. You should see the normal + remote manager or POP3 server greeting and have normal operation. +
+ - If, using openssl s_client, you get a connection refused/ error no + 111, just try again. This probably means you got to the port before it + was ready. +
+

+

+ (Negative Test) telnet to port 4555 (ie without SSL). This should hang the + telnet client. It should also lock port 4555 until the connection times out, + I think. +

+
+ + + diff --git a/server/src/site/xdoc/design_objectives.xml b/server/src/site/xdoc/design_objectives.xml new file mode 100644 index 00000000000..a373e108d46 --- /dev/null +++ b/server/src/site/xdoc/design_objectives.xml @@ -0,0 +1,122 @@ + + + + + Design Objectives + James Project Web Team + + +
+ + +

These are some of the currently implemented features:

+

+ + Complete portability + Apache James is be a 100% pure Java application + based on the Java 2 platform and the JavaMail 1.3 API. +

+

+ + Protocol abstraction + Unlike other mail engines, protocols are seen only + like "communication languages" ruling comunications between clients and + the server. Apache James is not be tied to any particular protocol but + follow an abstracted server design (like JavaMail did on the + client side)

+

+ + Complete solution + the mail system is able to handle both mail + transport and storage in a single server application. Apache James + works alone without the need for any other server or solution.

+

+ + Mailet support + Apache James supports the Apache Mailet API. A Mailet + is a discrete piece of mail-processing logic which is incorporated into + a Mailet-compliant mail-server's processing. This easy-to-write, + easy-to-use pattern allows developers to build powerful customized mail + systems. Examples of the services a Mailet might provide include: a + mail-to-fax or mail-to-phone transformer, a filter, a language translator, a mailing + list manager, etc. Several Mailets are included in the JAMES + distribution (see documentation).

+

+ + Resource abstraction + Like protocols, resources are abstracted and, + accessed through defined interfaces (JavaMail for transport, JDBC for + spool storage or user accounts in RDBMS's, Apache Mailet API). The server is + highly modular and reuse solutions from other projects.

+

+ + Secure and multi-threaded design + Based on the technology developed + for the Apache JServ servlet engine, Apache James has a careful, + security-oriented, full multi-threaded design, to allow performance, + scalability and mission-critical use.

+

Anything else you may want if you help us write it :-)

+ + +

It is the existence of published "open" standards which +allows independant teams to develop interoperable software. +
James attempts to support a number of these standards most of which are +IETF RFC's and in the areas covered by these standards the published standard +is our requirements document. +
This sometimes leads to confusion where behaviour is not +the subject of a relevant standard, or conflict where common +(de-facto) behaviour is actually at odds with a supported standard. +
We believe that it is our responsibility to adhere to the published standard. +If we allow our implementation to deviate it means that we are tacitly encouraging +the situation whereby interoperability is no longer guarenteed by standards +compliance alone, but also requires access to undocumented and possibly +even commercially licenced technology. There is no easy route for a +newcomer to aquire these secrets, and interoperabilty +becomes something only available to the elite. +

+

The James policy for issues of non-compliance tries to tread the fine line +between a pragmatic acceptance of other people's misinterpretation of the +RFC's and an evangelical defence of open standards as the key to freedom of interoperation. +

+

+In practice this policy is that certain well argued of cases of +non-compliance which can be *safely* worked around, will be tolerated by +James. +

+

+In cases (like jira issue JAMES-344 ) where variance from a published standard is +required it is desirable that this functionality is disabled in James by default, +it must be prominently and clearly documented that this causes James +to violate the relevant standard, and should be enabled by explicit +configuration, making its use a conscious decision of the user rather +than an decision taken by the James team. +

+

+In cases where the required behaviour is not within the scope of any standard which +James claims to support (such as behaviour which is a de-facto standard or +an internet draft RFC but not yet subject of a standards track RFC) it is +acceptable to implement the behaviour so long as it is adequately +documented (for instance by refrence to an internet draft or +other public document) and users can be clear about what to expect from James. +

+ +
+ + diff --git a/server/src/site/xdoc/index.xml b/server/src/site/xdoc/index.xml new file mode 100644 index 00000000000..fc3b5e8693b --- /dev/null +++ b/server/src/site/xdoc/index.xml @@ -0,0 +1,131 @@ + + + + + Overview + James Project Web Team + + +
+

The Apache Java Enterprise Mail Server (a.k.a. Apache James) is a 100% pure Java SMTP and POP3 Mail server and NNTP News server. We have designed James to be a complete and portable enterprise mail engine solution based on currently available open protocols.

+

James is also a mail application platform. We have developed a Java API to let you write Java code to process emails that we call the mailet API. A mailet can generate an automatic reply, update a database, prevent spam, build a message archive, or whatever you can imagine. A matcher determines whether your mailet should process an email in the server. The James project hosts the Mailet API, and James provides an implementation of this mail application platform API.

+

James is based upon the Apache Avalon application framework, formerly a product of the Apache Avalon project (see "news" below).

+

James requires Java 1.4 (For further information you may want to search the web, our dev and user mail archives or our wiki).

+
+
+

+ Latest and Stable: James v2.2.0 +
+James v2.2.0 is the current release, and the latest in the James v2 series. +Both binary and source distributions are available.

+

James v2.2.0 is a major update to the James platform, with many new features, functional improvements, and bug fixes. +See the Change Log for a detailed list of changes. All +users are urged to upgrade to v2.2.0 as soon as possible.

+

Any bugs found in James are dealt with promptly. Please provide feedback on the james-user and james-dev mailing lists.

+

+ Get your hands on the latest versions.. +
We put significant milestones, and potential release candidates in the download area. +
Whilst the quality of these versions cannot be guaranteed they may contain important bug fixes and cool new features.
+

+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ItemStatusSinceFirst released
SMTP serverStable1.00.95
Mailet EngineStable1.20.95
FileSystem mailboxes/spoolStable1.21.0
RDBMS mailboxes/spoolStable1.21.2
POP3 serverStable1.11.0
RDBMS - UsersStable1.2.11.2.1
LDAP Support - UsersExperimental1.21.2
TLS Support - POP3Experimental1.21.2
Remote ManagerStable1.01.0
TLS Support - Remote ManagerStable1.21.2
NNTP serverExperimental1.21.2
FetchPOPDeprecated2.32.1
+
+ + diff --git a/server/src/site/xdoc/rfclist.xml b/server/src/site/xdoc/rfclist.xml new file mode 100644 index 00000000000..f7c2af12841 --- /dev/null +++ b/server/src/site/xdoc/rfclist.xml @@ -0,0 +1,93 @@ + + + + + + James - RFC Directory + + + +
+

This document contains a list of and links to RFCs relevant to James.

+ +RFC 822: Mail Message Format
+RFC 1123: Requirements for Internet Hosts -- Application and Support (updated by RFC 2821)
+RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
+RFC 2822: Internet Message Format
+ + +RFC 821: SMTP Protocol
+RFC 974: Mail Routing and the Domain System
+RFC 1652: SMTP Service Extension for 8bit-MIMEtransport (elective, but widely adopted)
+RFC 1830: SMTP Service Extensions for Transmission of Large and Binary MIME Messages (experimental, but cool idea)
+RFC 1869: SMTP Service Extensions
+RFC 1870: SMTP Service Extension for Message Size Declaration
+RFC 1891: SMTP Service Extension for Delivery Status Notifications (elective)
+RFC 1893: Enhanced Mail System Status Codes (experimental)
+RFC 1985: SMTP Service Extension for Remote Message Queue Starting (elective)
+RFC 2034: SMTP Service Extension for Returning Enhanced Error Codes (elective)
+RFC 2142: Mailbox Names For Common Services, Roles And Functions
+RFC 2197: SMTP Service Extension for Command Pipelining (elective)
+RFC 2554: SMTP Service Extension for Authentication
+RFC 2821: Simple Mail Transfer Protocol (obsoletes RFC 821)
+ + +RFC 1725: POP3 Protocol
+RFC 1734: POP3 AUTHentication command
+RFC 1939: POP3 Protocol (obsoletes RFC 1725)
+ + + +RFC 1731: IMAP4 Authentication Mechanisms
+RFC 2060: IMAP Version 4rev1
+RFC 2086: IMAP4 ACL extension
+RFC 2087: IMAP4 QUOTA extension
+RFC 2088: IMAP4 non-synchronizing literals
+RFC 2177: IMAP4 IDLE command
+RFC 2180: IMAP4 Multi-accessed Mailbox Practice
+RFC 2192: IMAP URL Scheme
+RFC 2193: IMAP4 Mailbox Referrals
+RFC 2195: IMAP/POP AUTHorize Extension for Simple Challenge/Response
+RFC 2221: IMAP4 Login Referrals
+RFC 2342: IMAP4 Namespace (elective)
+RFC 2359: IMAP4 UIDPLUS extension (elective)
+RFC 2595: Using TLS with IMAP, POP and ACAP
+RFC 2683: IMAP4 Implementation Recommendations
+ + +RFC 977 : NNTP Protocol
+RFC 1036: Format of News Messages
+RFC 2980: Common NNTP Extensions
+NNTP Working Group
+ + +RFC 3377 : Lightweight Directory Access Protocol (v3): Technical Specification
+RFC 2251 : Lightweight Directory Access Protocol (v3)
+RFC 2252 : Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
+RFC 2253 : Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
+RFC 2254 : The String Representation of LDAP Search Filters
+RFC 2255 : The LDAP URL Format
+RFC 2256 : A Summary of the X.500(96) User Schema for use with LDAPv3
+RFC 2829 : Authentication Methods for LDAP
+RFC 2830 : Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
+ +
+ + diff --git a/server/src/site/xdoc/todo.xml b/server/src/site/xdoc/todo.xml new file mode 100644 index 00000000000..8c249fd8c5b --- /dev/null +++ b/server/src/site/xdoc/todo.xml @@ -0,0 +1,109 @@ + + + + + + TODO + Serge Knystautas + Charles Benett + Peter M. Goldstein + + + + +
+

This is a living document that will give new and existing volunteers some areas where we need help. As always, any help is appreciated, be it documentation, code, suggestions, or feedback. +Last Updated July 2006.

+
+ +
+

Determine a way to support multiple domains.

+

Revisit UserRepository. The interface must support multiple authentication types per user, +aliasing (both local and non-local), as well as per-user quotas. It may be desirable to be able +to associate attributes with users in the repository.

+

Revisit the MailRepository interface and associated implementations. Special consideration is +necessary to support IMAP Search functionality. It should be possible to associate attributes +with mail messages stored in the repository.

+

Revisit the SpoolRepository implementations and do away with the current exception-generating +two-phase message retrieval.

+

Define a simple mechaism for addressing repositories in a uniform way.

+

Add support for mbox mail file repository.

+

Add support for the maildir file repository.

+

Add support for DRAC login/relay authorization. This feature records the IP addresses and times of +POP3 logins. SMTP connections from these same IP addresses are considered authenticated if they occur +within a fixed period of the POP3 authentication.

+

Develop repository migration tools so that users of the old repositories can easily migrate to newer repositories.

+
+ +
+

Add support for the 8BITMIME extension.

+

Expand the SMTP server so it supports a variety of SASL authentication mechanisms.

+

Complete support for delivery service notification (RFC 1891).

+

Discuss optional support for VRFY and EXPN.

+
+ +
+

Get IMAP server to alpha standard (i.e. basic interoperation with e-mail clients).

+

Add #news namespace to IMAP system

+
+ +
+

Give admins the option to enforce one access at a time to a POP3 mailbox.

+
+ +
+

Refactor NNTP code base.

+

Tie in the NNTP Repository with POP/SMTP/IMAP repository structure.

+
+ +
+

Write a list server implementation with functionality comparable to ezmlm. This would include +the capability to handle multiple lists of 100,000+ members, double opt-in subscription mechanisms, +and a full suite of mail-driven commands.

+
+
+

Discuss and agree future architecture in the light of Avalon's demise. Modify codebase to implement architecture design.

+
+ +
+

Discuss and design the next revision of the Mailet API.

+
+ +
+

Improve the debugging output, including a) catching that DNS servers are not correct (at least have DNS log channel record DNS server usage)

+
+
+

Add support for better mailet router/processing (maybe like RequestDispatcher) - Use Stage/Pipeline pattern

+

Add support for deployable message processing apps using Camelot pattern

+
+ +
+

Rewrite RemoteManager to be an exposed object that can be controlled via RMI or what have you, and have the remote manager telnet interface make appropriate calls to this interface.

+

Take advantage of Phoenix JMX capabilities to enable more complete measurement of James behavior.

+

Add support in the RemoteManager to manage repositories. This includes listing what's in a repository, viewing individual messages, deleting messages, copying messages, and moving messages.

+

Add needed functions to RemoteManager, Including Stop and ReConfigure (?), Reinject mail (this should just be copying/moving messages...), Store RemoteManger password securely.

+
+ +
+

Document instructions on configuring logging in James.

+
+ + + diff --git a/src/site/resources/css/site.css b/src/site/resources/css/site.css new file mode 100644 index 00000000000..b9279090553 --- /dev/null +++ b/src/site/resources/css/site.css @@ -0,0 +1,13 @@ +#apacheconbox { + margin: 20px 0px 0px 20px; + padding: 10px; + border: 1px solid #ccc; + background-color: white; + background-image: url(../images/button-top.gif); + background-repeat: repeat-x; +} +#apacheconspacer { + float: right; + margin: 0px 0px 10px 10px; + background-color: white; +} diff --git a/src/site/resources/download.cgi b/src/site/resources/download.cgi new file mode 100644 index 00000000000..06a42f2012b --- /dev/null +++ b/src/site/resources/download.cgi @@ -0,0 +1,6 @@ +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* diff --git a/src/site/resources/favicon.ico b/src/site/resources/favicon.ico new file mode 100644 index 0000000000000000000000000000000000000000..f0c22ad9bf0c7db2eaa899c41405a27f6b2281d5 GIT binary patch literal 3638 zcmeH}i(k$6AIG1kbLmu4%-AiL%zd_Do6Y7r6Xw1wl|qE5SSl7%8Ix9RvNUrkYS|Ez zp)ytzN^UFZcGRg;o$gXeNayz<9#h)m@%sbzemq|1d|vO@`}6sJzn|~-`+j{vf*z)( zJdUMu=qpA&d$#ajln^9x{RMqg@+d7qBt?voJpOy`N2k-_XQt*i<#6WynaAosWsstr5rqX5Z~G5tWor4tKxIk>0QFB zM>1Q@j<9-cE{9Yl?30I)U^s=MtOk;js;H@YK=jEfHeA1nyM7$@eYAKiEyhJLp1(Ty z;_-4mmT^~z-Eo7mvO+@qig4A-;z!w5GIDF#uW;v*finlf%UQ1I&+@SvyezadHa4)u z(1N8y^Vuvr&oVO&c3nzw=%!+(yf>STP7$iV2fs~U@$Iz&&MVgtd!z!_4w)1bG!UYH z41ehvwku{3vZ0IvhJM_?_mGpo7m&OU(Ke$8?br52zQw+`KB8fV(*T#vop54O8M(V z72m%SM^08U(?a4fH#aBl_fW>_O&}yahZ1!iJKfZrFipj+?_~~!77`udg_qtH;T;~F zQh0MsxqyV;lj)&njAvjr9+&>cW=fZ4$=@Tiy+Yb@pP4Fs7e84dZn8<7?YahA{R&ojWpVuHEWT5W zV8x5+q#AAHa>rRXy_d(lekH8$eu2Cj#Y8Iiuxl~q`vo7K$ zi@N7<;tvfDor{^>tAP9tmiRgsvgo`DBjhyRZ6rH88>^97>`~bBt9&={M%!30K9?Kn z+k7p&ck*{fSS86MARqwi85(SkXEJweDT$|cVLiBt9bP#M&@*MmzBAY^Ea&>QvjjTl zV{<8=goHA}uI7@IrWO9!$g)wHq?|uVV4#|U+jT6F6p4LVfK@^ku?i24EBweYUBwTw z1Hy|2;wA4x@I@6#@dw#qu!c|N-6=JmK!EUeyUw@pm8J2U(N12HC`mVPBIZ~*U&*YA z|2>R3rUfJzco8a(!_3T#WD^h07=FVpSrqQBD$0t=*xzvuw&@xccTq7>+6Aq_EbI)c zQR*wOmz3Zt(eSk_g`ea{ITx>Gu6ZT)z4EZSlFdBhQVuEivce|^$Ir5P@Sur1wf6`T z-kp(lku#@?*mFb0@*dgTuBqg@(PUgCDr|-nQ>MLxx~huBvV7|6YYCSfWUizftGL_E5sVI>w>XE4IBw-lPg| z2#GxU79on%X@ zz$YDsir(}u;ko+*iRTR8e^I&qXV3m2Lwkrm*IrzIz4SHxcTddtwmlK9&kfg(STwmq z{EZVi?Nmr!4{x>@v~KWuD|!DDHP01DzH(F@o_Q?V@|}(czBBWDPTzXLUt3rao$+R@ z!-N%6#Z|VB;&aK`jn?ai#dN-?(oAcu36}Rwy~-l?w)EDWZog@U|K3)=XK>EH{B(uX z^3doxea=;HZmVy<+Td?dyKYkO=sDLue(#00`;)ohq$(=X`j?pHKP&wm7YiF`6|-Nw zIw0zFtf6C)@pkC85i|khmE!OV;-#3s)B+Vr?i&$)T_%QkG-+~*1?r2Doyq3ovmca#OnI+ z@`t%+SDms@grE-)jzJ@P zw^|$0FFT#y8_{clZKQwrr6PBqw(__jFFn&vpI)44p>dp^+D0Ypt?$)`kC)Ag^l#1% zaL#KhPg(!U4>uKEBQ2U;>ZbqHRz>pmmC*4ob(bv6!#;^mRJ5M5jv-y3Z4cPm5-OrYC4bUsoeOH4+4T=pml9(aqr9B$jMMBG4kM87)e@ Ubv|M>F;ge1bt0t`R41tJf5W(}rvLx| literal 0 HcmV?d00001 diff --git a/src/site/resources/images/asf-logo-reduced.gif b/src/site/resources/images/asf-logo-reduced.gif new file mode 100644 index 0000000000000000000000000000000000000000..93cc102077a940966a0bf6d77e74ac273a10ef8f GIT binary patch literal 6636 zcmW-jdpy&NB^`k5({Ud=*EWJLJM77(p_7Ubjo^?L{6ozBTG zrT8~-uT3`YA6z(iU(uWv#wdC?*LrZ+m}~LRdiKU&$f@Oy^oJ`=i6+hgRAVF_PDwp- ztgxs!1ZD4l68M_KW_UVk-#Q!$Pa@K2Br166_?3pnI2h|A-a0BAXQR5&A?Fpb?Gb8 z2*k5oCs=r^?5ey-sZ^AxYup^lC`5wE?{)1hj19^$$^{?dW+pEpj_VrXL%+<@Wf;^t zJCdiUvs(#-G^G|kfoFntz873~ctb_>t(@D#$7q=4Jv#>J`Qv=$b>~!(=u%)Bm4nQx4G0uy}~g_xl^(YUhBvak#5 zgOuvw;WT+BuH_Fe^Qfh^cx6`2s#Q)p=qizh0B=u>WgT3-Um`*}GI*J|%p$EpRN<4Y zGf~z{=<@Z%ciE4S^38-`SDls-3H17pfQxW&*i~EFS~THa;&q8l$;Vfpq4`<-XV(d$ z`-SexHAn1eerw`+&nuVTz17YrVcMN=n%6b~Pk7R#fQs2Gpwl_l;)!9Zix3)AS!c&C zQ34C)+gAHfADmZ#J!@ouF>Xj{z_YVB18pQxGV z#8&ZYQIjf}4+ukXt98XP)EbGFTjdXCr7XQ<39V`EX@7dX7sgi%K^WawfM#Gv=)Aa1 z+o?NS!01`I1iDVjJKI}zgx$&^C5Ef~EU7JH?OH!a+{=QV@_zU`-5PH*I zPuRv#n3aaLEiBR7@r{SVvX-}mUhuV3xb?k!BFIAH>qbPzbWFRFgIRYuh*K-nKBmlY zXo!mHbNn_F82LJk8Y(6HVBaJGfDmIP$=s!3^Huul_S2gBtEE}_T2@5k_$OT|Hfb(5 z)X<#6D%iKo^EXxX4F^7^85Vz6sG)}#XEvtZDoScZ&v0xHPB;j%ar+w*l2aoKKDo2- zb9>!cbUD@Cqd08ehtuEgl-E^3le=d;7%p1%H-?USDXO&=Ns#x}Gv34#dLGHj^Mbev){8$exY)@D8txn4_GgU^Q#nGSmQLy^q-T1(e6TLYS zkyodfAaB@J5Bc38m*mNB>VrC0Ux|ebUq~Fex!-O z_3SLrfr{Ra$gx{pd(y!YKvCLGkH;%6{CVnQ{;UW?4*=tq1vDz`SEy-1yIj(V2R)ZFCY__!(Zs!f z`rl=^e16E7%Pt1a*QGNC=$-{`qOzJAu$vUT+P&2n>8pCwFvLX7zj^SYb`8p=S+0`E z$XYnM2{X2F1lL-FD1N}lfYe#DT)AY*L<*-3n_K(QvY5+XtlTfjs_Xqib0@!ESbnk! zSA5ArtJN=qF`{-hEnA~6zDFo%d=8mF^^sHw%D{yEh@{rPMqBF5>hB{?M8h{}t@d0a z$TBh@8x%i2xYqf->Z_kO?ik9N@?Tnd1s`-Sm~BEsL0u8q&B1GhLXeauby8lte(=TH z=AV&6s2Bxw4Bv}#m_ApmU%KiQkf8nY=}IGzQPzj<_?tbT?S^q>@387$GCgoZ>{a?} zs*!BKHygc@UGbJ=GHbM@>qZ!K2AH8?ChBt!Rc8lW$zk7VEIyd*pHZ< zE$>3tEVKs2MMV7_y;EJ&`Ixn`WSsRp6bJd9jN0ez7 z|Ma|Lc!>!cW3KHdjTYX+6Ie1ce`!;(oJVsG#TcaQP4A00xHl)OMsj5M5|l7eC(3az zDJOcF{El8dJ#Rzx_qnmF*i5mBua?=I@#wMvrXgR?ichil(W`n;21chubB`0YX{t^$lR@)6e zzxHWowXNRH^1Qj<$tzEf&Y^`bdfs&ERfbPdDZ3B53tO443vu5as^NZ_IwXJfQLrGe z*svE7@rd$rX)~s^qXx&9l&pV0F0Lg#>vRaEt0D{^yK6JYuX|TyX#+v*D)2mcq;*Cp zfmg+{`z{X8I**n$^E#AvnZc#GzrRAukx7ov5b^QQouH>j)7lqpVBE5P^}wWc9VJMF zl|RDZCikc^4kDE8%0ixL8a>;T0`GN{#v6|OnR?@tEUXAkxLJ7eVdS$v?N0>>6O+H` z^2{Fo2$O4$vb6y!ta9)n;7$uEBjvIC)aTjix?Ev&58b zTHCwd`4prf7n;f;4aFhXHwe2DD!6nD&voHBVW_e^kk z4BA-^s7S#3%MdJ4#z`=;Gr>L_NJXrykOQM%3PUrC{5VkM211p-l*eeZE_gIfIC*wHsp5pD4ONn{s>gfc~b%Z~YZ zfnp?qAD#z;w}Pl!;NNdN^7{Ah$UuBd#BGr$q;yX1IYErS2Le0Dx zqKPdB6#2#+aF1s2nU>;y3GRIxtU@)ZW|^FpfQ~=ZZp%^@YPfu9&Thx@P=y`kq&RXQ zrP!}nk8sM64X>6!PGY$JGH6aPF_geaVX2e20;v#Fg(T&7r%qiezhli!WB6VLkCZ*B zG&`?pe<1&KTg6Y!%9gm&{(-Dz0m4ZN2hm-2e=EFq8EYj6+(TS9F#>*%LhWhDO$Eqg(i@Bw z)ysu*&R-5ba{&B^X%ph=;~Ze6V^@UXC;oaVAh3nK4e=SJ+})Q!mhX`!p&LC@;->&y z*%W2taFQ)dn8M%$JL=tRX3)qPH=>dPFsJGwCA2L|HJ%mKj z+y{JohjEIwLdk)ki%L3nlF_un1W|C)_?oXdHHJxWEt5OSuAY78a@UvZQv>#fngy#D zda$eabAW`YbKVk=e-xVk`<#M<0C`~Vq#5R;JN!<{#bsQ{XJ#H_~xNkfws>)tk=Nd2=DuVh(`? zKbj9|62X&jT2m5yRsj^6*w}MyONIWHK+*)q!^jL_U2(Mwdv&9cwJ)Nvvpa7o8k)iy zo$y3h|0JtOk~^bd8{WmujPMc%sHVchB03^Sb~uD=9ux_+r#L6jz0P(=Y$!X|c){Km z?fLK}si+@jkFBv!Q@K0>0$w#6{ub%)YMSm>%~9uFy#et(ya<}gRQ2;ElN`gOWOB)M z?>DekR{i9Jsx8$4$*0#w)Bf5RkUxJ!K+o^z4rbhv;V_6(p-7uz?>a# zDmQ!+XacocAKJy4EE*aJ5_O zOl7@}o4eoGZTmg|$@UZeg7>|qstB=;z~yyP7^X&>6Iul9wdDbqR!|(HgI(~y4bEgj z%tqp_C+GnG6Eu5vYZwFarm%kO0S`>W{wXs4Bc*Kx9v*U#|E11@P&c^;w33o+rS3mX zZ^{t6E||fFhT*& z$DjcTq$Y2;o9%Wf9FZevyFIOXQdsN9MYJA58+<3}B-N#2cE!;z5WI==7sz?xMoOhz zCcFEp2Joy;%Tm{v(b4hj?*Q^*NLZjte-Cvs+}BwF*3RDM+ZvgK2YRtLoAP1um6~CC zw@>rEM)H;)OM3k2JaP$*d$h-ya-e6dr-4L468u-H8afR_e5*9CiF(K(Cm9J@isrWu;W$PP1TA^Q5f6Fvm^0E!e%5G?i3bKu z{Y_bc)_ET~Je&J>&|Ppxty-gD7^mFzg)*;3yK$m!uh89nW?=u;;J(Ukj}X{@$o$uk z$D||T{CMs~RQp&nti<#1&O(x{p7CHf|PgnQpY-@>Nvror76~GP}JT(kgx;Nb}5NhSZnAlLKawpPv{}C;)2hij} z-VORkhG$HWlVpA6+QO`}!i1jeMpnIN(Qw3S+*Ou5@BOsu;ShlNeakxDSlH5X@`wsZ-B=B^}t8EVN2WpeWtGP7&oYjaRX;8E)O+J)+0Eg`%&btht7o@_=5B zG}L1PyFKiFGCjmEgcCDdUcVCjw?p#*6+*WFo_@ZNNb6~LvrE2P1Ru4##STL3u4F3L z*$=Vae1mATs5Qf%z+bemF7Xbf3~@o!*q#q%6(KZ*3pVUEz8tvgS;Lvcg@LO8O#eXH zq>p^m_Q3Yl@-yi5M)=KD;6NHM`7vBn)9`{|U3AEtE=_e1P?$VMP7CLdHrY4?p-KJt z?4I-SV<|g?s@V3;aUsaKmh-9j@-TT;R2b6YKEmiZGJXW%GmD56}7a!qg*ZT093>v zRz?yK$i^kR0fx>=K=sg4p)3658SV*r>97F6DgYB65WZigcl|(D>z%LO=H`Mnn`wZ$ z17R)!YJR$CP66?+0Ra!Q>N@l%0q;r2xtIPhwW?=e^`9!vZwV17-} z`v&|Lxi`;X*yrlGVH2dVIefugw~g0%h=SUIP?B$j31DUvBdWX!RR_#(g^grxEaBNF zPBtudN<)iV+FZ!d+5hg+5J&Kc{8OETWxW%AhS&-JAzgnD!y2*9@s(5EO^-9pGAbx= zg#EdZxG!MeuOgDwu1+Avr1pU-1JvD&F&{S%|h`1jKPE8AZ9k@JRFi0v2K#muJ(ewI`fD=fye1%bs?&BeGF zZ;Kf*o`hYW^tpt?tq$ty>AH5Dulshs%z~6tiW1;GG`f9=Ly2Rh*sacZBEQUkRMCso zF(ECs$v<#4B+Ci`W8DE(IH(va?>eRhd&*Ws)cPcdW>57a3zdK*%pb*f<;JNtKI0 z-OK4Xju4k0B=B+2Gi?d-6YhU0Hg-u4T3_eoi!hE{=_4w2X!!hhR9UR3Z*bVfO^dB@ z%PGwF+v0V23+}E!LbhW#s?0(LXH?3&zWt$Tk-C=x5J4Uxye3j?S>N?L*6t@Ap4dt zcM)kz>l6V3L(wORWE4ZuXZU>MMajkfSMTVD^jZMsMn!gIo{f6w>v(K0>sOvxzEw=a zrNq05F^F4qmE!-zC(QGQ`ALI5Ao<%CXooIt<-mU(5n<_HaS8j zDuLZSYT+|{!Wh1VGuH~Ji%q}YTBR-VL>(y61_$YZ82tG5K;VJrr`+k+V ifk3o@FNQYto?ua@#Ta7 literal 0 HcmV?d00001 diff --git a/src/site/resources/images/james-project-logo.gif b/src/site/resources/images/james-project-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..715a9bf970849d7564a7c4ac46f6512d6e2d8bbd GIT binary patch literal 7227 zcmWldc{J3E1I54Fm>G;2``E_V*OmMZ?MPVgzsp_gB9UnA&z+p~Kl7iG{Gvt6|9<|nAzEG<(XiQWWs^wr6n*(Q-*!i| z_G`0D^y1>@-9|4#oMYiaRv-}au`y08B()Kyp4*xC8-2s`2H_xA1d z%KE=QfBtN2YAn4}+}_sqYIg3$Kz}FiF#rJnWooP;{}})<{=fXc6CftyRWh87l`r(w zMD~Z;RPr05UH|gA`MNoF@N41|0XKfHN!g3Jw#4DE2Y(COH>^tK#IN*JkF3h2SQ2rv zc0@^{Y|<`boQ^D!75}g_r@+tkGkP>>q#n%k1PGist$Taf^BBjU9QcAKrm5JY_e6* zWt$~qMB73=d9y(4teu1V(SEZDLoucB3<`znn5W#R%qd}mwT7ZRyvAKs*XY4?`RIV! zEshOt@L7G;hSQsw0E%E7SfyX+=ia}ct&14B-Zhr1NoTjvugYlBUJfB=9YXgkIW=|LrTpezp=(vH=JcTaOl zs|`omJF`JKV2C2Ek}e5pTizI0-s<5n%F9vqy`^9fav~`c_nVi>%tx?$860YPS0)~( z5IrYEtJiGn?3Ue~*j?av*Db;D?+*aNoWnL9WO7+AR(25|rYXLttiFYjo@R9Wxng$@ zXeo9w;7~c9qI!&iF#y9PNm&=|e@|MExLc`mL;zyF%;@%crex-PoWkP+665`WU1?Vy zae09XJFDNF-ypxFN{OcfAdaxi%`!aqddykvTQu#^N!^DSAcibSKQ4x1r*)<5=4O1j zd`XULha;`W^T4gkls>%G>q{&x|4j#g(7l#xA3ez>Z*0Z1E~e>7`$W!vQZedlrAqE{ z<#d5tRC%_z>4eK(R%+IC&$N99EbAq-Y2H-q&_-QJ{khDmz3!kY2f}G2W$WX%P8$r0 zcV^$|LaR&CU!9G7erigJgbd_I95&Ql;0A5nvWwlEpA&+ijtag=7z@FEoJZu3G?bZ# zLOJ%b@5xRK<;!@drqi;^myQ#}ZK6)>)_kljMuR~%MQb9ba&aieAwXP`%`l3d_HqoW zqj0)%rDv;ea21{XxX+*y6Dq0576$DWrrD7X6rZJVyC8*)sQ_rd&%_AHfYT-%IMp2E z0b2x9bU|@vO7}wrd!9X3Eg>-j$F^CgFSP~xMY8Ds8D?tGXt z3Y>{NwvP}Q%6Fls@($s+%-uv8(0D9V<>feLI|Be8X)ugTahiQ9Jji2`ZHF>xBbFoD z_VacCu4d~~^)ps~(yzQSwhh4l$mORZ;vU<74MW!i{~(INjMBThuZ<}f1rJI-x8NQL z^`SFN_SZv=Rf5PAZBC$=;-C2nyH4Vu?JJk=DlvjW9=5kUBowNHzX|9cGM&?HNA@N6 z$Uot~gp~Wpk(b^`C9SyIH9y)|b5ks|G(-RPLli57>7vo;4)OeVfycW=FO-Pdt;DIsVl)x?PzA|wZ|3ZsA7RE?bE}>9a zW?dQ8&mIFqI4IYy7+;fSjtU0!)_%{t<{*$-lE8ecrc^|xCWnEE$lj~(CJwP-RSXqy z`vT%a7*Gx6x%ExELA)ygm>!mZEUtU^%<0@D9VG`Wf+h3WucXgv6Ew5+dl!5)0QJ|R zrGlNjX)uvs$Kdk{wgPApo`=xJHBiz#Td7C_thRk5=lmC2#Enwjt@?@5RPy#=AfY#Y zc>if;)C;~g)pC4C&k1~Ex7JfLr$ggQ1zW5^ygvup--l0g?<( zn&W!_y*Zloj(xNL`*c3bQggPX9&aIE)@D`I@-`-Re`t`g)cku@2hVdwke*cwop zhYT{DfeV`j|EOW#q_@2WOKfP`2yxz7PeC?!FrRsaf-Quep2=U{M*SLg#VRqvp=e6; zs^|b3qak@6oY}0Ww$$)kQwUrDX}wtC9IVc6|y8S0$}`l1x-4UDYY>aA;rzr3W=mPig-_BZWJ{kTCKZ7H~!J-N+@Rg zhD_Vbs}pHt8yXCHTUKtSn3Pt$?(<)vmOhna!du9x56|bo7C%_fT-K{GnZ;-m0qEG{ zpH_?9EqAd7Nc~2cveOEgTVK~IL%bnOG%Fo;?aI7F$g!uvWGx~~i!9x6YvRz8e&{c= zS0V4OnEZ0GE*sirjt0jHTFw5b@KB_8v3Kem(f&Dduv`$JWTND3S7PiZ`s6Zge*nG1b6@#l*QwK@6(c@Z-n!oA*_;2w;{zlUxF^1k*{f~X~9(FkACLqYjYf>8* zAj3aAr8VUB&s(oh+2>zjN4)Jreu~|uv13T|)wuq+p}5OTyYpBf?{7>nD^1!~^D)9} z-jw;CGNp4b?bDAOQ;s4?#)!I=KHfqhK*fcsZpU5mN!n!<+}1+Ms7{$`ZTk66oMVBL zk-El}gri-dPm+;vE8EFftFG(G{7~I&#VIGkw-<4z7YXTdejJ0KLte|@&~1V&S$+KX z0ky*chUS%Q4{IdT;IQ6f-r=$brLVHq`C&FWH|4#l`o2(Pqv1O-?PA_kt?R1Yhg-tk zya)L7f^_+5=~ZXpZ<(6mGZ#{$vDVxZvX}>}*NkixGQE$%mi$!ob}FpJP_pfhEAhU) zTJp!ZnG%970CW&SUkS zuAC$nYE)kkawf=0gw95=#Q4EO$w`NZtpv$JE@aAw6FY$vd#N5a1dm#gD8~nC;YF*1 z2D2uc`HY@)^V}|%gk_7J3Xt+ANRgl*OTauBkxiv)k1|0k9-0M;YcAPO>7+L~X!r)Y zg)Jk@Sj5xf%=cN(_Bf~eP6*1HxsM)>(~ojyXB;m)Geu6HS z)cp$~eSS0xIBvm%cLY-X8v-I6u)ob&>LWZ86(N4_5KshJQZO%h@;f>K z-6c@&K!B??Bae+sW8l7VTnz-E!6nG!fVSZnawr(N-ph0#hhMNlcChn0ypa{LDA8Uv z^X`?TzDk2_P7ShWOKw3;S9j0k1Keuf3m;@J8Aq1*% zAr%5(8kjg318oy#<&VSL2nBu$f!lbn#RsT;Go(iV{Z?QlD)jsv(9Koz2j%?Sp|&ph zsS!|}&hBQw9EwH{&%BAD_R1Q1*UoMl-_C81jdMESC=5N-huofn&%`Iccoo-8O!{^A zqHzc7;_SHtg!2oq^ms5$n+oaC(Ni(F4`!eQ2PV+BZsJ3c-LMuP1ce763gltA+k&mA zCxm3ip&PwUDgX!z04*UzpuqP1peY41rh`%fU&uf~lu5_z;sav+4gttz6^dk%A3m}O zR3`w+WLpbIfI!VIsW041$b;tc?1Z6|!+v5!RHi|G`0Ba2%oMg#=|uy;k)2@?hcZhD zi7GMOBnWp(6Oa2Y^^5;sWHN>W?jQh1*8mqQV4-Bc4Fy63;buZm3jiGqAaPp4j1?eo zhRO|K3$KJtR486EgGfpJCNNVW8`Ss1+nKPYAROkh7496=lm^V0fbDmGgkSn+1q$`o zawC`6Q&y1Z7ccq6|CiSLnv{)5!p-A2X~;N3h1ADE$$+FDOA;c?%q6KIrtuqLeCi zLU~gXo&6Pni}m1=z6)A{WE(yZ%qkS?fb6`;4!Hr2%*Y|{ytaj;4;Cl|%kZX!i)-Sj zmEI^mkvo)@oHqt`goxLd;G~(+o0;ly{?a4>))rO)21rCMU?#*U7MrmtRUzxpGfTBv?0JVJ%BXt3K@|q1Py`wY*lO)cB6(VZk|8oMaI21| z@=>T(JD&`3aovFAk%+r9ieL}#f|9^Woea%b6>Z`GsYdOhm2eyK*?a*|X8>EV&334C zWCJC82zlGtp3>HpH*yjES7#6KJAO6Q*m3faZK$vF@GqrHVh@gmby>GB)Yb_JMg;7X ztxlpJTOpyy?=Gm`v?D8`TK+zU>WwD-fQsv3|KHe7LMqf`C?Pqsz#q21}TMtt~7;I`UrO)h(oy{;v01yG;p}LT4>2K@TNxtoVX_P5wDtliP8B z7d`yvHq_eZj@5y-r99O4m3;4kr-o1OvH1Y)8a9guNK?vHB?@A$vPTR%Ih}x9NN1vR zZ)Q!W#zUJ^)8Ot2aKMN6q!_n_&@NJ;Xyo%7Dw%S^-8$--=V9vYW&_A>_E1`Wck$`I zo%wy=W1qTGp6)kde*28%Ha|T`zoTfJPi)U*OOIfI!6;9XEjD; z57m@TAbd$$cjXkqD@RBr2n$qWlQU zlltV^qv7mOt+StBbgWmdjRJDHfH74k>Z?@D`Fco*H7ei!aVwJYR-%dU+FGSuf_IGi zZ*uQdNbL5pUljbdQuPb}!V+9aTTm65=qeM4a3$Acq7jdAQ&)R&W<-?0V7 zmPZyOKE6SVk_Y*xbFsz8P*;v2b;>A(yKi?fp45MaPkllz8;sr#=}(fu)<2qvWrCx$ z@fjz8K}n=1YTjN5YY_m{amZV4fnrgFz^Ut*(D%$ zjhU$2b2+s8Sj0>FvX|Kp-^Dxh?_*YEB|JGzjP_=~^E^AzWhCBk=HurKXzQM7HoaB6 zX!d3j+RqsFi|DjtL)(1uJ7)lC`c;^U&K3+H0^eCg@`P@}>nrL;XJ@Dl3hDr;A0j1N zPS>%{&NqoIcZDyO!JA&e}7KGHRj_}Njp+- z(xT*bLLBdb@1*=HuU#|&8F5VWE9N2%=EA4s)F$L~3vZ|cs8??h`LK81`zCgOe(c0; z>kLL|JfE)#n>|%N6Z+^<_p!MP=ew8p=@`*I#r<*2<9>S05dTM5^^a=05-+)~A8MIZ z=?D{?={(@s;EUoaDNMa@@tXH`d%v6g)w>=L!b^DXYMYAajP~E4jYYJpO=*00A;VT%}3 z)R^1X*rNO6nNDSOFPBd*(>VD@cfQwrt{2p@;<}W-QF(n23`B{; z_fK74c=SNGlKnBw_${7ZuH67{63La>-s>{PSq)2w)u9*fS+|MCj zv6FkqNyopwUHA~Y5Zkt5IpNA&V%q-vyZ+KQE>PZoRZ&1lQu!9Uslp?2s?HlpDHpG# zNuF~b#1jA=27E#1ErtM4D8J(T-JG&br)|Slt5nsP=^I2$s-U*jYV}34@TcMIK6Z%< z<4xIO_x1BlJ2}IO_{F)uxSr=`l{s}U*LuF7Bz=rJJ~qIOofvo0)L-+fDTxS=|cpK?y4 z3ED{a(4w2X{Jp~?`QCSPLEg!jm;4Qh@GGS$2Xs@!clwY>TQXB}T`dDh1d`=WqRBxs zJy$8&7%y=%W8IS&330BNuDY+d<^Bwghb%UevYogSBctwYLoq35ZgzFFv~xD|Wgl|Y zJ+L#~)hi`5RCf!(SiviF^;%t1%j4SNIXYfLQ7)Qs+IOU{wZXt-)!D)fJuCzYn$V_3v`rj2ac zIgKf<>V%|ksBRBsT*v0hYdN$vENd2KN>gZCf~mKZ^gK1aw%Ce(Zc;6d_){^|y%122 zS3555F~8aAw3715C{tP%klbaNTz&V!_ZMzBkiO&|KD@R*PJTnWkJ}pTKVP9v;R<~7e)0=~ynjExoujyqIseY+A zF?MIIb|9aLw%o+!vE)n+M=-$@I#2`WG3fg@wnWl)V0ICrUnq{22w=LnF)PDTcFEXH z!KS?md>b;!10|-Hjj_^VujwpQiIA7p7@B^<^<4Dc#Vpl}ZJ(H?jn|>n==fkMsT=Q? z>NDZ{2QKCk{H-)#$WzEF%>cYmlZ^c4mNvcC>rQq@KrlQe?ANx{&>Mfs`O*Nd9U}0qQhZtPF~p-8<}ppS+{KR$;-AT z2?51%zNNEOev8&Y)oHQcgR9)7)`B=`y|1xRf6iV#Rb1tGb*?1p`Q*vs;)%6|yeC7< zn~=D}yFwQq?`k%mOrtJ#%(qM}K3IBwSf*=URnwg*s;c(TFD_^PCdL zmcsF!wO0Y1OqlZG=#Sy8-==@Ou*Dx+9&s^!yFBK;|5$W)BisJxD?hzQ#|zVGVJ#2H41jm5+f7=(PS-jwIkwq*^Kiu^rUy*Bsxv3a{f$Dl6^c0b}#ADTXxRawATq6 zNj5|XOcb$+?(9Xl*Mn-o=`CmBZ|a$N&@LoyM7@)~_gzXIk;vKi)DG=mfx-GFa2%ONrx-#U&LD z>UCL7UdEv%_Y4x%+ZJuZgzODRVPZ+YM=JX1mwh@H(%U}jl#|7GS9aKfNlQ+ Deg8ll literal 0 HcmV?d00001 diff --git a/src/site/resources/robots.txt b/src/site/resources/robots.txt new file mode 100644 index 00000000000..da97f40a611 --- /dev/null +++ b/src/site/resources/robots.txt @@ -0,0 +1,5 @@ +# /robots.txt file for http://james.apache.org + +User-agent: * +Disallow: /CVS +Disallow: /images diff --git a/src/site/site.xml b/src/site/site.xml new file mode 100644 index 00000000000..08407856b26 --- /dev/null +++ b/src/site/site.xml @@ -0,0 +1,113 @@ + + + + + + James Project + images/james-project-logo.gif + http://james.apache.org/index.html + + + + The Apache Software Foundation + images/asf-logo-reduced.gif + http://www.apache.org/index.html + + + + org.apache.james + maven-skin + 1.1-SNAPSHOT + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/site/xdoc/code-standards.xml b/src/site/xdoc/code-standards.xml new file mode 100644 index 00000000000..c1343f7258e --- /dev/null +++ b/src/site/xdoc/code-standards.xml @@ -0,0 +1,97 @@ + + + + + + Coding Standards + Serge Knystautas + + + + +
+ +

+ Submissions to the James project must follow the coding conventions + outlined in this document. James developers + are asked to follow coding conventions already present in the code. + (For example, if the existing code has the bracket on + the same line as the if statement, then all subsequent code + should also follow that convention.) Anything not + explicitly mentioned in this document should adhere to the + official + Sun + Java Coding Conventions. +

+ +

+ Developers who commit code that does not follow + the coding conventions outlined in this document will be + responsible for fixing their own code. +

+ +

+1. Spaces between parentheses are optional. The preference is to exclude +extra spaces. Both of these conventions are acceptable: +

+ +

+ +

+ +

+2. Four spaces. NO tabs. Period. The James +mailing list receives cvs commit messages that are almost impossible +to read if tabs are used. +

+ +

+In Emacs-speak, this translates to the following command: + +(setq-default tab-width 4 indent-tabs-mode nil) +

+ +

+3. Use Unix linefeeds for all .java source code files. Only platform-specific +files (e.g. .bat files for Windows) should contain non-Unix linefeeds. +

+ +

+4. Javadoc must exist on all methods. Contributing +a missing javadoc for any method, class, variable, etc., will be GREATLY +appreciated as this will help to improve the James project. +

+ +

+5. The Jakarta Apache/James License MUST be placed +at the top of every file. +

+ +
+ + + diff --git a/src/site/xdoc/contribute.xml b/src/site/xdoc/contribute.xml new file mode 100644 index 00000000000..c3af9292fa1 --- /dev/null +++ b/src/site/xdoc/contribute.xml @@ -0,0 +1,112 @@ + + + + + Contributors How To + Danny Angus + + +
+

+ Anyone can contribute
+ That's right, we always want to hear from people with contributions to the code, + the documentation, the website, and bug reports.
+ The rest of this document outlines the way to go about these to maximum effect.
+

+

+ If you are new to this you may be interested in some of these resources.
+ A good, full, summary of links to guidelines
+ Subscribe to the relevant mailing lists (link on the left).
+ Craig R. McClanahan's advice how to get involved
+ How Jakarta projects run
+

+ +
+ +
+

+ Patches should be submitted to the developers mailing list.
+ Always use diff -u to generate patches, so we can apply them using 'patch'.
+ Make sure you are patching the latest cvs (the HEAD). + (You might want to try 'cvs diff -u -w -b -rHEAD' against the checked out module where + you have implemented the patch.
+
Make sure the patch only contains what is intended, your checkout could be outdated.
+ Make your patch from the jakarta-james directory and make sure it conforms + to the code standards, otherwise it may be ignored. It is OK to make a single patch covering several + files, but please only one issue at a time.
+ Prefix the mail subject with [PATCH]
+ Briefly outline the reason for your patch, + the solution your patch implements, why a patch is + needed and why your code will solve the problem. Note any bug numbers your patch addresses.
+ Submit the patch as an attachment to the mail, this + mail should preferably be in either BASE64 or QuotedPrintable format, to prevent line wrapping.
+

+ +

+ The reason for these rules is so that commiters can easily see what you are trying to achieve, + it is their resonsibility to manage the code and review submissions, + if you make it easy for them to see what you are doing your patch is more likely to + be commited quickly (or at all).
+

+
+ +
+

+ Like the principles for patch submission, mark your mail [PATCH] and ensure + your submission conforms to the code standards. Provide a Brief outline of + your intentions, as above, so that your code can be reviewed easily, and a + note of any relevant bug numbers.
+ New files must contain a reference to the Apache licence, copy the header from an existing file.
+ It also helps if you send your files in an archive (tar, zip) which preserves directories, make it from the jakarta-james directory so we can un-tar your files into the right place. +

+
+ +
+

+ Many improvements come as a direct result of bug + reports, and contributed fixes, often by the same person. It is sometimes said that Apache + projects evolve because users become so fed-up waiting for bugs to be addressed that they + fix them themselves. :)
+ If you report a bug, here we'd appreciate it if you could send a mail to the users or developers + mailing lists, so that we can discuss it with you, bugzilla isn't a great way for mediating + communication.
+ If you want to fix a bug, please contribute your changes according to the guidelines above, + in the Code Patches section. It is much simpler to deal with submissions if they all come + through the same channel. If you still really want to attach patches to bug submissions, please do send us a mail tagged [PATCH] too, so that we notice your patch. +

+
+ +
+

+ While we are glad to accept contributions to documentation + from anyone, in almost any format, because its much better than none, please consider these + guidelines to help us to assimilate your contribution.
+ To edit an existing document try to edit the xml version in src/xdocs (check it out from cvs) + and if you can, submit a patch as for Code Patches.
+ If you want to contribute new files please try to use the simple xml format we use.
+ If this means nothing to you please try to contribute HTML or plain text documents without + any styling, so that we can get at the words and easily convert them into our xml format.
+ If all this seems like unnecessary nonsense, send us whatever you like, we'd still be + happy to receive good documentation. +

+
+ + + diff --git a/src/site/xdoc/download.xml b/src/site/xdoc/download.xml new file mode 100644 index 00000000000..36aa4f34163 --- /dev/null +++ b/src/site/xdoc/download.xml @@ -0,0 +1,159 @@ + + + + + Apache James Mail Server Project + Download + + +
+ +

Use the links below to download the Apache James Mail Server from one of +our mirrors. You must verify the +integrity of the downloaded files using signatures downloaded from +our main distribution directory.

+ +

Only current recommended releases are available on the main +distribution site and its mirrors. Older releases are available from +the archive download +site.

+ +
+ +

[if-any logo] +[end] +The currently selected mirror is [preferred]. If you encounter a +problem with this mirror, please select another mirror. If all +mirrors are failing, there are backup mirrors (at the end of +the mirrors list) that should be available.

+ +
+Other mirrors: + +
+ +

You may also consult the complete +list of mirrors.

+ +
+ +
+ +

This release has many enhancements and bug fixes over the previous +release. See the Change Log +for a detailed list of changes. Some of the earlier defects could +turn a James mail server into an Open Relay. All users of James are urged to upgrade to James v2.2.0 as soon as +possible.

+ + + +
+ +
+ +

It is essential that you verify the integrity of the downloaded +files using the PGP or MD5 signatures.

+ +

The PGP signatures can be verified using PGP or GPG. First +download the KEYS +as well as the asc signature file for the particular +distribution. Make sure you get these files from the main distribution +directory, rather than from a mirror. Then verify the signatures +using

+ +

+% pgpk -a KEYS
+% pgpv james-version.tar.gz.asc
+ +or
+ +% pgp -ka KEYS
+% pgp james-version.tar.gz.asc
+ +or
+ +% gpg --import KEYS
+% gpg --verify james-version.tar.gz.asc +

+ +
+ +
+ +

The software listed above represents the latest Release Build +available from the Apache James Project. From time to time, we also +make available Test Builds. These Test Builds are periodic +snapshots during development. Generally, these are considered +stable snapshots, but they have not undergone as much testing as a +Release Build, nor have they been voted upon for release by the +developer community. These are simply convenient test builds. +Sometimes the purpose for a Test Build could be soliciting feedback on +a specific change. Test Builds are announced on the General mailing +list (general@james.apache.org).

+ +Latest Test Build + +
+ +
+ + diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml new file mode 100644 index 00000000000..d0ddcd4139f --- /dev/null +++ b/src/site/xdoc/index.xml @@ -0,0 +1,46 @@ + + + + Overview + JAMES Project Web Team + + +
+

The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

+

JAMES is organized into subprojects with JAMES Server and the Mailet API as their core.

+

Apache JAMEs is a project of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.

+

The ASF maintains other Java projects which may also be of interest. These are detailed on the ASF Projects page.

+

We recommended that users of JAMES products subscribe to the JAMES users mailing list.

+
+
+
+
+ + ApacheCon US 2006 +
+ +

JAMES Server 2.3.0 RC3 Released

+

James PMC is proud to announce the availability of the third, and hopefully last, release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

+

New development roadmaps are being discussed right now, so stay tuned for 2.3.0 final and for the following news. - Sep/2006

+

JAMES Products website revamped

+

We just finished a major update of james products to be able to publish each product specific site under this new website structure - Aug/2006

+

JAMES Server 2.3.0 on the way

+

After a long time of development we have released the first release candidate of JAMES Server 2.3.0. After a period of user testing version 2.3.0 will be released. - Jul/2006

+

New project JAMES jSPF

+

JAMES PMC is happy to announce that we are working on a Java implementation of the SPF specification. The first betas are already available for download. - Jul/2006

+ + +

JAMES PMC react to the closure of Apache Avalon.

+

JAMES PMC would like to reassure all of our users that JAMES Server is alive and well. All of the James team have kept abreast of the Avalon developments culminating in the closure of the Avalon project and dispersal of its codebase. We are are keen to stress that this has little impact on our ability to support and develop Server in both the short and long terms.
Over the coming months we will be finalising and publishing a road map for JAMES Server which will address all of the specific concerns raised by Avalon's closure, but rest assured JAMES Server' future is safe, and we have enthusiasm and plans aplenty.
In the meantime we would like to extend our best wishes to all our friends from Avalon, here's luck with your future projects guys!
If you are at all concerned please subscribe to the server-user mailing list and raise your points there. - 05/Jan/2005

+ +

JAMES product sources have moved to "Subversion"

+

Subversion is a version control system like CVS, but it has advantages over CVS for Apache Software Foundation (ASF) projects.
In common with all other ASF projects we have reviewed our use of CVS and migrated our code to Subversion.
+Have a look at this FAQ for further details. - 05/Jan/2005

+

+ +

+ + diff --git a/src/site/xdoc/license.xml b/src/site/xdoc/license.xml new file mode 100644 index 00000000000..06475cf8c68 --- /dev/null +++ b/src/site/xdoc/license.xml @@ -0,0 +1,208 @@ + + + + + + Apache Software License + Serge Knystautas + + + +
+

+ James is released under the Apache Software License + listed below: +

+ + + +
+ +
+

+ dnsjava is distributed with James, a copy of the licence is contained in the distribution +

+
+ + + + diff --git a/src/site/xdoc/mail.xml b/src/site/xdoc/mail.xml new file mode 100644 index 00000000000..5919d820f48 --- /dev/null +++ b/src/site/xdoc/mail.xml @@ -0,0 +1,249 @@ + + + + + Mailing lists + James Project Web Team + + +
+

This is a living +document that provides details of mailing lists and guidelines for their +use for the Apache James project.
Please read the whole document +and find a list of available mailinglists at the bottom of the +page.
Last Updated June 2006.

+
+
+

A mailing list is an electronic discussion forum +that anyone can subscribe to. When someone sends an email message to the +mailing list, a copy of that message is broadcast to everyone who is +subscribed to that mailing list. Mailing lists provide a simple and +effective communication mechanism for discussion and decision making. +

+

The Apache Software Foundation has well established reasons for +using email and not other types of forum.
We are +not interested in hearing proposals to use NNTP (news +groups) or web forums or any other medium.
You may use a mail-news +gateway, gmail or anything else you like but email is, and will remain, +the official medium.

+

With potentially thousands of subscribers, +there is a common etiquette that you should observe. Please keep on +reading.

+

+ Respect the mailing list type +

+

+

    +
  • "User" lists are lists where you can send questions +and comments about configuration, setup, usage and other "user" types of +questions.
    • +
  • "Developer" lists are lists where you can send +questions, comments and contributions about the project's software +source code and general "development" types of questions.
    • +
+

+

Some questions are appropriate for posting on both the +"user" and the "developer" lists. In this case, pick one and only one. +Do not cross post.

+

Asking a configuration question on the +developers list is frowned upon because developers' time is as precious +as yours. By contacting them directly instead of the users list you are +abusing resources. It is unlikely that you will get a quicker answer +this way, those developers who have time to devote to providing support +are also subscribed to the users list. If you contact individuals +directly, or post your user issues to the developer list you may get no +answer at all.

+

+ Join the lists that are appropriate for +your discussion. +
Please make sure that you are joining +the list that is appropriate for the topic that you would like to +discuss. The general list is for discussions about the management and +direction of the James project, not for "general support".

+

+ Ask smart questions. +
+ +Every volunteer project obtains its strength from the people involved in +it. You are welcome to join any of our mailing lists. You can choose to +lurk, or actively participate; it's up to you. The level of community +responsiveness to specific questions is generally directly proportional +to the amount of effort you spend formulating your question. Eric +Raymond and Rick Moen have even written an essay entitled "Asking +Smart Questions" precisely on this topic. Although somewhat +militant, it is definitely worth reading.
+ Note: Please do +NOT send your Java problems to the two authors. They welcome feedback on +the FAQ's contents, but are simply not a Java help resource. Follow the +essay's advice and choose +your forum carefully.

+

+ Keep your email short and to +the point. +
If your email is more than about a page of +text, chances are that it won't get read by very many people. It is much +better to try to pack a lot of informative information (see above about +asking smart questions) into as small of an email as possible. If you +are replying to a previous email only quote the parts that you are +replying to and to remove the unnecessary bits. This makes it easier for +people to follow a thread as well as making the email archives easier to +search and read.

+

+ Do your best to ensure that you are +not sending HTML or "Stylelized" email to the list. +
If +you are using Outlook or Outlook Express or Eudora, chances are that you +are sending HTML email by default. There is usually a setting that will +allow you to send "Plain Text" email. If you are using Microsoft +products to send email, there are several bugs in the software that +prevent you from turning off the sending of HTML email. Please read this +page as well...

+

+ Watch +where you are sending email. +
The majority of our mailing +lists have set the Reply-To to go back to the list. That means that when +you Reply to a message, it will go to the list and not to the original +author directly. The reason is because it helps facilitate discussion on +the list for everyone to benefit from. Be careful of this as sometimes +you may intend to reply to a message directly to someone instead of the +entire list. The appropriate contents of the Reply-To header is an +age-old debate that should not be brought up on the mailing lists. You +can examine opposing points of view condemning our +convention and +condoning it. Bringing this up for debate on a mailing list will add +nothing new and is considered off-topic. +

+

+ Do not +cross post messages. +
In other words, pick one mailing +list and send your messages to that mailing list only. Do not send your +messages to multiple mailing lists. The reason is that people may be +subscribed to one list and not to the other. Therefore, some people will +only see part of the conversation.

+
+
+

There are several sites on the net that archive and +provide searching for our mailing lists in HTML readable format. If a +list is not there, then feel free to take initiative and submit it for +us via jakarta-general mailing list. +

+

+

+

+
+
+

+ Now that you have +read the guidelines above please subscribe to our lists and join our +community.

+ +

+ Low +Traffic + Subscribe + Unsubscribe + Guidelines + +Archive +

+

This is the list where users of the Apache James +(Server) meet and discuss issues. Developers are also expected to be +subscribed to this list to offer support to users of Apache James +(Server).

+ + +

+ Low Traffic + Subscribe + Unsubscribe + Guidelines + +Archive +

+

This is the list where participating developers of +the the Apache James Project meet and discuss issues, code +changes/additions, etc. Subscribers to this list get notices of each and +every code change, build results, testing notices, etc. Do not send +mail to this list with usage questions or configuration problems -- +that's what server-user@james is for.

+ + +

+ Very Low Traffic + Subscribe + Unsubscribe + Guidelines + +Archive +

+

This is the list where participating developers of +the the Apache James project discuss changes/additions to the James +websites etc. Subscribers to this list get notifications of every commit +of the website reaourcesDo not send mail to this list with James +software problems -- that's what server-user@james is for.

+ + +

+ Low +Traffic + Subscribe + Unsubscribe + Guidelines + +

+

This is the list for general discussions +relating to the running of the project, it is the public list of the +James project management comittee (PMC) and is a public list open to +all. Do not send mail to this list with James software problems +-- that's what server-user@james is for.

+ +
+ + diff --git a/src/site/xdoc/weare.xml b/src/site/xdoc/weare.xml new file mode 100644 index 00000000000..eab3e15ad63 --- /dev/null +++ b/src/site/xdoc/weare.xml @@ -0,0 +1,172 @@ + + + + + Who We Are + James Project Web Team + + +
+

Special thanks go to the following people for their contributions to this project. We also appreciate documentation, feedback, and bug reports. This is a living document that describes the key contributors to James. Last Updated July 2006.

+
+
+

+ Serge Knystautas (sergek at lokitech.com) (SK) +
Serge was the original donator of the James code, which has since been massively improved by people smarter than him. He tries to answer questions on the listserv and make code contributions when he does get a rare bit of free time.

+

+ Harmeet Bedi (harmeet at kodemuse.com) (HB) +

+

+ Danny Angus (danny at apache.org) (DA) +
Danny is a member of the Apache Software Foundation and married father of two by night, and by day works as lead technical consultant for the Student Loans Company ltd. +

+

+ Noel J. Bergman (noel at devtech.com) (NjB) +

+

+ Vincenzo Gianferrari Pini (vincenzo.gianferraripini at praxis.it) [VGP] +

+

+ Soeren Hilmer (sh at widetrail.dk) [SH] +

+

+ Steve Brewin (sbrewin at synsys.com) [SB] +

+

+ Jason Webb (jw at inovem.com) [JW] +

+

+ Stefano Bagnara (apache at bago.org) [SB2] +

+

+ Norman Maurer (nm at byteaction.de) [NM] +

+

+ Bernd Fondermann (bf_jak at brainlounge.de) [BF] +

+ +
+
+

Many people have had a hand in James' success over the years, here we'd like to give credit to those who have made a difference and to those who have left.

+

+ Alan D. Cabrera (list at toolazydogs.com) [ADC] +

+

+ Darrell DeBoer (DD) +

+

+ Stephen J. McConnell (mcconnell at apache.org) (SJM) +

+

+ Peter M. Goldstein (farsight at alum.mit.edu) (PG) +

+

+ Pete Donald (PD) +

+

+ Charles Benett (charles at benett1.demon.co.uk) (CB) +

+

+ Federico Barbieri, (scoobie at systemy.it) (FB) +

+

+ Stuart Roebuck, stuart.roebuck at adolos.co.uk (SR) +

+

+ Ivan Seskar, iseskar at upsideweb.com (IS) +

+

+ Prasanna Uppaladadium, prasanna at vayusphere.com (PU) +

+

+ Gabriel Bucher, gabriel.bucher at razor.ch (GB) +

+

+ Matthew Pangaro, mattp at lokitech.com (MP) +

+

+ Jason Borden, jborden at javasense.com (JB) +

+

+ Randy Stanard (rstanard at lokitech.com) (RS) +
Contributed the James logo.

+

+ Samuel Sadek (Samuel.Sadek at kpmg.co.uk) (SS) +

+

+ Stephan Schiessling (s at rapi.com) (SS2) +

+

+ Eung-ju Park (colus at apache.org) (EP) +

+

+ Paul Hammant (Paul_Hammant at yahoo.com) (PH) +

+

+ Jeff Keyser (JKeyser at telocity.com) (JK) +

+

+ Andrei Ivanov (myfam at surfeu.fi) (AI) +

+

+ Brad Walker (bwalker at studentadvantage.com) (BW) +

+

+ Christian Buchegger (christian.buchegger at planet-interkom.de) (CB2) +

+

+ Shilpa Dalmia (shilpa at postx.com) (SD) +

+

+ Steve Short (sshort at postx.com) (SS3) +

+

+ Aaron Knauf (aknauf at xtra.co.nz) (AK) +

+

+ Serge "Sergei" Sozonoff (serge at globalbeach.com) (SS4) +

+

+ Kai Londenberg (kai.londenberg at my-vwclub.de) [KL] +

+

+ Mark Imel (james at imelshire.com) [MI] +

+

+ Kevin Schmidt (ktschmidt at earthlink.net) [KS] +

+

+ Hontvari Jozsef (hontvari2 at solware.com) [HJ] +

+

+ Cesar Bonadio (bonadio at picture.com.br) [CB3] +

+

+ Marco Tedone (mtedone at jemos.org) [MT] +

+

+ Tim Stephenson (tim at thestephensons.me.uk) [TS] +

+

+ Richard O. Hammer (rohammer at earthlink.net) [ROH] +

+
+ + From e5db35b2020d9455f34e000251228d3377e1ff3b Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 30 Sep 2006 17:20:44 +0000 Subject: [PATCH 002/541] Make space for root folders git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@451620 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 56 - .../src/main/resources/css/maven-theme.css | 257 - .../main/resources/images/button-bottom.gif | Bin 590 -> 0 bytes .../src/main/resources/images/button-top.gif | Bin 392 -> 0 bytes .../src/main/resources/images/collapsed.gif | Bin 53 -> 0 bytes .../src/main/resources/images/expanded.gif | Bin 52 -> 0 bytes .../src/main/resources/images/external.png | Bin 230 -> 0 bytes .../src/main/resources/images/h2feather.gif | Bin 360 -> 0 bytes maven-skin/src/main/resources/images/h4.jpg | Bin 360 -> 0 bytes .../main/resources/images/icon_error_sml.gif | Bin 1010 -> 0 bytes .../main/resources/images/icon_info_sml.gif | Bin 606 -> 0 bytes .../resources/images/icon_success_sml.gif | Bin 990 -> 0 bytes .../resources/images/icon_warning_sml.gif | Bin 576 -> 0 bytes .../src/main/resources/images/newwindow.png | Bin 220 -> 0 bytes maven-skin/src/main/resources/images/void.gif | Bin 50 -> 0 bytes server/2.2.0/pom.xml | 52 - .../resources/images/asf-logo-reduced.gif | Bin 6636 -> 0 bytes .../resources/images/james-server-logo.gif | Bin 6944 -> 0 bytes server/2.2.0/src/site/site.xml | 53 - server/2.2.0/src/site/xdoc/adding_users.xml | 58 - .../src/site/xdoc/build_instructions.xml | 79 - server/2.2.0/src/site/xdoc/changelog.xml | 446 -- server/2.2.0/src/site/xdoc/custom_mailet.xml | 117 - server/2.2.0/src/site/xdoc/custom_matcher.xml | 128 - .../2.2.0/src/site/xdoc/dns_configuration.xml | 59 - .../src/site/xdoc/fetchmail_configuration.xml | 967 --- .../src/site/xdoc/fetchpop_configuration.xml | 105 - server/2.2.0/src/site/xdoc/index.xml | 104 - .../site/xdoc/installation_instructions.xml | 110 - .../src/site/xdoc/james_and_sendmail.xml | 124 - server/2.2.0/src/site/xdoc/mailet_api.xml | 51 - server/2.2.0/src/site/xdoc/mailing_lists.xml | 115 - .../src/site/xdoc/nntp_configuration.xml | 98 - .../src/site/xdoc/pop3_configuration.xml | 74 - .../2.2.0/src/site/xdoc/provided_mailets.xml | 253 - .../2.2.0/src/site/xdoc/provided_matchers.xml | 186 - .../site/xdoc/remotemanager_configuration.xml | 78 - server/2.2.0/src/site/xdoc/repositories.xml | 86 - .../site/xdoc/serverwide_configuration.xml | 100 - server/2.2.0/src/site/xdoc/smtp_auth.xml | 70 - .../src/site/xdoc/smtp_configuration.xml | 85 - server/2.2.0/src/site/xdoc/spoolmanager.xml | 85 - .../site/xdoc/spoolmanager_configuration.xml | 99 - server/2.2.0/src/site/xdoc/summary.xml | 116 - server/2.2.0/src/site/xdoc/usingTLS.xml | 89 - server/2.2.0/src/site/xdoc/using_database.xml | 143 - server/pom.xml | 94 - server/src/site/resources/css/site.css | 31 - .../resources/images/asf-logo-reduced.gif | Bin 6636 -> 0 bytes .../resources/images/james-server-logo.gif | Bin 6944 -> 0 bytes .../images/james_config_load_balance.png | Bin 3645 -> 0 bytes .../images/james_config_secondary.png | Bin 5758 -> 0 bytes .../images/james_config_smart_host.png | Bin 3266 -> 0 bytes .../site/resources/rfclist/basic/rfc0822.txt | 2902 --------- .../site/resources/rfclist/basic/rfc1123.txt | 5781 ----------------- .../site/resources/rfclist/basic/rfc2045.txt | 1740 ----- .../site/resources/rfclist/basic/rfc2046.txt | 2468 ------- .../site/resources/rfclist/basic/rfc2822.txt | 2858 -------- .../site/resources/rfclist/imap4/rfc1731.txt | 340 - .../site/resources/rfclist/imap4/rfc2060.txt | 4596 ------------- .../site/resources/rfclist/imap4/rfc2086.txt | 452 -- .../site/resources/rfclist/imap4/rfc2087.txt | 284 - .../site/resources/rfclist/imap4/rfc2088.txt | 116 - .../site/resources/rfclist/imap4/rfc2177.txt | 228 - .../site/resources/rfclist/imap4/rfc2180.txt | 787 --- .../site/resources/rfclist/imap4/rfc2192.txt | 900 --- .../site/resources/rfclist/imap4/rfc2193.txt | 508 -- .../site/resources/rfclist/imap4/rfc2195.txt | 284 - .../site/resources/rfclist/imap4/rfc2221.txt | 284 - .../site/resources/rfclist/imap4/rfc2342.txt | 564 -- .../site/resources/rfclist/imap4/rfc2359.txt | 340 - .../site/resources/rfclist/imap4/rfc2595.txt | 843 --- .../site/resources/rfclist/imap4/rfc2683.txt | 1291 ---- .../site/resources/rfclist/ldap/rfc2251.txt | 2803 -------- .../site/resources/rfclist/ldap/rfc2252.txt | 1388 ---- .../site/resources/rfclist/ldap/rfc2253.txt | 470 -- .../site/resources/rfclist/ldap/rfc2254.txt | 451 -- .../site/resources/rfclist/ldap/rfc2255.txt | 423 -- .../site/resources/rfclist/ldap/rfc2256.txt | 1137 ---- .../site/resources/rfclist/ldap/rfc2829.txt | 865 --- .../site/resources/rfclist/ldap/rfc2830.txt | 419 -- .../site/resources/rfclist/ldap/rfc3377.txt | 339 - .../nntp/draft-ietf-nntpext-base-13.txt | 3270 ---------- .../site/resources/rfclist/nntp/rfc0977.txt | 1540 ----- .../site/resources/rfclist/nntp/rfc1036.txt | 1068 --- .../site/resources/rfclist/nntp/rfc2980.txt | 1516 ----- .../site/resources/rfclist/pop3/rfc1725.txt | 1012 --- .../site/resources/rfclist/pop3/rfc1734.txt | 284 - .../site/resources/rfclist/pop3/rfc1939.txt | 1290 ---- .../site/resources/rfclist/smtp/rfc0821.txt | 4051 ------------ .../site/resources/rfclist/smtp/rfc0974.txt | 365 -- .../site/resources/rfclist/smtp/rfc1652.txt | 340 - .../site/resources/rfclist/smtp/rfc1830.txt | 452 -- .../site/resources/rfclist/smtp/rfc1869.txt | 620 -- .../site/resources/rfclist/smtp/rfc1870.txt | 508 -- .../site/resources/rfclist/smtp/rfc1891.txt | 521 -- .../site/resources/rfclist/smtp/rfc1893.txt | 844 --- .../site/resources/rfclist/smtp/rfc1985.txt | 396 -- .../site/resources/rfclist/smtp/rfc2034.txt | 340 - .../site/resources/rfclist/smtp/rfc2142.txt | 338 - .../site/resources/rfclist/smtp/rfc2197.txt | 452 -- .../site/resources/rfclist/smtp/rfc2554.txt | 620 -- .../site/resources/rfclist/smtp/rfc2821.txt | 4426 ------------- server/src/site/site.xml | 57 - server/src/site/xdoc/FAQ.xml | 318 - .../site/xdoc/archive/announcement_2_1.xml | 57 - .../site/xdoc/archive/architecture_v1_2.xml | 51 - .../site/xdoc/archive/architecture_v2_0.xml | 55 - .../site/xdoc/archive/configuration_v2_0.xml | 716 -- .../site/xdoc/archive/document_archive.xml | 54 - server/src/site/xdoc/archive/install.xml | 113 - .../src/site/xdoc/archive/usingJDBC_v2.0.xml | 174 - .../src/site/xdoc/archive/usingLDAP_v1_2.xml | 185 - .../src/site/xdoc/archive/usingTLS_v1_2.xml | 96 - server/src/site/xdoc/design_objectives.xml | 122 - server/src/site/xdoc/index.xml | 131 - server/src/site/xdoc/rfclist.xml | 93 - server/src/site/xdoc/todo.xml | 109 - src/site/resources/css/site.css | 13 - src/site/resources/download.cgi | 6 - src/site/resources/favicon.ico | Bin 3638 -> 0 bytes .../resources/images/asf-logo-reduced.gif | Bin 6636 -> 0 bytes .../resources/images/james-project-logo.gif | Bin 7227 -> 0 bytes src/site/resources/robots.txt | 5 - src/site/site.xml | 113 - src/site/xdoc/code-standards.xml | 97 - src/site/xdoc/contribute.xml | 112 - src/site/xdoc/download.xml | 159 - src/site/xdoc/index.xml | 46 - src/site/xdoc/license.xml | 208 - src/site/xdoc/mail.xml | 249 - src/site/xdoc/weare.xml | 172 - 132 files changed, 68193 deletions(-) delete mode 100644 maven-skin/pom.xml delete mode 100644 maven-skin/src/main/resources/css/maven-theme.css delete mode 100644 maven-skin/src/main/resources/images/button-bottom.gif delete mode 100644 maven-skin/src/main/resources/images/button-top.gif delete mode 100644 maven-skin/src/main/resources/images/collapsed.gif delete mode 100644 maven-skin/src/main/resources/images/expanded.gif delete mode 100644 maven-skin/src/main/resources/images/external.png delete mode 100644 maven-skin/src/main/resources/images/h2feather.gif delete mode 100644 maven-skin/src/main/resources/images/h4.jpg delete mode 100644 maven-skin/src/main/resources/images/icon_error_sml.gif delete mode 100644 maven-skin/src/main/resources/images/icon_info_sml.gif delete mode 100644 maven-skin/src/main/resources/images/icon_success_sml.gif delete mode 100644 maven-skin/src/main/resources/images/icon_warning_sml.gif delete mode 100644 maven-skin/src/main/resources/images/newwindow.png delete mode 100644 maven-skin/src/main/resources/images/void.gif delete mode 100644 server/2.2.0/pom.xml delete mode 100644 server/2.2.0/src/site/resources/images/asf-logo-reduced.gif delete mode 100644 server/2.2.0/src/site/resources/images/james-server-logo.gif delete mode 100644 server/2.2.0/src/site/site.xml delete mode 100644 server/2.2.0/src/site/xdoc/adding_users.xml delete mode 100644 server/2.2.0/src/site/xdoc/build_instructions.xml delete mode 100644 server/2.2.0/src/site/xdoc/changelog.xml delete mode 100644 server/2.2.0/src/site/xdoc/custom_mailet.xml delete mode 100644 server/2.2.0/src/site/xdoc/custom_matcher.xml delete mode 100755 server/2.2.0/src/site/xdoc/dns_configuration.xml delete mode 100755 server/2.2.0/src/site/xdoc/fetchmail_configuration.xml delete mode 100644 server/2.2.0/src/site/xdoc/fetchpop_configuration.xml delete mode 100644 server/2.2.0/src/site/xdoc/index.xml delete mode 100644 server/2.2.0/src/site/xdoc/installation_instructions.xml delete mode 100644 server/2.2.0/src/site/xdoc/james_and_sendmail.xml delete mode 100644 server/2.2.0/src/site/xdoc/mailet_api.xml delete mode 100644 server/2.2.0/src/site/xdoc/mailing_lists.xml delete mode 100644 server/2.2.0/src/site/xdoc/nntp_configuration.xml delete mode 100644 server/2.2.0/src/site/xdoc/pop3_configuration.xml delete mode 100644 server/2.2.0/src/site/xdoc/provided_mailets.xml delete mode 100644 server/2.2.0/src/site/xdoc/provided_matchers.xml delete mode 100644 server/2.2.0/src/site/xdoc/remotemanager_configuration.xml delete mode 100644 server/2.2.0/src/site/xdoc/repositories.xml delete mode 100644 server/2.2.0/src/site/xdoc/serverwide_configuration.xml delete mode 100644 server/2.2.0/src/site/xdoc/smtp_auth.xml delete mode 100644 server/2.2.0/src/site/xdoc/smtp_configuration.xml delete mode 100644 server/2.2.0/src/site/xdoc/spoolmanager.xml delete mode 100644 server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml delete mode 100644 server/2.2.0/src/site/xdoc/summary.xml delete mode 100644 server/2.2.0/src/site/xdoc/usingTLS.xml delete mode 100644 server/2.2.0/src/site/xdoc/using_database.xml delete mode 100644 server/pom.xml delete mode 100644 server/src/site/resources/css/site.css delete mode 100644 server/src/site/resources/images/asf-logo-reduced.gif delete mode 100644 server/src/site/resources/images/james-server-logo.gif delete mode 100644 server/src/site/resources/images/james_config_load_balance.png delete mode 100644 server/src/site/resources/images/james_config_secondary.png delete mode 100644 server/src/site/resources/images/james_config_smart_host.png delete mode 100644 server/src/site/resources/rfclist/basic/rfc0822.txt delete mode 100644 server/src/site/resources/rfclist/basic/rfc1123.txt delete mode 100644 server/src/site/resources/rfclist/basic/rfc2045.txt delete mode 100644 server/src/site/resources/rfclist/basic/rfc2046.txt delete mode 100644 server/src/site/resources/rfclist/basic/rfc2822.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc1731.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2060.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2086.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2087.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2088.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2177.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2180.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2192.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2193.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2195.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2221.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2342.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2359.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2595.txt delete mode 100644 server/src/site/resources/rfclist/imap4/rfc2683.txt delete mode 100644 server/src/site/resources/rfclist/ldap/rfc2251.txt delete mode 100644 server/src/site/resources/rfclist/ldap/rfc2252.txt delete mode 100644 server/src/site/resources/rfclist/ldap/rfc2253.txt delete mode 100644 server/src/site/resources/rfclist/ldap/rfc2254.txt delete mode 100644 server/src/site/resources/rfclist/ldap/rfc2255.txt delete mode 100644 server/src/site/resources/rfclist/ldap/rfc2256.txt delete mode 100644 server/src/site/resources/rfclist/ldap/rfc2829.txt delete mode 100644 server/src/site/resources/rfclist/ldap/rfc2830.txt delete mode 100644 server/src/site/resources/rfclist/ldap/rfc3377.txt delete mode 100644 server/src/site/resources/rfclist/nntp/draft-ietf-nntpext-base-13.txt delete mode 100644 server/src/site/resources/rfclist/nntp/rfc0977.txt delete mode 100644 server/src/site/resources/rfclist/nntp/rfc1036.txt delete mode 100644 server/src/site/resources/rfclist/nntp/rfc2980.txt delete mode 100644 server/src/site/resources/rfclist/pop3/rfc1725.txt delete mode 100644 server/src/site/resources/rfclist/pop3/rfc1734.txt delete mode 100644 server/src/site/resources/rfclist/pop3/rfc1939.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc0821.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc0974.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc1652.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc1830.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc1869.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc1870.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc1891.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc1893.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc1985.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc2034.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc2142.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc2197.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc2554.txt delete mode 100644 server/src/site/resources/rfclist/smtp/rfc2821.txt delete mode 100644 server/src/site/site.xml delete mode 100644 server/src/site/xdoc/FAQ.xml delete mode 100755 server/src/site/xdoc/archive/announcement_2_1.xml delete mode 100644 server/src/site/xdoc/archive/architecture_v1_2.xml delete mode 100644 server/src/site/xdoc/archive/architecture_v2_0.xml delete mode 100644 server/src/site/xdoc/archive/configuration_v2_0.xml delete mode 100644 server/src/site/xdoc/archive/document_archive.xml delete mode 100644 server/src/site/xdoc/archive/install.xml delete mode 100644 server/src/site/xdoc/archive/usingJDBC_v2.0.xml delete mode 100644 server/src/site/xdoc/archive/usingLDAP_v1_2.xml delete mode 100644 server/src/site/xdoc/archive/usingTLS_v1_2.xml delete mode 100644 server/src/site/xdoc/design_objectives.xml delete mode 100644 server/src/site/xdoc/index.xml delete mode 100644 server/src/site/xdoc/rfclist.xml delete mode 100644 server/src/site/xdoc/todo.xml delete mode 100644 src/site/resources/css/site.css delete mode 100644 src/site/resources/download.cgi delete mode 100644 src/site/resources/favicon.ico delete mode 100644 src/site/resources/images/asf-logo-reduced.gif delete mode 100644 src/site/resources/images/james-project-logo.gif delete mode 100644 src/site/resources/robots.txt delete mode 100644 src/site/site.xml delete mode 100644 src/site/xdoc/code-standards.xml delete mode 100644 src/site/xdoc/contribute.xml delete mode 100644 src/site/xdoc/download.xml delete mode 100644 src/site/xdoc/index.xml delete mode 100644 src/site/xdoc/license.xml delete mode 100644 src/site/xdoc/mail.xml delete mode 100644 src/site/xdoc/weare.xml diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml deleted file mode 100644 index d5fc06ca6df..00000000000 --- a/maven-skin/pom.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - 4.0.0 - org.apache.james - maven-skin - 1.1-SNAPSHOT - JAMES Skin - Apache JAMES Official Maven2 Site Skin - - - - - apache.snapshots - Apache Development Snapshot Repository - scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository - - - maven-skin-website - scp://minotaur.apache.org/www/james.apache.org/maven-skin - - - - - - - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/maven-skin - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/maven-skin - http://svn.apache.org/viewvc/james/project/trunk/maven-skin - - - \ No newline at end of file diff --git a/maven-skin/src/main/resources/css/maven-theme.css b/maven-skin/src/main/resources/css/maven-theme.css deleted file mode 100644 index 19ac0cbae3c..00000000000 --- a/maven-skin/src/main/resources/css/maven-theme.css +++ /dev/null @@ -1,257 +0,0 @@ -/* - Licensed to the Apache Software Foundation (ASF) under one - or more contributor license agreements. See the NOTICE file - distributed with this work for additional information - regarding copyright ownership. The ASF licenses this file - to you under the Apache License, Version 2.0 (the - "License"); you may not use this file except in compliance - with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, - software distributed under the License is distributed on an - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - KIND, either express or implied. See the License for the - specific language governing permissions and limitations - under the License. -*/ - -#apacheconbox { - margin: 20px 0px 0px 20px; - padding: 10px; - border: 1px solid #ccc; - background-color: white; - background-image: url(../images/button-top.gif); - background-repeat: repeat-x; -} -#apacheconspacer { - float: right; - margin: 0px 0px 10px 10px; - background-color: white; -} -#poweredBy { - display: none; -} -.xleft { - float: right; -} -.xright { - float: left; -} -#bannerLeft img { - margin-left: 20px; -} -#bannerRight img { - padding: 0px; - border: 0px; - margin-top: 20px; - margin-right: 20px; - margin-bottom: 0px; -} -body { - padding: 0px 0px 10px 0px; -} -body, td, select, input, li{ - font-family: Verdana, Helvetica, Arial, sans-serif; - font-size: 13px; -} -code{ - font-family: Courier, monospace; - font-size: 13px; -} -a { - text-decoration: none; -} -a:link { - color:#36a; -} -a:visited { - color:#47a; -} -a:active, a:hover { - color:#69c; -} -#legend li.externalLink { - background: url(../images/external.png) left top no-repeat; - padding-left: 18px; -} -a.externalLink, a.externalLink:link, a.externalLink:visited, a.externalLink:active, a.externalLink:hover { - background: url(../images/external.png) right center no-repeat; - padding-right: 18px; -} -#legend li.newWindow { - background: url(../images/newwindow.png) left top no-repeat; - padding-left: 18px; -} -a.newWindow, a.newWindow:link, a.newWindow:visited, a.newWindow:active, a.newWindow:hover { - background: url(../images/newwindow.png) right center no-repeat; - padding-right: 18px; -} -.section { -margin-left: 10px; -} -.section p, .section table { -margin-left: 10px; -} -h2 { - color: #904040; - background-color: white; - border: 0px; - border-bottom: 2px solid #525D76; - padding: 0px; - padding-left: 20px; - vertical-align: bottom; - font-weight:900; - font-size: large; - background: url(../images/h2feather.gif) left center no-repeat; - margin-bottom: 15px; -} -h3 { - border: thin solid #828DA6; - padding-bottom: 0px; - color: #525D76; - background-color: white; - padding: 2px 2px 2px 2px; - border: 0px; - font-weight: bold; - font-size: 15px; - margin-top: 5px; - margin-bottom: 13px; - border-bottom: 1px dotted #525D76; -} -h4 { - padding: 2px 2px 2px 2px; - border: 0px; - background: url(../images/h4.jpg) 0% 70% no-repeat; - color: black; - margin-top: 5px; - padding-left: 12px; - background-color: #fff; - font-weight: bold; - font-size: small; - margin-left: 10px; -} -h5 { - padding: 2px px 2px 2px; - border: 0px; - border-bottom: 0px; - color: black; - background-color: #fff; - font-weight: bold; - font-size: small; -} -p { - line-height: 1.3em; - font-size: small; -} -#breadcrumbs { - background: url(../images/button-top.gif) left top repeat; - border-top: 0px solid #525D76; - border-bottom: 1px solid #ccc; /* #525D76;*/ - border-top: 1px solid #ccc; - padding-top: 3px; - padding-bottom: 3px; - background-color: #eeeeee; - font-size: small; -} -#breadcrumbs a { - font-weight: bold; -} -#bodyColumn { -} -#leftColumn { - margin: 0px; - margin-top: -1px; - border: 0px; - padding: 0px; - padding-left: 20px; - background: none; -} -#leftColumn ul { - font-size: 15px; - padding-top: 4px; - padding-bottom: 10px; -} -#leftColumn li { - padding-left: 10px; - padding-bottom: 3px; -} -#navcolumn { - border: 1px solid #ccc; /* #525D76;i*/ - background: url(../images/button-bottom.gif) left bottom no-repeat; - padding: 15px; - border-top: 0px solid white; - background-color: white; -} -#navcolumn h5 { - font-size: 12px; - border-bottom: 1px solid #eee; - padding-top: 3px; - padding-bottom: 2px; - margin-right: 10px; - color: #000; -} -table.bodyTable { - padding-right: 20px; -} -table.bodyTable th { - color: black; - background-color: #bbb; - text-align: left; - font-weight: bold; - border-top: 1px solid #ccc; - border-bottom: 1px solid #ccc; - background-image: url(../images/button-top.gif); -} -#footer { - border-top: 1px solid #ccc; - margin-top: 30px; - padding: 10px; - background-image: url(../images/button-top.gif); -} -table.bodyTable th, table.bodyTable td { - padding: 2px; - font-size: 1em; -} -table.bodyTable tr.a { - background-color: #fff; -} -table.bodyTable tr.a td { - border-bottom: 1px solid #eee; -} -table.bodyTable tr.b { - background-color: #fff; -} -table.bodyTable tr.b td { - border-bottom: 1px solid #ddd; -} -.source { - border: 1px solid #525D76; -} -dl { - padding: 4px 4px 4px 6px; - border: 1px solid #aaa; - background-color: #ffc; -} -dt { - color: #900; -} -#organizationLogo img, #projectLogo img, #projectLogo span{ - margin: 8px; -} -#banner img { - padding: 10px; -} -.errormark, .warningmark, .donemark, .infomark { - background: url(../images/icon_error_sml.gif) no-repeat; -} -.warningmark { - background-image: url(../images/icon_warning_sml.gif); -} -.donemark { - background-image: url(../images/icon_success_sml.gif); -} -.infomark { - background-image: url(../images/icon_info_sml.gif); -} diff --git a/maven-skin/src/main/resources/images/button-bottom.gif b/maven-skin/src/main/resources/images/button-bottom.gif deleted file mode 100644 index 4c992992537acd3ae629ee046c446d68dad05deb..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 590 zcmV-U0M)j$~<`D4?!v>%MR- z&vb3yc&_h!@BhG{a7Zi~kI1BQ$!t2G(CBkOty-_xtai)odcWYXcuX#v&*-#z&2GEj z@VIs;jK6uCK7Mva__cwzs&sx}68TzQ4f1!o$SH#>dFX%FE2n&d<=%($mz{*4NnC z+S}aSzzyKx;^XAy=I7|?>g(+7?(gvN^7Hid_5}F(`uqI-{{H|23LHqVpuvL(6DnND zu%W|;5F<*QNU@^Dix~GM*vPS?$B!WYLy8oJq5$&6_xL z>fGtkfzO{ng9;r=w5ZXeNRujE%CxD|r%fOt?uiw9b0}CEZxUk{Fh!ZPb%($`R$B-jSo=my2 z<;$2e^HspPv**vCLyI0wy0q!js8g$6&APSg*RW&Do=v;9?c2C>>)y@#bAjK$g9{%{ zytwh>$dfBy&b+zv=g^}|pH98H_3PNPYv0bjyZ7(H7l)+46zyJRL1}IKEy*TU5yZ@lqjAUt^XsWJk>%MUO zB6Mxvc&_h!@BhG{5LhT0kI1BQ$!t2G(5Q48U0AQ!tai)odcWYXcuW>6&gisy&2GEj z@VIs;jK6uCK7J2eY)bwzs&sy1Tr+zQ4f1zX8O>#>dFX%FE2n&d<=%($E9d*4NnC z+S}aS-rwNi;^W}}=I7|?>g(+7?(gvN^7Hia4EOl?`uqI-{{H|23LHqVpuvL(6DnND zu%W|;5F<*QNU@^Dix@L%+{m$`$B!UALy8oJq5$&6_xL m>fFh*r_Y~2g9;r=w5ZXeNRujE%CxD|r%#h)yUTnvm1Iv_qshJlI4r7uBZ*YkPFU8d4p4Aua}2?(?R diff --git a/maven-skin/src/main/resources/images/expanded.gif b/maven-skin/src/main/resources/images/expanded.gif deleted file mode 100644 index 0fef3d89e0df1f8bc49a0cd827f2607c7d7fd2f0..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 52 xcmZ?wbhEHbWM^P!XkdT>#h)yUTnvm1Iv_qshJlH@g}+fUi&t{amUB!D)&R0C2fzRT diff --git a/maven-skin/src/main/resources/images/external.png b/maven-skin/src/main/resources/images/external.png deleted file mode 100644 index 3f999fc88b360074e41f38c3b4bc06ccb3bb7cf8..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 230 zcmeAS@N?(olHy`uVBq!ia0vp^+(699!3-oX?^2ToQY`6?zK#qG>ra@ocD)4hB}-f* zN`mv#O3D+9QW+dm@{>{(JaZG%Q-e|yQz{EjrrH1%@dWsUxR#cd{{R1fCIbVIy!atN z8e~{WkY6y6%iy53@(Yk3;OXKRQgJIOfsI*BO@UFsfhWLBc>*(#PB?Jn2*(o!76E4F z2oaVU3``tH+Kgs0GI5+@Tg}d)z%jd%F@?{8!SRZ5b1yT80-FZIMn)zc2Ca66y`pzY R*nws*Vde$l!dH+G>WG0AkX9 zkw^kO#R5~f0aWVd+rdU|kr+Si_VM}o_L~4i{{R1E0Y;4gL(m&pmH<-GRdQ4VNXrIK zG6p+K1xfSs^r&!}(M4+c|NmbFUeHl(I7LJBadO19Z?}R=@%Qb_ zUw+eqhx6az`t$SLbC2rg!|?j`%n?`h`T2zbUHbd|`u_XaJz1}qOsSPq;ibOfx3Eta zLjV8&A^8LV00000EC2ui01p5Z000JsK#Ak_D;keQ$Ij$IIwdNdtL8+?R*)8|YNQ-2 zmP~p<114LCg84U{-IRaz?G&UR! zDO+4I4H_B@0~A~@GzlCwAS{CoA{{h6WH2YD69{BK2CO~+a%4OoBm@DsKLG>;#6=#+ GK>$0AHKMBk diff --git a/maven-skin/src/main/resources/images/h4.jpg b/maven-skin/src/main/resources/images/h4.jpg deleted file mode 100644 index 859f82f381a2c18f9768c9360ef25fcfa644bd8d..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 360 zcmex=;a)Bf!ASz{JdmkYQwEW?*3z5*7r?ih_KO3P6U53StNg{=db*12l$7kXewy zp5f~3U3Y#L@2O4RYA;f5TH-V*;+uWii;P;?DJQfU_VT=Vx@&v)rhf(#|KH>S0HGN@ A3jhEB diff --git a/maven-skin/src/main/resources/images/icon_error_sml.gif b/maven-skin/src/main/resources/images/icon_error_sml.gif deleted file mode 100644 index 61132ef2b01806f6122c31d173c98e01e499b9a0..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 1010 zcmZ?wbhEHbJMCn#OVEqF*oew~oaAu*+mN;-=y?VHT3tIe$XQqrDo-uB_a z!$aaK`z6))OKGn34?nwc^SuifkIL#EmDgV_qjg-#8v*0u4q4%1moUw{LZ54UeCgzNF^jX`uv-XK+9g@yFrG9?@ z!9&5&Tgk*j(b!GF&{N4I-Owl3GNQ;Kslp@APSw&&&ux9d>WxL~{EYoKm2KHvv3+ax zZUYB?Ae*8JnchZheXeEaa>@87?_fB*jV>(`erUx0B6j@wa!KnN)QWMO1rn9HC8 zQU}Tt3>@bftT|;oHYhlHH8T8tc{qL2LBC1&wnQeg^-S05<#H=J%;q~&KX!$OXH$lP zifQJ#9>L8|xhAVRHT-xPa*}7JK>(A*!AmL!CQC~j>707p+C5b#ib-SZ5@wfn#-0y8 zor_pb3M^%mkXhlduwjw4dk@RWhYZ<*tSUAV9x3eYyi#^d39lH{872xT#>g14FgCZb z+Lvv}DClhGVU*`8y(Qe}(9I>Lw<6->0~Q`zX3oMH2272dBARI`0wDzxS_G8b_H+a` TZ#n2*^y*Bf^Krq04Gh)*dSnrT diff --git a/maven-skin/src/main/resources/images/icon_info_sml.gif b/maven-skin/src/main/resources/images/icon_info_sml.gif deleted file mode 100644 index c6cb9ad7ce438a798426703e86a7ffc197d51dbb..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 606 zcmZ?wbhEHb!Rj)7jHhhdgsOUdoQoueZi?7 z>>gViTe&E#V48n=mrru5S3;v}WQB8hiDz7$TU2Fg8RZkU)J)l4H+4sO@7jjxJ4?G(<~7c1nYFul=C0P+d#d`@bj{yi z-npcE!T#Qb2PP~z)H;3B%r(bntUlH>Y2~CvyV|C%UbyM>vTf&9?!2&e&!siHFV0_c zVB`KP8}?n^dg$7Yqc`@PxOMQ%-NWbZ9Xfk=)1K2OFF!hV;r{6>kIr6ua^~ve%eS9j zy7lbD`I|4_et!J??bq+WzI^-n`RfmdkOIfh!pgqYwSCK`t~@$#!^!1aj_y2mzyI{@?vuB79>2N$==JkApPs$`_~ygc*YCf)diVLp z{pXKfy#M&+`?nvze*gIk#Q*;N0|qHLXbBUFKUo+V7>XElKuSSz!oa?}p{S|3rL`#` zEj=M8CWV#D$GthOu#hRgfH^NPHz`Z6or!6tudIJkhF|)EqL_SUmH;#E=*;vU)ut4d z*}1MJ+3|6yK5|W*0YQlwY}}E_93D;*P3)($(!#iHyj&dYc$?gAB*f@)n?~7Mn)5Ze zB*b!gs&gB@F*e|Da`5(ac688Lp~TGAEh5PBlHo`4aV}w%hy?;49h(#+>`NXTD0Bjy;4ci{C-1K14rU#4Xoa9{m6qopA9n0cn|!>ecYkij zwyX=!4*mH3EoqLqSGiVbyFqxD(bS8XSDu{6U1jZO70Ic@{~t&7=B^ zBD)NOoAkU&Gy^LQJ5PtV?u{&65}4ZUmfYbweP{LTy^YnAGv=AGa7*6wj}%~b0?7r5!@qH7P%p1*$L z@#{ODxoUwG+WsY)zWExj-aqxpQS(e!bx&6L`u)?tfB$~}{{8*?cVO&*V`-G2NeC$Z zWMO1r=w{FXnGVVm3>>=|#5rX=HY{-DP?VFNPL-%m%>B+*~5-k^-+4*MLFr;tQ0}^rlS-^!^Q`Mx1hrB$jwn&hk~Xk=#Nl+_9Nu|Y$D G!5RQ;-6)O# diff --git a/maven-skin/src/main/resources/images/icon_warning_sml.gif b/maven-skin/src/main/resources/images/icon_warning_sml.gif deleted file mode 100644 index 873bbb52cb9768103c27fbb9a9bac16ac615fce5..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 576 zcmZ?wbhEHbB!Sy%bj7w z8LP{2I!WYbmF&-Ixi?j6tD|K1XR2M#l>Aw*aXL%wXS3nYW}{zi=4WzsU5r%E6qx+# za{AThd85YVOsT`KDUrWsBtGknIa3>Sy(4;AS@f^Dxt>-=XPXm#FD(1Lr2hBv=9?3X zZS^!XrNw@)>eiN((2|w-y>{aB1+99DGMA?}+UTggT+(Z*rf8+5x~aWVOGcurtl;&U zIa)H3I&#vwvQjJBn`YHj9iKlB7`)(M#!e{yWMO1rC}Yq8NrU2qfqia6SyOXMYa1sM zM_a34eqyRfcQbQJY;^IYGTuzaxglKLqNQEA}OiQec+sQ#rUUjLqg_MpsPmY43 zsgmVV8EHK$eV-B~6*UcAW2+w%1e4o&9#aAczLGF}PmMg|6J0Ey4q A)Bpeg diff --git a/maven-skin/src/main/resources/images/newwindow.png b/maven-skin/src/main/resources/images/newwindow.png deleted file mode 100644 index 6287f72bd08a870908e7361d98c35ee0d6dcbc82..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 220 zcmeAS@N?(olHy`uVBq!ia0vp^+(699!3-oX?^2ToQY`6?zK#qG>ra@ocD)4hB}-f* zN`mv#O3D+9QW+dm@{>{(JaZG%Q-e|yQz{EjrrH1%@dWsUxR#cd&SYTt4+aeuCvSob zD+%%o1`04ZXs!GLj7%Iec?BF2%&y2ZFfeUwWbk2P5nvW+xWT~4#-PT{uyM;F);OSv44$rjF6*2U FngH~|K)3(^ diff --git a/maven-skin/src/main/resources/images/void.gif b/maven-skin/src/main/resources/images/void.gif deleted file mode 100644 index e3a7d8c469d83eef8aed3cc26266438752d536ec..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 50 zcmZ?wbhEHbWMp7unE0RJ|Ns9C3=9Vj8~~DvKUo+V7?>DzfNY>Fh|Ltj$Y9L{09+#q AWdHyG diff --git a/server/2.2.0/pom.xml b/server/2.2.0/pom.xml deleted file mode 100644 index 6ba8a4ab0ee..00000000000 --- a/server/2.2.0/pom.xml +++ /dev/null @@ -1,52 +0,0 @@ - - - - 4.0.0 - org.apache.james - james-server-site-2-2-0 - JAMES Server 2.2.0 Documentation - 1.0-SNAPSHOT - - Apache JAMES Server 2.2.0 Documentation - - pom - - org.apache.james - james-server-root - 1.0-SNAPSHOT - - http://james.apache.org/server/2.2.0/ - 2006 - - - - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/server/2.2.0 - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/server/2.2.0 - http://svn.apache.org/viewvc/james/project/trunk/server/2.2.0 - - - - - - james-server-website - scp://minotaur.apache.org/www/james.apache.org/server/2.2.0/ - - - \ No newline at end of file diff --git a/server/2.2.0/src/site/resources/images/asf-logo-reduced.gif b/server/2.2.0/src/site/resources/images/asf-logo-reduced.gif deleted file mode 100644 index 93cc102077a940966a0bf6d77e74ac273a10ef8f..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6636 zcmW-jdpy&NB^`k5({Ud=*EWJLJM77(p_7Ubjo^?L{6ozBTG zrT8~-uT3`YA6z(iU(uWv#wdC?*LrZ+m}~LRdiKU&$f@Oy^oJ`=i6+hgRAVF_PDwp- ztgxs!1ZD4l68M_KW_UVk-#Q!$Pa@K2Br166_?3pnI2h|A-a0BAXQR5&A?Fpb?Gb8 z2*k5oCs=r^?5ey-sZ^AxYup^lC`5wE?{)1hj19^$$^{?dW+pEpj_VrXL%+<@Wf;^t zJCdiUvs(#-G^G|kfoFntz873~ctb_>t(@D#$7q=4Jv#>J`Qv=$b>~!(=u%)Bm4nQx4G0uy}~g_xl^(YUhBvak#5 zgOuvw;WT+BuH_Fe^Qfh^cx6`2s#Q)p=qizh0B=u>WgT3-Um`*}GI*J|%p$EpRN<4Y zGf~z{=<@Z%ciE4S^38-`SDls-3H17pfQxW&*i~EFS~THa;&q8l$;Vfpq4`<-XV(d$ z`-SexHAn1eerw`+&nuVTz17YrVcMN=n%6b~Pk7R#fQs2Gpwl_l;)!9Zix3)AS!c&C zQ34C)+gAHfADmZ#J!@ouF>Xj{z_YVB18pQxGV z#8&ZYQIjf}4+ukXt98XP)EbGFTjdXCr7XQ<39V`EX@7dX7sgi%K^WawfM#Gv=)Aa1 z+o?NS!01`I1iDVjJKI}zgx$&^C5Ef~EU7JH?OH!a+{=QV@_zU`-5PH*I zPuRv#n3aaLEiBR7@r{SVvX-}mUhuV3xb?k!BFIAH>qbPzbWFRFgIRYuh*K-nKBmlY zXo!mHbNn_F82LJk8Y(6HVBaJGfDmIP$=s!3^Huul_S2gBtEE}_T2@5k_$OT|Hfb(5 z)X<#6D%iKo^EXxX4F^7^85Vz6sG)}#XEvtZDoScZ&v0xHPB;j%ar+w*l2aoKKDo2- zb9>!cbUD@Cqd08ehtuEgl-E^3le=d;7%p1%H-?USDXO&=Ns#x}Gv34#dLGHj^Mbev){8$exY)@D8txn4_GgU^Q#nGSmQLy^q-T1(e6TLYS zkyodfAaB@J5Bc38m*mNB>VrC0Ux|ebUq~Fex!-O z_3SLrfr{Ra$gx{pd(y!YKvCLGkH;%6{CVnQ{;UW?4*=tq1vDz`SEy-1yIj(V2R)ZFCY__!(Zs!f z`rl=^e16E7%Pt1a*QGNC=$-{`qOzJAu$vUT+P&2n>8pCwFvLX7zj^SYb`8p=S+0`E z$XYnM2{X2F1lL-FD1N}lfYe#DT)AY*L<*-3n_K(QvY5+XtlTfjs_Xqib0@!ESbnk! zSA5ArtJN=qF`{-hEnA~6zDFo%d=8mF^^sHw%D{yEh@{rPMqBF5>hB{?M8h{}t@d0a z$TBh@8x%i2xYqf->Z_kO?ik9N@?Tnd1s`-Sm~BEsL0u8q&B1GhLXeauby8lte(=TH z=AV&6s2Bxw4Bv}#m_ApmU%KiQkf8nY=}IGzQPzj<_?tbT?S^q>@387$GCgoZ>{a?} zs*!BKHygc@UGbJ=GHbM@>qZ!K2AH8?ChBt!Rc8lW$zk7VEIyd*pHZ< zE$>3tEVKs2MMV7_y;EJ&`Ixn`WSsRp6bJd9jN0ez7 z|Ma|Lc!>!cW3KHdjTYX+6Ie1ce`!;(oJVsG#TcaQP4A00xHl)OMsj5M5|l7eC(3az zDJOcF{El8dJ#Rzx_qnmF*i5mBua?=I@#wMvrXgR?ichil(W`n;21chubB`0YX{t^$lR@)6e zzxHWowXNRH^1Qj<$tzEf&Y^`bdfs&ERfbPdDZ3B53tO443vu5as^NZ_IwXJfQLrGe z*svE7@rd$rX)~s^qXx&9l&pV0F0Lg#>vRaEt0D{^yK6JYuX|TyX#+v*D)2mcq;*Cp zfmg+{`z{X8I**n$^E#AvnZc#GzrRAukx7ov5b^QQouH>j)7lqpVBE5P^}wWc9VJMF zl|RDZCikc^4kDE8%0ixL8a>;T0`GN{#v6|OnR?@tEUXAkxLJ7eVdS$v?N0>>6O+H` z^2{Fo2$O4$vb6y!ta9)n;7$uEBjvIC)aTjix?Ev&58b zTHCwd`4prf7n;f;4aFhXHwe2DD!6nD&voHBVW_e^kk z4BA-^s7S#3%MdJ4#z`=;Gr>L_NJXrykOQM%3PUrC{5VkM211p-l*eeZE_gIfIC*wHsp5pD4ONn{s>gfc~b%Z~YZ zfnp?qAD#z;w}Pl!;NNdN^7{Ah$UuBd#BGr$q;yX1IYErS2Le0Dx zqKPdB6#2#+aF1s2nU>;y3GRIxtU@)ZW|^FpfQ~=ZZp%^@YPfu9&Thx@P=y`kq&RXQ zrP!}nk8sM64X>6!PGY$JGH6aPF_geaVX2e20;v#Fg(T&7r%qiezhli!WB6VLkCZ*B zG&`?pe<1&KTg6Y!%9gm&{(-Dz0m4ZN2hm-2e=EFq8EYj6+(TS9F#>*%LhWhDO$Eqg(i@Bw z)ysu*&R-5ba{&B^X%ph=;~Ze6V^@UXC;oaVAh3nK4e=SJ+})Q!mhX`!p&LC@;->&y z*%W2taFQ)dn8M%$JL=tRX3)qPH=>dPFsJGwCA2L|HJ%mKj z+y{JohjEIwLdk)ki%L3nlF_un1W|C)_?oXdHHJxWEt5OSuAY78a@UvZQv>#fngy#D zda$eabAW`YbKVk=e-xVk`<#M<0C`~Vq#5R;JN!<{#bsQ{XJ#H_~xNkfws>)tk=Nd2=DuVh(`? zKbj9|62X&jT2m5yRsj^6*w}MyONIWHK+*)q!^jL_U2(Mwdv&9cwJ)Nvvpa7o8k)iy zo$y3h|0JtOk~^bd8{WmujPMc%sHVchB03^Sb~uD=9ux_+r#L6jz0P(=Y$!X|c){Km z?fLK}si+@jkFBv!Q@K0>0$w#6{ub%)YMSm>%~9uFy#et(ya<}gRQ2;ElN`gOWOB)M z?>DekR{i9Jsx8$4$*0#w)Bf5RkUxJ!K+o^z4rbhv;V_6(p-7uz?>a# zDmQ!+XacocAKJy4EE*aJ5_O zOl7@}o4eoGZTmg|$@UZeg7>|qstB=;z~yyP7^X&>6Iul9wdDbqR!|(HgI(~y4bEgj z%tqp_C+GnG6Eu5vYZwFarm%kO0S`>W{wXs4Bc*Kx9v*U#|E11@P&c^;w33o+rS3mX zZ^{t6E||fFhT*& z$DjcTq$Y2;o9%Wf9FZevyFIOXQdsN9MYJA58+<3}B-N#2cE!;z5WI==7sz?xMoOhz zCcFEp2Joy;%Tm{v(b4hj?*Q^*NLZjte-Cvs+}BwF*3RDM+ZvgK2YRtLoAP1um6~CC zw@>rEM)H;)OM3k2JaP$*d$h-ya-e6dr-4L468u-H8afR_e5*9CiF(K(Cm9J@isrWu;W$PP1TA^Q5f6Fvm^0E!e%5G?i3bKu z{Y_bc)_ET~Je&J>&|Ppxty-gD7^mFzg)*;3yK$m!uh89nW?=u;;J(Ukj}X{@$o$uk z$D||T{CMs~RQp&nti<#1&O(x{p7CHf|PgnQpY-@>Nvror76~GP}JT(kgx;Nb}5NhSZnAlLKawpPv{}C;)2hij} z-VORkhG$HWlVpA6+QO`}!i1jeMpnIN(Qw3S+*Ou5@BOsu;ShlNeakxDSlH5X@`wsZ-B=B^}t8EVN2WpeWtGP7&oYjaRX;8E)O+J)+0Eg`%&btht7o@_=5B zG}L1PyFKiFGCjmEgcCDdUcVCjw?p#*6+*WFo_@ZNNb6~LvrE2P1Ru4##STL3u4F3L z*$=Vae1mATs5Qf%z+bemF7Xbf3~@o!*q#q%6(KZ*3pVUEz8tvgS;Lvcg@LO8O#eXH zq>p^m_Q3Yl@-yi5M)=KD;6NHM`7vBn)9`{|U3AEtE=_e1P?$VMP7CLdHrY4?p-KJt z?4I-SV<|g?s@V3;aUsaKmh-9j@-TT;R2b6YKEmiZGJXW%GmD56}7a!qg*ZT093>v zRz?yK$i^kR0fx>=K=sg4p)3658SV*r>97F6DgYB65WZigcl|(D>z%LO=H`Mnn`wZ$ z17R)!YJR$CP66?+0Ra!Q>N@l%0q;r2xtIPhwW?=e^`9!vZwV17-} z`v&|Lxi`;X*yrlGVH2dVIefugw~g0%h=SUIP?B$j31DUvBdWX!RR_#(g^grxEaBNF zPBtudN<)iV+FZ!d+5hg+5J&Kc{8OETWxW%AhS&-JAzgnD!y2*9@s(5EO^-9pGAbx= zg#EdZxG!MeuOgDwu1+Avr1pU-1JvD&F&{S%|h`1jKPE8AZ9k@JRFi0v2K#muJ(ewI`fD=fye1%bs?&BeGF zZ;Kf*o`hYW^tpt?tq$ty>AH5Dulshs%z~6tiW1;GG`f9=Ly2Rh*sacZBEQUkRMCso zF(ECs$v<#4B+Ci`W8DE(IH(va?>eRhd&*Ws)cPcdW>57a3zdK*%pb*f<;JNtKI0 z-OK4Xju4k0B=B+2Gi?d-6YhU0Hg-u4T3_eoi!hE{=_4w2X!!hhR9UR3Z*bVfO^dB@ z%PGwF+v0V23+}E!LbhW#s?0(LXH?3&zWt$Tk-C=x5J4Uxye3j?S>N?L*6t@Ap4dt zcM)kz>l6V3L(wORWE4ZuXZU>MMajkfSMTVD^jZMsMn!gIo{f6w>v(K0>sOvxzEw=a zrNq05F^F4qmE!-zC(QGQ`ALI5Ao<%CXooIt<-mU(5n<_HaS8j zDuLZSYT+|{!Wh1VGuH~Ji%q}YTBR-VL>(y61_$YZ82tG5K;VJrr`+k+V ifk3o@FNQYto?ua@#Ta7 diff --git a/server/2.2.0/src/site/resources/images/james-server-logo.gif b/server/2.2.0/src/site/resources/images/james-server-logo.gif deleted file mode 100644 index f69394f6bbee48b5b336395a573aa484fe1e05dc..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6944 zcmWkxc|6mPAO3tk+w8E-%ze)>cNs;Y_%OH9=^LqY!p6C5~|M5J|u1;GmLv_J0U;+RJRY#^L#+n)$-(9#+ zy+3^Y&w6}p-1uGlNG0VswXXG*g(dO&`uZY+!B`s}&P~lsA(7YD*FJoB|F25w^6WKb zd99Ji1M9yA*2H4*>UwK-`ufKY$$R6)OMgGF{}C@Oj%r!KTWpd%yu_b>F5GSvul+J5 z$1bgZUlp%brx6yve_35y`8z8-Zejk+!>YIX>X*MCYpScS+S~8<3O^L~&+P1r)wRDr zmzS?JTswcZq@(55)cg67fyaFQLjVB&)6`r={zm}7`2X<#On`)#ewY`pk%{&wQXk&ai<(K@^JgErzM-gvFd(D2gsijs=b ziMEO;C26XnVoXu-*%Ie`l$z;QS$$kQDm^wWBN5NZqe>T^t8ZvLgwn$q7@*N7GLmgk zu~(Y)JCx4or#3z6f9w~Zg}&Wpt}hwSxqn5!CQqriZ{XjTublPuskUt!+R#L*o}z_P z;&|qLNlE?h!j;v>v^N^EZLP$E7yv=fB#PjHYWmSGDbF=6w+h)%@Qfr7;U7IGq-VzC zw?v8dHt~{0bazl|Q_ts(QPtv-d=>$nLa{GH)O|YjbxCX=|IOqT1b3uF_vyGWVtPcsvaZ(clg4kUw_ryM zS{`6SG-Dx~#(|H$N`FO)PXh^x6j*8t_ncT!lPy9a@Hn0zDDl%yRJWu;m_((a?4$BC z1X~)1j?ml&r-9qw#tcX;JuAvJw1^Wzi9k759T;KLfMg|E$`kBQxuViDel4LrICBB3 zxKTBES!@g>{UR3El;n!=GEJRfR(aM+8jZhk6AmS^| zx9&s}NrH-FZXS~rk~(3&Fm`BOzM>}SxS=x^RD=-(&COhG!lt(zITQ6lE(9kj|rZKWx!)+CkEM9DSotW zAL%$wc2hPg;;VehRV}d{QR4PZV}fcllaH5roMV6GSzil)z18Mxbf?t+_G3e*wSP<*?VC1r68u=L)VR173Y%55{^Mit~opR}< zqn*Rw8IV0rP|d2ZzgDXrNjb>r$8NtC87F%}{tu(sa+s1jZu)eaAwfW_ooM}QxQE@a zlgNb~$z;1XqhVgA{i@m`!AA6^$eoLIvauuwXABhh0DW}}5E%>f?L&Z+Ckvxz2J-KOohq*THAPi3)8RUok zqZ35y58bbFwEeY1`Xz#-M9>qEAm>d#ec?(AYYfWBHnm zy~Zk)<5B?2Y&Ou=uBrYEMr}5no%Zu7)nK`$s8YOthXYN|M_FiDk!tbsByc1~oUTr* zNYl&?wc20Dg={!l(g}iIz4y#q2Hhr&_~^F#+etCCORUU{Whv-zL_h^_iiFL8TU zxG3-nQDosv^?`SLH3NaZFk$0yV%sZXbZ; z(*HJtq28i2bxL%2)Y;%AWf&kN*B@wIJHOs(vGKLb5XHH|LB@!i4s2cIv?r%hGJ9Rr zgg|Y#}$n)kX?dhIZVTN=oTa2CJt21Lp!wbFCB|ciprB-HZ zwi^B!3~XhE;nhVfRR?l0{|}XVexPiXMvV$~$rMB7wZw$z;Y1n}VVV8n-I4Z3=X2l! zxyZfiHTKspeyNJKPC*eaPXoG3%sO|!3~Sj`XZ3mDYGBwDBKz*MI;UfK+bF&#9D1r8maluh^IZ(XHL_sf(BxSx1z@J1reMKfis;a9&Ejp;TBG z3lLC_-0tC!|M6|kpC8$|f%gV{@;r-96DmRpRiDiQQIH`d`_r!rt=gr4g?~2o)Q6V; z8SML5P=czAD~*&fGK7MT)&zbEJR8JglS%vKz6r%8Iy#gf4el*Tkb48EOMV3m-@!k+ zMxOO{uvkJ$FvQ}U7Vo4oL3B_mH6jk`u*?kTe z?vCGXD&Z>Pf$6l@dQa}2@6NB2QD1Y=t(!qdI)xHnsvfW&zkC0LN2(@9`mLM@s4+k2 zsu4+H8|1a!8a^lySXWXH<}{8 zz?t(y%J{`g`r!BBU6_saWwcKLl5>+DJL06{Mk3}OOp)b^GPSm_03-|}HCEh}&JF+f zjy`#x_f4|*l6+K!!okrW#d>|pFalUd_f1O=Y3U|Mu-|_>ex?7ja zq7DQ;f>EF4z9wt_@zN7LpLSf?LPlQxl-lu2V$C;!{GO!aD8YS>ImkXqnA2oTQvk$E zMy<;E2lv-^UxyOxzEt@1#Iym~~groMgMq*${F1wcp$Y2azZMePl?F*vUlcr!Oc9fe1PmrBY5mk@+FZ zEh4V?y}E9Pn~G2916IDpRkd^@Ch#KFgBx~@kFp;v4g-pNcbEU1$>&7twM{IfsN25- zgLUVs&SMJ;&B;1V>3aiTVw#pgX^YdV+M-laO&%W|0Dzc-T!hh&r*xth%PrPZhNiKh zBo-J@5K<&c(sW;xltU&5V!0mo;LTyXvcn=zePl4_KMah$BopT*1|P6LWbj1|o4S@r z3aQIwywtDzU!vzU9+Ep_-)bcD2T%C3{_VBH%P#4;Z4rW{zW+R(aA(LP-qs+@6t+ih z^4N;DGSxo1k(VI;E<(30#I}>lE}8}6^ccpe0zLTz3nCPT%W&RJLj0CE&i&wE zDnOWRP1`(;2>F08l|SB%+DB)k*)!rr{Ydu@DUPB9Q@=Fxgfz>Q6l*`EO&zjRB=<%u zNdw-T!IbKahN!>LimVt=5M?5Ql&L$+OPqq1fC+~kDt)`ZS~y!$O!mKnDgyUZ}FJ!_**y8jd8NhC)h)`Fev@x*LGyQyo)>2e*s;%q+ht`7rg9(YKRMo zCjmMzM269wKIqqE5XVJGQJ@WsqC>rit#W|dHI}w8FT@*hyb>~j0a>iqb_SqA@*>h8 z6Izk{Dx}Sa6XTp8Hv(ypJu(e$U_^M8A~Li+gX4z7Xea= zCMO{T542`^TG1dRBg#w!s&GLwZHOQ|e)L3{3Jl53KrTv9>lCEJ0mEC^ik#D5xI3hI zU_Ml)!$&|AXu<**if0tbrGgX$hGDW@P)x}JOlUf^*GGRJS8UV^@~4#Uh|Z~MN7f!d zqL>#$bIy4(IKBHzCrS~QIfOzuTbUU}5d!Z_^|Xb+(d!_Mhj9A`k%9%yVCX4S&U+1* zF_K6?S;}=#V3}v;dfBv8DT9={oh@%gg3N@#cnl=Xhf=U*p$=+4qybG9Km>~V$Y&9Z zs3zBZU0qb+FNcfSNMnqn_>Muvihhuc_3RKY4o)(zEu{@kwH=Nu@JPW|Z` ziKs({sJw6tik76K9H*x#c_0VS;wefC^j=3JsI<$Pzd(I1q#j*Og5?SX?3wv9nX3@v zf`ToNZO8>CWSODC)KdRruYCEIA#hH6*+Qpb07_d-X6MQ z4+HNE5I2|&I~Fm|7miyo;cgbB>9>7S7qLviEaXDtN*7eP0KM&uwy2uK<4jdH%=$NN zosnINhWNY!Uy^k<>OgQAPe!?RC#TR$$r{(eOMhR<)klr<2`#^>l?C-bnj2Lp;H3+o zktn~+EZbx5xCv#WEff557bUq>&l2ri@pfd5|zu%0C{)I zC&Qy0!mbg4t4JPbBp|6Iq#ief8PO?cT#&aU(g;b-JAw4b!-}`!kb$2NVwnh3zm?~A zPmP4ZdP^*JT$*}f(eOjImqQ!)b`=U}hPLDaW*p4q!Bq8VZbPnae6+4wG&CUr5^0S# zo|IG9!GaP*vGrZ$=(}Yqe(9`+wZmn7qk)b38j@}()xlQp0iJxv%}#8Eq;-8)?!99H z^$sZ90V*=;MRNvxar-@tq3BSGGWV(0<%YqQjYF4M9i-7^$n_?|Vn)ucC7+80-EYcB zj@K?_<~QeJU-+pzWd_OH-Flk?r~<934ysi*QJ9M->72r+zNkYtk*f#KrCFT(^eHm< z=Dn*JO%}g-#EM2t1$P8QZJ?1f7-vivMDvw~;KUdAAR;5NN8fc6(F&^l2~#|xXB9`0G_*(nHd zV%>BR^>5jRdUWj}p5I))kAUYxwr&7E74kQ2eYaTMWU%#&AtF$@Wa}z|{0CynU`9D% z6Z9&J>!fGCNl3=Eu~LkgktY2QM%|9Mxfm3ad6(WEO1iLLt%HXOpRCN1=-nlHATkPS z4fk02jaZ!?X0V219N{y=4<&S{cwvKh5YQ7*l;HDyW3?uvj7!GI8P4%d7w<%lV#e>7 zng|EeaqUqb266D_=|wsIHVm&Ht(yf>d0_nP(5c+Io1zj1=YfAmME6AE!H8jJPLF48 zp^G3A|F&iR!lH0!A?OCa3z-FzO;Y+VgtI=x2d5&`cLT^Oz3FO&LD(#Yj0HTW}^woeLb% zgM82Avf7&)*0A~w@rgbM;i#~8=C8hKNcGmPN_LGTWW}aBhJuU0jjgDGT{6@ zZ{c)F5AvEynVOXqo8SyV6_*XWL9{40>VoD;Ez7#=}pJP?K>+N)SI z%BOr6cU~^(^m-pW=D8cvJAyG-S1^7l7rv2-V=lys(8YhcG(;Flf#f!}^G~~N-z!u5 zeSq^t4dTYmk2{zE`U%p(`QatMnv#_Ho4>t+XR_rJXUFnKpQXH0HTr~Nj=yLC%8%@$ zruc?Oy?2(kI7FP?{hBlcUp{TQQH^%{-Q6y#Bfe~mWE+f^bNnA_zfjtCgdo&2_oYY&L$%SJ{!Xd2Jero?$zjZyNxkPXj`5urL7bl$tq zhuS-%r*2zMlV}%~xQN#tn@i2q|0R4)cwp)3qfeZ6!XKlmOT9LyM+zo%0`OnB*Iko9@$XyZ`=s_Y_A5M{a^y}f1fxHCbUep{ zVvq!G;eSla2SCAyI%N@O-nufD^r{@w3*H#;US=_-mOYTJ$j45ii0+q>_d`6wFN%Bw z+@}N->l^ZYT$}fU7*0rqKVcy(G73S1+PT>>AVR|Y{9|VS)-|lnDENm1#7#=omHWu>n zW;BK|i4+z|lw2y-3Lzomtr*`|zMsPRsxqVlY>wc}%oJrE7@DdUvWkjFv@G^GIRsc7 z2|=1WF+CIw-F@8*(If|7j?=`27W;(y8vC!s$6Av2wI8;ht(s5%Ja*TxV(?qp>ii@LwpigzE-dgfw_;neJY(XQzRBfmcQv7e_FKPAQWE0nt zhj?9Q^~koqVe{}A6lk}>#X(UXL>Xa`4m`z0JG3KGHIdI0i|o3xim4vbeu+9gYT)X$ zxxka&mk&rJ3ur5dkW!pff(yfw-hbwH(ELo`MWp+=`>xO1*hXcI!L7dE*Z+@h(ZmN4vY|J_Bzna@DkqjBlpQhQnl$6SfCZ zQQ9XA@15C%g*I&7R@F9#IX=Y#1=5@}!fcbzlT z@ibPZ7OGwIfsT&Q4h<&Og$@{$MSdU9zuuXqk3ZHNYK@}&28!ra@It0?!n9pRW9jFO zkE!?1=Vd9sY=4ufmf-ROQxP%~+hPn7yajgPJ6an3!JiDIEb(Vern4r2<$=}DcsAy4 zIW{^?qDhxCHLpQ9x74S(Dq!Ze#G}h)ZH(WFOGH*_RPi%Y?zvj9o@Mn zIOfX&H(h#(rt7%Nn90o8W}j2}I7Pf_-ty`+Nc0o3u^XqEr=>jn<}ze#is!O43ly1I zs3(;rHZ;TL^e6{KcAZLlI<-V+*&%gk%bPq@>A4p=<6$Lb(W}JryNr{v7p8LI@beAA z^Ma$DcTc)qN?WoFuc(F{axgmjxB!%eC - - James Server - images/james-server-logo.gif - http://james.apache.org/server/ - - - The Apache Software Foundation - images/asf-logo-reduced.gif - http://www.apache.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/server/2.2.0/src/site/xdoc/adding_users.xml b/server/2.2.0/src/site/xdoc/adding_users.xml deleted file mode 100644 index e063dcf480e..00000000000 --- a/server/2.2.0/src/site/xdoc/adding_users.xml +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - James 2.1 - Adding Users - - - -
-

User accounts are shared across services. A common user repository is shared across James -services. That is, once you've created a POP3 mail account and set a password, that same -account is available for authenticated SMTP and NNTP.

- -

In James, user accounts are created throught the RemoteManager. So, after installation is complete, the first step to adding users -is to configure the RemoteManager. More information on RemoteManager configuration can be found -here. You will need to have configured at least one administrator account and -ensured that the RemoteManager is enabled.

-

Also, you need to make sure that your user repository configuration is correct before adding any users. If -you change your user repository type (i.e. file to database) or the configuration of your user repository -(i.e. the file or database URL) after you have added users, you may lose your user data. Please change these -values with care.

-

After you've done this, restart James to ensure that any changes you've made in the configuration are incorporated into -the running system. You are now ready to create user accounts.

- -

Once James is up and listening, adding a user is simple:

-1. Telnet to the host and port on which the RemoteManager is listening. For command-line telnet clients -this is generally done by typing "telnet <host> <pass>" where <host> is the James -hostname and <port> is the RemoteManager port specified in the James config.xml.

-2. You will be prompted for your administrator userid and password. Enter the values you specified -in the James config.xml.

-3. After logging in, type "adduser <user> <password>" where <user> is the user name -and <password> is the password of the account you wish to create. Please note that the user name -should NOT be a complete email address. Rather, all email addresses of the form <user>@<domain> -(where <domain> is any of the values specified in the <servernames> block) will be delivered to -this account by default. Mailet configuration can change this default behavior.

-4. Repeat step 3 for all user accounts you wish to create. -

That's it. Your user accounts are now created and can be used by all James services.

-
- - diff --git a/server/2.2.0/src/site/xdoc/build_instructions.xml b/server/2.2.0/src/site/xdoc/build_instructions.xml deleted file mode 100644 index b6ff76db084..00000000000 --- a/server/2.2.0/src/site/xdoc/build_instructions.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - James 2.1 - Building James - - -

This step is not necessary to use the standard out of the box version of James. A -pre-built binary version of James is available from the James download directory. But -if you wish to customize the James source code, it will be necessary for you to build the -distribution yourself. -

-
-

There are two ways to get the James source code.

-

1. Download the source distribution - the source is available from the -James release mirrors. -Simply choose the version of James you'd like to download, and pick the source distribution appropriate for your platform. -

-

2. Get the source code using CVS - this method gives you access to the cutting edge code -base. Instructions on how to use CVS to get the James source code (the jakarta-james distribution) -can be found here. -

-
-
-

To run the build you need two third-party tools.

-

1. Java Development Kit - You must have a JDK of Java version 1.3 or higher installed to build the -James distribution. The exact JDKs available depend on the platform. A JDK must be downloaded and -installed before the build can run.

-

2. Ant - This is a Java-tailored, XML-configured, extensible build or make system. The James -source tree includes Ant v1.5. You can get the latest version of Ant -here. Since Ant is currently included in the source -distribution, it is not necessary to download it separately.

-
-
-

In the top level directory of the source distribution James includes two helper scripts for running -the build. The script build.bat should be used on Windows systems, while build.sh is appropriate for -Unix systems. Each script takes an optional set of arguments that tell the script exactly what to build.

-

To use these scripts, simple set the environment variable JAVA_HOME to the base directory of the -JDK. Then run the build script, optionally with any of the following command line arguments: -

    -
  • clean - deletes the build directory, making the system ready for a clean build.
    • -
  • compile - compiles the source code.
    • -
  • dist - generates all the James distributions, packed.
    • -
  • dist-lite - generates all the James distributions, unpacked. This is the default argument.
    • -
  • javadocs - builds the James javadocs.
    • -
  • usage - prints out the usage instructions for the script.
    • -
  • website - builds the entirety of the James website.
    • -
  • xdocs - creates the documentaion for James.
    • -
-

-

All build products are output in the dist subdirectory of the James source distribution directory. There -is also a build subdirectory of the James source distribution directory that is created during the build process. Both -of these directories will be deleted if you run build with the clean argument.

-

Warning! Any changes you've made in the 'dist' directory -will be lost after a recompilation. If you are making changes to the config.xml -or other files, we recommend you backup and then change the copies in src to -avoid losing work.

-
- - - diff --git a/server/2.2.0/src/site/xdoc/changelog.xml b/server/2.2.0/src/site/xdoc/changelog.xml deleted file mode 100644 index d9841e13ebd..00000000000 --- a/server/2.2.0/src/site/xdoc/changelog.xml +++ /dev/null @@ -1,446 +0,0 @@ - - - - - - ChangeLog - James Project Web Team - - - - -

This is a document that records what was done between releases. As always, thank you to everyone who contributed code, documentation, bug reports, and feedback. -

-
-

Released 15 June 2004

-

-Below are some highlights of features and changes already available: -

    -
  • mbox support
    • -
  • Mail attributes
    • -
  • JavaMail 1.3.1
    • -
  • dnsjava 1.6.2, includes auto-discover DNS servers
    • -
  • FetchMAIL, deprecating FetchPop
    • -
  • Quotas
    • -
  • Extensive message redirect system
    • -
  • Improved network address handling
    • -
  • Multiple remote delivery gateway servers
    • -
  • Many performance improvements
    • -
  • Many new matchers and mailets
    • -
  • Many bug fixes
    • -
  • And much more!
    • -
-

-

Details

- - -
    -
  • [JAMES-9] - JamesSpoolManager doesn't shutdown gracefully
    • -
  • [JAMES-62] - Spooler loops and add message many times
    • -
  • [JAMES-72] - SMTP Handler DATA buffering issue
    • -
  • [JAMES-96] - Mailet container should not trap exceptions in init()
    • -
  • [JAMES-109] - run.bat created wrong temp dir
    • -
  • [JAMES-128] - Fix problem when invalid domain name is passed to NetMatcher
    • -
  • [JAMES-133] - NullPointerException at org.apache.james.mailrepository.AvalonMailRepository.store
    • -
  • [JAMES-135] - NPE on nonexistant mailing-list repository
    • -
  • [JAMES-142] - RemoteDelivery only tries one of multiple A record entries.
    • -
  • [JAMES-144] - POP3Handler breaks with message numbers out of bounds
    • -
  • [JAMES-147] - Update libraries
    • -
  • [JAMES-150] - NullPointer Exception when mail does not contain any Received: headers
    • -
  • [JAMES-151] - connectionLimit on services ignored
    • -
  • [JAMES-152] - When a Received header is invalid mail may be created with a null remote address and host name
    • -
  • [JAMES-153] - Looping MessageException causes system stall
    • -
  • [JAMES-156] - AbstractStorageQuota matcher subclasses never match when recipient alias is used
    • -
  • [JAMES-157] - AbstractQuotaMatcher subclasses should not match when reverse path is NULL
    • -
  • [JAMES-163] - RemoteManager buffering issues
    • -
  • [JAMES-167] - Remote delivery counting retries wrong
    • -
  • [JAMES-170] - Postmaster address should be case insensitive
    • -
  • [JAMES-176] - MySQL query not using index for string comparison
    • -
  • [JAMES-178] - MailAddress can spit OutOfBoundsException
    • -
  • [JAMES-182] - Fix the TMPDIR path under windows/cygwin use of script
    • -
  • [JAMES-187] - Bug with DNS entries with 0 TTL
    • -
  • [JAMES-189] - Remote delivery sometimes not trying all MX records
    • -
  • [JAMES-191] - HasAttachment has false positives and negatives
    • -
  • [JAMES-192] - MSSQL mail table create bug
    • -
  • [JAMES-193] - MailetConfig does not implement getInitParameterNames()
    • -
  • [JAMES-194] - DNS occassional null pointer
    • -
  • [JAMES-199] - Bounce not using null sender
    • -
  • [JAMES-200] - MailetConfig throws exception for empty getInitAttribute
    • -
  • [JAMES-202] - Proper POP3 response to QUIT
    • -
  • [JAMES-203] - File protocol URL with JDK 1.4.2
    • -
  • [JAMES-207] - Exception handling when fetching message, stranding connection
    • -
  • [JAMES-208] - Regex code is not thread-safe
    • -
  • [JAMES-215] - Javadoc corrections in mailet API
    • -
  • [JAMES-230] - File stream repository may strand resource
    • -
  • [JAMES-233] - SMTP AUTH PLAIN doesn't work
    • -
  • [JAMES-236] - java.lang.NullPointerException iterating over SMTP hosts
    • -
  • [JAMES-238] - Missing Date: header with CommandListserv
    • -
  • [JAMES-239] - CommandListserv corrupts Subject: header
    • -
  • [JAMES-240] - LinearProcessor.verifyMailAddresses should catch java.lang.ArrayStoreException
    • -
  • [JAMES-243] - FromRepository does not reset mail state
    • -
  • [JAMES-247] - James Does Not Work With Oracle DB For Spool Repository
    • -
  • [JAMES-249] - getSMTPHostAddresses doesn't resolve when MX RHS is CNAME
    • -
  • [JAMES-251] - ClassCastException
    • -
  • [JAMES-253] - deadlock in mordred connection pool
    • -
  • [JAMES-255] - SMTPHandler logs exceptions that abort the connection only at DEBUG level
    • -
  • [JAMES-261] - Text error in config.xml
    • -
  • [JAMES-262] - Invalid link in james-fetchmail.xml
    • -
  • [JAMES-265] - org.xbill.DNS.Address not resolving addresses in some configurations
    • -
  • [JAMES-267] - NullPointerException in Fetchmail when there are no From: or Sender: headers
    • -
  • [JAMES-268] - Spooler.accept(...) can leave locked messages and leak memory
    • -
  • [JAMES-269] - AvalonMailRepository emits spurious "so we're deleting it... good riddance" messages due to synchronization
    • -
  • [JAMES-271] - can't resolve when MX record direct an ip
    • -
  • [JAMES-276] - The url for the ENTITY declarations in config.xml should be just "../conf/file-name"
    • -
  • [JAMES-278] - Remove references to Jakarta where no longer accurate
    • -
  • [JAMES-280] - DNSServer does not cleanup DNS cache cleaner thread.
    • -
  • [JAMES-281] - Return-Path twice in header
    • -
  • [JAMES-282] - Partial message may be delivered if client disconnects
    • -
  • [JAMES-294] - Database Pool becomes exhausted after a short time when heavily polled
    • -
- - -
    -
  • [JAMES-99] - RFC1894 format notification
    • -
  • [JAMES-161] - Quota framework
    • -
  • [JAMES-162] - Partial send support
    • -
  • [JAMES-169] - Network-based authorization for SMTP AUTH
    • -
  • [JAMES-171] - Improve support for character encoded subjects in mailing lists
    • -
  • [JAMES-172] - New thread pool implementation
    • -
  • [JAMES-173] - Control number of rows returned in JDBCSpoolRepository
    • -
  • [JAMES-174] - Improve performance on message size
    • -
  • [JAMES-177] - DNS settings autodiscovery
    • -
  • [JAMES-179] - Reduce memory footprint of sql resouces
    • -
  • [JAMES-180] - Faster listing usernames
    • -
  • [JAMES-181] - Better CRLF handling in protocols
    • -
  • [JAMES-183] - Overhauled Redirect mailet
    • -
  • [JAMES-184] - New network matcher classes
    • -
  • [JAMES-188] - Improved error handling in processors
    • -
  • [JAMES-198] - New listserv code.
    • -
  • [JAMES-204] - Upgrade to JavaMail 1.3.1
    • -
  • [JAMES-205] - New database connection pooler
    • -
  • [JAMES-210] - Upgrade to dnsjava 1.4.0
    • -
  • [JAMES-212] - Batch delete from mail repository
    • -
  • [JAMES-214] - Better PID handling
    • -
  • [JAMES-217] - Upgrade to dnsjava 1.4.1
    • -
  • [JAMES-218] - showalias and showforwarding commands
    • -
  • [JAMES-221] - SenderInFakeDomain network setting
    • -
  • [JAMES-222] - Make file mail repository sort FIFO
    • -
  • [JAMES-225] - Upgrade to dnsjava 1.4.2
    • -
  • [JAMES-226] - Simplify connection tracking
    • -
  • [JAMES-227] - Upgrade to dnsjava 1.4.3
    • -
  • [JAMES-228] - Upgrade to DBCP 1.1
    • -
  • [JAMES-232] - JMX exposes more server information
    • -
  • [JAMES-234] - Improved bounce from RemoteDelivery
    • -
  • [JAMES-283] - James should use default backLog value when creating a ServerSocket
    • -
- - - - - -
    -
  • [JAMES-149] - Add soft-fail to unresolved received from domains
    • -
  • [JAMES-190] - Apache license 2.0
    • -
  • [JAMES-213] - Mail repository throw MessagingException instead of RuntimeException
    • -
  • [JAMES-223] - Remove stack traces to console
    • -
  • [JAMES-252] - Upgrade to dnsjava 1.6.2
    • -
  • [JAMES-277] - Generate mailet.jar as separate from core james.jar
    • -
- -
- -
-

Released 12 May 2003

-
    -
  • [NjB] (code) Fixed stream handling in MimeMessageWrapper to address a JavaMail issue introduced in v2.1.2
    • -
  • [NjB] (code) Fixes to AddFooter for text/html parts
    • -
  • [MI,PG,NjB] (code) Fixes to AddFooter for MimeMultipart messages
    • -
  • [NjB] (code) Changed ExtraDotOutputStream to enforce RFC 2821 #2.3.7
    • -
  • [NjB] (code) Corrected allowable characters for localpart of address
    • -
  • [NjB] (update) Removed generated files from source distributions
    • -
  • [PG] (code) Corrrected handling of NNTP messages to avoid character encoding issues
    • -
  • [NjB] (code) James.getId bug - courtesy of Sid Stuart
    • -
  • [KS} (code) Added NNTP linecounting support
    • -
  • [KS} (code) Fixed NNTP authentication
    • -
  • [HJ] (code) Fixed bug 18726 (optional socket factory to specify outgoing bind address)
    • -
  • [NjB] (code) Fixed bug 19418 (changed notify/wait code in spooler)
    • -
  • [NjB] (code) Fixed bug 18307 (NotifySender headers)
    • -
  • [NjB] (code) Fixed bug with non-InternetAddress addresses - courtesy of Steen Jansdal
    • -
  • [NjB] (code) Fixed bug in NotifySender with complex MIME messages
    • -
  • [SK, NjB] (code) Added Delivered-To header in LocalDelivery
    • -
  • [NjB] (code) Fixed Bug 15428 - check for valid user before attempting removal
    • -
-
- -
-

Released 21 February 2003

-
    -
  • [NjB] (code) Fixed handling of permanent/temporary errors in RemoteDelivery
    • -
  • [NjB] (code) Fixed bug where connect error could cause outgoing mail to be discarded.
    • -
  • [PG] (code) Fixed the bounce() method to add the original message as a message MIME type with an attachment disposition.
    • -
-
- -
-

Released 11 February 2003

-
    -
  • [KL] (code) SMTP AUTH compatibility change
    • -
  • [NjB] (code) Changed MimeMessageWrapper to use the raw stream when possible
    • -
  • [NjB] (code) Fixed synchronization bug in AvalonMailRepository
    • -
  • [NjB] (update) Updated Avalon LogKit
    • -
  • [NjB] (code) Infinite loops are interruptable
    • -
  • [HB, NjB] (code) Fixed NNTP crossposting
    • -
  • [NjB] (code) Fixed synchronizaion bug in file repository
    • -
  • [NjB] (code) Enabled log rotation
    • -
  • [NjB] (doc) Fixed broken links
    • -
  • [DA, NjB] (update) Updated JavaMail and JAF
    • -
  • [NjB] (code) Updated sqlResources.xml for PostgreSQL with patch from simon
    • -
  • [NjB] (code) Reorder primary key for JDBCMailRepository to optimize queries using just the repository name.
    • -
  • [PG,HB] (code) NNTP dot stuffing fix
    • -
  • [PG] (code) NNTP OVER/XOVER fix
    • -
  • [NjB] (code) Experimental RegexMatcher classes
    • -
-
- -
-

Released 29 December 2002

-
    -
  • (AK) (doc) Added LDAP RFCs.
    • -
  • (PG) (code) Fixed platform-specific performance issue with the POP3 server delivery.
    • -
  • (PG) (code) Fixed bug where RemoteDelivery did not iterate through all MX records on connect failure.
    • -
  • (PG) (update) Updated James to use the Avalon Framework version 4.1.3.
    • -
  • (PG) (update) Updated James to use Avalon Phoenix version 4.0.1.
    • -
  • (PG) (doc) Added extensive commenting - specifically Javadoced the vast majority of methods.
    • -
  • (PG,AI) (code) Added a James specific abstract Service implementation. Unified configuration, logging, as well as enabling the use of thread pools and socket types on a per service basis.
    • -
  • (NjB) (code) Corrected JDBCMailRepository to obey stated contract.
    • -
  • (NjB,PG) (code) Adjusted service handlers to flush socket output streams to ensure prompt client interactions.
    • -
  • (PG) (code) Adjusted the NNTP server so that it better conforms to the NNTP specification (see bug #13564 for details).
    • -
  • (PG) (code) Corrected a typo that had been disabling NNTP using SSL functionality.
    • -
  • (PG) (code) Corrected an architectural flaw in the NNTP server implemenation that disabled NNTP authentication.
    • -
  • (NjB) (code) Fixed a bug in the GenericListserv subject normalization. Neatened the code to make later modifications easier.
    • -
  • (BW) (code) Fixed a bug in the RemoteDelivery mailet that caused the mailet to unnecessarily split the recipient list when using a gateway.
    • -
  • (NjB,PG) (code) Added object pooling for service handlers to substantially improve performance.
    • -
  • (AI,PG) (code) Added a new Watchdog interface to effectively support connection timeouts. An implementation of the interface was added that uses a second thread per connection to ensure timeouts.
    • -
  • (NjB,PG) (code) Resolved a memory leak in the source - a list of files to be deleted was being maintained that was unnecessary. The file to be deleted is now deleted immediately after it is no longer needed.
    • -
  • (PG) (code) Changed the code to ensure that all thread pool threads are returned to the thread pool in a non-interrupted state.
    • -
  • (PG) (code) Centralized the file/directory lookup code inside James and fixed it so that it handled absolute URLs properly.
    • -
  • (AI,PG) (code) Added a more substantial connection manager. This connection manager allows us to limit the maximum number of client connections per server socket. It also allows us to set the socket timeout for client sockets explicitly.
    • -
  • (DA,PG) (code) Added enabled/disabled switch to main server components.
    • -
  • (DA) (code) Added new FetchPOP functionality, to allow James to consolidate mail from a number of POP3 servers in a single server.
    • -
  • (DA) (doc) Added documentation to demonstrate how to configure James as a universal sendmail relay.
    • -
  • (NjB) (code) Made subject prefix bracketing in GenericListserv configurable.
    • -
  • (NjB) (code) Added the HasHeader matcher.
    • -
  • (NjB) (code) Added the JDBCVirtualUserTable mailet.
    • -
  • (NjB) (code) Enhanced the RemoteAddrInNetwork and RemoteAddrNotInNetwork to accept domain names.
    • -
  • (PG) (update) Fixed the log configuration so that AM and PM entries are properly distinguishable by default.
    • -
  • (NjB) (code) Added a configurable debug parameter to several mailets to allow a more granular control of debug logging.
    • -
  • (NjB) (code) Added the Habeas warrant mailet and matcher.
    • -
  • (NjB,PG) (update) Changed the server configuration to default log at INFO level. Adjusted logging statements so that they are log level appropriate.
    • -
  • (PG) (code) Fixed a critical bug in the dbfile implementation. Fixed repository implementation so that db repositories do not behave as dbfile repositories.
    • -
  • (NjB) (code) Fixed MimeMessageWrapper so that mail headers are properly updated when headers are set on the wrapper.
    • -
  • (PG) (code) Added UNSETFORWARDING functionality to the RemoteManager.
    • -
  • (PG) (code) Closed an open relay hole involving an empty Sender header.
    • -
  • (PG) (code) Fixed Oracle specific bug that limited us to messages of 4K or less in the repository.
    • -
  • (SS,NjB,PG) (code) Ensured that a number of database and I/O resources are properly closed under all conditions.
    • -
  • (NjB) (code) Changed default column sizes for JDBC repositories to be RFC compliant.
    • -
  • (NjB) (code) Fixed exception handling in JdbcDataSource when getConnection() fails.
    • -
  • (PG) (code) Fixed NotifySender/NotifyPostmaster to be more robust against ill-formed headers in the email being forwarded.
    • -
  • (SD,SS3) (code) Made a substantial performance enhancement to the LinearProcessor such that mail changes are not persisted to the store until necessary. Also reduced synchronization scope.
    • -
  • (PG) (code) Converted String concatenation to the use of StringBuffers throughout the code base.
    • -
  • (PG) (code) Fixed date formatting to be thread safe.
    • -
  • (NjB) (code) Fixed InSpammerBlacklist
    • -
  • (PH) (update) Upgrade James to the Avalon 4.0/4.1 actual releases.
    • -
  • (NjB,SK) (update) Fixed MailImpl.duplicate to include remote addr, remote host, and last updated fields.
    • -
  • (CB2) (update) Fixed NNTP server bug where the NEXT command was not being properly dispatched and handled.
    • -
  • (SK) (update) Cleaned up error handling in LocalDelivery.
    • -
  • (SS2) (code) Changed the default configuration so that log files are appending by default.
    • -
  • (SS2) (update) Reported the lack of in.close in MimeMessageSource.getSize(), which was causing stranded file handles, especially during large POP3 sessions.
    • -
  • (AI) (update) Matcher config implementation object now properly set with matcher name.
    • -
-
-
-

Released 20 April 2002

-
    -
  • (DA) (update) Fixed POP3 message size bug that prevented retrieval
    • -
  • (SK) (code) FileRepository should no longer produce 0-byte files. It checks that the source is different than the target, or confirm it is in memory before saving to disk.
    • -
  • (SK) (update) Removed check that connection is not closed before returning it. The pooler is already confirming the connection was open before putting it in the pool, so this was a big unnecessary performance drain.
    • -
  • (SK) (update) Fixed the delay in the JDBC mail spool repository as it wasn't rechecking correctly after it emptied the spool.
    • -
  • (SS2) (code) Added dot-stuffing in POP3 message delivery to fix problems with Netscape and other mail clients and to comply with RFC.
    • -
  • (JK) (code) Fixed bounce method to use the Return-Path header if there is one.
    • -
  • (SK) (update) Improved handling of delivery error messages when the remote server returns a specific 5XY complaint.
    • -
  • (SK) (code) Better diagnosing of temporary vs. permanent delivery exceptions, most notably "Could not connect to host.." is a temporary exception.
    • -
  • (SK) (code) Remote SMTP delivery now sets the remote hostname using the servername configuration setting (uses the first one).
    • -
  • (SK) (update) Have it cleanly (not print stack trace) if the remote manager handler has io/socket exceptions.
    • -
  • (SK) (update) Support in "IsSenderInFakeDomain" to handle null senders properly (was producing a false positive in this case).
    • -
  • (PH) (update) Added releaseConnection method to BaseConnectionHandler as per Paul H's bug report.
    • -
  • (SK) (update) Reordered 250 SMTP responses to fix Mac client issue per Giles Chanot's bug report.
    • -
-
- -
-

Released 1 December 2001

-
    -
  • (*) (update) Moved to Avalon snapshot of November 2001
    • -
  • (DA) (update) Fixed POP3 message size bug that prevented retrieval
    • -
  • (SK) (code) Added Mordred database connection pooling. It is the marriage of Town's db pooling code and Excalibur's configuration.
    • -
  • (SK) (update) Changed MailImpl.getSize() to getMessageSize() and from int to long.
    • -
  • (SK) (docs) Small updates to documentation
    • -
  • (SK) (code) Added JDBCListserv, straight JDBC implementation of old TownListserv that extends GenericListserv
    • -
  • (SK) (update) Patched bug in GenericListserv for when subject was null
    • -
  • (SK) (update) Got mailets/matchers to load from something besides james.bar
    • -
  • (SK) (code) Added scheduler notification during SMTP DATA reception and POP3 RETR sending so the connection handler doesn't time out connection while data is being transfered.
    • -
  • (SK) (code) Support <gatewayPort> setting on RemoteDelivery to send all messages to a non-port 25 SMTP server. Only makes sense when <gateway> is also set.
    • -
  • (EP) (update) Used getAsBooleanValue in various configuration methods to make code more readable.
    • -
  • (SS) (update) Added support for Oracle database for mail and spool JDBC repositories.
    • -
-
- -
-

Released 26 October 2001

-
    -
  • (CB,*) (update) Moved to Avalon snapshot of 9-25-2001.
    • -
  • (HB) (code) Added NNTP service.
    • -
  • (SK) (update) Greatly improved multi-threading support for repositories and SMTP reception.
    • -
  • (JB) (code) SMTP AUTH support
    • -
  • (SK) (update) Support null senders, i.e., MAIL RCPT: <>.
    • -
  • (DD,SK) (update) Converted Town mail and user repositories to straight JDBC ones, using Excalibur connection pooling and configurable SQL statements per DB.
    • -
  • (SK) (update) Messages are no longer loaded until absolutely necessary.
    • -
  • (GB) (update) Fixed exception being thrown on MailAddress parsing.
    • -
  • (CB) (update) Rebuilt CVS tree after hack and moved src to src/java.
    • -
  • (DA) (code) New extensible, flexible Redirect mailet that handles notifications and forwarding.
    • -
  • (SK) (code) JDBC Alias mailet.
    • -
  • (various) (docs) Added a whole bunch of related RFCs to the webdocs.
    • -
  • (DA) (update) Add date to bounced emails.
    • -
  • (HB) (update) Updated DNS library and started process to move it to Avalon service.
    • -
  • (various) (update) More checks to fix "stuck file" problem in Avalon mail repository.
    • -
  • (MP) (code) Limit the size of a message on reception (rather than waiting until processors).
    • -
  • (SK) (update) Fixed dot-stuffing in SMTP reception/delivery.
    • -
  • (SK) (update) Improved how Return-Path and Received headers are generated during SMTP reception.
    • -
  • (SK) (update) More efficient remote delivery code, better error messages, and gateway parameter to route all messages to a single target.
    • -
  • (DA) (update) Fixed timezone bug in RFC822DateFormat
    • -
  • (MP) (update) Patch to support username@[yyy.yyy.yyy.yyy] addresses
    • -
  • (GB) (update) Patch to fix size calculation from headers
    • -
  • (RS) (image) Contributed James logo
    • -
  • (SK) (update) Changed MailetException to extend MessagingException, and Mailet.init() throws MailetException.
    • -
-
- -
-

Released 13 December 2000

-
    -
  • (SK,SR,CB) (update) Fix for "stuck file" problem in Avalon mail repository.
    • -
  • (SK) (design) Made usernames case insensitive on MailAddress
    • -
  • (SK) (code) Complete rewrite of processor code to send through Mail object through matchers and mailets. Design might be less efficient but easier to understand and more flexible for later improvements to API. Also no longer "loses" IP address and error message information when Mail object go from one processor/state to the next (ToProcessor changed as well now that processor works).
    • -
  • (SK) (update) Updated to JavaMail 1.2
    • -
  • (SK) (update) Changed instantiation of recipients on a Mail object to a Set (HashSet) whenever possible in preparation for the API having this change.
    • -
  • (IS) (code) Added UsersTownRepository to let you maintain user lists in a database
    • -
  • (SR) (update) In POP3 handler, properly includes headers in calculating size of messages.
    • -
  • (SK) (update) Removed "synchronized" attribute on many methods in town and file spool repositories. Should significantly boost performance and multithreaded capabilities.
    • -
  • (SK) (code) Optimization of town mail repository, introduction of JamesMimeMessageInputStream and the James MimeMessage. Should significantly reduce the number of unnecessary parses or saves on MimeMessages in server.
    • -
  • (SR) (update) Properly calculates hashCode for MailAddress so duplicates do not exist in Hashmaps
    • -
  • (SR) (update) Hardcoded serialVerUID on MailAddress and MailImpl to that of James 1.2 release so future releases can continue to use mail stored in earlier releases.
    • -
  • (IS) (update) Added ability on NotifySender and NotifyPostmaster to attach informative notice.
    • -
  • (SK) (update) GenericListservManager now requires existsAddress() which it uses to prevent someone already on the list from subscribing or someone not on the list from removing themselves.
    • -
  • (SK) (update) Changed User repository for file to *always* end the destination with a File.separator. Otherwise if people mixed usage of this, it would crash the repositories with confusing error messages. Child repositories were already properly created with a terminating File.separator.
    • -
  • (SK) (code) New matcher: IsSingleRecipient
    • -
  • (SK) (code) Added spam blacklist checking for 3 spam blacklists that make this available in a simple DNS lookup check. All free services through mail-abuse.org. Added to default configuration in config.xml
    • -
  • (PU) (code) Added first testing program. This would recreate file stuck problem. Would be good to build collection of testing utilities in this new package.
    • -
  • (SK) (docs) Documented what all the jars are in the lib directory (what they're called, where they're from)
    • -
-
- -
-

Released 16 October 2000

-
    -
  • (SK) (design) Abstracted mailet API to be Avalon (implementation) independent
    • -
  • (CB) (code) Abstracted mail repository in JAMES/Avalon to allow more varied implementations.
    • -
  • (SK) (code) Database implementations of mail repositories
    • -
  • (SK) (code) Changed remote delivery to use an outgoing spool with a specified number of delivery threads
    • -
  • (CB) (code) Experimental implementation of LDAP user manager
    • -
  • (SK) (update) Reworked mailets and matchers to fit new API and added many more classes
    • -
  • (CB, SK) (update) Fixed some bugs in POP3 server
    • -
  • (CB) (update) Added full TLS support in POP3 (POP3S)
    • -
  • (SK) (update) Fixed sorting of MX records so it attempts delivery in correct order
    • -
  • (SK) (update) Changed remote manager to not allow a login if an admin account's password is empty, - and sets the root account's password empty by default (so you have to set one... prevents someone - from knowing the password to your system out of the box)
    • -
-
-
-

Release 27 July 2000

-
    -
  • (??) (code) Unknown changes
    • -
  • (SK) (code) Made DNS functionality a separate block
    • -
-
- -
-

Released 26 February 2000

-
    -
  • (SK, FB) (code) Added DNS stuff to remote delivery.
    • -
  • (FB) (code) Add some autodetect support for easier configuration.
    • -
  • (FB) (code) Add support for Mailet.
    • -
  • (FB) (update) Add Mailet interface draft.
    • -
-
- -
-

Released early 2000

-
    -
  • (FB) (update) Split the SMTP Server in a protocol handler and a MailServer available to - all Avalon blocks.
    • -
  • (FB) (update) Tune MessageContainer class.
    • -
-
- -
-

Unknown release date

-
    -
  • (FB) (update) Based on much code from Serge Knystautas first implementation of JAMES on - top of the Avalon framework.
    • -
-
- -
-

Check out our Who We Are page to see who to thank.

-
- - - diff --git a/server/2.2.0/src/site/xdoc/custom_mailet.xml b/server/2.2.0/src/site/xdoc/custom_mailet.xml deleted file mode 100644 index 3a9dab66755..00000000000 --- a/server/2.2.0/src/site/xdoc/custom_mailet.xml +++ /dev/null @@ -1,117 +0,0 @@ - - - - - - James 2.1 - Writing a Custom Mailet - - - -
-

Implementing a custom mailet is generally a simple task, most of whose complexity -lies in coding the actual work to be done by the mailet. This is largely due to the -simplicity of the Mailet interface and the fact that a GenericMailet class is provided -as part of the Mailet package.

-

In this discussion we will assume that any mailet being implemented is a subclass of -GenericMailet. The GenericMailet class serves to abstract away of the configuration and -logging details. While it provides a noop implementation of the init() and destroy() methods, -these can be easily overridden to provide useful functionality.

-

In general, the only four methods that you should need to implement are init(), destroy(), -getMailetInfo(), and service(Mail). And only the last is required in all cases.

- -

As described in the SpoolManager configuration -section, mailets are configured with a set of String (name, value) pairs. These values are -passed into the Mailet upon initialization (although the details of this process are hidden by -the GenericMailet implementation). GenericMailet provides access to this configuration -information through use of the getInitParameter(String) method. Passing in the name of the -requested configuration value will yield the value if set, and null otherwise. Configuration -values are available inside the init(), destroy(), and service(Mail) methods.

- - -

There is a simple logging mechanism provided by the Mailet API. It does not support -logging levels, so any log filtering will have to be implemented in the Mailet code. -Logging is done by calling one of the two logging methods on GenericMailet - log(String) -or log(String,Throwable). Logging is available inside the init(), destroy(), and service(Mail) -methods.

-

The value of getMailetInfo() for the Mailet is prepended to the log entries for that -Mailet. So it may be desirable for you to override this method so you can distinguish mailet -log entries by Mailet.

- - -

As part of the Mailet lifecycle, a Mailet is guaranteed to be initialized immediately after -being instantiated. This happens once and only once for each Mailet instance. The -Initialization phase is where configuration parsing and per-Mailet resource creation generally -take place. Depending on your Mailet, it may or may not be necessary to do any initialization -of the mailet. Initialization logic is implemented by overriding the init() method of -GenericMailet.

- - -

The bulk of the Mailet logic is expected to be invoked from the service(Mail) method. This -method is invoked each time a mail message is to be processed by the mailet. The message is -passed in as an instance of the Mail interface, which is part of the Mailet API.

-

The Mail interface is essentially a light wrapper around JavaMail's MimeMessage class with a -few important differences. See the Javadoc for the interface for a description of the additional -methods available on this wrapper.

- - -

As part of the Mailet lifecycle, a Mailet is guaranteed to be destroyed when the container -cleans up the Mailet. This happens once and only once for each Mailet instance. The -Destruction phase is where per-Mailet resource release generally takes place. Depending -on your Mailet, it may or may not be necessary to do any destruction -of the mailet. Destruction logic is implemented by overriding the destroy() method of -GenericMailet.

- -
-
-

Once a Mailet has been successfully implemented there are only a couple of -additional steps necessary to actually deploy the Mailet.

- -

-The Mailet must be added to James' classpath so that the Mailet can be loaded by James. There -are two ways to add a custom Mailet to the classpath so that James will be able to load the -Mailet. These are: -

-

-1. Download the source distribution, add a jar file containing the custom files to the lib -directory of the unpacked source distribution, and build a new .sar file by following the -directions here. This new .sar file will now -include your custom classes. -

-

-or -

-

-2. Place a jar file containing the custom class files in the lib subdirectory of the James -installation. It will also be necessary to unpack the JavaMail and James jar files from -the provided .sar file and add them to this directory. -

- - -

Configuration of the processor chain is discussed -elsewhere in this documentation. The -details of configuring mailet deployment is discussed at length. Here we will only comment -that it is important to add the appropriate mailet package for your custom mailet to the -<mailetpackages> list and that the name of your mailet should not conflict with any of -the mailets described here. -

- -
- - diff --git a/server/2.2.0/src/site/xdoc/custom_matcher.xml b/server/2.2.0/src/site/xdoc/custom_matcher.xml deleted file mode 100644 index b590166b76b..00000000000 --- a/server/2.2.0/src/site/xdoc/custom_matcher.xml +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - James 2.1 - Writing a Custom Matcher - - - -
-

Implementing a custom matcher is generally a simple task, most of whose complexity -lies in coding the actual work to be done by the matcher. This is largely due to the -simplicity of the Matcher interface and the fact that a couple of abstract Matcher template -classes are provided in the Mailet package. These two classes, GenericMatcher and -GenericRecipientMatcher, greatly simplfy the task of Matcher authoring.

-

As discussed elsewhere in this manual, the Matcher interface does not simply match -or not match a particular message. Rather, it returns some subset of the original message -recipients as a result of the match(Mail) method. This leads to the two different abstract -Matcher implementations.

-

The first, GenericMatcher, is intended for matchers where recipient evaluation is not -necessary. Basically, you should subclass this implementation if your matcher is going to -return all or none of the recipients.

-

When subclassing this class, there are four methods that potentially need to be -overridden. These are getMatcherInfo(), init(), match(Mail), and destroy(). More on these -anon.

-

The second implementation, GenericRecipientMatcher, is intended for those matchers where -each recipient is evaluated individually. It is a subclass of GenericMatcher, and inherits -most of its behavior from that class. The only major difference is that subclasses are -expected to override matchRecipient(MailAddress) rather than match(Mail).

- -

Matchers are passed a single String as part of their configuration. Interpretation of this -list is left entirely to the body of the Matcher. This String value is available in -the body of the Matcher through use of the getCondition() method of the -GenericMatcher class. This method returns the String value passed to the Matcher, and returns -null if no value is set. The method getCondition() is available inside the init(), destroy(), match(Mail), -and matchRecipient(MailAddress) methods.

- - -

There is a simple logging mechanism provided by the Mailet API. It does not support -logging levels, so any log filtering will have to be implemented in the Matcher code. -Logging is done by calling one of the two logging methods on GenericMatcher/GenericRecipientMatcher - log(String) -or log(String,Throwable). Logging is available inside the init(), destroy(), match(Mail), -and matchRecipient(MailAddress) methods.

-

The value of getMatcherInfo() for the Matcher is prepended to the log entries for that -Matcher. So it may be desirable for you to override this method so you can distinguish Matcher -log entries by Matcher.

- - -

As part of the Matcher lifecycle, a Matcher is guaranteed to be initialized immediately after -being instantiated. This happens once and only once for each Matcher instance. The -Initialization phase is where configuration parsing and per-Matcher resource creation generally -take place. Depending on your Matcher, it may or may not be necessary to do any initialization -of the Matcher. Initialization logic is implemented by overriding the init() method of -GenericMatcher/GenericRecipientMatcher.

- - -

It is the matching phase where the Matcher's work is done. The exact form of this phase largely -depends on which Matcher superclass is subclassed.

-

If GenericMatcher is being subclassed, it is the match(Mail) that is implemented. As described -above, this method returns a Collection of MailAddresses that is a subset of the original -recipients for the Mail object.

-

If it is a purely recipient-filtering Matcher, then the GenericRecipientMatcher should be -subclassed. In this case, developers must provide an implementation of the -matchRecipient(MailAddress) method. This method returns true if the recipient matches, -and false otherwise.

- - -

As part of the Matcher lifecycle, a Matcher is guaranteed to be destroyed when the container -cleans up the Matcher. This happens once and only once for each Matcher instance. The -Destruction phase is where per-Matcher resource release generally takes place. Depending -on your Matcher, it may or may not be necessary to do any destruction -of the Matcher. Destruction logic is implemented by overriding the destroy() method of -GenericMatcher/GenericRecipientMatcher.

- -
-
-

Once a Matcher has been successfully implemented there are only a couple of -additional steps necessary to actually deploy the Matcher.

- -

-The Matcher must be added to James' classpath so that the Matcher can be loaded by James. There -are two ways to add a custom Matcher to the classpath so that James will be able to load the -Matcher. These are: -

-

-1. Download the source distribution, add a jar file containing the custom files to the lib -directory of the unpacked source distribution, and build a new .sar file by following the -directions here. This new .sar file will now -include your custom classes. -

-

-or -

-

-2. Place a jar file containing the custom class files in the lib subdirectory of the James -installation. It will also be necessary to unpack the JavaMail and James jar files from -the provided .sar file and add them to this directory. -

- - -

Configuration of the processor chain is discussed -elsewhere in this documentation. The -details of configuring matcher deployment is discussed at length. Here we will only comment -that it is important to add the appropriate matcher package for your custom matcher to the -<matcherpackages> list and that the name of your matcher should not conflict with any of -the matchers described here. -

- -
- - diff --git a/server/2.2.0/src/site/xdoc/dns_configuration.xml b/server/2.2.0/src/site/xdoc/dns_configuration.xml deleted file mode 100755 index 2405840f245..00000000000 --- a/server/2.2.0/src/site/xdoc/dns_configuration.xml +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - James 2.1 - Configuring DNS Services - - - -
- - -

DNS Transport services are controlled by a configuration block in -the config.xml. This block affects SMTP remote delivery.

- -

The dnsserver tag defines the boundaries of the configuration -block. It encloses all the relevant configuration for the DNS server. -The behavior of the DNS service is controlled by the attributes and -children of this tag.

- -

The standard children of the dnsserver tag are:

-
    -
  • servers - This is a list of DNS Servers to be used by James and are -specified by one, or more server elements, which are child elements. -Each server element is the IP address of a single DNS server. - -<servers> - <server>127.0.0.1</server> - <server>166.181.194.205</server> -</servers> - -
    • - -
  • authoritative - (true/false)This tag specifies whether or not -to require authoritative (non-cached) DNS records; to only accept DNS responses that are -authoritative for the domain. It is primarily useful in an intranet/extranet environment. -

    This should always be false unless you understand the implications.

    -
    • -
-
- - diff --git a/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml b/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml deleted file mode 100755 index 512e7de1b52..00000000000 --- a/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml +++ /dev/null @@ -1,967 +0,0 @@ - - - - - James 2.2 - fetchmail Configurartion - - - -
-

fetchmail acts as a gateway between an external message store such as an IMAP -or POP3 server and James. Mail is fetched from the external message store and -injected into the James input spool.

- -

fetchmail is useful when delivery via standard SMTP is not an option, as a -means of consolidating mail delivered to several external accounts into a single -James account, or to apply the mail processing capabilities of James to mail -stored in an external message store.

- -

fetchmail has several configuration options that control the fetching and -filtering of mail injected into the James input spool. Once there, James' -flexible mail processing engine can be used to further process the mail, just as -if it had been delivered via standard SMTP.

- -

-How fetchmail Works
-fetchmail Configuration Parameters
-fetchmail Examples
-fetchmail Caveats -

-
- -
-

Mail is delivered by periodically running fetch tasks that read messages from -an external message store and injects them into the James input spool. Fetch -tasks run concurrently.

- -

A set of filters applies to each fetch task. Each filter provides the ability -to reject a message that matches the filter criteria. Rejected messages are not -injected into the James input spool; they are either marked as seen or deleted. -When a filter is configured to accept a message that matches its criteria, -messages are marked with a MailAttribute. This MailAttribute can be detected -within the James matcher/mailet chain, allowing further processing as -required.

- -

Each fetch task is associated with a single host server. Accounts are defined -to the fetch task for each mailbox on the server from which mail is to be -fetched. Accounts run consecutively.

- -

Optionally, the fetch task can be configured with an <alllocal> Account that -generates an Account entry for each user defined in the James user repository. -This removes the requirement to manually add or remove Account entries to the -fetchmail configuration each time a James user is added or removed. Currently -this is only useful if the server supports virtual mailboxes that allow the same -password to apply to all users within a domain.

- -

Accounts can be configured to deliver all mail for an Account to a specified -recipient or to deduce the intended recipient from the mail headers.

- -

Accounts are normally configured to deliver all mail for an Account to a -specified recipient, ignoring the recipient in the mail headers. This works well -in the majority of cases where a mailbox is guaranteed to contain mail for a sole -mailbox recipient.

- -

Accounts are configured to deduce the intended recipient from the mail headers -when a mailbox contains mail for several users, typically all users in a domain. -Used alone, this is not foolproof as there are circumstances when a single unique -recipient cannot be deduced from the mail headers alone. Used in conjunction with -an appropriately configured <alllocal> account, it is always possible to deduce -the intended recipient when the recipient is a James user.

-
- -
-

The fetchmail configuration parameters are part of the James configuration, -whose base file is config.xml. For clarity and flexibility, the -fetchmail configuration parameters are stored in the file -james-fetchmail.xml, which is referenced within -config.xml.

- -

The configuration parameters are described below.

- - -

The configuration block delimited by the fetchmail tag -controls fetchmail.

- -

The tag has these attributes: -

-
enabled
-
A boolean. If "true", the fetch tasks will be run periodically. If "false", -no fetch tasks will be run. The default is "false".
-
-

- -

The tag has these child tags (minimum cardinality, maximum cardinality): -

-

- -

- -<fetchmail enabled="true"> -... -</fetchmail> - -

- - - -

The fetch tag defines a fetch task to be run -periodically. Fetch tasks run concurrently.

- -

The tag has these attributes: -

-
name
-
A string uniquely identifying the fetch task.
-
-

- -

The tag has these child tags (minimum cardinality, maximum cardinality): -

-

- -

- -<fetch name="mydomain.com"> -... -</fetch> - -

- - - -

The accounts tag declares the accounts from which mail will -be fetched by the fetch task. Accounts run concurrently.

- -

The tag has these child tags (minimum cardinality, maximum cardinality): -

-

- -

- -<accounts> -... -</accounts> - -

- - - -

The blacklist tag declares a list of recipient addresses -for whom mail will be rejected and what happens to the rejected mail.

- -

The tag value is a tab, comma or space delimited list of recipient -addresses, eg: wibble@mydomain.com, flobble@mydomain.com.

- -

The tag has these attributes: -

-
reject
-
A boolean. If "true", mail for recipients in the blacklist will -not be injected into the James input spool. If "false", mail for -recipients in the blacklist will be injected into the James input spool with the -Mail Attribute org.apache.james.fetchmail.isBlacklistedRecipient -added to the mail.
-
leaveonserver
-
A boolean. If "true", mail for recipients in the blacklist will be -left on the server. If "false", mail for recipients in the blacklist -will be marked for deletion.
-
markseen
-
A boolean. If "true", mail for recipients in the blacklist will be -marked as seen on the server. If "false", mail for recipients in the blacklist -will not be marked as seen.
-
-

- -

- -<blacklist - reject="true" - leaveonserver="true" - markseen="true"> -wibble@mydomain.com, flobble@mydomain.com -</blacklist> - -

- - - -

The defaultdomain tag declares the domain name to be -appended to the From: header of a mail that has a valid user part -but is missing the domain part.

- -

If not specified, the default behaviour is to append the canonical host name -of the James server.

- -

The tag value is the name of the server to append. The name must be a server -declared in the servernames tag of the James -block in the configuration or the name localhost.

- -

- -<defaultdomain> - mydomain.com -</defaultdomain> - -

- - - -

The fetchall tag declares if all mail should be fetched from -the server, or just unseen mail.

- -

The tag value is a boolean. If true, all mail is fetched. If false, only -unseen mail is fetched.

- -

- -<fetchall>false</fetchall> - -

- - - -

The fetched tag declares what will happen to mail on the -external server that is successfully injected into the James input spool.

- -

The tag has these attributes: -

-
leaveonserver
-
A boolean. If "true", mail injected into the James input spool -will be left on the server. If "false", mail injected into the James -input spool will be marked for deletion.
-
markseen
-
A boolean. If "true", mail injected into the James input spool -will be marked as seen on the server. If "false", mail injected into -the James input spool will not be marked as seen.
-
-

- -

- -<fetched leaveonserver="true" markseen="true"/> - -

- - - -

The host tag declares the IP address of the external -server from which mail is fetched.

- -

The tag value is the DNS name or IP address literal of the external -server.

- -

- -<host>pop3.server.com</host> - -

- - - -

The interval tag declares the period between invocations of -the fetch tasks. If a fetch task is still active from a previous invocation -when the period expires, the new invocation is skipped over.

- -

The tag value is an integer representing the number of milliseconds to elapse -between invocations of the fetch tasks.

- -

- -<interval>60000</interval> - -

- - - -

The javaMailFolderName tag declares the name of the root -folder on the external server from which mail is fetched.

- -

The tag value is the cAsE-sEnSiTiVe name of the root folder on the external -server from which mail is fetched. For POP3 servers this is always -INBOX.

- -

- -<javaMailFolderName>INBOX</javaMailFolderName> - -

- - - -

The javaMailProperties tag declares the properties to be -applied to the JavaMail Session used by the fetch task. These override the -properties answered by System.getProperties(). Many JavaMail -properties are specific to the JavaMail Provider selected by the -javaMailProviderName tag.

- -

Relying on the default values selected by the Provider can be -inappropriate. For instance, the default connection and I/O timeout -values of infinite for the default IMAP and POP3 Providers is rarely what is -required. Consult the documentation of the Provider for details and options.

- -

Documentation for the default Provider for IMAP is located - -here.

- -

Documentation for the default Provider for POP3 is located - -here.

- -

Details of how to change a Provider are located - -here.

- -

The tag has these child tags (minimum cardinality, maximum cardinality): -

-

- -

- -<javaMailProperties> -... -</javaMailProperties> - -

- - - -

The javaMailProviderName tag selects the JavaMail protocol -Provider used to interact with the external server.

- -

The tag value is the name of a JavaMail supported protocol, such as -pop3 or imap. The name is used to select the default -Provider for the protocol.

- -

- -<javaMailProviderName>pop3</javaMailProviderName> - -

- - - -

The maxmessagesize tag declares the maximum permitted message -size for messages injected into the James input spool and what happens to fetched -messages that exceed this size.

-

The tag has these attributes: -

-
limit
-
An integer. The maximum message size expressed in Kilobytes. If 0, there is -no limit.
-
reject
-
A boolean. If "true", mail whose message size exceeds the maximum -permitted size will not be injected into the James input spool. If -"false", mail whose message size exceeds the maximum permitted size will -have its contents removed, an explanatory error message and the Mail Attribute -org.apache.james.fetchmail.isMaxMessageSizeExceeded added prior to -injection into the James input spool, (see below for the location of an example).
-
leaveonserver
-
A boolean. If "true", mail whose message size exceeds the maximum -permitted size will be left on the server. If "false", mail whose message -size exceeds the maximum permitted size will be marked for deletion.
-
markseen
-
A boolean. If "true", mail whose message size exceeds the maximum -permitted size will be marked as seen on the server. If "false", -mail whose message size exceeds the maximum permitted size will not be marked as -seen.
-
-

- -

- -<maxmessagesize - limit="4096" - reject="false" - leaveonserver="false" - markseen="false"/> - -

- -

An example configuration using James mailet processing to bounce fetched -messages that exceed the maximum permitted size can be found in the file -$PHOENIX_HOME/apps/james/conf/samples/fetchmail/maxMessageSize.xml. -

- - - -

The recipientnotfound tag declares what happens to mail for -which a sole intended recipient cannot be found when attempting to determine -the recipient from the mail headers.

- -

In configurations with more than one account per fetch task, processing of -matched mail can be deferred to the next run of the fetch task. This gives -other accounts that may be able to determine a sole intended recipient an -opportunity to do so before recipientnotfound processing is invoked.

- -

The tag has these attributes: -

-
defer
-
A boolean. If "true", mail for which a sole intended recipient -cannot be determined is left unprocessed until the next run of the fetch task. -If "false", mail for which a sole intended recipient cannot be -determined is processed immediately.
-
reject
-
A boolean. If "true", mail for which a sole intended recipient -cannot be determined will not be injected into the James input spool. If -"false", mail for which a sole intended recipient cannot be -determined will be injected into the James input spool using the recipient -attribute of the current account and with the Mail Attribute -org.apache.james.fetchmail.isRecipientNotFound added to the -mail.
-
leaveonserver
-
A boolean. If "true", mail for which a sole intended recipient -cannot be determined will be left on the server. If "false", mail for -which a sole intended recipient cannot be determined will be marked for -deletion.
-
markseen
-
A boolean. If "true", mail for which a sole intended recipient -cannot be determined will be marked as seen on the server. If "false", -mail for which a sole intended recipient cannot be determined will not be marked -as seen.
-
-

- -

- -<recipientnotfound - defer="true" - reject="true" - leaveonserver="true" - markseen="true"/> - -

- - - -

The recursesubfolders tag declares if mail should be fetched -from sub-folders of the root folder, or just the root folder.

- -

The tag value is a boolean. If true, mail is fetched from the root folder and -its subfolders. If false, mail is fetched from just the root folder.

- -

- -<recursesubfolders>false</recursesubfolders> - -

- - - -

The remoteReceivedHeader tag declares the zero based -index of the RFC2822 compliant RECEIVED header used to determine the address and -host name of the remote MTA that sent a fetched message and what happens to -messages when the specified header is invalid.

- -

Typically, the first (index = 0) RECEIVED header is for the local MTA that -delivered the message to the message store and the second (index = 1) RECEIVED -header is for the remote MTA that delivered the message to the local MTA. When -this configuration applies, the remoteReceivedHeaderIndex should -be set to 1. -

- -

To verify the correct setting, examine the RECEIVED headers for messages -delivered to the configured message store and locate the first one containing a -remote domain in the'from' field. Remembering that zero based indexing is used, -if this the second header, use an index of 1, if this is the third header, use an -index of 2, and so forth.

- -

Matchers such as InSpammerBlacklist use the remote address and/or remote host -name to identify illegitimate remote MTAs. If you do not use such matchers, the -remoteReceivedHeaderIndex tag may be omitted or the default -index value of -1 can be specified. This causes the remote address to be set to -127.0.0.1 and the remote host name to be set to -localhost. Matchers almost always considered these values to be -legitimate.

- -

The tag has these attributes: -

-
index
-
An integer whose meaning is described above. -
-
reject
-
A boolean. If "true", mail whose specified recieved header is invalid -will not be injected into the James input spool. If "false", mail whose -specified recieved header is invalid will be injected into the James input spool with -the Mail Attribute org.apache.james.fetchmail.isInvalidReceivedHeader -added to the mail, the remote address set to 127.0.0.1 and the remote -host name set to localhost. -
-
leaveonserver
-
A boolean. If "true", mail whose specified recieved header is invalid -will be left on the server. If "false", mail whose specified recieved header -is invalid will be marked for deletion.
-
markseen
-
A boolean. If "true", mail whose specified recieved header is invalid -will be marked as seen on the server. If "false", mail whose specified -recieved header is invalid will not be marked as seen.
-
-

- -

- -<remoteReceivedHeader - index="1" - reject="true" - leaveonserver="true" - markseen="true"/> - -

- -

An example configuration using James mailet processing to notify the postmaster -of fetched messages that contain an invalid Received header can be found in the file -$PHOENIX_HOME/apps/james/conf/samples/fetchmail/remoteReceivedHeader.xml. -

- - - -

The remoterecipient tag declares what happens to mail for -which the domain part of the recipient is remote. A domain is remote if it is -not a server declared in the servernames tag of the -James block in the configuration.

- -

The tag has these attributes: -

-
reject
-
A boolean. If "true", mail for remote recipients will not be -injected into the James input spool. If "false", mail for remote -recipients will be injected into the James input spool with the Mail Attribute -org.apache.james.fetchmail.isRemoteRecipient added to the mail. -
-
leaveonserver
-
A boolean. If "true", mail for remote recipients will be left on -the server. If "false", mail for remote recipients will be marked for -deletion.
-
markseen
-
A boolean. If "true", mail for remote recipients will be marked as -seen on the server. If "false", mail for remote recipients will not be -marked as seen.
-
-

- -

- -<remoterecipient - reject="true" - leaveonserver="true" - markseen="true"/> - -

- - - -

The undeliverable tag declares what happens to mail that -cannot be delivered.

- -

The tag has these attributes: -

-
leaveonserver
-
A boolean. If "true", mail that cannot be delivered will be left -on the server. If "false", mail that cannot be delivered will be -marked for deletion.
-
markseen
-
A boolean. If "true", mail for that cannot be delivered will be -marked as seen on the server. If "false", mail that cannot be -delivered will not be marked as seen.
-
-

- -

- -<undeliverable - leaveonserver="true" - markseen="true"/> - -

- - - -

The userundefined tag declares what happens to mail for -which the recipient is not defined as a James user.

- -

The tag has these attributes: -

-
reject
-
A boolean. If "true", mail for recipients who are not defined as -James users will not be injected into the James input spool. If -"false", mail for recipients who are not defined as James users will -be injected into the James input spool with the Mail Attribute -org.apache.james.fetchmail.isUserUndefined added to the mail. -
-
leaveonserver
-
A boolean. If "true", mail for recipients who are not defined as -James users will be left on the server. If "false", mail for -recipients who are not defined as James users will be marked for deletion.
-
markseen
-
A boolean. If "true", mail for recipients who are not defined as -James users will be marked as seen on the server. If "false", mail -for recipients who are not defined as James users will not be marked as seen. -
-
-

- -

- -<userundefined - reject="true" - leaveonserver="true" - markseen="true"/> - -

- - - -

The account tag declares an account on the external server -from which mail should be fetched.

- -

The tag has these attributes: -

-
user
-
The string to be passed as the user when connecting to the external server. -
-
password
-
The string to be passed as the password when connecting to the external -server.
-
recipient
-
The recipient to whom messages will be delivered when the intended recipient -cannot be determined or when the intended recipient is to be ignored.
-
ignorercpt-header
-
A boolean. If "true", mail is always delivered to the recipient -declared in the recipient attribute above. If -"false", the intended recipient is determined from the mail headers or -the process declared by the recipientnotfound tag. -
-
-

- -

- -<account - user="myaccount" - password="mypassword" - recipient="user@localhost" - ignorercpt-header="true"/> - -

- - - -

The alllocal tag declares the parameters to be applied to -dynamic accounts. The set of dynamic accounts is refreshed each time the fetch -task runs by combining the alllocal tag attributes with each of -the currently defined James users to create an account for every James user.

- -

The tag has these attributes: -

-
userprefix
-
The string to be added before the James user when constructing the string -passed as the user when connecting to the external server. -
-
usersuffix
-
The string to be added after the James user when constructing the string -passed as the user when connecting to the external server. -
-
password
-
The string to be passed as the password when connecting to the external -server.
-
recipientprefix
-
The string to be added before the James user when constructing the recipient -to whom messages will be delivered when the intended recipient cannot be -determined or when the intended recipient is to be ignored.
-
recipientsuffix
-
The string to be added after the James user when constructing the recipient -to whom messages will be delivered when the intended recipient cannot be -determined or when the intended recipient is to be ignored.
-
ignorercpt-header
-
A boolean. If "true", mail is always delivered to the recipient -constructed from the recipientprefix and -recipientsuffix attributes above and the James user. If -"false", the intended recipient is determined from the mail headers or -the process declared by the recipientnotfound tag. -
-
-

- -

- -<alllocal - userprefix="" - usersuffix="@external.domain.com" - password="mypassword" - recipientprefix="" - recipientsuffix="@mydomain.com" - ignorercpt-header="true"/> - -

- - - -

The property tag declares a name/value pair.

- -

The tag has these attributes: -

-
name
-
The name of the property. -
-
value
-
The value of the property.
-
-

- -

- -<property - name="mail.pop3.connectiontimeout" - value="180000"/> - -

- - -
- -
-

Full sources to the examples discussed below can be found in the directory -$PHOENIX_HOME/apps/james/conf/samples/fetchmail.

- - -

When all mail for an account is to be delivered to a single user, -configure each account to ignore the recipient in the mail headers and deliver -to the specified recipient. The accounts block looks like -this:

- -

- -<accounts> - <account - user="user1@external.domain.com" - password="password1" - recipient="user1@localhost" - ignorercpt-header="true"/> - - <account - user="user2@external.domain.com" - password="password2" - recipient="user2@localhost" - ignorercpt-header="true"/> - - <account - user="user3@external.domain.com" - password="password3" - recipient="user3@localhost" - ignorercpt-header="true"/> -</accounts> - -

- - - -

When an account contains mail to be delivered to many users, configure each -account to determine the recipient from the mail headers and deliver to that -user. The accounts block looks like this:

- -

- -<accounts> - <account - user="global@external.domain.com" - password="password" - recipient="fetchmail@localhost" - ignorercpt-header="false"/> -</accounts> - -

- -

The recipientnotfound tag is used to declare what happens -when the recipient cannot be determined from the mail headers. In the example -below, mail is injected into the spool using the recipient declared in the -account tag:

- -

- -<recipientnotfound - defer="false" - reject="false" - leaveonserver="false" - markseen="false"/> - -

- - - -

When an external server supports virtual mailboxes, fetchmail's dynamic -account facility can be used. This greatly simplifies user configuration as -the fetchmail accounts for users are automatically synchronized with those -defined in the James user repository. This guarantees that mail for all local -users will be fetched and delivered.

- -

Currently, there is a limitation that all virtual accounts and the global -account must share the same password.

- -

The alllocal tag declares the parameters for the dynamic -accounts. The accounts block below will deliver mail for -user1@external.domain.com to user1@localhost, -user2@external.domain.com to user2@localhost, -userZ@external.domain.com to userZ@localhost etc.:

- -

- -<accounts> - <alllocal - userprefix="" - usersuffix="@external.domain.com" - password="mypassword" - recipientprefix="" - recipientsuffix="@localhost" - ignorercpt-header="true"/> -</accounts> - -

- - - -

The -One Account, One User - Dynamic -example guarantees delivery of mail for all local users, but leaves other mail -on the external server unprocessed. The -One Account, Many Users example -processes all mail on the external server, but cannot guarantee delivery to the -intended recipient. By combining the two, it is possible to guarantee the -delivery of mail for all local users and process all mail.

- -

In the snippet below, the alllocal tag declares dynamic -accounts for all local users and the account tag configures an -account to fetch all mail.

- -

The recipientnotfound tag rejects mail for which a recipient -cannot be determined. By the time this processing is activated, the dynamic -accounts will have processed mail for all local users, so the mail can -only be mail for non-local users or newly arrived mail for local users. It is -not possible to know which, but we want to leave mail for local users to be -dealt with by the dynamic accounts. The next time the dynamic accounts run any -newly arrived mail for local users will be processed. The remainder will be for -non-local users and can now be safely dealt with.

- -

The <recipientnotfound defer="true" attribute -enables deferal of the processing of messages for which the recipient cannot be -determined to the next iteration of the fetch task, and is used here. The -relevant tags are:

- -

- -<accounts> - <alllocal - userprefix="" - usersuffix="@external.domain.com" - password="mypassword" - recipientprefix="" - recipientsuffix="@localhost" - ignorercpt-header="true"/> - - <account - user="global@external.domain.com" - password="password" - recipient="fetchmail@localhost" - ignorercpt-header="false"/> -</accounts> - -<recipientnotfound - defer="true" - reject="true" - leaveonserver="true" - markseen="true"/> - -

- - -
- -
-

These are some things to be aware of when using fetchmail: -

    -
  • As noted in the -One Account, One User - Dynamic -example, all virtual accounts and the global account must share the same -password. A future version might associate each James user to a set of account -credentials. -
    • - -
  • When using dynamic accounts, an account is generated and an attempt made to -fetch mail for all James users defined to James even if there is no such mailbox -on the server. This is inefficient but not fatal. The solution is the same as -described above. -
    • - -
  • When using dynamic accounts, as described in the -One Account, Many Users - Dynamic -example, the user name used to fetch the mail for all accounts must not be -defined as a James user. If it is, a dynamic account will be generated for it -and fetch all the mail before the account declared to process mail for all users -has an opportunity to run! -
    • - -
  • The now deprecated fetchPOP interacted with the FetchedFrom -matcher to detect mail injected by fetchPOP. This will not work with fetchmail. -Compared to fetchPOP, there are far fewer occasions when mail injected by -fetchmail requires special processing. When it does, use the HasMailAttribute -matcher to match the attribute named -org.apache.james.fetchmail.taskName to detect all mail injected by -fetchmail. To detect mail injected by a specific fetch task, use one of the -HasMailAttributeWithValue matchers to match on the attribute name and the -attribute value. The attribute value is the name of the fetch task that -injected the mail. -
    • - -
  • The POP3 protocol does not enforce support of any of the Flags associated -with messages other than DELETED. This means that -markseen="true" will most likely have no effect and -therefore, the fetchall tag will be inoperative. In this -situation, the only way to avoid repeatedly fetching the same mail is to delete -it from the server using leaveonserver="false"/>. -
    • -
-

-
- - - - - diff --git a/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml b/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml deleted file mode 100644 index 08bc7a5448d..00000000000 --- a/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml +++ /dev/null @@ -1,105 +0,0 @@ - - - - - - James 2.1 - Configuring FetchPOP - - - -
-

FetchPOP is being deprecated. -fetchMail provides a superset of -FetchPOP's functionality and is the preferred solution.

-
- -
-

FetchPOP is controlled by a configuration block in the config.xml. -The fetchpop tag defines the boundaries of the configuration block. It encloses -all the relevant configuration for the FetchPOP scheduler. The behavior of the POP service is -controlled by the attributes and children of this tag.

-

This tag has an optional boolean attribute - enabled - that defines whether -the service is active or not. The value defaults to "false" if not present.

-

The only permitted children of the fetchpop tag are fetch elements. Each of -these fetch tags defines a single FetchPOP task.

-

The fetch tag has a single required attribute, name. The name -of each FetchPOP task must be unique.

-

In addition to the name attribute, the fetch tag has four -children, all of which are required.

-
    -
  • host - The host name or IP address of the POP3 server hosting the mail to be fetched.
    • -
  • user - The user name of the account whose mail is to be fetched.
    • -
  • password - The password for the account whose mail is to be fetched.
    • -
  • interval - A non-negative integer representing the number of milliseconds between fetches.
    • -
-
-
-

There are a number of issues which have to be considered when handling fetched mail, such as avoiding circular -routing of mail. Some scenarios are described below with suggested configurations.

- - -

This is the intended primary use of FetchPOP. -If all mail for a domain being fetched is ultimately being handled by this server then it is enough to add -the domain name as a servername to the servernames section described here. -
This is the simplest solution and is used where James is being used to redistribute all mail from the -free catch-all POP accounts provided by many domain registration/hosting companies.

- - -

If only part of a domain's mail (perhaps only a single user's POP account) is being handled by this instance -of James it is important that outgoing mail addressed to this domain that is not intended for James be properly delivered.

-

To enable this filtering the FetchPOP scheduler adds a header, X-fetchedby, to the fetched message. This header can be checked using -the provided matcher FetchedFrom. This matcher can be used to direct fetched mail to a processor set up -to handle mail fetched from one or more POP3 accounts. The matcher should be used exactly once in the mail -pipeline for each FetchPOP task, as the matcher removes a matching header to prevent outgoing replies or -redirections from looping.

-

The FetchedFrom matcher is configured with the name of the particular FetchPOP task it is supposed to match. In general, -this matcher will be used to direct mail to a custom processor for further processing. A mailet tag such as the -following

- -<mailet match="FetchedFrom=fetchtaskname" class="ToProcessor">
-<processor>fetchprocessor</processor> -</mailet> - -

where fetchtaskname is the name of the FetchPOP task being matched and fetchprocessor is the name of the fetched mail -processor can be used to this purpose. The fetched mail processor should contain mailets which will filter -and forward mail to real local or remote users. This can be achieved in the usual fashion as described in the -SpoolManager configuration section and in the out of the box -configuration file.

- - -

It is important to note that this first version of FetchPOP does not access the original intended recipient -address of the mail, but instead uses the To: address from the message headers. Since this header may contain an -alias for the intended recipient, or may never have contained the intended recipient address (it could have been -in the Cc: or Bcc: fields) it is possible that James will be unable to deliver the fetched mail. It is intended -that this behaviour be addressed in the next version of James, but in the meantime a catch-all forwarding of -locally undeliverable fetched mail is recommended.

-

To handle messages where the intended recipient can be determined but is not present in the To: header, the FetchedFrom -matcher can be used. Place a mailet tag with this matcher between the "RecipientIsLocal" and "HostIsLocal" in the -Transport processor as defined in the out of the box configuration. The mailet tag should be configured to use the -provided ToProcessor mailet to direct fetched mail to a custom processor. Thus all mail fetched by FetchPOP that -could not be trivially mapped to a local user account will undergo further processing, allowing more complex -delivery handling.

-

For safety the All matcher should be used at the end of your custom fetched mail processor. This can be used to -catch all mail not handled by previous mailets in the processor. This will enable you to ensure that your -configuration is correct and that any mail not correctly delivered is available for examination by the postmaster.

- -
- - diff --git a/server/2.2.0/src/site/xdoc/index.xml b/server/2.2.0/src/site/xdoc/index.xml deleted file mode 100644 index 837d82d68a1..00000000000 --- a/server/2.2.0/src/site/xdoc/index.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - James 2.1/2.2 - Table of Contents - - - -
-

-The Java Apache Mail Enterprise Server (a.k.a. Apache James) is a 100% pure Java SMTP and POP3 Mail -server and NNTP News server designed to be a complete and portable enterprise mail engine -solution. James is based on currently available open protocols. -

-

-The James server also serves as a mail application platform. The James project hosts the Apache Mailet API, -and the James server is a Mailet container. This feature makes it easy to design, write, and deploy -custom applications for mail processing. This modularity and ease of customization is one of James' -strengths, and can allow administrators to produce powerful applications surprisingly easily. -

-

-James is built on top of version 4.1.3 of the Avalon Application Framework. This -framework encourages a set of good development practices such as Component Oriented Programming and -Inversion of Control. The standard distribution of James includes version 4.0.1 of the -Phoenix Avalon Framework container. This stable -and robust container provides a strong foundation for the James server. -

-

-This documentation is intended to be an introduction to the concepts behind the James implementation, as well -as a guide to installing, configuring, (and for developers) building the James server. -

- -

-I. James Concepts -

-II. How To Build James - -III. How To Install James - -IV. Configuring James - -V. Common Configurations - -VI. Customizing James - -V. Other Information - -

- -
- - diff --git a/server/2.2.0/src/site/xdoc/installation_instructions.xml b/server/2.2.0/src/site/xdoc/installation_instructions.xml deleted file mode 100644 index 771619dfba6..00000000000 --- a/server/2.2.0/src/site/xdoc/installation_instructions.xml +++ /dev/null @@ -1,110 +0,0 @@ - - - - - - James 2.1 - Installation - - -
-

James requires a Java Runtime Environment of Java version 1.3 or higher installed to run the -James application. The exact JREs available depend on the platform. A JRE must be downloaded and -installed before James can run. In addition, the environment variable JAVA_HOME must be set to -the JRE home directory before running James.

-

-Warning! - Issues have been observed when using Sun's Java 1.3.0 on older Linux -distributions. It is recommended that users of these platforms run James using a more recent -Sun JRE or a JRE produced by an alternate vendor. -

-

-On Unix platforms, root access will be required to run James. On these platforms, access to ports -below 1024 is generally restricted to the root user. As SMTP, POP3, and NNTP all need to open -server sockets on such ports in standard configurations, James requires root access. -

-

-Obviously James also requires sufficient disk space, processor power, and network bandwidth. But, -other than what's been discussed here, it has no additional special requirements.

-
-
-

James installation involves a number of steps, each of which is described in some detail in the -following sections. But as this sequence of steps has confused some users in the past, additional -comments seem warranted.

-

It is important to realize that the James configuration files are not unpacked from the James -distribution until the first time James is started. This is a consequence of the design of the -Avalon Phoenix container used to run James. Once James has been started, the distribution will -be unpacked. The server should be stopped, the configuration files edited, and the server restarted.

-

So the installation sequence is: 1) Start, 2) Stop, 3) Edit, 4) Restart.

-
-
- -

Obtain the full James binary distribution from the James -release mirrors. Unpack the archive into your James installation directory. Go to the bin subdirectory of the -installation directory and run the "run" script (either run.sh or run.bat, depending on your platform). The configuration -file is now unpacked and available for editing.

- - -

Warning! - James requires Phoenix version 4.0.x to run. There is a known issue with logging in Phoenix 4.0, so version -4.0.1 or higher is strongly recommended. Before attempting to deploy James in a Phoenix container, please make sure -it meets these version criteria.

-

Deploying James in Phoenix is fairly easy. Obtain the james.sar file from the James -release mirrors. It can be found in the "Other Binaries" -area of the distribution directory. After downloading the james.sar, -simply place it in the apps subdirectory of your Phoenix installation. Restart Phoenix, and the james.sar should unpack and you -will be ready to configure your James installation.

- -
- -
-

-After installing the binary, the next step is to adjust the initial configuration. The server should be stopped, and then -configuration can proceed. The most essential configuration is set in the config.xml file. This file can be -found in the apps/james/SAR-INF subdirectory of the installation directory.

-

The out of the box configuration makes certain assumptions and has some default values that are unlikely to -be appropriate for real-world servers. There are a few issues that should be addressed immediately upon installation: -

-
    -
  • RemoteManager Administrator Account - Before the RemoteManager service can be used to add users to this server -installation an administrator account must be created. More information can be found here.
    • -
  • DNS Servers - James needs to have access to a DNS server for domain resolution. The out of the box -configuration assumes that there is a DNS server on localhost. In general administrators will have to change -the configuration to point to a valid DNS server. This can be done by adjusting the dnsserver configuration -block in the config.xml. More information can be found here.
    • -
  • Managed Domain Names/IP Addresses - Out of the box, James only handles mail that is sent to recipients at -localhost. It will attempt to deliver all other email to remote SMTP servers. To allow James to handle email -for your domain or IP address, you simply need to add the appropriate domain name or IP address to the servernames -section of the config.xml. More information can be found here.
    • -
  • Postmaster Address - More information can be found here.
    • -
-

In addition to adjusting these parameters, you may wish to consult the documentation for a discussion of -common configurations. A list of such configurations, as well as the steps necessary to configure them, can -be found here.

-
-
-

Once you have edited the configuration file you will need to restart James so that the changes take -effect. When James starts, a list of the James services and the ports on which they are listening should -be displayed on the console. Additional information about the system configuration is printed in the James log files -upon startup.

-

Finally, after configuration is complete, it will be necessary to create user accounts before the James server -will be fully operational. Instructions on creating user accounts can be found -here.

-
- - - diff --git a/server/2.2.0/src/site/xdoc/james_and_sendmail.xml b/server/2.2.0/src/site/xdoc/james_and_sendmail.xml deleted file mode 100644 index 067a7f4d755..00000000000 --- a/server/2.2.0/src/site/xdoc/james_and_sendmail.xml +++ /dev/null @@ -1,124 +0,0 @@ - - - - - - Sendmail integration - Danny Angus - - - - -
- -

- This document explains how to configure sendmail to route all mail generated by /usr/sbin/sendmail or local mail on a host through James on the same host, including mail to local addresses without @host.
- All sendmail configuration file locations are for Redhat Linux 7.2, other installations may have different locations.
- We take no responsibility for the quality of the information in this document.
You should back-up any configuration files *before* you alter them. -

-
- -
- -

-Ok so you want to use James for everything, including delivering mail from localhost to local users.
-Well the first step is to stop sendmail from starting up as the SMTP Daemon on port 25, otherwise it will route mail to itself and who knows what will happen then.
-Open the sendmail configuration file /etc/sysconfig/sendmail -Change the line:DAEMON=yesintoDAEMON=no -Restart sendmail with:[root@apache root]# /etc/rc.d/init.d/sendmail restartThis will make sendmail process its outgoing queue, but not listen on port 25 for incoming mail. -

- - -

-Ok, so far so good, now you need to tell sendmail to relay everything, regardless of its rules, through James. James will take the roles of "local relay" (destination for all unqualified local addresses), "mail hub" (destination for all qualified local addresses) and "smart relay" (destination for all other mail) for this instance of sendmail, thereby catching everything.
-So open /etc/sendmail.cf and.. -

    -
  • Look for the line beginning DS make this line DSesmtp:localhost
    • -
  • Look for the line beginning DR make this line DResmtp:localhost
    • -
  • Look for the line beginning DH make this line DHesmtp:localhost
    • -
-Now that wasn't too hard was it?
-What we have done is to tell sendmail to use its "mailer" called esmtp to relay mail using ESMTP to localhost for each role.
-Of course no-one in their right mind would relay mail to localhost, because it would loop forever right? -

- - - -

-The developers of sendmail have, wisely, built sendmail in such a way as to prevent, by default, mail being sent by sendmail back to itself, this is done by making a quick check on outgoing mail to see if its destination is our machine. If it is you'll see this message config error: mail loops back to me when you try to send mail.
-But we *want* to relay mail to localhost, and because sendmail isn't receiving our mail, James is, we won't be creating a loop. (make sure you've followed step one though).
-So open /etc/sendmail.cf again and go to the bottom of the file, start scrolling upwards until you see the declaration of the esmtp mailer it'll look something like this - -Mesmtp, P=[IPC], F=mDFMuXa, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990, - T=DNS/RFC822/SMTP, - A=TCP $h - -You need to change it so its more like this: :-D - -Mesmtp, P=[IPC], F=kmDFMuXa, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990, - T=DNS/RFC822/SMTP, - A=TCP $h - -But seriously, we've added a k to the "F=" list F=mDFMuXa becomes F=kmDFMuXa
-And again, thats it, sendmail will now skip the loopback test on mail leaving through the esmtp mailer. -

-

Now you have to make some tests.
Try each of the following, replace names in [] with names of the kind described. -/[root@apache root]# mail -v [real-localusername] - -[root@apache root]# mail -v [nonexistant-localusername] - -[root@apache root]# mail -v [real-localusername]@localhost - -[root@apache root]# mail -v [real-localusername]@[myhostname.mydomainname] - -[root@apache root]# mail -v [real-username]@[real-remote-account] - -Sendmail echoes each conversation to STDOUT so you can see what its trying to do with each mail.
-

- - - -

-SMTP AUTH is a different Kettle of Fish.
-The scenario is that you're using SMTP AUTH on James to restrict SMTP relaying to authenticated users, allowing them to connect from any IP address but still not letting James become an open relay for spam, cool.
-However you now want to let sendmail relay through James, so you need to tell it how to authenticate.
-So open /etc/sendmail.cf again and this time.. -

    -
  • Look for the line beginning O AuthMechanisms= If this line is commented out with a leading #, remove the # then make sure LOGIN and PLAIN are at the beginning of this line like this O AuthMechanisms=LOGIN PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5
    • -
  • Look for the line beginning O DefaultAuthInfo= If this line is commented out with a leading #, remove the # then make this line O DefaultAuthInfo=/etc/mail/default-auth-info
    • -
  • Create a user account on James for sendmail to login as.
    • -
  • Create the file /etc/mail/default-auth-info
    • -
  • It should contain thisusername -username -password -localhostYes the username appears twice.
    • -
  • Replace username and password with the details of the account you just created.
    • -
  • This file has to be chmod'ed 600 (-rw------) or sendmail won't read it.
    • -
  • Look for the line beginning O AuthOptions= If this line is commented out with a leading #, remove the # and it should be O AuthOptions=A
    • -
- -

Ta-da!

Now you're ready to run the tests in Step3, all of the mail should be accepted, the most likely rejection will be the final one. -

- -

Thats it, good luck and happy mailing :)
Danny Angus

-
- - - diff --git a/server/2.2.0/src/site/xdoc/mailet_api.xml b/server/2.2.0/src/site/xdoc/mailet_api.xml deleted file mode 100644 index 489ab7e6401..00000000000 --- a/server/2.2.0/src/site/xdoc/mailet_api.xml +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - James 2.1 - Mailet API - - - -
-

The Mailet API is a simple API used to build mail processing applications. James is a Mailet -container, allowing administrators to deploy Mailets (both custom and pre-made) to carry out a -variety of complex mail processing tasks. In the default configuration James uses Mailets to carry -out a number of tasks that are carried out deep in the source code of other mail servers (i.e. list -processing, remote and local delivery).

-

-As it stands today, the Mailet API defines interfaces for both Matchers and Mailets.

-

Matchers, as their name would suggest, match mail messages against certain conditions. They -return some subset (possibly the entire set) of the original recipients of the message if there -is a match. An inherent part of the Matcher contract is that a Matcher should not induce any changes -in a message under evaluation.

-

Mailets are responsible for actually processing the message. They may alter the message in any fashion, -or pass the message to an external API or component. This can include delivering a message to its destination -repository or SMTP server.

-

The Mailet API is currently in its second revision. Although, the Mailet API is expected to undergo substantial changes in the near future, it is our aim that existing Mailets that abided purely by the prior Mailet API interfaces will continue to run with the revised specification.

- -

James bundles a number of Matchers and Mailets in its distribution. Descriptions of provided matchers -can be found here, while descriptions of provided mailets can be found -here.

-
- - diff --git a/server/2.2.0/src/site/xdoc/mailing_lists.xml b/server/2.2.0/src/site/xdoc/mailing_lists.xml deleted file mode 100644 index ffdbb7515bf..00000000000 --- a/server/2.2.0/src/site/xdoc/mailing_lists.xml +++ /dev/null @@ -1,115 +0,0 @@ - - - - - James 2.1 - Creating Mailing Lists - - - -
-

One of the frequent questions on the James-User Mailing List is how -to create a mailing list. This document explains one way of using the -currently supplied Matchers and Mailets in James v2.1.

- -

Basically, the process requires creating two <mailet> entries -and a repository. The first mailet handles list commands (currently -only list-name-on and list-name-off). The second mailet -handles list messages. The repository will hold the e-mail addresses -of list subscribers.

- -

The mailets go into the processor chain (e.g., at the top of the -transport processor), the repository goes into the -<users-store> block.

- - - -

You need to setup two mailets.

- -

The first mailet that you need to setup is an instance of the Avalon Listserv -Manager mailet. This will handle subscribing and unsubscribing. -[Note: the current code does not support confirmed opt-in, just basic -commands.] The CommandForListserv -matcher is used to invoke match messages containing commands for the -mailing list.

- -

The second mailet is an instance of the Avalon Listserv -mailet. That mailet actually receives messages for the list and -causes them to be distributed. The RecipientIs matcher -is used to match messages intended for the mailing list.

- -

The following illustrates the two <mailet> elements that need to be added:

- - - <mailet match="CommandForListserv=list-name@domain" - class="AvalonListservManager"> - <repositoryName>list-name</repositoryName> - </mailet> - - <mailet match="RecipientIs=list-name@domain" class="AvalonListserv"> - <repositoryName>list-name</repositoryName> - ... list options ... - </mailet> - - - - - - -

The mailing list mailets need a repository within which to store -the subscriber list. There is a separate repository for each mailing -list, and is completely independent of the user repository used by -James to manage e-mail accounts. This is configured in the -<users-store> block of config.xml.

- -

The following illustrates a database-backed repository using JDBC -with the ListUsersJdbcRepository class. Notice that there will be a -single table, lists, created in the db://maildb resource -defined elsewhere. There are currently two columns: the list name and -the list subscriber.

- - - <repository name="list-name" - class="org.apache.james.userrepository.ListUsersJdbcRepository" - destinationURL="db://maildb/lists/list-name"> - <sqlFile>file://conf/sqlResources.xml</sqlFile> - </repository> - - -

The following illustrates a file-system repository using the -UsersFileRepository class. [Note: the destination URL is a child -element when configuring a file-system repository, and an attribute -when configuring a database-backed repository. This inconsistency -will be addressed in a future version of James.]

- - - <repository name="list-name" - class="org.apache.james.userrepository.UsersFileRepository"> - <destination URL="file://var/lists/list-name/" /> - </repository> - - - -
- - diff --git a/server/2.2.0/src/site/xdoc/nntp_configuration.xml b/server/2.2.0/src/site/xdoc/nntp_configuration.xml deleted file mode 100644 index 97ef95efe48..00000000000 --- a/server/2.2.0/src/site/xdoc/nntp_configuration.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - James 2.1 - Configuring the NNTP Service - - - -
-

The NNTP service is controlled by a two configuration blocks in the config.xml. These are the nntpserver block and the nntp-repository block.

- -

The nntpserver tag defines the boundaries of the configuration block. It encloses -much of the relevant configuration for the NNTP server.

- -

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if -not present.

-

The standard children of the nntpserver tag are:

-
    -
  • port - This is an optional integer value. This value is the port on which this NNTP server is configured -to listen.If the tag or value is omitted, the value will default to the standard NNTP port, 119.
    • -
  • bind - This is an optional value. If present, this value is a string describing -the IP address to which this service should be bound. If the tag or value is absent then the service -will bind to all network interfaces for the machine.
    • -
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" -server socket factory is used to generate the server socket for this service. If it is false, the -"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType -tag which is described under the expert configuration options.
    • -
  • handler - This is an artifact preserved for backwards compatibility. This tag -was used to group related parameters. It should disappear in future versions.
    • -
      -
    • helloName - This is a required tag with an optional body that defines the server name -used in the initial service greeting. The tag may have an optional attribute - autodetect. If -the autodetect attribute is present and true, the service will use the local hostname -returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In -this case, if no body is present, the value "localhost" will be used.
      • -
    • connectionTimeout - This is an optional tag with a non-negative integer body.
      • -
    • authRequired - This is an optional tag with a boolean body. If true, then the server will -require authentication before allowing the client to view news articles. If this tag is absent, or the value -is false then the client will not be prompted for authentication. Only simple user/password authentication is -supported at this time.
      • -
    -
-

There are a few additional children of the nntpserver tag that are appropriate for advanced -configurations. These should only be used by expert administrators. All tags in this group are optional.

-
    -
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, -the body must be the name of one of the server socket factories specified in the socket manager block. Any other -value will result in an error. If present, this tag overrides the useTLS tag.
    • -
  • threadGroup - This is an optional tag with a string body. If the tag is present, -the body must be the name of one of the thread groups specified in the thread manager block. Any other -value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • -
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client -connections that this service will allow. If no value is specified, the value defaults to that specified in -the connectionmanager block. A value of 0 means that there is no limit imposed -by the service, although resource limitations imposed by other components -(i.e. max # of threads) may serve to limit the number of open connections.
    • -
- - -The remainder of the NNTP service configuration is controlled by the nntp-repository configuration block. This -section of configuration data relates to the server-side NNTP article repository. -
    -
  • readOnly - This is a required boolean tag. If the value is true, posting will not be -permitted by the NNTP server.
    • -
  • rootPath - This is a required string tag. It must be in the form of a URL with a "file:" prefix. This -specifies the root directory for the NNTP repository. Groups hosted on the NNTP server will be represented as -folders under this root, and articles will be stored in the appropriate folders.
    • -
  • tempPath - This is a required string tag. It must be in the form of a URL with a "file:" prefix. This -specifies the directory where the NNTP server will store posted articles before they are added to the spool.
    • -
  • articleIDPath - This is a required string tag. It must be in the form of a URL with a "file:" prefix. This -specifies the directory where the NNTP server will store the mappings between article ID and the groups containing that article.
    • -
  • articleIDDomainSuffix - This is a required string tag. It is the suffix appended to all article IDs generated -by this NNTP server.
    • -
  • newsgroups - This is a required container tag. It has a single newsgroup child for each newsgroup -hosted on the server. The body of each of those newsgroup tags is the name of the newsgroup.
    • -
- -
- - diff --git a/server/2.2.0/src/site/xdoc/pop3_configuration.xml b/server/2.2.0/src/site/xdoc/pop3_configuration.xml deleted file mode 100644 index 2cc037aa6a7..00000000000 --- a/server/2.2.0/src/site/xdoc/pop3_configuration.xml +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - James 2.1 - Configuring the POP3 Service - - - -
-

The POP3 service is controlled by a configuration block in the config.xml. -The pop3server tag defines the boundaries of the configuration block. It encloses -all the relevant configuration for the POP3 server. The behavior of the POP service is -controlled by the attributes and children of this tag.

- -

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if -not present.

-

The standard children of the pop3server tag are:

-
    -
  • port - This is an optional integer value. This value is the port on which this POP3 server is configured -to listen.If the tag or value is omitted, the value will default to the standard POP3 port, 110.
    • -
  • bind - This is an optional value. If present, this value is a string describing -the IP address to which this service should be bound. If the tag or value is absent then the service -will bind to all network interfaces for the machine.
    • -
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" -server socket factory is used to generate the server socket for this service. If it is false, the -"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType -tag which is described under the expert configuration options.
    • -
  • handler - This is an artifact preserved for backwards compatibility. This tag -was used to group related parameters. It should disappear in future versions.
    • -
      -
    • helloName - This is a required tag with an optional body that defines the server name -used in the initial service greeting. The tag may have an optional attribute - autodetect. If -the autodetect attribute is present and true, the service will use the local hostname -returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In -this case, if no body is present, the value "localhost" will be used.
      • -
    • connectionTimeout - This is an optional tag with an integer body.
      • -
    -
-

There are a few additional children of the pop3server tag that are appropriate for advanced -configurations. These should only be used by expert administrators. All tags in this group are optional.

-
    -
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, -the body must be the name of one of the server socket factories specified in the socket manager block. Any other -value will result in an error. If present, this tag overrides the useTLS tag.
    • -
  • threadGroup - This is an optional tag with a string body. If the tag is present, -the body must be the name of one of the thread groups specified in the thread manager block. Any other -value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • -
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client -connections that this service will allow. If no value is specified, the value defaults to that specified in -the connectionmanager block. A value of 0 means that there is no limit imposed -by the service, although resource limitations imposed by other components -(i.e. max # of threads) may serve to limit the number of open connections.
    • -
-
- - diff --git a/server/2.2.0/src/site/xdoc/provided_mailets.xml b/server/2.2.0/src/site/xdoc/provided_mailets.xml deleted file mode 100644 index 33c677961b7..00000000000 --- a/server/2.2.0/src/site/xdoc/provided_mailets.xml +++ /dev/null @@ -1,253 +0,0 @@ - - - - - - James 2.1 - Provided Mailets - - - - -
- -

James provides a number of implemented Mailets for use by James administrators in their -configurations. These are primarily mailets that members of the James developer or user -communities have found useful in their own configurations. A description of how to configure -Mailets and use them in the James SpoolManager can be found here.

- - -

Description: This mailet adds a text footer to the message.

-

Parameters: -

    -
  • text (required) - the text that will be added as a footer to the message.
    • -
-

- - -

Description: This mailet adds a Habeas warrant mark (see http://habeas.com for details) to the message.

-

Parameters: None.

- - -

Description: This mailet adds a text header to the message.

-

Parameters: -

    -
  • name (required) - the name of the header to be added to the message.
    • -
  • value (required) - the text that will be added as a header to the message.
    • -
-

- - -

Provides basic list server functionality. Implements basic filters for emails sent to the list, -including restriction of senders to members, diallowing attachments in list messages, and subject line -processing

-

Parameters: -

    -
  • repositoryName (required) - the name of the user repository that contains the users -for this list.
    • -
  • membersonly (optional) - whether only members of the list can send messages to this -list. Defaults to false.
    • -
  • attachmentsallowed (optional) - whether attachments are allowed in messages sent to this -list. Defaults to true.
    • -
  • replytolist (optional) - whether the reply-to address for all messages sent to this -list is set to the list address. Defaults to true.
    • -
  • subjectprefix (optional) - a String value. If set, this value is prepended to the subject -line of all messages sent to the list.
    • -
  • autobracket (optional) - a boolean value. If a subjectprefix is set, this value determines -whether the prefix is bracketed before being prepended to the subject line. Defaults to true.
    • -
-

- - -

Processes list management commands of the form <list-name>-on@<host> and -<list-name>-off@<host> where <list-name> and lt;host> are arbitrary. Note -that this should be used in tandem with a CommandForListserv matcher to ensure that only commands -intended for a specific list are processed.

-

Parameters: -

    -
  • repositoryName (required) - the name of the user repository that contains the users -for this list.
    • -
-

- - -

Description: This mailet forwards the message to a set of recipients.

-

Parameters: -

    -
  • forwardto (required) - a comma delimited list of email addresses.
    • -
-

- - -

Description: This mailet does alias translation for email addresses stored in a database table.

-

Parameters: -

    -
  • mappings (required) - a URL of the form db://<data-source>/<table>, where -<table> is the table in the database containing the alias info and <data-source> is the name -of the data-source in config.xml that is to be used.
    • -
  • source_column (required) - the column containing the aliases.
    • -
  • target_column (required) - the column containing the alias targets.
    • -
-

- - -

Description: This mailet does complex alias translation for email addresses stored in a database table.

-

Parameters: -

    -
  • table (required) - the URL describing the database table. This URL has the form -db://<data-source>/<table> where <data-source> and <table> are the names of -the data-source as defined in config.xml and the table in the database.
    • -
  • sqlquery (optional) - the text of the SQL query used by the mailet to do user -lookup. The default is "select VirtualUserTable.target_address from VirtualUserTable, VirtualUserTable as VUTDomains where (VirtualUserTable.user like ? or VirtualUserTable.user like '\\%') and (VirtualUserTable.domain like ? or (VirtualUserTable.domain like '\\%' and VUTDomains.domain like ?)) order by concat(VirtualUserTable.user,'@',VirtualUserTable.domain) desc limit 1"
    • -
-

- - -

Description: This mailet delivers messages to local mailboxes.

-

Parameters: None.

- - -

Description: This mailet forwards the message as an attachment to the James postmaster.

-

Parameters: -

    -
  • sendingAddress (optional) - the address from which the forwarded email will be -sent. Defaults to the postmaster address.
    • -
  • notice (optional) - the text message that will accompany the forwarded message. Defaults -to "We were unable to deliver the attached message because of an error in the mail server."
    • -
  • attachStackTrace (optional) - whether an error stack trace is attached to the forwarded message.
    • -
-

- - -

Description: This mailet forwards the message as an attachment to the original sender.

-

Parameters: -

    -
  • sendingAddress (optional) - the address from which the forwarded email will be -sent. Defaults to the postmaster address.
    • -
  • notice (optional) - the text message that will accompany the forwarded message. Defaults -to "We were unable to deliver the attached message because of an error in the mail server."
    • -
  • attachStackTrace (optional) - whether an error stack trace is attached to the forwarded message.
    • -
-

- - -

Description: This mailet ends processing for this mail.

-

Parameters: None.

- - -

Description: Intercepts all mails addressed to postmaster@<domain> where <domain> is one -of the domains managed by this James server and substitutes the configured James postmaster address for -the original recipient address. This mailet is inserted automatically by James at the head of the root -processor.

-

Parameters: None.

- - - -

Description: A mailet providing powerful, configurable redirection services.
- This mailet can produce listserver, forward and notify behaviour, with the - original message intact, attached, appended or left out altogether.
- This built in functionality is controlled by the configuration as described - here.

-

It is also intended to be easily subclassed to make providing bespoke redirection - mailets simple.
- By extending it and overriding one or more of its methods new behaviour can - be quickly created without the author having to address any other issue than - the relevant one. For more information see the javadocs - here.

-

Parameters: See javadocs.

- - - -

Manages delivery of messages to recipients on remote SMTP hosts.

-

Parameters: -

    -
  • outgoing (required) - The URL for the repository that will hold messages being processed -by the RemoteDelivery Mailet.
    • -
  • delayTime (optional) - a non-negative Long value that is the time in -milliseconds between redelivery attempts for a particular mail. Defaults to six hours.
    • -
  • maxRetries (optional) - a non-negative Integer value that is number of times -the Mailet will attempt to deliver a particular mail. Defaults to five.
    • -
  • timeout (optional) - The SMTP connection timeout for SMTP connections generated -by this Mailet. Defaults to 60 seconds.
    • -
  • deliveryThreads (optional) - The number of threads this Mailet will use to generate -SMTP connections.
    • -
  • gateway (optional) - The host name of the SMTP server -to be used as a gateway for this server. If this value is set, then all -messages will be delivered to the gateway server, regardless of recipient -address. To specify more than one gateway server, add multiple gateway tags, -each containing one value. If more than one server is specified, they will be -tried in order until one is successful. In addition the port may be specified -for each gateway in the format <host>:<port>. If this -value is unset, delivery will occur to SMTP servers resolved by MX lookup.
    • -
  • gatewayPort (optional) - The default port number of the -SMTP server to be used as a gateway for this server. This value will be -employed when a gateway is set and the gateway value does not specify -a port as described above.
    • -
  • bind (optional) - If present, this value is a string -describing the local IP address to which the mailet should be bound while -delivering emails. If the tag is absent then the service will bind to the -default local address of the machine. This tag is useful for multihomed machines.
    -Note: Currently you must use the same IP address for all of those RemoteDelivery -instances where you explicitly supply a bind address.
    • -
  • debug (optional) - a boolean value (true/false) indicating whether debugging is -on. Defaults to false.
    • -
-

- - -

Description: This mailet sends a message to the sender of the original mail message with a server timestamp.

-

Parameters: None.

- - -

Redirects processing of the mail message to the specified processor.

-

Parameters: -

    -
  • processor (required) - the name of the processor to which the message -is to be redirected.
    • -
  • noticeText (optional) - a String value that, if present, -is set as the error message of the redirected message. If this value is not -present, no error message is set.
    • -
-

- - -

Places a copy of the message in the specified repository.

-

Parameters: -

    -
  • repositoryPath (required) - the URL of the repository to which the message -is to be added.
    • -
  • passThrough (optional) - a boolean value (true/false) indicating whether -processing should continue on the message is on. If false, the original message is GHOSTed. Defaults to false.
    • -
-

- - -

Description: Ignores the recipients associated with the Mail interface. Instead, it regenerates the -mail recipients from the MimeMessage headers (To, Cc, Bcc) and inserts a new message at the queue root -these new recipients. The original message is GHOSTed.

-

Parameters: -

    -
  • debug (optional) - a boolean value (true/false) indicating whether debugging is -on. Defaults to false.
    • -
-

- -
- - diff --git a/server/2.2.0/src/site/xdoc/provided_matchers.xml b/server/2.2.0/src/site/xdoc/provided_matchers.xml deleted file mode 100644 index 9c461636aff..00000000000 --- a/server/2.2.0/src/site/xdoc/provided_matchers.xml +++ /dev/null @@ -1,186 +0,0 @@ - - - - - - James 2.1 - Provided Matchers - - - - -
- -

James provides a number of implemented Matchers for use by James administrators in their -configurations. These are primarily matchers that members of the James developer or user -communities have found useful in their own configurations. A description of how to configure -Matchers and use them in the James SpoolManager can be found here.

- - -

Description: This matcher is the trivial one - it matches all mails being processed. All recipients are returned.

-

Configuration string: None.

- - -

Description: It can be used to refuse emails with SCR, PIF, EXE etc. attachments. -It matches mails that has a file attachment with a file name meeting one of the supplied filters. -All recipients are returned.

-

Configuration string: A comma or space delimited list of file names. -File names may start with a wildcard '*'. Example: *.scr,*.bat,*.pif,*.pi,*.com,*.exe

- - -

Description: The CommandForListserv matcher is used as a simple filter to recognize emails that are list server -commands. It will match any email addressed to the list server host, as well as any email that is addressed -to a user named <prefix>-on or <prefix>-off on any host. Only those matching recipients will be returned.

-

Configuration string: An email address of the form <prefix>@<host>, where host is the hostname used for the listserver and prefix is the command prefix.

- - -

Description: A matcher intended for use with the FetchPOP server. It matches a custom header (X-fetched-from) that is -set by the FetchPOP server. FetchPOP sets this header to the name of the FetchPOP task which originally fetched -the message. All recipients are returned.

-

Configuration string: The name of the FetchPOP task which originally fetched the message.

- - -

Description: Matches those messages with a MIME type of "multipart/mixed". All recipients are returned.

-

Configuration string: None.

- - -

Description: Matches mails that have the Habeas Warrant (see http://www.habeas.com for details). All recipients are returned.

-

Configuration string: None.

- - -

Description: Matches mails that have the specified header. All recipients are returned.

-

Configuration string: The name of the header whose presence determines the match.

- - -

Description: Matches mails that have the specified Mail Attribute. All -recipients are returned.

-

Configuration string: The name of the Mail Attribute to match. For example:
-


-<mailet match="HasMailAttribute=name" class="<any-class>">
-
-

- - -

Description: Matches mails that have the specified Mail Attribute and the -specified MailAttribute value. All recipients are returned.

-

MailAttributes are types of Object whereas the value specified in the Matcher -condition is of type String. The toString() method is used to obtain a String -representation of the Mail Attribute value for matching. The -String.equals(String) method tests for a match.

-

Configuration string: The name of the Mail Attribute to be matched, a comma -and then the String value to be matched. For example:
-


-<mailet match="HasMailAttributeWithValue=name, value" class="<any-class>">
-
-

- - -

Description: Matches mails that have the specified Mail Attribute and -a MailAttribute value that matches the specified regular expression. -All recipients are returned.

-

MailAttributes are types of Object whereas the value specified in the Matcher -condition is of type String. The toString() method is used to obtain a String -representation of the Mail Attribute value for matching. The regular -expression must follow Perl5 syntax.

-

Configuration string: The name of the Mail Attribute to be matched, a comma -and then the regular expression used to match the value against. For example:
-


-<mailet match="HasMailAttributeWithValueRegex=name, regex" class="<any-class>">
-
-

- - -

Description: Matches mails that are sent to email addresses on hosts that are in the configuration list. Only -recipients that are on one of the hosts are returned.

-

Configuration string: A list of host names, comma or space delimited.

- - -

Description: Matches mails that are sent to email addresses on local hosts. Only -recipients that are on one of the local hosts are returned.

-

Configuration string: None.

- - -

Description: Checks the mail against one of a number of mail-abuse.org IP lists.

-

Configuration string: One of three strings - "blackholes.mail-abuse.org", "relays.mail-abuse.org", or "dialups.mail-abuse.org".

- - -

Description: Matches those messages sent to only a single recipient. The single recipient is returned.

-

Configuration string: None.

- - -

Description: A matcher derived from a Netscape Mail Server spam filter. If the matcher detects headers that -indicate spam, the message is matched. All recipients are returned.

-

Configuration string: None.

- - -

Description: Matches mails that are sent to one of the recipients on a specified list. Only -matching recipients are returned.

-

Configuration string: A list of recipient addresses, comma, tab, or space delimited.

- - -

Description: Matches mails that are sent to email addresses on local hosts with users that have local acccunts. Only -matching recipients are returned.

-

Configuration string: None.

- - -

Description: Counts the number of Received headers in the mail (each of which represents a server -in the relay chain). If the number equals or exceeds the specified limit, the mail is -matched. All recipients are returned.

-

Configuration string: a positive integer that is the limit on the number of relays.

- - -

Description: Checks the remote address from which the mail was received against the configured list. If the address matches one on the list, the matcher considers it a match. All recipients are returned.

-

Configuration string: A list of domain names, IP addresses, or wildcarded IP subnets of any class. The -list may be comma or space delimited.

- - -

Description: Checks the remote address from which the mail was received against the configured list. If the address doesn't match one on the list, the matcher considers it a match. All recipients are returned.

-

Configuration string: A list of domain names, IP addresses, or wildcarded IP subnets of any class. The -list may be comma or space delimited.

- - -

Description: Matches mails where the host name in the address of the sender cannot be resolved. All -recipients are returned.

-

Configuration string: None.

- - -

Description: Matches mails that are sent by one of the senders on a specified list. All -recipients are returned.

-

Configuration string: A list of sender addresses, comma, tab, or space delimited.

- - -

Description: Matches emails with a total message size (headers and body) greater than the specified limit. All recipients are returned.

-

Configuration string: a positive integer followed by an 'm' or a 'k'. This is the maximum message size permitted specified in megabytes or kilobytes respectively.

- - -

Description: Matches emails with the specified subject. All recipients are returned.

-

Configuration string: The string against which mail subject headers are matched.

- - -

Description: Matches emails whose subject header starts with the specified string. All recipients are returned.

-

Configuration string: The string against which mail subject headers are matched.

- - -

Description: Matches mails that are sent to email addresses that have userids that are in the configuration list. Only -matching recipients are returned.

-

Configuration string: A list of user names, comma or space delimited.

- -
- - diff --git a/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml b/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml deleted file mode 100644 index 1a3ef797089..00000000000 --- a/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - James 2.1 - Configuring the RemoteManager - - - -
-

The RemoteManager is controlled by a configuration block in the config.xml. -The remotemanager tag defines the boundaries of the configuration block. It encloses -all the relevant configuration for the RemoteManager. The behavior of the RemoteManager is -controlled by the attributes and children of this tag.

- -

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if -not present.

-

The standard children of the remotemanager tag are:

-
    -
  • port - This is an optional integer value. This value is the port on which this POP3 server is configured -to listen.If the tag or value is omitted, the value will default to 4555.
    • -
  • bind - This is an optional value. If present, this value is a string describing -the IP address to which this service should be bound. If the tag or value is absent then the service -will bind to all network interfaces for the machine.
    • -
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" -server socket factory is used to generate the server socket for this service. If it is false, the -"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType -tag which is described under the expert configuration options.
    • -
  • handler - This is an artifact preserved for backwards compatibility. This tag -was used to group related parameters. It should disappear in future versions.
    • -
      -
    • helloName - This is a required tag with an optional body that defines the server name -used in the initial service greeting. The tag may have an optional attribute - autodetect. If -the autodetect attribute is present and true, the service will use the local hostname -returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In -this case, if no body is present, the value "localhost" will be used.
      • -
    • administrator_accounts - This is an required container tag. It contains -one or more administrator_account elements, each of which has a login attribute -and a password attribute. These two attributes correspond to the login id and password for the -administrative account respectively. Obviously, for security reasons, these should be set upon James installation.
      • -
    • connectionTimeout - This is an optional tag with an integer body.
      • -
    -
-

There are a few additional children of the pop3server tag that are appropriate for advanced -configurations. These should only be used by expert administrators. All tags in this group are optional.

-
    -
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, -the body must be the name of one of the server socket factories specified in the socket manager block. Any other -value will result in an error. If present, this tag overrides the useTLS tag.
    • -
  • threadGroup - This is an optional tag with a string body. If the tag is present, -the body must be the name of one of the thread groups specified in the thread manager block. Any other -value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • -
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client -connections that this service will allow. If no value is specified, the value defaults to that specified in -the connectionmanager block. A value of 0 means that there is no limit imposed -by the service, although resource limitations imposed by other components -(i.e. max # of threads) may serve to limit the number of open connections.
    • -
-
- - diff --git a/server/2.2.0/src/site/xdoc/repositories.xml b/server/2.2.0/src/site/xdoc/repositories.xml deleted file mode 100644 index ca99c31ccf2..00000000000 --- a/server/2.2.0/src/site/xdoc/repositories.xml +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - Repositories - - - -
- -

James uses a number of different repositories to both store message data (email, news messages) and -user information. User repositories store user information, including user names, authentication -information, and aliases. Mail repositories store messages that have been delivered locally. Spool -repositories store messages that are still being processed. Finally, news repositories are used to -store news messages.

- -
-
- -

Aside from the type of data they store, repositories are distinguished by -where they store data. There are three types of storage - File, Database, and DBFile.

- - -

File-based repositories store all data in the file system. In general, these repositories are extremely -simple to configure, but may compare poorly in terms of performance when compared to other repository -types. File repositories are not recommended for large or performance-critical configurations. In the -default configuration, all repositories are file repositories.

- -

File repository paths typically begin with the prefix "file". Paths are relative to the application -base directory, unless the path begins with a slash. As an example, assume that James is running in -/usr/james/phoenix/apps/james. Then "file://var/mail/spool/" would refer to the directory /usr/james/phoenix/apps/james/var/mail/spool. -And "file:///var/mail/spool/" (note the extra '/') would refer to the directory /var/mail/spool.

- -

All repository types (mail, spool, user, and news) have file-based implementations. No special configuration is required to enable file-based repositories

- - - - -

Database repositories store all data in an administrator-supplied database. Configuration is somewhat -more complex, requiring that the administrator adjust the data-connections section. Detailed directions -are included in the sample configuration file. The administrator will need to know the JDBC driver class, -the appropriate URL for use with his database, and a valid username/password for the database.

- -

If the administrator wants to configure a database other than MySQL, it will be necessary to add the jar -or zip file containing the JDBC driver classes to the lib subdirectory of the installation directory. This -will allow Phoenix to properly load the driver when it is initializing the database repository. The MySQL -driver is pre-packaged with James.

- -

Database repository paths typically begin with the prefix "db". The format is "db://<data-source>/<table>" -where <data-source> is the name of the data-source defined in the data-connections section. And <table> is -the particular table associated with the repository.

- -

Mail, spool, and user repositories have JDBC-based implementations.

- - - - -

This is a special repository type used only for mail repositories. DBFile repositories store the body of -a mail message in the file system, while headers are stored in the database. This allows the administrator -to minimize the size of data stored in the database, while conserving most of the performance of the -database repository.

- -

Only mail repositories have dbfile-based implementations.

- - -
- - diff --git a/server/2.2.0/src/site/xdoc/serverwide_configuration.xml b/server/2.2.0/src/site/xdoc/serverwide_configuration.xml deleted file mode 100644 index 9d60dbc191a..00000000000 --- a/server/2.2.0/src/site/xdoc/serverwide_configuration.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - James 2.1 - Global Server Configuration - - - -
-

There are a number of global configuration blocks that do not fall into any one -component. They have effects that are global in scope across the server. Some of -these blocks are crucial, while others can be ignored by any but the most sophisticated -server administrators.

- -

This configuration block is defined by the James tag. All administrators -need to adjust this configuration block upon installation. It no attributes, but several -children, all of which are required. -

    -
  • postmaster - the body of this element is the address that the server -will consider its postmaster address. This address will be listed as the sender address -of all error messages that originate from James. Also, all messages addressed to -postmaster@<servername>, where <servername> is one of the domain names whose -mail is being handled by James, will be redirected to this email address.
    • -
  • usernames - this element has no body, but instead has three required -boolean attributes. These are ignoreCase, enabledAliases, -and enableForwarding. The first of these determines whether email user names -will be treated as case-insensitive or not. The second attribute configures whether local user -aliasing will be enabled. Finally, the value of the third attribute determines whether forwarding -to potentially remote users will be enabled.
    • -
  • servernames - this element determines exactly which mail domains and IP -addresses the server will treat as local. It has two boolean attributes - -autodetect and autodetectIP. The first attribute, if true, -causes the server to attempt to determine its own host name and add that to the list of local -mail domains. The second attribute causes the server to attempt to determine its own IP -address and add it to the list of local mail domains. In addition to these attributes, this -tag has zero or more servername children.
    • -
      -
    • servername - a single host name or IP address that should be added to the list of -mail domains that the server considers local.
      • -
    -
  • inboxRepository - This is a simple container tag which contains a single child element.
    • -
      -
    • repository - this defines the mail repository that will be used to store -mail delivered locally. This element has no body. The required attribute type -is always set to "MAIL". The required attribute repositoryURL addresses the -repository as described in the repository configuration section.
      • -
    -
-

- - -

-This block controls general connection management. There are two elements. -

    -
  • idle-timeout - the number of milliseconds that it will take for idle -client connections managed by this connection manager to be marked at timed out. If no -value is specified, the value defaults to 5 minutes, 300000 milliseconds. A value of 0 -means that client sockets will not timeout.
    • -
  • max-connections - The max-connections parameter specifies the default -maximum number of client connections that this connection manager will allow per managed -server socket. This value can be overridden by each individual service. If no value is -specified, the value defaults to 30. A value of 0 means that there is no limit imposed -by the connection manager, although resource limitations imposed by other components -(i.e. max # of threads) may serve to limit the number of open connections.
    • -
-

- - -

This block controls the low level file repository to file mapping. There is no need to modify this.

- - -

This block controls the socket types available inside James. Unless you are intending to enable SSL, it -shouldn't be necessary for you to adjust this block. For modifications to this block that are required to -enable TLS, see the using TLS section.

- - -

This block controls the thread pools available inside James. Only expert administators should modify -this configuration.

- -
- - diff --git a/server/2.2.0/src/site/xdoc/smtp_auth.xml b/server/2.2.0/src/site/xdoc/smtp_auth.xml deleted file mode 100644 index 7e3577f3509..00000000000 --- a/server/2.2.0/src/site/xdoc/smtp_auth.xml +++ /dev/null @@ -1,70 +0,0 @@ - - - - - - James 2.1 - Using Authenticated SMTP - - - -
-

Authenticated SMTP is a method of securing your SMTP server. With SMTP AUTH enabled senders who wish to -relay mail through the SMTP server (that is, send mail that is eventually to be delivered to another SMTP -server) must authenticate themselves to James before sending their message. Mail that is to be delivered -locally does not require authentication. This method ensures that spammers cannot use your SMTP server -to send unauthorized mail, while still enabling users who may not have fixed IP addresses to send their -messages.

-

Mail servers that allow spammers to send unauthorized email are known as open relays. So SMTP AUTH -is a mechanism for ensuring that your server is not an open relay .

-

At this time James only supports simple user name / password authentication.

- -

Configuring James for Authentication SMTP is a multi-step process. It requires several adjustments of -the config.xml. To enable SMTP AUTH, do the following:

-

First, as mentioned above, SMTP AUTH requires that James be able to distinguish between mail intended -for local delivery and mail intended for remote delivery. James makes this determination by matching the -domain to which the mail was sent against the <servernames> element of the James configuration block. Any -local domains should be explicitly listed as <servername> elements in this section.

-

Second, James is configured out of the box so as to not serve as an open relay for spammers. This is done -by restricting the IP addresses from which mail will be accepted using the RemoteAddrNotInNetwork mailet. This -restriction must be lifted before users can send from arbitrary clients. To do this, comment out or remove the -mailet tag containing the class attribute "RemoteAddrNotInNetwork". This tag can be found in the spoolmanager -configuration block, in the root processor configuration.

-

Third, set the authRequired element of the smtpserver configuration block to "true".

-

Fourth, if you wish to ensure that authenticated users can only send email from their own account, you may -optionally set the verifyIdentity element of the smtpserver configuration block to "true".

-

Fifth, restart James. This will pull in all of your configuration changes.

- - -

Finally, you need to verify that your configuration was done correctly. This step is -important and should not be skipped.

-

Verify that you have not inadvertantly configured your server as an open relay. This is most easily -accomplished by using the service provided at ORDB.org. ORDB.org will -check your mail server and inform you if it is an open relay.

-

It is extremely important that your server not be configured as an open relay. Aside from potential -costs associated with usage by spammers, connections from servers that are determined to be open relays -are routinely rejected by SMTP servers. This can severely impede the ability of your mail server to -send mail.

-

Of course it is also necessary to confirm that users and log in and send -mail through your server. This can be accomplished using any standard mail client (i.e. Outlook, -Eudora, Evolution).

- -
- - diff --git a/server/2.2.0/src/site/xdoc/smtp_configuration.xml b/server/2.2.0/src/site/xdoc/smtp_configuration.xml deleted file mode 100644 index ef0ab3002c9..00000000000 --- a/server/2.2.0/src/site/xdoc/smtp_configuration.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - James 2.1 - Configuring the SMTP Service - - - -
-

The SMTP service is controlled by a configuration block in the config.xml. -The smtpserver tag defines the boundaries of the configuration block. It encloses -all the relevant configuration for the SMTP server. The behavior of the SMTP service is -controlled by the attributes and children of this tag.

- -

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if -not present.

-

The standard children of the smtpserver tag are:

-
    -
  • port - This is an optional integer value. This value is the port on which this SMTP server is configured -to listen.If the tag or value is omitted, the value will default to the standard SMTP port, 25.
    • -
  • bind - This is an optional value. If present, this value is a string describing -the IP address to which this service should be bound. If the tag or value is absent then the service -will bind to all network interfaces for the machine.
    • -
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" -server socket factory is used to generate the server socket for this service. If it is false, the -"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType -tag which is described under the expert configuration options.
    • -
  • handler - This is an artifact preserved for backwards compatibility. This tag -was used to group related parameters. It should disappear in future versions.
    • -
      -
    • helloName - This is a required tag with an optional body that defines the server name -used in the initial service greeting. The tag may have an optional attribute - autodetect. If -the autodetect attribute is present and true, the service will use the local hostname -returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In -this case, if no body is present, the value "localhost" will be used.
      • -
    • connectionTimeout - This is an optional tag with a non-negative integer body.
      • -
    • authRequired - This is an optional tag with a boolean body. If true, then the server will -require authentication before delivering mail to non-local email addresses. If this tag is absent, or the value -is false then the client will not be prompted for authentication. Only simple user/password authentication is -supported at this time.
      • -
    • verifyIdentity - This is an optional tag with a boolean body. This option can only be used -if SMTP authentication is required. If the parameter is set to true then the sender address for the submitted message -will be verified against the authenticated subject.
      • -
    • maxmessagesize - This is an optional tag with a non-negative integer body. It specifies the maximum -size, in kbytes, of any message that will be transmitted by this SMTP server. It is a service-wide, as opposed to -a per user, limit. If the value is zero then there is no limit. If the tag isn't specified, the service will -default to an unlimited message size.
      • -
    -
-

There are a few additional children of the smtpserver tag that are appropriate for advanced -configurations. These should only be used by expert administrators. All tags in this group are optional.

-
    -
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, -the body must be the name of one of the server socket factories specified in the socket manager block. Any other -value will result in an error. If present, this tag overrides the useTLS tag.
    • -
  • threadGroup - This is an optional tag with a string body. If the tag is present, -the body must be the name of one of the thread groups specified in the thread manager block. Any other -value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • -
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client -connections that this service will allow. If no value is specified, the value defaults to that specified in -the connectionmanager block. A value of 0 means that there is no limit imposed -by the service, although resource limitations imposed by other components -(i.e. max # of threads) may serve to limit the number of open connections.
    • -
-
- - diff --git a/server/2.2.0/src/site/xdoc/spoolmanager.xml b/server/2.2.0/src/site/xdoc/spoolmanager.xml deleted file mode 100644 index 245cd3e78c8..00000000000 --- a/server/2.2.0/src/site/xdoc/spoolmanager.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - James 2.1 - The SpoolManager, Matchers, and Mailets - - - -
- -

James separates the services that deliver mail to James (i.e. SMTP, FetchPOP) -from the engine that processes mail after it is received by James. The -SpoolManager component is James' mail processing engine. James' SpoolManager component -is a Mailet container. It is these mailets and matchers that actually carry out mail processing.

- -

Core to the SpoolManager operation are Matchers and Mailets. A Matcher is a -simple object that checks whether a mail message matches a particular condition. -A mailet is another type object that processes an email message in some way. Some -typical tasks appropriate for a mailet would be adding a header, delivering the message -to a local repository, or handling remote delivery. Both the Matcher and Mailet APIs are -public, allowing James users to write their own custom matchers and mailets. James -comes with a large set of pre-built matchers and mailets.

- -

Matchers and mailets are used in pairs. At each stage in processing a message is checked -against a matcher. The matcher will attempt to match the mail message. The match is not simply -a yes or no issue. Instead, the match method returns a collection of matched recipients. If the -this collection of matched recipients is empty, the mailet is not invoked. If the collection of -matched recipients is the entire set of original recipients, the mail is then processed by the -associated mailet. Finally, if the matcher only matches a proper subset of the original recipients, -the original mail is duplicated. The recipients for one message are set to the matched recipients, -and that message is processed by the mailet. The recipients for the other mail are set to the -non-matching recipients, and that message is not processed by the mailet.

- -

More on matchers and mailets can be found here.

- -

One level up from the matchers and mailets are the processors. Each processor -is a list of matcher/mailet pairs. During mail processing, mail messages will be -processed by each pair, in order. In most cases, the message will be processed by -all the pairs in the processor. However, it is possible for a mailet to change the -state of the mail message so it is immediately directed to another processor, and no -additional processing occurs in the current processor. Typically this occurs when the mailet wants to prevent -future processing of this message (i.e. the mail message has been delivered locally, -and hence requires no further processing) or when the mail message has been identified -as a candidate for special processing (i.e. the message is spam and thus should be -routed to the spam processor). Because of this redirection, the processors in the -SpoolManager form a tree. The root processor, which must be present, is the root of -this tree.

- -

The SpoolManager continually checks for mail in the spool repository. When -mail is first found in the repository, it is delivered to the root processor. -Mail can be placed on this spool from a number of sources (SMTP, FetchPOP, a -custom component). This spool repository is also used for storage of mail that is -being redirected from one processor to another. Mail messages are driven through -the processor tree until they reach the end of a processor or are marked completed -by a mailet.

- -

More on configuration of the SpoolManager can be found here.

- -

Much of the power of James lies in the SpoolManager component. Custom matchers and -mailets can be easily developed to address an administrator's particular needs. The -processor tree can easily be configured to sort, filter, and deliver mail based on any -number of criteria. Mail administrators new to James should spend some time learning how -to configure the SpoolManager to meet their needs.

- -
- - diff --git a/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml b/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml deleted file mode 100644 index da3f4846072..00000000000 --- a/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml +++ /dev/null @@ -1,99 +0,0 @@ - - - - - - James 2.1 - Configuring the SpoolManager - - - -
-

The SpoolManager is controlled by a single configuration block in the config.xml. -The spoolmanager tag defines the boundaries of the configuration block. The behavior of -the SpoolManager, most importantly the routing of mail messages through the processor tree, -is controlled by this block.

- -

The spoolmanager tag has a few simple children. These are:

-
    -
  • threads - This is a required positive integer element. It specifies -the number of threads the SpoolManager will use to process messages in the spool. This -parameter tends to substantially impact performance, so it is advisable to tune it in production -configurations.
    • -
  • mailetpackages - This is a required container tag. It contains some number -of mailetpackage children. The body of each of these mailetpackage -elements is a Java package name. It is these packages that contain the classes to be instantiated -as mailets.
    • -
  • matcherpackages - This is a required container tag. It contains some number -of matcherpackage children. The body of each of these matcherpackage -elements is a Java package name. It is these packages that contain the classes to be instantiated -as matchers.
    • -
- -

The remaining SpoolManager configuration elements are complex enough to require a more in-depth -discussion.

- - -

In addition to the child elements discussed above, the SpoolManager tag can have several -processor children. It is these tags and their children that define the processor tree -for the SpoolManager.

-

Each processor has a required attribute, name. The value of this attribute must be -unique for each processor tag. The name of a processor is significant. Certain processors are required -(specifically root and error). The name "ghost" is forbidden as a processor name, as it is used to denote -a message that should not undergo any further processing.

-

The James SpoolManager creates a correspondance between processor names and the "state" of a mail as defined -in the Mailet API. Specifically, after each mailet processes a mail, the state of the message is examined. If -the state has been changed, the message does not continue in the current processor. If the new state is "ghost" -then processing of that message terminates completely. If the new state is anything else, the message is -re-routed to the processor with the name matching the new state.

-

The root processor is a required processor. All new messages that the SpoolManager finds on the spool are -directed to this processor.

-

The error processor is another required processor. Under certain circumstances James itself will redirect messages -to the error processor. It is also the standard processor to which mailets redirect messages when an error -condition is encountered.

-

The transport and spam processors are two useful, but optional, processors that are included in the out of -the box configuration. These processors include logic for actual mail delivery and spam handling respectively. More -information on these processors can be found in the default config.xml.

-

Each processor element has zero or more mailet child elements. Each of these elements describes a -matcher/mailet pair. The ordering of the mailet children is crucial to the configuration, as -it is the order in which pairs will be traversed in the processor.

-

It is this mailet element that is at the core of the SpoolManager configuration.

- - -

Consider the following simple mailet tag:

-<mailet match="RemoteAddrNotInNetwork=127.0.0.1" class="ToProcessor">
-<processor>spam</processor>
-</mailet>
-

The mailet tag has two required attributes, match and class.

-

The match attribute is set to the value of the specific Matcher class to be instantiated with a an -optional argument. If present, the argument is separated from the Matcher class name by an '='. Semantic -interpretation of the argument is left to the particular mailet.

-

The class attribute is set to the value of the Mailet class that is to be instantiated.

-

Finally, the children of the mailet tag define the configuration that is passed to the Mailet. The -tags used in this section should have no attributes or children. The names and bodies of the elements will be passed to -the mailet as (name, value) pairs.

-

So in the example above, a Matcher instance of RemoteAddrNotInNetwork would be instantiated, and the value "127.0.0.1" -would be passed to the matcher. The Mailet of the pair will be an instance of ToProcessor, and it will be passed the (name, value) -pair of ("processor", "spam").

-

James includes a number of pre-packaged Mailets and Matchers. A list of provided Mailets may be found -here. A list of provided Matchers may be found here.

- -
- - diff --git a/server/2.2.0/src/site/xdoc/summary.xml b/server/2.2.0/src/site/xdoc/summary.xml deleted file mode 100644 index b534a06d675..00000000000 --- a/server/2.2.0/src/site/xdoc/summary.xml +++ /dev/null @@ -1,116 +0,0 @@ - - - - - - James 2.1 - Component Summary - - - - -
- -

James is an open source project intended to produce a robust, flexible, and powerful -enterprise class server that provides email and email-related services. It is also designed to -be highly customizable, allowing administrators to configure James to process email in a -nearly endless variety of fashions.

- -

The James server is built on top of the Avalon Framework. The standard James distribution -deploys inside the Phoenix Avalon Framework container. In addition to providing a robust -server architecuture for James, the use of Phoenix allows James administrators to deploy -their own applications inside the container. These applications can then be accessed during -mail processing.

- -

The James server is implemented as a complete collection of servers and related components that, taken together, -provide an email solution. These components are described below.

- -
-
- -

The POP3 protocol allows users to retrieve email messages. It is the method -most commonly used by email clients to download and manage email messages.

- -

The James version of the POP3 service is a simple and straightforward implementation that -provides full compliance with the specification and maximum compatibility with common -POP3 clients. In addition, James can be configured to require SSL/TLS connections for -POP3 client connecting to the server.

- -

More information on configuring the POP3 service can be found here.

- -
-
- -

SMTP (Simple Mail Transport Protocol) is the standard method of sending and delivering -email on the internet. James provides a full-function implementation of the SMTP specification, -with support for some optional features such as message size limits, SMTP auth, and encrypted -client/server communication.

- -

More information on configuring the SMTP service can be found here.

- -
-
- -

NNTP is used by clients to store messages on and retrieve messages from news servers. James provides -the server side of this interaction by implementing the NNTP specification as well as an appropriate -repository for storing news messages. The server implementation is simple and straightforward, but -supports some additional features such as NNTP authentication and encrypted client/server communication.

- -

More information on configuring the NNTP service can be found here.

- -
-
- -

FetchPOP, unlike the other James components, is not an implementation of an RFC. Instead, it's a -component that allows the administrator to configure James to retrieve email from a number of POP3 -servers and deliver them to the local spool. This is useful for consolidating mail delivered to a -number of accounts on different machines to a single account.

- -

More information on configuring FetchPOP can be found here.

-
-
- -

James separates the services that deliver mail to James (i.e. SMTP, FetchPOP) -from the engine that processes mail after it is received by James. The -SpoolManager component is James' mail processing engine. James' SpoolManager component -is a Mailet container. It is these mailets and matchers that actually carry out mail processing.

- -

More on the structure of the SpoolManager and the Mailet API can be found here.

- -
-
- -

James uses a number of different repositories to both store message data (email, news messages) and -user information. User repositories store user information, including user names, authentication -information, and aliases. Mail repositories store messages that have been delivered locally. Spool -repositories store messages that are still being processed. Finally, news repositories are used to -store news messages. Aside from what type of data they store, repositories are distinguished by -where they store data. There are three types of storage - File, Database, and DBFile.

- -
-
- -

James provides a simple telnet-based interface for control. Through this interface you can add -and delete users, configure per-user aliases and forward addresses, and shut down the server.

- -

More on the configuring the RemoteManager can be found here.

- -
- - diff --git a/server/2.2.0/src/site/xdoc/usingTLS.xml b/server/2.2.0/src/site/xdoc/usingTLS.xml deleted file mode 100644 index a2d25ec76c2..00000000000 --- a/server/2.2.0/src/site/xdoc/usingTLS.xml +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - James 2.1 - Using TLS - - - - -
- -

-This document explains how to enable James 2.1 services to use Transport Layer Security (TLS) for encrypted client-server communication.

- - -

James uses the Sun Java Secure Sockets Extension (JSSE) infrastructure to provide TLS/SSL -sockets. JSSE comes packaged with several vendor Java distributions (i.e. Sun Java 1.4.x, -IBM Java 1.3.x). For these distributions, please follow the vendor provided instructions for -configuring the JVM to use JSSE services.

- -

If you are using a Java distribution that does not include JSSE as part of the -distribution you will need to download the JSSE package separately. It can be obtained from -here. Please follow Sun's instructions for installation -and configuration of JSSE.

-

In either case, you will need to statically define a JSSE TLS provider. In general, this -is the default installation.

-

Once you've installed JSSE, James still needs to be configured to take advantage of the JSSE -functionality.

- - -

To use TLS/SSL inside James you will need a certificate keystore.

- - -

The out of the box configuration file contains a template for the SSL configuration in place. Specifically, -in the sockets block, under the server-sockets element, there is a commented out factory with the -name "ssl". The first step to configuring the server socket factory is uncommenting out this element.

-

The factory element contains several children. Of these, it should only be necessary to adjust two or three children.

-

The required file element specifies the location of the keystore to be used by the factory. This is specified -as a file path using Unix-style formatting. The path is taken to be relative to the apps/james/ subdirectory of -the application installation directory unless an absolute path is specified.

-

The password element should be set to the keystore password. This password should have been specified -when the keystore was created, and it is required to open the keystore. This value is required.

-

Finally, it may be necessary to adjust the type element. This element can take on any keystore type -supported by the JSSE provider being used (see the JSSE documentation for details). The out of the box -configuration specifies JKS (Java Keystore).

-

The remaining children should not need to be deleted or adjusted.

- - -

Each of the services - SMTP, -POP3, NNTP, -and RemoteManager - supports use of TLS. Each of -these services has an optional boolean configuration element useTLS which is used to toggle -use of TLS for the service. When this value is set to true, that particular service will use the "ssl" -server socket factory to spawn server sockets.

- - -

After you've configured a particular service to use TLS/SSL connections, the service port -should no longer accept unencrypted TCP/IP connections. This can be tested by using a telnet -client to directly connect to the service port. The telnet connection should simply hang until -the client times out.

-

-To validate that the port is properly accepting SSL connections an SSL client can be used to -open a connection to the service port. One such client is OpenSSL, available from the -OpenSSL web site. Follow the instructions provided with -the SSL client to create a connection to the service port. Upon connection, the usual -service greeting should appear.

- -
- - - diff --git a/server/2.2.0/src/site/xdoc/using_database.xml b/server/2.2.0/src/site/xdoc/using_database.xml deleted file mode 100644 index b7b2d7ed156..00000000000 --- a/server/2.2.0/src/site/xdoc/using_database.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - James 2.1 - Using a Database - - - -
-

James has the capacity to use a JDBC-compatible database for storage of both message and user -data. This section explains how to configure James to utilize a database for storage.

- -

Using James with a database backend has certain requirements. Database configuration is -extremely vendor-specific, so we can only state the requirements in general terms.

-

There must be a database instance accessible from the James server. An account with appropriate -privileges (select, insert, delete into tables, and on initial startup creation of tables) and -with sufficient quota for the data to be inserted into the database must be available. Also, -since James will use JDBC to access the database, an appropriate JDBC driver must be -available for installation.

-

It is important to verify the functionality of the database before attempting to configure -James to use it as a repository. This will help ensure that configuration issues are properly -identified.

- - -

Configuring the Phoenix container to work with JDBC is the first step in enabling James database support.

-

First, Phoenix must be able to load the JDBC classes. To make these classes available to Phoenix, place the -jar/zip files for the JDBC driver in the lib subdirectory of the James installation directory. Any additional -libraries upon which the JDBC library depends that are not part of the standard Java distribution should also be -added to this directory.

-

Please note that a MySQL driver is included as part of the James distribution and -so there is no need to add such a driver to the lib directory.

-

Second, the config.xml must be modified so that Phoenix initializes the database connections. The relevant -configuration is in the database-connections block. The database-connections tag has only a single child tag, -data-sources. This latter tag is a simple container tag for a number of child elements. It is these child -elements, data-source elements, that define the database connections.

-

Each data-source tag has a required attribute, name. This value -must be unique to each data-source element. It is this name that will -be used to specify the database connection in other parts of the config.xml file.

-

The data-source element has five children, all of whom are required. -

    -
  • driver - The class name of the database driver to be used.
    • -
  • dburl - The JDBC connection URL for your database/driver.
    • -
  • user - The user id of the database account to be used by this connection.
    • -
  • password - The password of the database account to be used by this connection.
    • -
  • max - The maximum number of JDBC connections to be used concurrently by this data-source.
    • -
-

- -

Generally, you simply configure these entries in the config.xml -file, which are commented, in order to use a database with James. You -would then use the db: or dbfile: prefix instead of the file: prefix -for a particular repository. You are currently free to mix and match -your use of these different storage types for different repositories. -See Repository Configuration for -more details. A sample configuration is described below.

- - - -

The precise SQL statements used by James to modify and view data stored in the database are specified in -an external configuration file. The sqlResources.xml file -(which can be found in the apps/james/conf directory) is a sample configuration file that contains the SQL -statements used by James. The purpose of each of these statements, as well as the repository with which -they are associated, is documented in situ.

- -

If you are using a SQL database with unusual SQL commands or data types, you may -need to add special entries to this file. The James team -does try to keep sqlResources.xml updated, so if you do run into a -special case, please let us know.

- -

Also, if the database tables are not created a priori, but rather are to be created by James -upon startup, special attention should be paid to the "create table" statements in this file. Such -statements tend to be both very database and very database instance specific.

- - - -

The config.xml file has commented out examples for MySQL and -MSSQL data sources, and for each of the standard repositories. For -example, to use MySQL, you would uncomment and adjust the following -data-source element.

- -

You must create the database, in this case named -mail, the user, and assign the user privileges. -You may create the tables before running James or, if you so choose, James -will automatically create the tables it needs. In the latter case the user -must have table creation privileges.

- - -<data-source name="maildb" class="org.apache.james.util.mordred.JdbcDataSource"> - <driver>org.gjt.mm.mysql.Driver</driver> - <dburl>jdbc:mysql://127.0.0.1/mail</dburl> - <user>username</user> - <password>password</password> - <max>20</max> -</data-source> - - -

Once the data-source element has been created, it can be referenced elsewhere in the config.xml -file. For example, the following element tells James to use the maildb data-source and dbfile -storage mechanism for the message spool:

- - -<spoolRepository> - <repository destinationURL="dbfile://maildb/spool/spool" type="SPOOL"/> -</spoolRepository> - - -

The following element tells James to store mailboxes in a the maildb data-source:

- - -<inboxRepository> - <repository destinationURL="db://maildb/inbox/" type="MAIL"/> -</inboxRepository> - - -

The configuration file contains further examples.

- - -

There are some vendor-specific subtleties in using databases with James that have been observed -by some users. These issues (and methods to resolve them) are recorded on the -James FAQ as they are reported. Please consult the FAQ if you encounter any -difficulties.

- -
- - diff --git a/server/pom.xml b/server/pom.xml deleted file mode 100644 index 87baec87ee9..00000000000 --- a/server/pom.xml +++ /dev/null @@ -1,94 +0,0 @@ - - - - 4.0.0 - org.apache.james - james-server-root - JAMES Server - 1.0-SNAPSHOT - - Apache JAMES Server - - pom - - org.apache.james - james-project - 1.1-SNAPSHOT - - - 2.2.0 - - http://james.apache.org/server/ - 2006 - - - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/server - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/server - http://svn.apache.org/viewvc/james/project/trunk/server - - - - - james-server-website - scp://minotaur.apache.org/www/james.apache.org/server/ - - - - - jira - http://issues.apache.org/jira/browse/JAMES - - - - continuum - - - mail - - -
server-dev@james.apache.org
- - - - - - - Server User List - server-user-subscribe@james.apache.org - server-user-unsubscribe@james.apache.org - http://www.mail-archive.com/server-user@james.apache.org/ - - - Server Developer List - server-dev-subscribe@james.apache.org - server-dev-unsubscribe@james.apache.org - server-dev@james.apache.org - http://www.mail-archive.com/server-dev@james.apache.org/ - - - James General List - server-general-subscribe@james.apache.org - server-general-unsubscribe@james.apache.org - http://www.mail-archive.com/server-general@james.apache.org/ - - - - - \ No newline at end of file diff --git a/server/src/site/resources/css/site.css b/server/src/site/resources/css/site.css deleted file mode 100644 index 315b8a9d8ea..00000000000 --- a/server/src/site/resources/css/site.css +++ /dev/null @@ -1,31 +0,0 @@ -/* - Licensed to the Apache Software Foundation (ASF) under one - or more contributor license agreements. See the NOTICE file - distributed with this work for additional information - regarding copyright ownership. The ASF licenses this file - to you under the Apache License, Version 2.0 (the - "License"); you may not use this file except in compliance - with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, - software distributed under the License is distributed on an - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - KIND, either express or implied. See the License for the - specific language governing permissions and limitations - under the License. -*/ -#apacheconbox { - margin: 20px 0px 0px 20px; - padding: 10px; - border: 1px solid #ccc; - background-color: white; - background-image: url(../images/button-top.gif); - background-repeat: repeat-x; -} -#apacheconspacer { - float: right; - margin: 0px 0px 10px 10px; - background-color: white; -} diff --git a/server/src/site/resources/images/asf-logo-reduced.gif b/server/src/site/resources/images/asf-logo-reduced.gif deleted file mode 100644 index 93cc102077a940966a0bf6d77e74ac273a10ef8f..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6636 zcmW-jdpy&NB^`k5({Ud=*EWJLJM77(p_7Ubjo^?L{6ozBTG zrT8~-uT3`YA6z(iU(uWv#wdC?*LrZ+m}~LRdiKU&$f@Oy^oJ`=i6+hgRAVF_PDwp- ztgxs!1ZD4l68M_KW_UVk-#Q!$Pa@K2Br166_?3pnI2h|A-a0BAXQR5&A?Fpb?Gb8 z2*k5oCs=r^?5ey-sZ^AxYup^lC`5wE?{)1hj19^$$^{?dW+pEpj_VrXL%+<@Wf;^t zJCdiUvs(#-G^G|kfoFntz873~ctb_>t(@D#$7q=4Jv#>J`Qv=$b>~!(=u%)Bm4nQx4G0uy}~g_xl^(YUhBvak#5 zgOuvw;WT+BuH_Fe^Qfh^cx6`2s#Q)p=qizh0B=u>WgT3-Um`*}GI*J|%p$EpRN<4Y zGf~z{=<@Z%ciE4S^38-`SDls-3H17pfQxW&*i~EFS~THa;&q8l$;Vfpq4`<-XV(d$ z`-SexHAn1eerw`+&nuVTz17YrVcMN=n%6b~Pk7R#fQs2Gpwl_l;)!9Zix3)AS!c&C zQ34C)+gAHfADmZ#J!@ouF>Xj{z_YVB18pQxGV z#8&ZYQIjf}4+ukXt98XP)EbGFTjdXCr7XQ<39V`EX@7dX7sgi%K^WawfM#Gv=)Aa1 z+o?NS!01`I1iDVjJKI}zgx$&^C5Ef~EU7JH?OH!a+{=QV@_zU`-5PH*I zPuRv#n3aaLEiBR7@r{SVvX-}mUhuV3xb?k!BFIAH>qbPzbWFRFgIRYuh*K-nKBmlY zXo!mHbNn_F82LJk8Y(6HVBaJGfDmIP$=s!3^Huul_S2gBtEE}_T2@5k_$OT|Hfb(5 z)X<#6D%iKo^EXxX4F^7^85Vz6sG)}#XEvtZDoScZ&v0xHPB;j%ar+w*l2aoKKDo2- zb9>!cbUD@Cqd08ehtuEgl-E^3le=d;7%p1%H-?USDXO&=Ns#x}Gv34#dLGHj^Mbev){8$exY)@D8txn4_GgU^Q#nGSmQLy^q-T1(e6TLYS zkyodfAaB@J5Bc38m*mNB>VrC0Ux|ebUq~Fex!-O z_3SLrfr{Ra$gx{pd(y!YKvCLGkH;%6{CVnQ{;UW?4*=tq1vDz`SEy-1yIj(V2R)ZFCY__!(Zs!f z`rl=^e16E7%Pt1a*QGNC=$-{`qOzJAu$vUT+P&2n>8pCwFvLX7zj^SYb`8p=S+0`E z$XYnM2{X2F1lL-FD1N}lfYe#DT)AY*L<*-3n_K(QvY5+XtlTfjs_Xqib0@!ESbnk! zSA5ArtJN=qF`{-hEnA~6zDFo%d=8mF^^sHw%D{yEh@{rPMqBF5>hB{?M8h{}t@d0a z$TBh@8x%i2xYqf->Z_kO?ik9N@?Tnd1s`-Sm~BEsL0u8q&B1GhLXeauby8lte(=TH z=AV&6s2Bxw4Bv}#m_ApmU%KiQkf8nY=}IGzQPzj<_?tbT?S^q>@387$GCgoZ>{a?} zs*!BKHygc@UGbJ=GHbM@>qZ!K2AH8?ChBt!Rc8lW$zk7VEIyd*pHZ< zE$>3tEVKs2MMV7_y;EJ&`Ixn`WSsRp6bJd9jN0ez7 z|Ma|Lc!>!cW3KHdjTYX+6Ie1ce`!;(oJVsG#TcaQP4A00xHl)OMsj5M5|l7eC(3az zDJOcF{El8dJ#Rzx_qnmF*i5mBua?=I@#wMvrXgR?ichil(W`n;21chubB`0YX{t^$lR@)6e zzxHWowXNRH^1Qj<$tzEf&Y^`bdfs&ERfbPdDZ3B53tO443vu5as^NZ_IwXJfQLrGe z*svE7@rd$rX)~s^qXx&9l&pV0F0Lg#>vRaEt0D{^yK6JYuX|TyX#+v*D)2mcq;*Cp zfmg+{`z{X8I**n$^E#AvnZc#GzrRAukx7ov5b^QQouH>j)7lqpVBE5P^}wWc9VJMF zl|RDZCikc^4kDE8%0ixL8a>;T0`GN{#v6|OnR?@tEUXAkxLJ7eVdS$v?N0>>6O+H` z^2{Fo2$O4$vb6y!ta9)n;7$uEBjvIC)aTjix?Ev&58b zTHCwd`4prf7n;f;4aFhXHwe2DD!6nD&voHBVW_e^kk z4BA-^s7S#3%MdJ4#z`=;Gr>L_NJXrykOQM%3PUrC{5VkM211p-l*eeZE_gIfIC*wHsp5pD4ONn{s>gfc~b%Z~YZ zfnp?qAD#z;w}Pl!;NNdN^7{Ah$UuBd#BGr$q;yX1IYErS2Le0Dx zqKPdB6#2#+aF1s2nU>;y3GRIxtU@)ZW|^FpfQ~=ZZp%^@YPfu9&Thx@P=y`kq&RXQ zrP!}nk8sM64X>6!PGY$JGH6aPF_geaVX2e20;v#Fg(T&7r%qiezhli!WB6VLkCZ*B zG&`?pe<1&KTg6Y!%9gm&{(-Dz0m4ZN2hm-2e=EFq8EYj6+(TS9F#>*%LhWhDO$Eqg(i@Bw z)ysu*&R-5ba{&B^X%ph=;~Ze6V^@UXC;oaVAh3nK4e=SJ+})Q!mhX`!p&LC@;->&y z*%W2taFQ)dn8M%$JL=tRX3)qPH=>dPFsJGwCA2L|HJ%mKj z+y{JohjEIwLdk)ki%L3nlF_un1W|C)_?oXdHHJxWEt5OSuAY78a@UvZQv>#fngy#D zda$eabAW`YbKVk=e-xVk`<#M<0C`~Vq#5R;JN!<{#bsQ{XJ#H_~xNkfws>)tk=Nd2=DuVh(`? zKbj9|62X&jT2m5yRsj^6*w}MyONIWHK+*)q!^jL_U2(Mwdv&9cwJ)Nvvpa7o8k)iy zo$y3h|0JtOk~^bd8{WmujPMc%sHVchB03^Sb~uD=9ux_+r#L6jz0P(=Y$!X|c){Km z?fLK}si+@jkFBv!Q@K0>0$w#6{ub%)YMSm>%~9uFy#et(ya<}gRQ2;ElN`gOWOB)M z?>DekR{i9Jsx8$4$*0#w)Bf5RkUxJ!K+o^z4rbhv;V_6(p-7uz?>a# zDmQ!+XacocAKJy4EE*aJ5_O zOl7@}o4eoGZTmg|$@UZeg7>|qstB=;z~yyP7^X&>6Iul9wdDbqR!|(HgI(~y4bEgj z%tqp_C+GnG6Eu5vYZwFarm%kO0S`>W{wXs4Bc*Kx9v*U#|E11@P&c^;w33o+rS3mX zZ^{t6E||fFhT*& z$DjcTq$Y2;o9%Wf9FZevyFIOXQdsN9MYJA58+<3}B-N#2cE!;z5WI==7sz?xMoOhz zCcFEp2Joy;%Tm{v(b4hj?*Q^*NLZjte-Cvs+}BwF*3RDM+ZvgK2YRtLoAP1um6~CC zw@>rEM)H;)OM3k2JaP$*d$h-ya-e6dr-4L468u-H8afR_e5*9CiF(K(Cm9J@isrWu;W$PP1TA^Q5f6Fvm^0E!e%5G?i3bKu z{Y_bc)_ET~Je&J>&|Ppxty-gD7^mFzg)*;3yK$m!uh89nW?=u;;J(Ukj}X{@$o$uk z$D||T{CMs~RQp&nti<#1&O(x{p7CHf|PgnQpY-@>Nvror76~GP}JT(kgx;Nb}5NhSZnAlLKawpPv{}C;)2hij} z-VORkhG$HWlVpA6+QO`}!i1jeMpnIN(Qw3S+*Ou5@BOsu;ShlNeakxDSlH5X@`wsZ-B=B^}t8EVN2WpeWtGP7&oYjaRX;8E)O+J)+0Eg`%&btht7o@_=5B zG}L1PyFKiFGCjmEgcCDdUcVCjw?p#*6+*WFo_@ZNNb6~LvrE2P1Ru4##STL3u4F3L z*$=Vae1mATs5Qf%z+bemF7Xbf3~@o!*q#q%6(KZ*3pVUEz8tvgS;Lvcg@LO8O#eXH zq>p^m_Q3Yl@-yi5M)=KD;6NHM`7vBn)9`{|U3AEtE=_e1P?$VMP7CLdHrY4?p-KJt z?4I-SV<|g?s@V3;aUsaKmh-9j@-TT;R2b6YKEmiZGJXW%GmD56}7a!qg*ZT093>v zRz?yK$i^kR0fx>=K=sg4p)3658SV*r>97F6DgYB65WZigcl|(D>z%LO=H`Mnn`wZ$ z17R)!YJR$CP66?+0Ra!Q>N@l%0q;r2xtIPhwW?=e^`9!vZwV17-} z`v&|Lxi`;X*yrlGVH2dVIefugw~g0%h=SUIP?B$j31DUvBdWX!RR_#(g^grxEaBNF zPBtudN<)iV+FZ!d+5hg+5J&Kc{8OETWxW%AhS&-JAzgnD!y2*9@s(5EO^-9pGAbx= zg#EdZxG!MeuOgDwu1+Avr1pU-1JvD&F&{S%|h`1jKPE8AZ9k@JRFi0v2K#muJ(ewI`fD=fye1%bs?&BeGF zZ;Kf*o`hYW^tpt?tq$ty>AH5Dulshs%z~6tiW1;GG`f9=Ly2Rh*sacZBEQUkRMCso zF(ECs$v<#4B+Ci`W8DE(IH(va?>eRhd&*Ws)cPcdW>57a3zdK*%pb*f<;JNtKI0 z-OK4Xju4k0B=B+2Gi?d-6YhU0Hg-u4T3_eoi!hE{=_4w2X!!hhR9UR3Z*bVfO^dB@ z%PGwF+v0V23+}E!LbhW#s?0(LXH?3&zWt$Tk-C=x5J4Uxye3j?S>N?L*6t@Ap4dt zcM)kz>l6V3L(wORWE4ZuXZU>MMajkfSMTVD^jZMsMn!gIo{f6w>v(K0>sOvxzEw=a zrNq05F^F4qmE!-zC(QGQ`ALI5Ao<%CXooIt<-mU(5n<_HaS8j zDuLZSYT+|{!Wh1VGuH~Ji%q}YTBR-VL>(y61_$YZ82tG5K;VJrr`+k+V ifk3o@FNQYto?ua@#Ta7 diff --git a/server/src/site/resources/images/james-server-logo.gif b/server/src/site/resources/images/james-server-logo.gif deleted file mode 100644 index f69394f6bbee48b5b336395a573aa484fe1e05dc..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6944 zcmWkxc|6mPAO3tk+w8E-%ze)>cNs;Y_%OH9=^LqY!p6C5~|M5J|u1;GmLv_J0U;+RJRY#^L#+n)$-(9#+ zy+3^Y&w6}p-1uGlNG0VswXXG*g(dO&`uZY+!B`s}&P~lsA(7YD*FJoB|F25w^6WKb zd99Ji1M9yA*2H4*>UwK-`ufKY$$R6)OMgGF{}C@Oj%r!KTWpd%yu_b>F5GSvul+J5 z$1bgZUlp%brx6yve_35y`8z8-Zejk+!>YIX>X*MCYpScS+S~8<3O^L~&+P1r)wRDr zmzS?JTswcZq@(55)cg67fyaFQLjVB&)6`r={zm}7`2X<#On`)#ewY`pk%{&wQXk&ai<(K@^JgErzM-gvFd(D2gsijs=b ziMEO;C26XnVoXu-*%Ie`l$z;QS$$kQDm^wWBN5NZqe>T^t8ZvLgwn$q7@*N7GLmgk zu~(Y)JCx4or#3z6f9w~Zg}&Wpt}hwSxqn5!CQqriZ{XjTublPuskUt!+R#L*o}z_P z;&|qLNlE?h!j;v>v^N^EZLP$E7yv=fB#PjHYWmSGDbF=6w+h)%@Qfr7;U7IGq-VzC zw?v8dHt~{0bazl|Q_ts(QPtv-d=>$nLa{GH)O|YjbxCX=|IOqT1b3uF_vyGWVtPcsvaZ(clg4kUw_ryM zS{`6SG-Dx~#(|H$N`FO)PXh^x6j*8t_ncT!lPy9a@Hn0zDDl%yRJWu;m_((a?4$BC z1X~)1j?ml&r-9qw#tcX;JuAvJw1^Wzi9k759T;KLfMg|E$`kBQxuViDel4LrICBB3 zxKTBES!@g>{UR3El;n!=GEJRfR(aM+8jZhk6AmS^| zx9&s}NrH-FZXS~rk~(3&Fm`BOzM>}SxS=x^RD=-(&COhG!lt(zITQ6lE(9kj|rZKWx!)+CkEM9DSotW zAL%$wc2hPg;;VehRV}d{QR4PZV}fcllaH5roMV6GSzil)z18Mxbf?t+_G3e*wSP<*?VC1r68u=L)VR173Y%55{^Mit~opR}< zqn*Rw8IV0rP|d2ZzgDXrNjb>r$8NtC87F%}{tu(sa+s1jZu)eaAwfW_ooM}QxQE@a zlgNb~$z;1XqhVgA{i@m`!AA6^$eoLIvauuwXABhh0DW}}5E%>f?L&Z+Ckvxz2J-KOohq*THAPi3)8RUok zqZ35y58bbFwEeY1`Xz#-M9>qEAm>d#ec?(AYYfWBHnm zy~Zk)<5B?2Y&Ou=uBrYEMr}5no%Zu7)nK`$s8YOthXYN|M_FiDk!tbsByc1~oUTr* zNYl&?wc20Dg={!l(g}iIz4y#q2Hhr&_~^F#+etCCORUU{Whv-zL_h^_iiFL8TU zxG3-nQDosv^?`SLH3NaZFk$0yV%sZXbZ; z(*HJtq28i2bxL%2)Y;%AWf&kN*B@wIJHOs(vGKLb5XHH|LB@!i4s2cIv?r%hGJ9Rr zgg|Y#}$n)kX?dhIZVTN=oTa2CJt21Lp!wbFCB|ciprB-HZ zwi^B!3~XhE;nhVfRR?l0{|}XVexPiXMvV$~$rMB7wZw$z;Y1n}VVV8n-I4Z3=X2l! zxyZfiHTKspeyNJKPC*eaPXoG3%sO|!3~Sj`XZ3mDYGBwDBKz*MI;UfK+bF&#9D1r8maluh^IZ(XHL_sf(BxSx1z@J1reMKfis;a9&Ejp;TBG z3lLC_-0tC!|M6|kpC8$|f%gV{@;r-96DmRpRiDiQQIH`d`_r!rt=gr4g?~2o)Q6V; z8SML5P=czAD~*&fGK7MT)&zbEJR8JglS%vKz6r%8Iy#gf4el*Tkb48EOMV3m-@!k+ zMxOO{uvkJ$FvQ}U7Vo4oL3B_mH6jk`u*?kTe z?vCGXD&Z>Pf$6l@dQa}2@6NB2QD1Y=t(!qdI)xHnsvfW&zkC0LN2(@9`mLM@s4+k2 zsu4+H8|1a!8a^lySXWXH<}{8 zz?t(y%J{`g`r!BBU6_saWwcKLl5>+DJL06{Mk3}OOp)b^GPSm_03-|}HCEh}&JF+f zjy`#x_f4|*l6+K!!okrW#d>|pFalUd_f1O=Y3U|Mu-|_>ex?7ja zq7DQ;f>EF4z9wt_@zN7LpLSf?LPlQxl-lu2V$C;!{GO!aD8YS>ImkXqnA2oTQvk$E zMy<;E2lv-^UxyOxzEt@1#Iym~~groMgMq*${F1wcp$Y2azZMePl?F*vUlcr!Oc9fe1PmrBY5mk@+FZ zEh4V?y}E9Pn~G2916IDpRkd^@Ch#KFgBx~@kFp;v4g-pNcbEU1$>&7twM{IfsN25- zgLUVs&SMJ;&B;1V>3aiTVw#pgX^YdV+M-laO&%W|0Dzc-T!hh&r*xth%PrPZhNiKh zBo-J@5K<&c(sW;xltU&5V!0mo;LTyXvcn=zePl4_KMah$BopT*1|P6LWbj1|o4S@r z3aQIwywtDzU!vzU9+Ep_-)bcD2T%C3{_VBH%P#4;Z4rW{zW+R(aA(LP-qs+@6t+ih z^4N;DGSxo1k(VI;E<(30#I}>lE}8}6^ccpe0zLTz3nCPT%W&RJLj0CE&i&wE zDnOWRP1`(;2>F08l|SB%+DB)k*)!rr{Ydu@DUPB9Q@=Fxgfz>Q6l*`EO&zjRB=<%u zNdw-T!IbKahN!>LimVt=5M?5Ql&L$+OPqq1fC+~kDt)`ZS~y!$O!mKnDgyUZ}FJ!_**y8jd8NhC)h)`Fev@x*LGyQyo)>2e*s;%q+ht`7rg9(YKRMo zCjmMzM269wKIqqE5XVJGQJ@WsqC>rit#W|dHI}w8FT@*hyb>~j0a>iqb_SqA@*>h8 z6Izk{Dx}Sa6XTp8Hv(ypJu(e$U_^M8A~Li+gX4z7Xea= zCMO{T542`^TG1dRBg#w!s&GLwZHOQ|e)L3{3Jl53KrTv9>lCEJ0mEC^ik#D5xI3hI zU_Ml)!$&|AXu<**if0tbrGgX$hGDW@P)x}JOlUf^*GGRJS8UV^@~4#Uh|Z~MN7f!d zqL>#$bIy4(IKBHzCrS~QIfOzuTbUU}5d!Z_^|Xb+(d!_Mhj9A`k%9%yVCX4S&U+1* zF_K6?S;}=#V3}v;dfBv8DT9={oh@%gg3N@#cnl=Xhf=U*p$=+4qybG9Km>~V$Y&9Z zs3zBZU0qb+FNcfSNMnqn_>Muvihhuc_3RKY4o)(zEu{@kwH=Nu@JPW|Z` ziKs({sJw6tik76K9H*x#c_0VS;wefC^j=3JsI<$Pzd(I1q#j*Og5?SX?3wv9nX3@v zf`ToNZO8>CWSODC)KdRruYCEIA#hH6*+Qpb07_d-X6MQ z4+HNE5I2|&I~Fm|7miyo;cgbB>9>7S7qLviEaXDtN*7eP0KM&uwy2uK<4jdH%=$NN zosnINhWNY!Uy^k<>OgQAPe!?RC#TR$$r{(eOMhR<)klr<2`#^>l?C-bnj2Lp;H3+o zktn~+EZbx5xCv#WEff557bUq>&l2ri@pfd5|zu%0C{)I zC&Qy0!mbg4t4JPbBp|6Iq#ief8PO?cT#&aU(g;b-JAw4b!-}`!kb$2NVwnh3zm?~A zPmP4ZdP^*JT$*}f(eOjImqQ!)b`=U}hPLDaW*p4q!Bq8VZbPnae6+4wG&CUr5^0S# zo|IG9!GaP*vGrZ$=(}Yqe(9`+wZmn7qk)b38j@}()xlQp0iJxv%}#8Eq;-8)?!99H z^$sZ90V*=;MRNvxar-@tq3BSGGWV(0<%YqQjYF4M9i-7^$n_?|Vn)ucC7+80-EYcB zj@K?_<~QeJU-+pzWd_OH-Flk?r~<934ysi*QJ9M->72r+zNkYtk*f#KrCFT(^eHm< z=Dn*JO%}g-#EM2t1$P8QZJ?1f7-vivMDvw~;KUdAAR;5NN8fc6(F&^l2~#|xXB9`0G_*(nHd zV%>BR^>5jRdUWj}p5I))kAUYxwr&7E74kQ2eYaTMWU%#&AtF$@Wa}z|{0CynU`9D% z6Z9&J>!fGCNl3=Eu~LkgktY2QM%|9Mxfm3ad6(WEO1iLLt%HXOpRCN1=-nlHATkPS z4fk02jaZ!?X0V219N{y=4<&S{cwvKh5YQ7*l;HDyW3?uvj7!GI8P4%d7w<%lV#e>7 zng|EeaqUqb266D_=|wsIHVm&Ht(yf>d0_nP(5c+Io1zj1=YfAmME6AE!H8jJPLF48 zp^G3A|F&iR!lH0!A?OCa3z-FzO;Y+VgtI=x2d5&`cLT^Oz3FO&LD(#Yj0HTW}^woeLb% zgM82Avf7&)*0A~w@rgbM;i#~8=C8hKNcGmPN_LGTWW}aBhJuU0jjgDGT{6@ zZ{c)F5AvEynVOXqo8SyV6_*XWL9{40>VoD;Ez7#=}pJP?K>+N)SI z%BOr6cU~^(^m-pW=D8cvJAyG-S1^7l7rv2-V=lys(8YhcG(;Flf#f!}^G~~N-z!u5 zeSq^t4dTYmk2{zE`U%p(`QatMnv#_Ho4>t+XR_rJXUFnKpQXH0HTr~Nj=yLC%8%@$ zruc?Oy?2(kI7FP?{hBlcUp{TQQH^%{-Q6y#Bfe~mWE+f^bNnA_zfjtCgdo&2_oYY&L$%SJ{!Xd2Jero?$zjZyNxkPXj`5urL7bl$tq zhuS-%r*2zMlV}%~xQN#tn@i2q|0R4)cwp)3qfeZ6!XKlmOT9LyM+zo%0`OnB*Iko9@$XyZ`=s_Y_A5M{a^y}f1fxHCbUep{ zVvq!G;eSla2SCAyI%N@O-nufD^r{@w3*H#;US=_-mOYTJ$j45ii0+q>_d`6wFN%Bw z+@}N->l^ZYT$}fU7*0rqKVcy(G73S1+PT>>AVR|Y{9|VS)-|lnDENm1#7#=omHWu>n zW;BK|i4+z|lw2y-3Lzomtr*`|zMsPRsxqVlY>wc}%oJrE7@DdUvWkjFv@G^GIRsc7 z2|=1WF+CIw-F@8*(If|7j?=`27W;(y8vC!s$6Av2wI8;ht(s5%Ja*TxV(?qp>ii@LwpigzE-dgfw_;neJY(XQzRBfmcQv7e_FKPAQWE0nt zhj?9Q^~koqVe{}A6lk}>#X(UXL>Xa`4m`z0JG3KGHIdI0i|o3xim4vbeu+9gYT)X$ zxxka&mk&rJ3ur5dkW!pff(yfw-hbwH(ELo`MWp+=`>xO1*hXcI!L7dE*Z+@h(ZmN4vY|J_Bzna@DkqjBlpQhQnl$6SfCZ zQQ9XA@15C%g*I&7R@F9#IX=Y#1=5@}!fcbzlT z@ibPZ7OGwIfsT&Q4h<&Og$@{$MSdU9zuuXqk3ZHNYK@}&28!ra@It0?!n9pRW9jFO zkE!?1=Vd9sY=4ufmf-ROQxP%~+hPn7yajgPJ6an3!JiDIEb(Vern4r2<$=}DcsAy4 zIW{^?qDhxCHLpQ9x74S(Dq!Ze#G}h)ZH(WFOGH*_RPi%Y?zvj9o@Mn zIOfX&H(h#(rt7%Nn90o8W}j2}I7Pf_-ty`+Nc0o3u^XqEr=>jn<}ze#is!O43ly1I zs3(;rHZ;TL^e6{KcAZLlI<-V+*&%gk%bPq@>A4p=<6$Lb(W}JryNr{v7p8LI@beAA z^Ma$DcTc)qN?WoFuc(F{axgmjxB!%eCwQp0Y-^ z8YTwW!jvT=Yl$Mu`A*-i>vz4^`~B;8uJhdI+@JeC=X&nXIoI=fNT$a6B0`cv000p~ z1A-X<+z0?%8w56R5LJqfI|sOIdeY(q{BPrczZ=KnO#TV}bN)N@&xHTY|KA)A@*Dh} z{Qq+QxqoPAC@hnKuLzLg0(&FjXfB*(V6i}7AK2LePfu|BHlR>IemxX6G|ML@xVQcb`hfN>N+ODX88 z0YlEfSU;Hg06s5-EetpWurlB;CE%zF0!%=RJ;=HOs;+^~XfQzoFjoea5#TEq$cTi! zxp0&LX90&G6a_9WAT;zBJEf(7!2sjq9A2a#)PV2|gnke{fUuCm4u>yEEZA=f)GmV) zcY(zd;M4@XMnEW(jD}bWM6;nwDGaTJ6b3Bqhm3K~ZQ&Gb2|xe<6acCK7~)jBZ5upz z5E2N`))sns!N^FMnhMLx;AZ0CTF&uvIT`5_KqRk}0ml*aG_dvoKv?|O!__%-eU$_9 z`x>Gr_`A5dHty$rdC1(E6FY54z*__+%_K*~XYP^EJ>u(Z`PuPtf`ziwNtCuUdeb#! zzAJDp#Sn?CYup)_=5mh#3^yHpD{P(!nNZ?Slu zlP)?jc{KIVFdU96HW9gl=MUjS>j@m^39?b+W5Y>)i8R6ej!Z7z6vW3Q4EZ>GNm(vk z&;UVK%X!eca6G@n;Vv#-I|Cpzf$DNiA!)i7mHlL0xw%Ra?{Ylm3uysqM8w2ND3j+{ z;^)w?T&k}ku~0y{l-U^fju<>$O~4(|YVFJN^aw-F5c_Eoo6a4@RqQEK3G$QUk?WPs zAjvx5cyH{GS7 z+$oyz31L(rqUf@U^{$Yr`Kt%!+$JtGG@s?3N|``~EU&1krgUSDuKI|6>r!(o*_tS! zqtGEV-P}wL?mR|*zt=s4*X#0whZU2HV@u6G!QN!nAM>?p7EEH)XCJKeOxeVLxG?}1Z4kjNiE=L5NQ`^Z^7tO9S@nqbrQkS8^ zPv4ZmY&ASt;z}l6x$Fr-+L!v4Y`#(Bwu0nW+-Bh-*NoS!k)#-AqtP+Uz8~fH9X(~# zlg-V@V__!ahEc36`pFByHxd1ERKWI9_Id2J`a8(uhvbMV*AiK+oIj_e+s(}QrW26c z)V_%%=tpwRl{J zI{nnVN{D7oF0@mV586MlfJD6M1-K(;hUGpTJ!E8K`%3XlU^lmTo({A9nS+{JIw>P} z@j%Xud$rz$w>Nc$75S3`4dptr21(nT7iUkItTg@HTNZ;fn0x%hX^cbUW?dBivHR@;%-T4DKH$vh|Ht}$=!>sM?Luq|Pij4#2hHmG~L;kB*pc)`RQK)pIwB!-I^B zN?c3W0xK`{9=M{H-MWGYx+x}^NBzY-J{5l3SRwWQ|IlBb2qFVy;bE6sR$ zocATX@UK5^?p-SOyf8$+?I)F}exSc^M@xSE=Bj5#a(k#mSNr+d+-hr_ASRx=E3bOJ z`_jWM;=_GZM$Rk4XKG3|=%!O}V{yK>vE0+LmbP4=WF%0P7#!b|weD=lue#-_%7>R! z601$-On}LD-%VbztUn&PpM92Yrz7S(JJ{sWA%e@!=v|prj*Hp@JFNA>pHx}`D}mS0&0Rrd^M%~fa1uM5pt6jNx2XNKP&-Y0#f z;e{EVylh~tXdgt4Wb>fo8d-Nn4*lKTE<#oLYAYyhsY0<=-Ig7dS2Yn$>X{N zgE6CSW^PO+mMX?|L@rEU7InXh*0UN-cw#5RjR}cvxRwIL1FFS{yD3u)M>2K5c;p}B zIk0@5T=7`Q2{W2t5FIivjyF4wDc9sEF-NW5C4R2^WGyJ!!Sly&fFra;$aT3#c#Nle zc_?!DCX%*iUg}s6RM-nJ%X%dWAMOY~HIy62#ruDYbTOu($S;li6=*#owX~5l z@=5&$KVtojFq&NFo7Md?)$nlx*c)iW_{rB!Eyb<8wx8+q)*L8++f73 zIqqp0D%x4tqn1v88_5#>N$GjZ_xqRiO*C!B=0|Fp5-(qBkR|b_^1-NmMSI>6)g1<( z8G33Xib+y-6@0=nR3=6DjTuG*V|Dn})2^=jVRB+c%v)kx6FBt=sCbD2tW$TqrIl4f zZ=-lK_wT*`W$Wmt?B=yU2oH9x&Ah*Hb;abuOsVa_&%nzwalKJ*7k`YyZg1+O;2F*Z5cF zj;w#zz9s5F{_57!S?hi1r&oQVSKU(bl{GSbXwJe>&G%&O(D5E^cFHvIQuU!?v8$hpZ4oW&dJ8HlBBm`sx4$t+!4Tx+RYjcy4RPNPg z`$w>55S1YIvhCPC2_CvS`txP&jllO2pLMFvn~Bj@xBvZVP1fGG2G@`h>sFO|K-hQ2 zv#e^+r+V0*OkEWo*!wM*7q2jTHe{22TCAot3=3D*Y>n({EqSA}ZKqL;+sH*x@4_vI zXAa~^C!O8OlT#khQIi+TR)0r`ovgjSaNk;H*^;W+wAoJOoGqqyGQVZdZ7Yw?{u`pp z^o`o9$9uJ1tgHLd>D%kIS$n5nu^J1htSpJ*zQ*?-daDBt#w~p-*{CyeJ4#IY&s*{I zf;#=(Y)!kSp=bJOq-b9od4ALROp?{pZLLzxJk-b`R)ur{vtlxp9VcrhW+%Ktt$oQy zsxjKZ9}pg;9JAv_s?T_zNWot}q&Kg3zZdz}t@^k7QE^H1ob0_F$9d-sf5i+>7!wMP HIfnfQdu`W3 diff --git a/server/src/site/resources/images/james_config_secondary.png b/server/src/site/resources/images/james_config_secondary.png deleted file mode 100644 index 2c29a53eba69116be76ab49f8679b18071103e99..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 5758 zcmbVPXIK;6wjMwM6-A0e6T|?DK;%FG0YL#7ngRytARtI@h9XM00)~JAQE8$HO79Sw z(xekg=zPD8LPKqhORatZfI|1;fFyaBKlwKt8Z%0kpXRI|L9c3dEv-0tJAq3QTDOumLaZ zAP@T+!I9oDF$yN-z|CZM2tXkKEeXI%3GmScA}oMpH=sNK=nMyD;sH1v0T-#l)pjsB z6z)rh$I0*#fIepG z07KMhIXGY>5>{1(&CFm71`Z8{lak<~BDgnm?a!kv#V{*G&Xlu-$16_ zmG6&}K|gA_HO#+nU#T6=T+(=iUmg`sbFfMT^S3y8IZIeV{$XjKdWq)=#E&CRK7!se z8Xs!zFE4E6JA;cj_B~X)f`Ftg9pygWP3y`c%m6;}_(vK2Au6TaiGo{$({(P3Xd4M|P9y=l@=QP;wMvh6OOp7C&hEuqa7{ho=f8+R`B>~*Uy zuQgKY=8Uf$R_s!V{kNiJ{r5=j=K?`|{j&1kGj7fDNQqga8^(mxrYvU%WXt4^PK*o@ z_7%B(PQ7e(q?GounZ61AVs!QqdjAgop|DvxGGFIL!Pv*cQ@77#W}WMAGvs;uTny~Y+dsYq@ znKgIvS~MRTBy4}X{i%P^gtZV#bddhW(LazAEc6TFYW?Lojg6ZCwF>Q5kBT*?h2;^Q zi%8|r@$uMZM_3I2K-LZfcN zo+$2$y}Mc#iRHGN)F^}L1|s;7)r5%$&bNt>z00NpotRT>bb0a8jV9@VDvI}7Z3}y! zgCde!@{Q?(k5^OGyBILlyytUM1JvejgvY<^3!q2NSoGBNJk_lyO7)+ z#L{+~Nu~$u`nTvb@)|Mzw5J9MjlAwwXvg@g`uwpz!!z=t8|Ndk6*)pf8gE$N~hRf@zi+gT(}`cwr341Yv)j0 zIUhDKiNdN5A+6ivyIpxG1_63dI(+ zP}*OR>8P@ZNSC8n)4O%J&3yf%-^~1fMmtQn4wHm`431wgBaR)ead>5Qr^Xv8Z&_IE zh&;M~-?yP6B7bNI;fB0BX(pPv1jcMSXyUc4(UW8m&043Spq64`(M@hw3KE$f7r)SU z(P^ghq<3Yu?0Ye+ByYAAdH~v%0(*9w?D?Xt{4d{{KZ-M%$|k8fzJvy*l|p z854Pb^<(a4QY&H1WjyDmO@+-|(Ni)8T>%Z*^Kujj3$4t{Yw_HD9@SK?#v@ZUjMDA* zl))bTg>!!~7F9kO69`}CcQ$#&>60Qkj9HR@b_6NX^x$qkjSe<~C1aoT0?N)G>LYLo z&AFpDr?FE7!dIs?;}L5P*BZ&bhGA9|&YwTu6<(cpN5e@prHRmf)39Sa;XSl&vor*5 zHP;Wai=WM{0^3O@Lh=>(N2Jv4uq7uJpV@1J1U%niHy2+L4%hcp&bjGppM&?5j8KGg zq1qnz1&dMcERWSFTBb~IS02uE=2LnzcCn@Ia@iyY=MKbi5ewD`e}n#B5*II`<|0EoE$7;*nQUG#ms<>Xd?Bg1ZE#jS^<-`H_mid)x0U!#gFTmH z^JV0=l1)^He<7nxZfb@>Qa)Ufg&NEr7tb*@g}I{ZI$Gmwn>n3y(xA1vsB2$l2c^<@ z)>G@qoYBWtSETKcgNW7YLX9b-Rz%#`8hG3GAxD@C)+sVO1{&KhJuNDs{Xq*vU%+8l z!h$J`GtJpmgw$HDB8{vVaDA5YmW1O1XGP0B@RP2B`C>n>$i&3R7Kn{~MM@4L0&I<5 z=WDbXXMB`D+#%-iTd=Hb04%MC5@J_5F*ocf0fLfZl2ZmR*zA3?9GRD!s`b_}c$cYg z3_e_`pwakSw5=E|-4S2fFeP>>4boBB@GP32C6tazl~ydm=dF$k(&7)eQtU6vjIcbV zambolgVR)=Js5ICUoxsvy{=J>59syJz@AW{gn0S9h12*DD@K^AX0Nu~WB!Y2+3CWR zyJ= zLcUQ>hwg5qe)?ZOH&u5vO*^7x zjb^x7kYm!0;2BVe&r~p~flv^U23f~!xA$D>J<%qx_EnR0JLDSISR~#}ue5h^w_N^P zd+N7D9g>EZS61d|y+~OKskJcF@bffd5NlhwrfIImS9ndu<;S883i2=$WLt2>zs`%j zEY`Vtg*Lil^)h!p6FwD6zQiV-=6%y+^lQw&b!js!$_uZs};pgw0O9&+s)`CsV@>I|i$98kyL(ax`(YWreq{SmB`} zYhUj$R>z+OiM+!TlW`|uu5yqn9mj67cucA!r?uZ#F23qrYA5ud;@Y1I8QENnJH0IY z84_d5bt;YX#Efa3Z&|KOpLA+pzd3-}$wG?}O^VDFOZXz<5XWa`$Z2QXkg{|V%tt~P zv09-enH1IZAQDk8yf`%e7-p-AAZgu}#CimzIgcq2TjQ(EQ+j8uSkAPnnkgIHwbz|> z@z;saz!ud-mn+YlKQ$VNh}_tVh#Ob7&|S4|qhVz6W5#(}<1={!lyiLSt~P7=bT}Ew zUbu4ar`x9)9p%dwmuvf5(4|ZPCTn!uFp37E8)szJu>M}}D@8~B8M%v{!_JP$1 zj`SnNz6GZCX9oo4t;u)r%V@)T9PISub*Pr|b&5jV^95#FFmYj;m<3TTa23dqQ>#Xa znFQb2czKmLb-j*TUacG$(TD1+bssHgbSk?&Y;CdD_Gj7HTEmhB3L1=9?9FPO%-E+{ z#L7fdp!%|Hu`H-vNDUf>0;eF0=p-apDlXe)bjm$(*llu zzdc|GDmD=t*bDv4YL9jmMIKL{LaHWh2P8nf1FylJJxyg@Q-#l^47x=cq-(B7krhTz zJIoDl-qVkWRL>XvSp1K|!}IhZ591&2_nPR1eh&%OUsE@g>GO zDp&Y;LkS~TO;G*)ZGgF4Exv=G#hg<`_y8hn(kDHvOlqyrLWamUbbjWCup)U*rKjH` zo$3!XW`#LlvLOF=1Mxx;C&6st~RYjy8qjn?O{v`w2& z?r}*H1(sbj*4N{OKX)$Z%Ig+5M3FRxW(ja)xwSQ_)S$lbOOM)i-h5y6Cb9%5_;vhi{|A`X%4w@_DbqkHyU(w(DzB{#s!|D#H z7)KklOa`BUXLvY7%b(?*`?n2%jr-eNxv771|Hl(3qjPpwyXp}5Xz+j$|4EGgy8%-7 z{LYo6FuO4iP${wgFB*LD<1F?)OX%qDF!3O>wNw-TmvkIg6*w0t{H!a4iP1NG4l9f$ z?=60x$_sqK1%zd*hC{u|qpK@bDG7U3Y}F{EgWuVMR;8#}p~AdKo@FgId<<#Alj+LX z!W}1KAVzfNhMFIXI}6WmY_hU?_>R@Kd$bIk&3UVMwcYKdi=1VVkMY{c@XMQ~lPz!? zb2w`K^70V)13!@Ro|}I)ebXaB_N)0Z^Tq3ij$w}(s@C&XsKw(i7?DJ(n5_wye8!!z z#rL=0p*T`QVt(2fJwT*@44@*b-d^cAq7pJ?W(1#i7sA}yW*3Tn8sF7mz`X-X>Bf@8 zqr|8ES*9o4qhb?(Y!N0Nsqxb~&>nmjuqzZY|B34V(`#7pOfN5rucl^L?zhXq=e9QY z*kprtzvTG+LcQS_2?t1fb!}r%pX;vBo1o3qfYRkOXg}bw;;~)i6Uo5Hs~lT8-NH45 z5tMiR{^Dbo-H}rK+)B*+t;rp1;; z7M(pY6Z$B2LS-O%|JO7+Np0Z18D{-MhGx5Rel92QAyo zrwl!G&mWYJ9?IBtVX;WUxqk!pex8YvdXo@;b+L12!M3djk)8A>2+LRC%z)d^4&(iu7dca! z1E&XXEo8NxyOOt;urDw#J81Uim*2iXx-rwk3h9CX=bcwi?qA`t_w5Yd5VfC-#^C3e zAw(gEN1brAezhL9;!5=BdO*=rC9%rEErTG>Zwd+V5lfm`of+e|2CpVRFRX62@7b8G zld+|k**yqcElM_s37A`*Hfp(1FSJQGwSc2|satkFxmv+~Uxois-?jpTU zwFtYr`v*?quO?+rgvj|y5pagMhNSwvL7oOn*Z7$gRV#PB>S4~W;B58I#$ik&C0B^q zGe~j7V^*LE%lF%{<1W_oguMk>qHKc%rHBT>GI_(4!2mh+zMRFFA*vSZoLb964;$i#hX%N3#oqFH_s0FP6)u z%w!Tp)nb#&)CR-%P3hq)+1=ldJTk8MRqqiuvnL9+adF8#tEtV16CbE3)+sry+;uE( zIeock->3RB9ig2g7Nl$;Hg<;3bF`IA_~Y+0)Upt@Jlu2ItlD#JTOJ;&w8yL^N7OuC z`fPw?Xi5zG7B%nfUK8l~i*8S@{0ZaQjsxX$r>pEvUQnOkW4Q;v`p?rzdi{uxO^Ez zL;wT<4<3M~CeYUhW@mYY@P;CUW)KEKmJRL101pPZS_|TPK-M%U zhM*G4KZAGTJfngrxsfD#R05un8ccn%b3B|@t_=vxI- zUck~}$N^XY$N;zl5DP#N04xB;ctC+Pl*U3V36fl(3k}i`h%h0O^M_v?kfec&JfJB7 z1Php2fP)8I5`Y%6@H`F%TfszMn3n>pO5qC*90vagNFG+=;WHP=iH7~faGV3@0S^#~ z1YBGIjrIo}CKGTtfXn4^k%bTkp%sL_5T-y_%A>>MC5;7p$w1v57{mheBH+XVo@0Op zrQ;zMfusWH!i2O&h;ShDE#z={-NGx_0swyi5CCcc80J+gApw<@As!Fy?4YM7jE;sm zIk2)4Qad{-yhh=3GBL!1=zqx?@e-lSMmF96tl#vZ z{@As=b7=4Ic*$Ya16$0*$9}j9OHuf>uG5H5{pC=L3A@B~z4%ksEv=*Sk2&TGRD`MX zNgYGW3E*Xu`09k(0ESOWj!P36B^_Iv#7lJrDS*n4p%Ft+w{vy9>#O^5VyeRtDf;x} zX-5>|^9`LHrR5po+qCObmiBRU zc?)CNLg?^Ql%PT%Tg^e%x#vj42C+onBtnah>9$)|3eN&4iJ#G7?|I7Wy3CQg^yA(g zc~;*JB3GPcDJc~?fy)-U=eOH*=Dx}mk84}Ze90L2!N4VdnU>JuWc`R}clK)jb_*xe zG5#vNqw>)M;(W$!8?^Ndxf(Y;Vfi(kEuxg&hpBN5a6(QS=cF~+n<%8SQ*oZ$ZjBVz z0Myd)1Tl;vE8B2sk&I{0WFT&egqg$v;M`g&ZRg!Ib{`Gac zQ*?Y=u=d6LQ{<3B#m~!`Mtc|0KFZzLgcD^prhVk~F5NMQ5-pDf4;fEgagQ`qp$FU~ z9h?q$)Z8vmA0u&MCmr)}WFoAFy*wb2Xp7#U%H4*mS-Vh$k@}r2N--0##2tKaPyiD~ zjFjn|#3a^V>p*#!#LkUYVn=#GZCci?-dM>-Dn<`2MPl6_np0rgd(^An^U_EZ!JRds zx9u*gwRUFRWS{(bMqntAhhtGxZ@_g%rTGlieeIzLNNL#-Qs8 zeZ^An<#nw0o!6;P{4c(Nah!K^w@;0`rDZ8){~BSOP^g)^u>m&}$PKx(L@@nc5Jha@ z-Z_g!Fj8q*6ot<6^#FNn(LkEkreetG06nBFt0=(Nc`TKiDR#PaW5=>V;dMc8P3fBi zU%}n|8K=Dbo;~hqmf?~zROycrs8Jq1oew^{?=x{Wd(+SYyI%LR;V)klv zXAOHZrrXw&GM1j6(Kx7Gc>IQ8Q7XY=p|!;4VScvr*nHMwv7wL`>Y>#^tV18n-qZ~} zbzNzQ`RFT%ti&$wm;aKMmSui`B2krFSCt&e$xWHZNPWsap&Q_kC7(MmlUF#-Tc(1$U<~=vxwWbUXGKYf&vC-_c@(v)P9YWpb;(2aPb= zWc1Mo6+1fFjE{o_;+PsYBv|O%HB60+H)l8u>CI85a|Th=Q>ygh=fB=f{P4yo3f+_X zbe)K{csFCdR%;Wo`BD3ktA*p$1CtZPw0JsUsra^I{;ABS-x)-&&h|lD#rSTaBa^yQ z&$*qU;yxZ{GB~H2)$Jmv^LV4V}r2S~{!a5o4dkW^@%UhQD5o?hvB(SngFDkKs%GURXms5$dP_=jq14NJi{| zkJb#uPm4LAnb~F>C4Z?kC~5D8?OBU5M|<-rBHH&i`5oQtvu5>si`Kbd<;bb;^7fl? zeZ@P{ez-+iADUfLTp)lEpQuK?8E$894H9BmF#0c!o8OZxosEg@rhgEkmL`vol8!WN zZ8rIe9&|zm-<|rBnV|y|B`qxm@)$bZfo)(=@%k7G`El)}9Dr^rEwTBOxDS zZ-&AklKH}UqEGB(JzLgs;3_$y_v#f5KBSA3 z-e5ZvIMvn?*sv2d9I32tg7*9JMBf(ep{g5wpSVuDGITN{`MPq#Af|kWiq$)U%hJ@Z_Vef-_dr)?M_8v~YVQiW>C3%9Crq#jUi-*m~L z>OlETo{^W_^()LT_hkRliM%qnL|qrEuj(3<&kW-(W}>JDYAM+<(jz8~H6+sR-AU)0}J zzD*+zc_BC}9+JVnUSiUCc}vJ8ROEljRiJA_n`)hUeP3DLr#ChBl(iSV;ZM+*3Wj*$ zB{#>8N2%rfh~&#KX5C#2mZqW5x46;!?XOmZ3O(93=AP9&8ZxM7aLKF8@>tMo&5?&% zT!~8;N-Vp|d4F;$sLS~?y;nsGdw^-(rEDB05uBZO1 zpU3A<6{+e$2Htd|+T3u9!otAxYKc~8U_3Dpw!qE(7ok>jf&uHs#swDTCvx-;!QkwC%7PZYFP#cvEOuyU;?d6Vo|FPS{j z_g+ldwhhdadn<{I){~gcacNDltFyGZ(c~kt&V2f#jiZZ3svl`9a((+AYq}OK`N$lbehiyf2-5zCUjEzGXzLF_=`A*|Jw@5POEUljgA@3NdXC}$2BZoUHUIzs diff --git a/server/src/site/resources/rfclist/basic/rfc0822.txt b/server/src/site/resources/rfclist/basic/rfc0822.txt deleted file mode 100644 index 32041b362d5..00000000000 --- a/server/src/site/resources/rfclist/basic/rfc0822.txt +++ /dev/null @@ -1,2902 +0,0 @@ - - - - - - RFC # 822 - - Obsoletes: RFC #733 (NIC #41952) - - - - - - - - - - - - - STANDARD FOR THE FORMAT OF - - ARPA INTERNET TEXT MESSAGES - - - - - - - August 13, 1982 - - - - - - - Revised by - - David H. Crocker - - - Dept. of Electrical Engineering - University of Delaware, Newark, DE 19711 - Network: DCrocker @ UDel-Relay - - - - - - - - - - - - - - - - Standard for ARPA Internet Text Messages - - - TABLE OF CONTENTS - - - PREFACE .................................................... ii - - 1. INTRODUCTION ........................................... 1 - - 1.1. Scope ............................................ 1 - 1.2. Communication Framework .......................... 2 - - 2. NOTATIONAL CONVENTIONS ................................. 3 - - 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 - - 3.1. General Description .............................. 5 - 3.2. Header Field Definitions ......................... 9 - 3.3. Lexical Tokens ................................... 10 - 3.4. Clarifications ................................... 11 - - 4. MESSAGE SPECIFICATION .................................. 17 - - 4.1. Syntax ........................................... 17 - 4.2. Forwarding ....................................... 19 - 4.3. Trace Fields ..................................... 20 - 4.4. Originator Fields ................................ 21 - 4.5. Receiver Fields .................................. 23 - 4.6. Reference Fields ................................. 23 - 4.7. Other Fields ..................................... 24 - - 5. DATE AND TIME SPECIFICATION ............................ 26 - - 5.1. Syntax ........................................... 26 - 5.2. Semantics ........................................ 26 - - 6. ADDRESS SPECIFICATION .................................. 27 - - 6.1. Syntax ........................................... 27 - 6.2. Semantics ........................................ 27 - 6.3. Reserved Address ................................. 33 - - 7. BIBLIOGRAPHY ........................................... 34 - - - APPENDIX - - A. EXAMPLES ............................................... 36 - B. SIMPLE FIELD PARSING ................................... 40 - C. DIFFERENCES FROM RFC #733 .............................. 41 - D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 - - - August 13, 1982 - i - RFC #822 - - - - - Standard for ARPA Internet Text Messages - - - PREFACE - - - By 1977, the Arpanet employed several informal standards for - the text messages (mail) sent among its host computers. It was - felt necessary to codify these practices and provide for those - features that seemed imminent. The result of that effort was - Request for Comments (RFC) #733, "Standard for the Format of ARPA - Network Text Message", by Crocker, Vittal, Pogran, and Henderson. - The specification attempted to avoid major changes in existing - software, while permitting several new features. - - This document revises the specifications in RFC #733, in - order to serve the needs of the larger and more complex ARPA - Internet. Some of RFC #733's features failed to gain adequate - acceptance. In order to simplify the standard and the software - that follows it, these features have been removed. A different - addressing scheme is used, to handle the case of inter-network - mail; and the concept of re-transmission has been introduced. - - This specification is intended for use in the ARPA Internet. - However, an attempt has been made to free it of any dependence on - that environment, so that it can be applied to other network text - message systems. - - The specification of RFC #733 took place over the course of - one year, using the ARPANET mail environment, itself, to provide - an on-going forum for discussing the capabilities to be included. - More than twenty individuals, from across the country, partici- - pated in the original discussion. The development of this - revised specification has, similarly, utilized network mail-based - group discussion. Both specification efforts greatly benefited - from the comments and ideas of the participants. - - The syntax of the standard, in RFC #733, was originally - specified in the Backus-Naur Form (BNF) meta-language. Ken L. - Harrenstien, of SRI International, was responsible for re-coding - the BNF into an augmented BNF that makes the representation - smaller and easier to understand. - - - - - - - - - - - - - August 13, 1982 - ii - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 1. INTRODUCTION - - 1.1. SCOPE - - This standard specifies a syntax for text messages that are - sent among computer users, within the framework of "electronic - mail". The standard supersedes the one specified in ARPANET - Request for Comments #733, "Standard for the Format of ARPA Net- - work Text Messages". - - In this context, messages are viewed as having an envelope - and contents. The envelope contains whatever information is - needed to accomplish transmission and delivery. The contents - compose the object to be delivered to the recipient. This stan- - dard applies only to the format and some of the semantics of mes- - sage contents. It contains no specification of the information - in the envelope. - - However, some message systems may use information from the - contents to create the envelope. It is intended that this stan- - dard facilitate the acquisition of such information by programs. - - Some message systems may store messages in formats that - differ from the one specified in this standard. This specifica- - tion is intended strictly as a definition of what message content - format is to be passed BETWEEN hosts. - - Note: This standard is NOT intended to dictate the internal for- - mats used by sites, the specific message system features - that they are expected to support, or any of the charac- - teristics of user interface programs that create or read - messages. - - A distinction should be made between what the specification - REQUIRES and what it ALLOWS. Messages can be made complex and - rich with formally-structured components of information or can be - kept small and simple, with a minimum of such information. Also, - the standard simplifies the interpretation of differing visual - formats in messages; only the visual aspect of a message is - affected and not the interpretation of information within it. - Implementors may choose to retain such visual distinctions. - - The formal definition is divided into four levels. The bot- - tom level describes the meta-notation used in this document. The - second level describes basic lexical analyzers that feed tokens - to higher-level parsers. Next is an overall specification for - messages; it permits distinguishing individual fields. Finally, - there is definition of the contents of several structured fields. - - - - August 13, 1982 - 1 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 1.2. COMMUNICATION FRAMEWORK - - Messages consist of lines of text. No special provisions - are made for encoding drawings, facsimile, speech, or structured - text. No significant consideration has been given to questions - of data compression or to transmission and storage efficiency, - and the standard tends to be free with the number of bits con- - sumed. For example, field names are specified as free text, - rather than special terse codes. - - A general "memo" framework is used. That is, a message con- - sists of some information in a rigid format, followed by the main - part of the message, with a format that is not specified in this - document. The syntax of several fields of the rigidly-formated - ("headers") section is defined in this specification; some of - these fields must be included in all messages. - - The syntax that distinguishes between header fields is - specified separately from the internal syntax for particular - fields. This separation is intended to allow simple parsers to - operate on the general structure of messages, without concern for - the detailed structure of individual header fields. Appendix B - is provided to facilitate construction of these parsers. - - In addition to the fields specified in this document, it is - expected that other fields will gain common use. As necessary, - the specifications for these "extension-fields" will be published - through the same mechanism used to publish this document. Users - may also wish to extend the set of fields that they use - privately. Such "user-defined fields" are permitted. - - The framework severely constrains document tone and appear- - ance and is primarily useful for most intra-organization communi- - cations and well-structured inter-organization communication. - It also can be used for some types of inter-process communica- - tion, such as simple file transfer and remote job entry. A more - robust framework might allow for multi-font, multi-color, multi- - dimension encoding of information. A less robust one, as is - present in most single-machine message systems, would more - severely constrain the ability to add fields and the decision to - include specific fields. In contrast with paper-based communica- - tion, it is interesting to note that the RECEIVER of a message - can exercise an extraordinary amount of control over the - message's appearance. The amount of actual control available to - message receivers is contingent upon the capabilities of their - individual message systems. - - - - - - August 13, 1982 - 2 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 2. NOTATIONAL CONVENTIONS - - This specification uses an augmented Backus-Naur Form (BNF) - notation. The differences from standard BNF involve naming rules - and indicating repetition and "local" alternatives. - - 2.1. RULE NAMING - - Angle brackets ("<", ">") are not used, in general. The - name of a rule is simply the name itself, rather than "". - Quotation-marks enclose literal text (which may be upper and/or - lower case). Certain basic rules are in uppercase, such as - SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in - rule definitions, and in the rest of this document, whenever - their presence will facilitate discerning the use of rule names. - - 2.2. RULE1 / RULE2: ALTERNATIVES - - Elements separated by slash ("/") are alternatives. There- - fore "foo / bar" will accept foo or bar. - - 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES - - Elements enclosed in parentheses are treated as a single - element. Thus, "(elem (foo / bar) elem)" allows the token - sequences "elem foo elem" and "elem bar elem". - - 2.4. *RULE: REPETITION - - The character "*" preceding an element indicates repetition. - The full form is: - - *element - - indicating at least and at most occurrences of element. - Default values are 0 and infinity so that "*(element)" allows any - number, including zero; "1*element" requires at least one; and - "1*2element" allows one or two. - - 2.5. [RULE]: OPTIONAL - - Square brackets enclose optional elements; "[foo bar]" is - equivalent to "*1(foo bar)". - - 2.6. NRULE: SPECIFIC REPETITION - - "(element)" is equivalent to "*(element)"; that is, - exactly occurrences of (element). Thus 2DIGIT is a 2-digit - number, and 3ALPHA is a string of three alphabetic characters. - - - August 13, 1982 - 3 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 2.7. #RULE: LISTS - - A construct "#" is defined, similar to "*", as follows: - - #element - - indicating at least and at most elements, each separated - by one or more commas (","). This makes the usual form of lists - very easy; a rule such as '(element *("," element))' can be shown - as "1#element". Wherever this construct is used, null elements - are allowed, but do not contribute to the count of elements - present. That is, "(element),,(element)" is permitted, but - counts as only two elements. Therefore, where at least one ele- - ment is required, at least one non-null element must be present. - Default values are 0 and infinity so that "#(element)" allows any - number, including zero; "1#element" requires at least one; and - "1#2element" allows one or two. - - 2.8. ; COMMENTS - - A semi-colon, set off some distance to the right of rule - text, starts a comment that continues to the end of line. This - is a simple way of including useful notes in parallel with the - specifications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 4 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3. LEXICAL ANALYSIS OF MESSAGES - - 3.1. GENERAL DESCRIPTION - - A message consists of header fields and, optionally, a body. - The body is simply a sequence of lines containing ASCII charac- - ters. It is separated from the headers by a null line (i.e., a - line with nothing preceding the CRLF). - - 3.1.1. LONG HEADER FIELDS - - Each header field can be viewed as a single, logical line of - ASCII characters, comprising a field-name and a field-body. - For convenience, the field-body portion of this conceptual - entity can be split into a multiple-line representation; this - is called "folding". The general rule is that wherever there - may be linear-white-space (NOT simply LWSP-chars), a CRLF - immediately followed by AT LEAST one LWSP-char may instead be - inserted. Thus, the single line - - To: "Joe & J. Harvey" , JJV @ BBN - - can be represented as: - - To: "Joe & J. Harvey" , - JJV@BBN - - and - - To: "Joe & J. Harvey" - , JJV - @BBN - - and - - To: "Joe & - J. Harvey" , JJV @ BBN - - The process of moving from this folded multiple-line - representation of a header field to its single line represen- - tation is called "unfolding". Unfolding is accomplished by - regarding CRLF immediately followed by a LWSP-char as - equivalent to the LWSP-char. - - Note: While the standard permits folding wherever linear- - white-space is permitted, it is recommended that struc- - tured fields, such as those containing addresses, limit - folding to higher-level syntactic breaks. For address - fields, it is recommended that such folding occur - - - August 13, 1982 - 5 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - between addresses, after the separating comma. - - 3.1.2. STRUCTURE OF HEADER FIELDS - - Once a field has been unfolded, it may be viewed as being com- - posed of a field-name followed by a colon (":"), followed by a - field-body, and terminated by a carriage-return/line-feed. - The field-name must be composed of printable ASCII characters - (i.e., characters that have values between 33. and 126., - decimal, except colon). The field-body may be composed of any - ASCII characters, except CR or LF. (While CR and/or LF may be - present in the actual text, they are removed by the action of - unfolding the field.) - - Certain field-bodies of headers may be interpreted according - to an internal syntax that some systems may wish to parse. - These fields are called "structured fields". Examples - include fields containing dates and addresses. Other fields, - such as "Subject" and "Comments", are regarded simply as - strings of text. - - Note: Any field which has a field-body that is defined as - other than simply is to be treated as a struc- - tured field. - - Field-names, unstructured field bodies and structured - field bodies each are scanned by their own, independent - "lexical" analyzers. - - 3.1.3. UNSTRUCTURED FIELD BODIES - - For some fields, such as "Subject" and "Comments", no struc- - turing is assumed, and they are treated simply as s, as - in the message body. Rules of folding apply to these fields, - so that such field bodies which occupy several lines must - therefore have the second and successive lines indented by at - least one LWSP-char. - - 3.1.4. STRUCTURED FIELD BODIES - - To aid in the creation and reading of structured fields, the - free insertion of linear-white-space (which permits folding - by inclusion of CRLFs) is allowed between lexical tokens. - Rather than obscuring the syntax specifications for these - structured fields with explicit syntax for this linear-white- - space, the existence of another "lexical" analyzer is assumed. - This analyzer does not apply for unstructured field bodies - that are simply strings of text, as described above. The - analyzer provides an interpretation of the unfolded text - - - August 13, 1982 - 6 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - composing the body of the field as a sequence of lexical sym- - bols. - - These symbols are: - - - individual special characters - - quoted-strings - - domain-literals - - comments - - atoms - - The first four of these symbols are self-delimiting. Atoms - are not; they are delimited by the self-delimiting symbols and - by linear-white-space. For the purposes of regenerating - sequences of atoms and quoted-strings, exactly one SPACE is - assumed to exist, and should be used, between them. (Also, in - the "Clarifications" section on "White Space", below, note the - rules about treatment of multiple contiguous LWSP-chars.) - - So, for example, the folded body of an address field - - ":sysmail"@ Some-Group. Some-Org, - Muhammed.(I am the greatest) Ali @(the)Vegas.WBA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 7 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - is analyzed into the following lexical symbols and types: - - :sysmail quoted string - @ special - Some-Group atom - . special - Some-Org atom - , special - Muhammed atom - . special - (I am the greatest) comment - Ali atom - @ atom - (the) comment - Vegas atom - . special - WBA atom - - The canonical representations for the data in these addresses - are the following strings: - - ":sysmail"@Some-Group.Some-Org - - and - - Muhammed.Ali@Vegas.WBA - - Note: For purposes of display, and when passing such struc- - tured information to other systems, such as mail proto- - col services, there must be NO linear-white-space - between s that are separated by period (".") or - at-sign ("@") and exactly one SPACE between all other - s. Also, headers should be in a folded form. - - - - - - - - - - - - - - - - - - - August 13, 1982 - 8 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.2. HEADER FIELD DEFINITIONS - - These rules show a field meta-syntax, without regard for the - particular type or internal syntax. Their purpose is to permit - detection of fields; also, they present to higher-level parsers - an image of each field as fitting on one line. - - field = field-name ":" [ field-body ] CRLF - - field-name = 1* - - field-body = field-body-contents - [CRLF LWSP-char field-body] - - field-body-contents = - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 9 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.3. LEXICAL TOKENS - - The following rules are used to define an underlying lexical - analyzer, which feeds tokens to higher level parsers. See the - ANSI references, in the Bibliography. - - ; ( Octal, Decimal.) - CHAR = ; ( 0-177, 0.-127.) - ALPHA = - ; (101-132, 65.- 90.) - ; (141-172, 97.-122.) - DIGIT = ; ( 60- 71, 48.- 57.) - CTL = ; ( 177, 127.) - CR = ; ( 15, 13.) - LF = ; ( 12, 10.) - SPACE = ; ( 40, 32.) - HTAB = ; ( 11, 9.) - <"> = ; ( 42, 34.) - CRLF = CR LF - - LWSP-char = SPACE / HTAB ; semantics = SPACE - - linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE - ; CRLF => folding - - specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- - / "," / ";" / ":" / "\" / <"> ; string, to use - / "." / "[" / "]" ; within a word. - - delimiters = specials / linear-white-space / comment - - text = atoms, specials, - CR & bare LF, but NOT ; comments and - including CRLF> ; quoted-strings are - ; NOT recognized. - - atom = 1* - - quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or - ; quoted chars. - - qtext = , ; => may be folded - "\" & CR, and including - linear-white-space> - - domain-literal = "[" *(dtext / quoted-pair) "]" - - - - - August 13, 1982 - 10 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - dtext = may be folded - "]", "\" & CR, & including - linear-white-space> - - comment = "(" *(ctext / quoted-pair / comment) ")" - - ctext = may be folded - ")", "\" & CR, & including - linear-white-space> - - quoted-pair = "\" CHAR ; may quote any char - - phrase = 1*word ; Sequence of words - - word = atom / quoted-string - - - 3.4. CLARIFICATIONS - - 3.4.1. QUOTING - - Some characters are reserved for special interpretation, such - as delimiting lexical tokens. To permit use of these charac- - ters as uninterpreted data, a quoting mechanism is provided. - To quote a character, precede it with a backslash ("\"). - - This mechanism is not fully general. Characters may be quoted - only within a subset of the lexical constructs. In particu- - lar, quoting is limited to use within: - - - quoted-string - - domain-literal - - comment - - Within these constructs, quoting is REQUIRED for CR and "\" - and for the character(s) that delimit the token (e.g., "(" and - ")" for a comment). However, quoting is PERMITTED for any - character. - - Note: In particular, quoting is NOT permitted within atoms. - For example when the local-part of an addr-spec must - contain a special character, a quoted string must be - used. Therefore, a specification such as: - - Full\ Name@Domain - - is not legal and must be specified as: - - "Full Name"@Domain - - - August 13, 1982 - 11 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.4.2. WHITE SPACE - - Note: In structured field bodies, multiple linear space ASCII - characters (namely HTABs and SPACEs) are treated as - single spaces and may freely surround any symbol. In - all header fields, the only place in which at least one - LWSP-char is REQUIRED is at the beginning of continua- - tion lines in a folded field. - - When passing text to processes that do not interpret text - according to this standard (e.g., mail protocol servers), then - NO linear-white-space characters should occur between a period - (".") or at-sign ("@") and a . Exactly ONE SPACE should - be used in place of arbitrary linear-white-space and comment - sequences. - - Note: Within systems conforming to this standard, wherever a - member of the list of delimiters is allowed, LWSP-chars - may also occur before and/or after it. - - Writers of mail-sending (i.e., header-generating) programs - should realize that there is no network-wide definition of the - effect of ASCII HT (horizontal-tab) characters on the appear- - ance of text at another network host; therefore, the use of - tabs in message headers, though permitted, is discouraged. - - 3.4.3. COMMENTS - - A comment is a set of ASCII characters, which is enclosed in - matching parentheses and which is not within a quoted-string - The comment construct permits message originators to add text - which will be useful for human readers, but which will be - ignored by the formal semantics. Comments should be retained - while the message is subject to interpretation according to - this standard. However, comments must NOT be included in - other cases, such as during protocol exchanges with mail - servers. - - Comments nest, so that if an unquoted left parenthesis occurs - in a comment string, there must also be a matching right - parenthesis. When a comment acts as the delimiter between a - sequence of two lexical symbols, such as two atoms, it is lex- - ically equivalent with a single SPACE, for the purposes of - regenerating the sequence, such as when passing the sequence - onto a mail protocol server. Comments are detected as such - only within field-bodies of structured fields. - - If a comment is to be "folded" onto multiple lines, then the - syntax for folding must be adhered to. (See the "Lexical - - - August 13, 1982 - 12 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Analysis of Messages" section on "Folding Long Header Fields" - above, and the section on "Case Independence" below.) Note - that the official semantics therefore do not "see" any - unquoted CRLFs that are in comments, although particular pars- - ing programs may wish to note their presence. For these pro- - grams, it would be reasonable to interpret a "CRLF LWSP-char" - as being a CRLF that is part of the comment; i.e., the CRLF is - kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a - backslash followed by a CR followed by a LF) still must be - followed by at least one LWSP-char. - - 3.4.4. DELIMITING AND QUOTING CHARACTERS - - The quote character (backslash) and characters that delimit - syntactic units are not, generally, to be taken as data that - are part of the delimited or quoted unit(s). In particular, - the quotation-marks that define a quoted-string, the - parentheses that define a comment and the backslash that - quotes a following character are NOT part of the quoted- - string, comment or quoted character. A quotation-mark that is - to be part of a quoted-string, a parenthesis that is to be - part of a comment and a backslash that is to be part of either - must each be preceded by the quote-character backslash ("\"). - Note that the syntax allows any character to be quoted within - a quoted-string or comment; however only certain characters - MUST be quoted to be included as data. These characters are - the ones that are not part of the alternate text group (i.e., - ctext or qtext). - - The one exception to this rule is that a single SPACE is - assumed to exist between contiguous words in a phrase, and - this interpretation is independent of the actual number of - LWSP-chars that the creator places between the words. To - include more than one SPACE, the creator must make the LWSP- - chars be part of a quoted-string. - - Quotation marks that delimit a quoted string and backslashes - that quote the following character should NOT accompany the - quoted-string when the string is passed to processes that do - not interpret data according to this specification (e.g., mail - protocol servers). - - 3.4.5. QUOTED-STRINGS - - Where permitted (i.e., in words in structured fields) quoted- - strings are treated as a single symbol. That is, a quoted- - string is equivalent to an atom, syntactically. If a quoted- - string is to be "folded" onto multiple lines, then the syntax - for folding must be adhered to. (See the "Lexical Analysis of - - - August 13, 1982 - 13 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Messages" section on "Folding Long Header Fields" above, and - the section on "Case Independence" below.) Therefore, the - official semantics do not "see" any bare CRLFs that are in - quoted-strings; however particular parsing programs may wish - to note their presence. For such programs, it would be rea- - sonable to interpret a "CRLF LWSP-char" as being a CRLF which - is part of the quoted-string; i.e., the CRLF is kept and the - LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- - lowed by a CR followed by a LF) are also subject to rules of - folding, but the presence of the quoting character (backslash) - explicitly indicates that the CRLF is data to the quoted - string. Stripping off the first following LWSP-char is also - appropriate when parsing quoted CRLFs. - - 3.4.6. BRACKETING CHARACTERS - - There is one type of bracket which must occur in matched pairs - and may have pairs nested within each other: - - o Parentheses ("(" and ")") are used to indicate com- - ments. - - There are three types of brackets which must occur in matched - pairs, and which may NOT be nested: - - o Colon/semi-colon (":" and ";") are used in address - specifications to indicate that the included list of - addresses are to be treated as a group. - - o Angle brackets ("<" and ">") are generally used to - indicate the presence of a one machine-usable refer- - ence (e.g., delimiting mailboxes), possibly including - source-routing to the machine. - - o Square brackets ("[" and "]") are used to indicate the - presence of a domain-literal, which the appropriate - name-domain is to use directly, bypassing normal - name-resolution mechanisms. - - 3.4.7. CASE INDEPENDENCE - - Except as noted, alphabetic strings may be represented in any - combination of upper and lower case. The only syntactic units - - - - - - - - - August 13, 1982 - 14 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - which requires preservation of case information are: - - - text - - qtext - - dtext - - ctext - - quoted-pair - - local-part, except "Postmaster" - - When matching any other syntactic unit, case is to be ignored. - For example, the field-names "From", "FROM", "from", and even - "FroM" are semantically equal and should all be treated ident- - ically. - - When generating these units, any mix of upper and lower case - alphabetic characters may be used. The case shown in this - specification is suggested for message-creating processes. - - Note: The reserved local-part address unit, "Postmaster", is - an exception. When the value "Postmaster" is being - interpreted, it must be accepted in any mixture of - case, including "POSTMASTER", and "postmaster". - - 3.4.8. FOLDING LONG HEADER FIELDS - - Each header field may be represented on exactly one line con- - sisting of the name of the field and its body, and terminated - by a CRLF; this is what the parser sees. For readability, the - field-body portion of long header fields may be "folded" onto - multiple lines of the actual field. "Long" is commonly inter- - preted to mean greater than 65 or 72 characters. The former - length serves as a limit, when the message is to be viewed on - most simple terminals which use simple display software; how- - ever, the limit is not imposed by this standard. - - Note: Some display software often can selectively fold lines, - to suit the display terminal. In such cases, sender- - provided folding can interfere with the display - software. - - 3.4.9. BACKSPACE CHARACTERS - - ASCII BS characters (Backspace, decimal 8) may be included in - texts and quoted-strings to effect overstriking. However, any - use of backspaces which effects an overstrike to the left of - the beginning of the text or quoted-string is prohibited. - - - - - - August 13, 1982 - 15 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS - - During transmission through heterogeneous networks, it may be - necessary to force data to conform to a network's local con- - ventions. For example, it may be required that a CR be fol- - lowed either by LF, making a CRLF, or by , if the CR is - to stand alone). Such transformations are reversed, when the - message exits that network. - - When crossing network boundaries, the message should be - treated as passing through two modules. It will enter the - first module containing whatever network-specific transforma- - tions that were necessary to permit migration through the - "current" network. It then passes through the modules: - - o Transformation Reversal - - The "current" network's idiosyncracies are removed and - the message is returned to the canonical form speci- - fied in this standard. - - o Transformation - - The "next" network's local idiosyncracies are imposed - on the message. - - ------------------ - From ==> | Remove Net-A | - Net-A | idiosyncracies | - ------------------ - || - \/ - Conformance - with standard - || - \/ - ------------------ - | Impose Net-B | ==> To - | idiosyncracies | Net-B - ------------------ - - - - - - - - - - - - August 13, 1982 - 16 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 4. MESSAGE SPECIFICATION - - 4.1. SYNTAX - - Note: Due to an artifact of the notational conventions, the syn- - tax indicates that, when present, some fields, must be in - a particular order. Header fields are NOT required to - occur in any particular order, except that the message - body must occur AFTER the headers. It is recommended - that, if present, headers be sent in the order "Return- - Path", "Received", "Date", "From", "Subject", "Sender", - "To", "cc", etc. - - This specification permits multiple occurrences of most - fields. Except as noted, their interpretation is not - specified here, and their use is discouraged. - - The following syntax for the bodies of various fields should - be thought of as describing each field body as a single long - string (or line). The "Lexical Analysis of Message" section on - "Long Header Fields", above, indicates how such long strings can - be represented on more than one line in the actual transmitted - message. - - message = fields *( CRLF *text ) ; Everything after - ; first null line - ; is message body - - fields = dates ; Creation time, - source ; author id & one - 1*destination ; address required - *optional-field ; others optional - - source = [ trace ] ; net traversals - originator ; original mail - [ resent ] ; forwarded - - trace = return ; path to sender - 1*received ; receipt tags - - return = "Return-path" ":" route-addr ; return address - - received = "Received" ":" ; one per relay - ["from" domain] ; sending host - ["by" domain] ; receiving host - ["via" atom] ; physical path - *("with" atom) ; link/mail protocol - ["id" msg-id] ; receiver msg id - ["for" addr-spec] ; initial form - - - August 13, 1982 - 17 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - ";" date-time ; time received - - originator = authentic ; authenticated addr - [ "Reply-To" ":" 1#address] ) - - authentic = "From" ":" mailbox ; Single author - / ( "Sender" ":" mailbox ; Actual submittor - "From" ":" 1#mailbox) ; Multiple authors - ; or not sender - - resent = resent-authentic - [ "Resent-Reply-To" ":" 1#address] ) - - resent-authentic = - = "Resent-From" ":" mailbox - / ( "Resent-Sender" ":" mailbox - "Resent-From" ":" 1#mailbox ) - - dates = orig-date ; Original - [ resent-date ] ; Forwarded - - orig-date = "Date" ":" date-time - - resent-date = "Resent-Date" ":" date-time - - destination = "To" ":" 1#address ; Primary - / "Resent-To" ":" 1#address - / "cc" ":" 1#address ; Secondary - / "Resent-cc" ":" 1#address - / "bcc" ":" #address ; Blind carbon - / "Resent-bcc" ":" #address - - optional-field = - / "Message-ID" ":" msg-id - / "Resent-Message-ID" ":" msg-id - / "In-Reply-To" ":" *(phrase / msg-id) - / "References" ":" *(phrase / msg-id) - / "Keywords" ":" #phrase - / "Subject" ":" *text - / "Comments" ":" *text - / "Encrypted" ":" 1#2word - / extension-field ; To be defined - / user-defined-field ; May be pre-empted - - msg-id = "<" addr-spec ">" ; Unique message id - - - - - - - August 13, 1982 - 18 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - extension-field = - - - user-defined-field = - - - 4.2. FORWARDING - - Some systems permit mail recipients to forward a message, - retaining the original headers, by adding some new fields. This - standard supports such a service, through the "Resent-" prefix to - field names. - - Whenever the string "Resent-" begins a field name, the field - has the same semantics as a field whose name does not have the - prefix. However, the message is assumed to have been forwarded - by an original recipient who attached the "Resent-" field. This - new field is treated as being more recent than the equivalent, - original field. For example, the "Resent-From", indicates the - person that forwarded the message, whereas the "From" field indi- - cates the original author. - - Use of such precedence information depends upon partici- - pants' communication needs. For example, this standard does not - dictate when a "Resent-From:" address should receive replies, in - lieu of sending them to the "From:" address. - - Note: In general, the "Resent-" fields should be treated as con- - taining a set of information that is independent of the - set of original fields. Information for one set should - not automatically be taken from the other. The interpre- - tation of multiple "Resent-" fields, of the same type, is - undefined. - - In the remainder of this specification, occurrence of legal - "Resent-" fields are treated identically with the occurrence of - - - - - - - - - August 13, 1982 - 19 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - fields whose names do not contain this prefix. - - 4.3. TRACE FIELDS - - Trace information is used to provide an audit trail of mes- - sage handling. In addition, it indicates a route back to the - sender of the message. - - The list of known "via" and "with" values are registered - with the Network Information Center, SRI International, Menlo - Park, California. - - 4.3.1. RETURN-PATH - - This field is added by the final transport system that - delivers the message to its recipient. The field is intended - to contain definitive information about the address and route - back to the message's originator. - - Note: The "Reply-To" field is added by the originator and - serves to direct replies, whereas the "Return-Path" - field is used to identify a path back to the origina- - tor. - - While the syntax indicates that a route specification is - optional, every attempt should be made to provide that infor- - mation in this field. - - 4.3.2. RECEIVED - - A copy of this field is added by each transport service that - relays the message. The information in the field can be quite - useful for tracing transport problems. - - The names of the sending and receiving hosts and time-of- - receipt may be specified. The "via" parameter may be used, to - indicate what physical mechanism the message was sent over, - such as Arpanet or Phonenet, and the "with" parameter may be - used to indicate the mail-, or connection-, level protocol - that was used, such as the SMTP mail protocol, or X.25 tran- - sport protocol. - - Note: Several "with" parameters may be included, to fully - specify the set of protocols that were used. - - Some transport services queue mail; the internal message iden- - tifier that is assigned to the message may be noted, using the - "id" parameter. When the sending host uses a destination - address specification that the receiving host reinterprets, by - - - August 13, 1982 - 20 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - expansion or transformation, the receiving host may wish to - record the original specification, using the "for" parameter. - For example, when a copy of mail is sent to the member of a - distribution list, this parameter may be used to record the - original address that was used to specify the list. - - 4.4. ORIGINATOR FIELDS - - The standard allows only a subset of the combinations possi- - ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, - and Resent-Reply-To fields. The limitation is intentional. - - 4.4.1. FROM / RESENT-FROM - - This field contains the identity of the person(s) who wished - this message to be sent. The message-creation process should - default this field to be a single, authenticated machine - address, indicating the AGENT (person, system or process) - entering the message. If this is not done, the "Sender" field - MUST be present. If the "From" field IS defaulted this way, - the "Sender" field is optional and is redundant with the - "From" field. In all cases, addresses in the "From" field - must be machine-usable (addr-specs) and may not contain named - lists (groups). - - 4.4.2. SENDER / RESENT-SENDER - - This field contains the authenticated identity of the AGENT - (person, system or process) that sends the message. It is - intended for use when the sender is not the author of the mes- - sage, or to indicate who among a group of authors actually - sent the message. If the contents of the "Sender" field would - be completely redundant with the "From" field, then the - "Sender" field need not be present and its use is discouraged - (though still legal). In particular, the "Sender" field MUST - be present if it is NOT the same as the "From" Field. - - The Sender mailbox specification includes a word sequence - which must correspond to a specific agent (i.e., a human user - or a computer program) rather than a standard address. This - indicates the expectation that the field will identify the - single AGENT (person, system, or process) responsible for - sending the mail and not simply include the name of a mailbox - from which the mail was sent. For example in the case of a - shared login name, the name, by itself, would not be adequate. - The local-part address unit, which refers to this agent, is - expected to be a computer system term, and not (for example) a - generalized person reference which can be used outside the - network text message context. - - - August 13, 1982 - 21 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Since the critical function served by the "Sender" field is - identification of the agent responsible for sending mail and - since computer programs cannot be held accountable for their - behavior, it is strongly recommended that when a computer pro- - gram generates a message, the HUMAN who is responsible for - that program be referenced as part of the "Sender" field mail- - box specification. - - 4.4.3. REPLY-TO / RESENT-REPLY-TO - - This field provides a general mechanism for indicating any - mailbox(es) to which responses are to be sent. Three typical - uses for this feature can be distinguished. In the first - case, the author(s) may not have regular machine-based mail- - boxes and therefore wish(es) to indicate an alternate machine - address. In the second case, an author may wish additional - persons to be made aware of, or responsible for, replies. A - somewhat different use may be of some help to "text message - teleconferencing" groups equipped with automatic distribution - services: include the address of that service in the "Reply- - To" field of all messages submitted to the teleconference; - then participants can "reply" to conference submissions to - guarantee the correct distribution of any submission of their - own. - - Note: The "Return-Path" field is added by the mail transport - service, at the time of final deliver. It is intended - to identify a path back to the orginator of the mes- - sage. The "Reply-To" field is added by the message - originator and is intended to direct replies. - - 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO - - For systems which automatically generate address lists for - replies to messages, the following recommendations are made: - - o The "Sender" field mailbox should be sent notices of - any problems in transport or delivery of the original - messages. If there is no "Sender" field, then the - "From" field mailbox should be used. - - o The "Sender" field mailbox should NEVER be used - automatically, in a recipient's reply message. - - o If the "Reply-To" field exists, then the reply should - go to the addresses indicated in that field and not to - the address(es) indicated in the "From" field. - - - - - August 13, 1982 - 22 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - o If there is a "From" field, but no "Reply-To" field, - the reply should be sent to the address(es) indicated - in the "From" field. - - Sometimes, a recipient may actually wish to communicate with - the person that initiated the message transfer. In such - cases, it is reasonable to use the "Sender" address. - - This recommendation is intended only for automated use of - originator-fields and is not intended to suggest that replies - may not also be sent to other recipients of messages. It is - up to the respective mail-handling programs to decide what - additional facilities will be provided. - - Examples are provided in Appendix A. - - 4.5. RECEIVER FIELDS - - 4.5.1. TO / RESENT-TO - - This field contains the identity of the primary recipients of - the message. - - 4.5.2. CC / RESENT-CC - - This field contains the identity of the secondary (informa- - tional) recipients of the message. - - 4.5.3. BCC / RESENT-BCC - - This field contains the identity of additional recipients of - the message. The contents of this field are not included in - copies of the message sent to the primary and secondary reci- - pients. Some systems may choose to include the text of the - "Bcc" field only in the author(s)'s copy, while others may - also include it in the text sent to all those indicated in the - "Bcc" list. - - 4.6. REFERENCE FIELDS - - 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID - - This field contains a unique identifier (the local-part - address unit) which refers to THIS version of THIS message. - The uniqueness of the message identifier is guaranteed by the - host which generates it. This identifier is intended to be - machine readable and not necessarily meaningful to humans. A - message identifier pertains to exactly one instantiation of a - particular message; subsequent revisions to the message should - - - August 13, 1982 - 23 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - each receive new message identifiers. - - 4.6.2. IN-REPLY-TO - - The contents of this field identify previous correspon- - dence which this message answers. Note that if message iden- - tifiers are used in this field, they must use the msg-id - specification format. - - 4.6.3. REFERENCES - - The contents of this field identify other correspondence - which this message references. Note that if message identif- - iers are used, they must use the msg-id specification format. - - 4.6.4. KEYWORDS - - This field contains keywords or phrases, separated by - commas. - - 4.7. OTHER FIELDS - - 4.7.1. SUBJECT - - This is intended to provide a summary, or indicate the - nature, of the message. - - 4.7.2. COMMENTS - - Permits adding text comments onto the message without - disturbing the contents of the message's body. - - 4.7.3. ENCRYPTED - - Sometimes, data encryption is used to increase the - privacy of message contents. If the body of a message has - been encrypted, to keep its contents private, the "Encrypted" - field can be used to note the fact and to indicate the nature - of the encryption. The first parameter indicates the - software used to encrypt the body, and the second, optional - is intended to aid the recipient in selecting the - proper decryption key. This code word may be viewed as an - index to a table of keys held by the recipient. - - Note: Unfortunately, headers must contain envelope, as well - as contents, information. Consequently, it is neces- - sary that they remain unencrypted, so that mail tran- - sport services may access them. Since names, - addresses, and "Subject" field contents may contain - - - August 13, 1982 - 24 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - sensitive information, this requirement limits total - message privacy. - - Names of encryption software are registered with the Net- - work Information Center, SRI International, Menlo Park, Cali- - fornia. - - 4.7.4. EXTENSION-FIELD - - A limited number of common fields have been defined in - this document. As network mail requirements dictate, addi- - tional fields may be standardized. To provide user-defined - fields with a measure of safety, in name selection, such - extension-fields will never have names that begin with the - string "X-". - - Names of Extension-fields are registered with the Network - Information Center, SRI International, Menlo Park, California. - - 4.7.5. USER-DEFINED-FIELD - - Individual users of network mail are free to define and - use additional header fields. Such fields must have names - which are not already used in the current specification or in - any definitions of extension-fields, and the overall syntax of - these user-defined-fields must conform to this specification's - rules for delimiting and folding fields. Due to the - extension-field publishing process, the name of a user- - defined-field may be pre-empted - - Note: The prefatory string "X-" will never be used in the - names of Extension-fields. This provides user-defined - fields with a protected set of names. - - - - - - - - - - - - - - - - - - - August 13, 1982 - 25 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 5. DATE AND TIME SPECIFICATION - - 5.1. SYNTAX - - date-time = [ day "," ] date time ; dd mm yy - ; hh:mm:ss zzz - - day = "Mon" / "Tue" / "Wed" / "Thu" - / "Fri" / "Sat" / "Sun" - - date = 1*2DIGIT month 2DIGIT ; day month year - ; e.g. 20 Jun 82 - - month = "Jan" / "Feb" / "Mar" / "Apr" - / "May" / "Jun" / "Jul" / "Aug" - / "Sep" / "Oct" / "Nov" / "Dec" - - time = hour zone ; ANSI and Military - - hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] - ; 00:00:00 - 23:59:59 - - zone = "UT" / "GMT" ; Universal Time - ; North American : UT - / "EST" / "EDT" ; Eastern: - 5/ - 4 - / "CST" / "CDT" ; Central: - 6/ - 5 - / "MST" / "MDT" ; Mountain: - 7/ - 6 - / "PST" / "PDT" ; Pacific: - 8/ - 7 - / 1ALPHA ; Military: Z = UT; - ; A:-1; (J not used) - ; M:-12; N:+1; Y:+12 - / ( ("+" / "-") 4DIGIT ) ; Local differential - ; hours+min. (HHMM) - - 5.2. SEMANTICS - - If included, day-of-week must be the day implied by the date - specification. - - Time zone may be indicated in several ways. "UT" is Univer- - sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- - mitted as a reference to Universal Time. The military standard - uses a single character for each zone. "Z" is Universal Time. - "A" indicates one hour earlier, and "M" indicates 12 hours ear- - lier; "N" is one hour later, and "Y" is 12 hours later. The - letter "J" is not used. The other remaining two forms are taken - from ANSI standard X3.51-1975. One allows explicit indication of - the amount of offset from UT; the other uses common 3-character - strings for indicating time zones in North America. - - - August 13, 1982 - 26 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 6. ADDRESS SPECIFICATION - - 6.1. SYNTAX - - address = mailbox ; one addressee - / group ; named list - - group = phrase ":" [#mailbox] ";" - - mailbox = addr-spec ; simple address - / phrase route-addr ; name & addr-spec - - route-addr = "<" [route] addr-spec ">" - - route = 1#("@" domain) ":" ; path-relative - - addr-spec = local-part "@" domain ; global address - - local-part = word *("." word) ; uninterpreted - ; case-preserved - - domain = sub-domain *("." sub-domain) - - sub-domain = domain-ref / domain-literal - - domain-ref = atom ; symbolic reference - - 6.2. SEMANTICS - - A mailbox receives mail. It is a conceptual entity which - does not necessarily pertain to file storage. For example, some - sites may choose to print mail on their line printer and deliver - the output to the addressee's desk. - - A mailbox specification comprises a person, system or pro- - cess name reference, a domain-dependent string, and a name-domain - reference. The name reference is optional and is usually used to - indicate the human name of a recipient. The name-domain refer- - ence specifies a sequence of sub-domains. The domain-dependent - string is uninterpreted, except by the final sub-domain; the rest - of the mail service merely transmits it as a literal string. - - 6.2.1. DOMAINS - - A name-domain is a set of registered (mail) names. A name- - domain specification resolves to a subordinate name-domain - specification or to a terminal domain-dependent string. - Hence, domain specification is extensible, permitting any - number of registration levels. - - - August 13, 1982 - 27 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Name-domains model a global, logical, hierarchical addressing - scheme. The model is logical, in that an address specifica- - tion is related to name registration and is not necessarily - tied to transmission path. The model's hierarchy is a - directed graph, called an in-tree, such that there is a single - path from the root of the tree to any node in the hierarchy. - If more than one path actually exists, they are considered to - be different addresses. - - The root node is common to all addresses; consequently, it is - not referenced. Its children constitute "top-level" name- - domains. Usually, a service has access to its own full domain - specification and to the names of all top-level name-domains. - - The "top" of the domain addressing hierarchy -- a child of the - root -- is indicated by the right-most field, in a domain - specification. Its child is specified to the left, its child - to the left, and so on. - - Some groups provide formal registration services; these con- - stitute name-domains that are independent logically of - specific machines. In addition, networks and machines impli- - citly compose name-domains, since their membership usually is - registered in name tables. - - In the case of formal registration, an organization implements - a (distributed) data base which provides an address-to-route - mapping service for addresses of the form: - - person@registry.organization - - Note that "organization" is a logical entity, separate from - any particular communication network. - - A mechanism for accessing "organization" is universally avail- - able. That mechanism, in turn, seeks an instantiation of the - registry; its location is not indicated in the address specif- - ication. It is assumed that the system which operates under - the name "organization" knows how to find a subordinate regis- - try. The registry will then use the "person" string to deter- - mine where to send the mail specification. - - The latter, network-oriented case permits simple, direct, - attachment-related address specification, such as: - - user@host.network - - Once the network is accessed, it is expected that a message - will go directly to the host and that the host will resolve - - - August 13, 1982 - 28 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - the user name, placing the message in the user's mailbox. - - 6.2.2. ABBREVIATED DOMAIN SPECIFICATION - - Since any number of levels is possible within the domain - hierarchy, specification of a fully qualified address can - become inconvenient. This standard permits abbreviated domain - specification, in a special case: - - For the address of the sender, call the left-most - sub-domain Level N. In a header address, if all of - the sub-domains above (i.e., to the right of) Level N - are the same as those of the sender, then they do not - have to appear in the specification. Otherwise, the - address must be fully qualified. - - This feature is subject to approval by local sub- - domains. Individual sub-domains may require their - member systems, which originate mail, to provide full - domain specification only. When permitted, abbrevia- - tions may be present only while the message stays - within the sub-domain of the sender. - - Use of this mechanism requires the sender's sub-domain - to reserve the names of all top-level domains, so that - full specifications can be distinguished from abbrevi- - ated specifications. - - For example, if a sender's address is: - - sender@registry-A.registry-1.organization-X - - and one recipient's address is: - - recipient@registry-B.registry-1.organization-X - - and another's is: - - recipient@registry-C.registry-2.organization-X - - then ".registry-1.organization-X" need not be specified in the - the message, but "registry-C.registry-2" DOES have to be - specified. That is, the first two addresses may be abbrevi- - ated, but the third address must be fully specified. - - When a message crosses a domain boundary, all addresses must - be specified in the full format, ending with the top-level - name-domain in the right-most field. It is the responsibility - of mail forwarding services to ensure that addresses conform - - - August 13, 1982 - 29 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - with this requirement. In the case of abbreviated addresses, - the relaying service must make the necessary expansions. It - should be noted that it often is difficult for such a service - to locate all occurrences of address abbreviations. For exam- - ple, it will not be possible to find such abbreviations within - the body of the message. The "Return-Path" field can aid - recipients in recovering from these errors. - - Note: When passing any portion of an addr-spec onto a process - which does not interpret data according to this stan- - dard (e.g., mail protocol servers). There must be NO - LWSP-chars preceding or following the at-sign or any - delimiting period ("."), such as shown in the above - examples, and only ONE SPACE between contiguous - s. - - 6.2.3. DOMAIN TERMS - - A domain-ref must be THE official name of a registry, network, - or host. It is a symbolic reference, within a name sub- - domain. At times, it is necessary to bypass standard mechan- - isms for resolving such references, using more primitive - information, such as a network host address rather than its - associated host name. - - To permit such references, this standard provides the domain- - literal construct. Its contents must conform with the needs - of the sub-domain in which it is interpreted. - - Domain-literals which refer to domains within the ARPA Inter- - net specify 32-bit Internet addresses, in four 8-bit fields - noted in decimal, as described in Request for Comments #820, - "Assigned Numbers." For example: - - [10.0.3.19] - - Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It - is permitted only as a means of bypassing temporary - system limitations, such as name tables which are not - complete. - - The names of "top-level" domains, and the names of domains - under in the ARPA Internet, are registered with the Network - Information Center, SRI International, Menlo Park, California. - - 6.2.4. DOMAIN-DEPENDENT LOCAL STRING - - The local-part of an addr-spec in a mailbox specification - (i.e., the host's name for the mailbox) is understood to be - - - August 13, 1982 - 30 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - whatever the receiving mail protocol server allows. For exam- - ple, some systems do not understand mailbox references of the - form "P. D. Q. Bach", but others do. - - This specification treats periods (".") as lexical separators. - Hence, their presence in local-parts which are not quoted- - strings, is detected. However, such occurrences carry NO - semantics. That is, if a local-part has periods within it, an - address parser will divide the local-part into several tokens, - but the sequence of tokens will be treated as one uninter- - preted unit. The sequence will be re-assembled, when the - address is passed outside of the system such as to a mail pro- - tocol service. - - For example, the address: - - First.Last@Registry.Org - - is legal and does not require the local-part to be surrounded - with quotation-marks. (However, "First Last" DOES require - quoting.) The local-part of the address, when passed outside - of the mail system, within the Registry.Org domain, is - "First.Last", again without quotation marks. - - 6.2.5. BALANCING LOCAL-PART AND DOMAIN - - In some cases, the boundary between local-part and domain can - be flexible. The local-part may be a simple string, which is - used for the final determination of the recipient's mailbox. - All other levels of reference are, therefore, part of the - domain. - - For some systems, in the case of abbreviated reference to the - local and subordinate sub-domains, it may be possible to - specify only one reference within the domain part and place - the other, subordinate name-domain references within the - local-part. This would appear as: - - mailbox.sub1.sub2@this-domain - - Such a specification would be acceptable to address parsers - which conform to RFC #733, but do not support this newer - Internet standard. While contrary to the intent of this stan- - dard, the form is legal. - - Also, some sub-domains have a specification syntax which does - not conform to this standard. For example: - - sub-net.mailbox@sub-domain.domain - - - August 13, 1982 - 31 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - uses a different parsing sequence for local-part than for - domain. - - Note: As a rule, the domain specification should contain - fields which are encoded according to the syntax of - this standard and which contain generally-standardized - information. The local-part specification should con- - tain only that portion of the address which deviates - from the form or intention of the domain field. - - 6.2.6. MULTIPLE MAILBOXES - - An individual may have several mailboxes and wish to receive - mail at whatever mailbox is convenient for the sender to - access. This standard does not provide a means of specifying - "any member of" a list of mailboxes. - - A set of individuals may wish to receive mail as a single unit - (i.e., a distribution list). The construct permits - specification of such a list. Recipient mailboxes are speci- - fied within the bracketed part (":" - ";"). A copy of the - transmitted message is to be sent to each mailbox listed. - This standard does not permit recursive specification of - groups within groups. - - While a list must be named, it is not required that the con- - tents of the list be included. In this case, the
- serves only as an indication of group distribution and would - appear in the form: - - name:; - - Some mail services may provide a group-list distribution - facility, accepting a single mailbox reference, expanding it - to the full distribution list, and relaying the mail to the - list's members. This standard provides no additional syntax - for indicating such a service. Using the address - alternative, while listing one mailbox in it, can mean either - that the mailbox reference will be expanded to a list or that - there is a group with one member. - - 6.2.7. EXPLICIT PATH SPECIFICATION - - At times, a message originator may wish to indicate the - transmission path that a message should follow. This is - called source routing. The normal addressing scheme, used in - an addr-spec, is carefully separated from such information; - the portion of a route-addr is provided for such occa- - sions. It specifies the sequence of hosts and/or transmission - - - August 13, 1982 - 32 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - services that are to be traversed. Both domain-refs and - domain-literals may be used. - - Note: The use of source routing is discouraged. Unless the - sender has special need of path restriction, the choice - of transmission route should be left to the mail tran- - sport service. - - 6.3. RESERVED ADDRESS - - It often is necessary to send mail to a site, without know- - ing any of its valid addresses. For example, there may be mail - system dysfunctions, or a user may wish to find out a person's - correct address, at that site. - - This standard specifies a single, reserved mailbox address - (local-part) which is to be valid at each site. Mail sent to - that address is to be routed to a person responsible for the - site's mail system or to a person with responsibility for general - site operation. The name of the reserved local-part address is: - - Postmaster - - so that "Postmaster@domain" is required to be valid. - - Note: This reserved local-part must be matched without sensi- - tivity to alphabetic case, so that "POSTMASTER", "postmas- - ter", and even "poStmASteR" is to be accepted. - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 33 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 7. BIBLIOGRAPHY - - - ANSI. "USA Standard Code for Information Interchange," X3.4. - American National Standards Institute: New York (1968). Also - in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- - book", NIC 7104. - - ANSI. "Representations of Universal Time, Local Time Differen- - tials, and United States Time Zone References for Information - Interchange," X3.51-1975. American National Standards Insti- - tute: New York (1975). - - Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. - 1979). - - Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- - ford and Appleton Laboratory: Didcot, England. - - Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. - "Standardizing Network Mail Headers," ARPANET Request for - Comments No. 561, Network Information Center No. 18516; SRI - International: Menlo Park (September 1973). - - Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. - "Grapevine: An Exercise in Distributed Computing," Communica- - tions of the ACM 25, 4 (April 1982), 260-274. - - Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. - "Standard for the Format of ARPA Network Text Message," - ARPANET Request for Comments No. 733, Network Information - Center No. 41952. SRI International: Menlo Park (November - 1977). - - Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- - work Information Center No. 7104 (NTIS AD A003890). SRI - International: Menlo Park (April 1976). - - Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. - (1969). - - Levin, R. and Schroeder, M. "Transport of Electronic Messages - through a Network," TeleInformatics 79, pp. 29-33. North - Holland (1979). Also as Xerox Palo Alto Research Center - Technical Report CSL-79-4. - - Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," - ARPANET Request for Comments, No. 680, Network Information - Center No. 32116. SRI International: Menlo Park (1975). - - - August 13, 1982 - 34 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - NBS. "Specification of Message Format for Computer Based Message - Systems, Recommended Federal Information Processing Standard." - National Bureau of Standards: Gaithersburg, Maryland - (October 1981). - - NIC. Internet Protocol Transition Workbook. Network Information - Center, SRI-International, Menlo Park, California (March - 1982). - - Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized - Agent for Locating Named Objects in a Distributed Environ- - ment," OPD-T8103. Xerox Office Products Division: Palo Alto, - CA. (October 1981). - - Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, - No. 820. SRI International: Menlo Park (August 1982). - - Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request - for Comments, No. 821. SRI International: Menlo Park (August - 1982). - - Shoch, J.F. "Internetwork naming, addressing and routing," in - Proc. 17th IEEE Computer Society International Conference, pp. - 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. - - Su, Z. and Postel, J. "The Domain Naming Convention for Internet - User Applications," ARPANET Request for Comments, No. 819. - SRI International: Menlo Park (August 1982). - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 35 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - APPENDIX - - - A. EXAMPLES - - A.1. ADDRESSES - - A.1.1. Alfred Neuman - - A.1.2. Neuman@BBN-TENEXA - - These two "Alfred Neuman" examples have identical seman- - tics, as far as the operation of the local host's mail sending - (distribution) program (also sometimes called its "mailer") - and the remote host's mail protocol server are concerned. In - the first example, the "Alfred Neuman" is ignored by the - mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- - pient. The second example contains no superfluous informa- - tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- - pient. - - Note: When the message crosses name-domain boundaries, then - these specifications must be changed, so as to indicate - the remainder of the hierarchy, starting with the top - level. - - A.1.3. "George, Ted" - - This form might be used to indicate that a single mailbox - is shared by several users. The quoted string is ignored by - the originating host's mailer, because "Shared@Group.Arpanet" - completely specifies the destination mailbox. - - A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US - - The "(the Stilt)" is a comment, which is NOT included in - the destination mailbox address handed to the originating - system's mailer. The local-part of the address is the string - "Wilt.Chamberlain", with NO space between the first and second - words. - - A.1.5. Address Lists - - Gourmets: Pompous Person , - Childs@WGBH.Boston, Galloping Gourmet@ - ANT.Down-Under (Australian National Television), - Cheapie@Discount-Liquors;, - Cruisers: Port@Portugal, Jones@SEA;, - Another@Somewhere.SomeOrg - - - August 13, 1982 - 36 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - This group list example points out the use of comments and the - mixing of addresses and groups. - - A.2. ORIGINATOR ITEMS - - A.2.1. Author-sent - - George Jones logs into his host as "Jones". He sends - mail himself. - - From: Jones@Group.Org - - or - - From: George Jones - - A.2.2. Secretary-sent - - George Jones logs in as Jones on his host. His secre- - tary, who logs in as Secy sends mail for him. Replies to the - mail should go to George. - - From: George Jones - Sender: Secy@Other-Group - - A.2.3. Secretary-sent, for user of shared directory - - George Jones' secretary sends mail for George. Replies - should go to George. - - From: George Jones - Sender: Secy@Other-Group - - Note that there need not be a space between "Jones" and the - "<", but adding a space enhances readability (as is the case - in other examples. - - A.2.4. Committee activity, with one author - - George is a member of a committee. He wishes to have any - replies to his message go to all committee members. - - From: George Jones - Sender: Jones@Host - Reply-To: The Committee: Jones@Host.Net, - Smith@Other.Org, - Doe@Somewhere-Else; - - Note that if George had not included himself in the - - - August 13, 1982 - 37 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - enumeration of The Committee, he would not have gotten an - implicit reply; the presence of the "Reply-to" field SUPER- - SEDES the sending of a reply to the person named in the "From" - field. - - A.2.5. Secretary acting as full agent of author - - George Jones asks his secretary (Secy@Host) to send a - message for him in his capacity as Group. He wants his secre- - tary to handle all replies. - - From: George Jones - Sender: Secy@Host - Reply-To: Secy@Host - - A.2.6. Agent for user without online mailbox - - A friend of George's, Sarah, is visiting. George's - secretary sends some mail to a friend of Sarah in computer- - land. Replies should go to George, whose mailbox is Jones at - Registry. - - From: Sarah Friendly - Sender: Secy-Name - Reply-To: Jones@Registry. - - A.2.7. Agent for member of a committee - - George's secretary sends out a message which was authored - jointly by all the members of a committee. Note that the name - of the committee cannot be specified, since names are - not permitted in the From field. - - From: Jones@Host, - Smith@Other-Host, - Doe@Somewhere-Else - Sender: Secy@SHost - - - - - - - - - - - - - - - August 13, 1982 - 38 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - A.3. COMPLETE HEADERS - - A.3.1. Minimum required - - Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT - From: Jones@Registry.Org or From: Jones@Registry.Org - Bcc: To: Smith@Registry.Org - - Note that the "Bcc" field may be empty, while the "To" field - is required to have at least one address. - - A.3.2. Using some of the additional fields - - Date: 26 Aug 76 1430 EDT - From: George Jones - Sender: Secy@SHOST - To: "Al Neuman"@Mad-Host, - Sam.Irving@Other-Host - Message-ID: - - A.3.3. About as complex as you're going to get - - Date : 27 Aug 76 0932 PDT - From : Ken Davis - Subject : Re: The Syntax in the RFC - Sender : KSecy@Other-Host - Reply-To : Sam.Irving@Reg.Organization - To : George Jones , - Al.Neuman@MAD.Publisher - cc : Important folk: - Tom Softwood , - "Sam Irving"@Other-Host;, - Standard Distribution: - /main/davis/people/standard@Other-Host, - "standard.dist.3"@Tops-20-Host>; - Comment : Sam is away on business. He asked me to handle - his mail for him. He'll be able to provide a - more accurate explanation when he returns - next week. - In-Reply-To: , George's message - X-Special-action: This is a sample of user-defined field- - names. There could also be a field-name - "Special-action", but its name might later be - preempted - Message-ID: <4231.629.XYzi-What@Other-Host> - - - - - - - August 13, 1982 - 39 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - B. SIMPLE FIELD PARSING - - Some mail-reading software systems may wish to perform only - minimal processing, ignoring the internal syntax of structured - field-bodies and treating them the same as unstructured-field- - bodies. Such software will need only to distinguish: - - o Header fields from the message body, - - o Beginnings of fields from lines which continue fields, - - o Field-names from field-contents. - - The abbreviated set of syntactic rules which follows will - suffice for this purpose. It describes a limited view of mes- - sages and is a subset of the syntactic rules provided in the main - part of this specification. One small exception is that the con- - tents of field-bodies consist only of text: - - B.1. SYNTAX - - - message = *field *(CRLF *text) - - field = field-name ":" [field-body] CRLF - - field-name = 1* - - field-body = *text [CRLF LWSP-char field-body] - - - B.2. SEMANTICS - - Headers occur before the message body and are terminated by - a null line (i.e., two contiguous CRLFs). - - A line which continues a header field begins with a SPACE or - HTAB character, while a line beginning a field starts with a - printable character which is not a colon. - - A field-name consists of one or more printable characters - (excluding colon, space, and control-characters). A field-name - MUST be contained on one line. Upper and lower case are not dis- - tinguished when comparing field-names. - - - - - - - - August 13, 1982 - 40 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - C. DIFFERENCES FROM RFC #733 - - The following summarizes the differences between this stan- - dard and the one specified in Arpanet Request for Comments #733, - "Standard for the Format of ARPA Network Text Messages". The - differences are listed in the order of their occurrence in the - current specification. - - C.1. FIELD DEFINITIONS - - C.1.1. FIELD NAMES - - These now must be a sequence of printable characters. They - may not contain any LWSP-chars. - - C.2. LEXICAL TOKENS - - C.2.1. SPECIALS - - The characters period ("."), left-square bracket ("["), and - right-square bracket ("]") have been added. For presentation - purposes, and when passing a specification to a system that - does not conform to this standard, periods are to be contigu- - ous with their surrounding lexical tokens. No linear-white- - space is permitted between them. The presence of one LWSP- - char between other tokens is still directed. - - C.2.2. ATOM - - Atoms may not contain SPACE. - - C.2.3. SPECIAL TEXT - - ctext and qtext have had backslash ("\") added to the list of - prohibited characters. - - C.2.4. DOMAINS - - The lexical tokens and have been - added. - - C.3. MESSAGE SPECIFICATION - - C.3.1. TRACE - - The "Return-path:" and "Received:" fields have been specified. - - - - - - August 13, 1982 - 41 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - C.3.2. FROM - - The "From" field must contain machine-usable addresses (addr- - spec). Multiple addresses may be specified, but named-lists - (groups) may not. - - C.3.3. RESENT - - The meta-construct of prefacing field names with the string - "Resent-" has been added, to indicate that a message has been - forwarded by an intermediate recipient. - - C.3.4. DESTINATION - - A message must contain at least one destination address field. - "To" and "CC" are required to contain at least one address. - - C.3.5. IN-REPLY-TO - - The field-body is no longer a comma-separated list, although a - sequence is still permitted. - - C.3.6. REFERENCE - - The field-body is no longer a comma-separated list, although a - sequence is still permitted. - - C.3.7. ENCRYPTED - - A field has been specified that permits senders to indicate - that the body of a message has been encrypted. - - C.3.8. EXTENSION-FIELD - - Extension fields are prohibited from beginning with the char- - acters "X-". - - C.4. DATE AND TIME SPECIFICATION - - C.4.1. SIMPLIFICATION - - Fewer optional forms are permitted and the list of three- - letter time zones has been shortened. - - C.5. ADDRESS SPECIFICATION - - - - - - - August 13, 1982 - 42 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - C.5.1. ADDRESS - - The use of quoted-string, and the ":"-atom-":" construct, have - been removed. An address now is either a single mailbox - reference or is a named list of addresses. The latter indi- - cates a group distribution. - - C.5.2. GROUPS - - Group lists are now required to to have a name. Group lists - may not be nested. - - C.5.3. MAILBOX - - A mailbox specification may indicate a person's name, as - before. Such a named list no longer may specify multiple - mailboxes and may not be nested. - - C.5.4. ROUTE ADDRESSING - - Addresses now are taken to be absolute, global specifications, - independent of transmission paths. The construct has - been provided, to permit explicit specification of transmis- - sion path. RFC #733's use of multiple at-signs ("@") was - intended as a general syntax for indicating routing and/or - hierarchical addressing. The current standard separates these - specifications and only one at-sign is permitted. - - C.5.5. AT-SIGN - - The string " at " no longer is used as an address delimiter. - Only at-sign ("@") serves the function. - - C.5.6. DOMAINS - - Hierarchical, logical name-domains have been added. - - C.6. RESERVED ADDRESS - - The local-part "Postmaster" has been reserved, so that users can - be guaranteed at least one valid address at a site. - - - - - - - - - - - August 13, 1982 - 43 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - D. ALPHABETICAL LISTING OF SYNTAX RULES - - address = mailbox ; one addressee - / group ; named list - addr-spec = local-part "@" domain ; global address - ALPHA = - ; (101-132, 65.- 90.) - ; (141-172, 97.-122.) - atom = 1* - authentic = "From" ":" mailbox ; Single author - / ( "Sender" ":" mailbox ; Actual submittor - "From" ":" 1#mailbox) ; Multiple authors - ; or not sender - CHAR = ; ( 0-177, 0.-127.) - comment = "(" *(ctext / quoted-pair / comment) ")" - CR = ; ( 15, 13.) - CRLF = CR LF - ctext = may be folded - ")", "\" & CR, & including - linear-white-space> - CTL = ; ( 177, 127.) - date = 1*2DIGIT month 2DIGIT ; day month year - ; e.g. 20 Jun 82 - dates = orig-date ; Original - [ resent-date ] ; Forwarded - date-time = [ day "," ] date time ; dd mm yy - ; hh:mm:ss zzz - day = "Mon" / "Tue" / "Wed" / "Thu" - / "Fri" / "Sat" / "Sun" - delimiters = specials / linear-white-space / comment - destination = "To" ":" 1#address ; Primary - / "Resent-To" ":" 1#address - / "cc" ":" 1#address ; Secondary - / "Resent-cc" ":" 1#address - / "bcc" ":" #address ; Blind carbon - / "Resent-bcc" ":" #address - DIGIT = ; ( 60- 71, 48.- 57.) - domain = sub-domain *("." sub-domain) - domain-literal = "[" *(dtext / quoted-pair) "]" - domain-ref = atom ; symbolic reference - dtext = may be folded - "]", "\" & CR, & including - linear-white-space> - extension-field = - - - - August 13, 1982 - 44 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - field = field-name ":" [ field-body ] CRLF - fields = dates ; Creation time, - source ; author id & one - 1*destination ; address required - *optional-field ; others optional - field-body = field-body-contents - [CRLF LWSP-char field-body] - field-body-contents = - - field-name = 1* - group = phrase ":" [#mailbox] ";" - hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] - ; 00:00:00 - 23:59:59 - HTAB = ; ( 11, 9.) - LF = ; ( 12, 10.) - linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE - ; CRLF => folding - local-part = word *("." word) ; uninterpreted - ; case-preserved - LWSP-char = SPACE / HTAB ; semantics = SPACE - mailbox = addr-spec ; simple address - / phrase route-addr ; name & addr-spec - message = fields *( CRLF *text ) ; Everything after - ; first null line - ; is message body - month = "Jan" / "Feb" / "Mar" / "Apr" - / "May" / "Jun" / "Jul" / "Aug" - / "Sep" / "Oct" / "Nov" / "Dec" - msg-id = "<" addr-spec ">" ; Unique message id - optional-field = - / "Message-ID" ":" msg-id - / "Resent-Message-ID" ":" msg-id - / "In-Reply-To" ":" *(phrase / msg-id) - / "References" ":" *(phrase / msg-id) - / "Keywords" ":" #phrase - / "Subject" ":" *text - / "Comments" ":" *text - / "Encrypted" ":" 1#2word - / extension-field ; To be defined - / user-defined-field ; May be pre-empted - orig-date = "Date" ":" date-time - originator = authentic ; authenticated addr - [ "Reply-To" ":" 1#address] ) - phrase = 1*word ; Sequence of words - - - - - August 13, 1982 - 45 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - qtext = , ; => may be folded - "\" & CR, and including - linear-white-space> - quoted-pair = "\" CHAR ; may quote any char - quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or - ; quoted chars. - received = "Received" ":" ; one per relay - ["from" domain] ; sending host - ["by" domain] ; receiving host - ["via" atom] ; physical path - *("with" atom) ; link/mail protocol - ["id" msg-id] ; receiver msg id - ["for" addr-spec] ; initial form - ";" date-time ; time received - - resent = resent-authentic - [ "Resent-Reply-To" ":" 1#address] ) - resent-authentic = - = "Resent-From" ":" mailbox - / ( "Resent-Sender" ":" mailbox - "Resent-From" ":" 1#mailbox ) - resent-date = "Resent-Date" ":" date-time - return = "Return-path" ":" route-addr ; return address - route = 1#("@" domain) ":" ; path-relative - route-addr = "<" [route] addr-spec ">" - source = [ trace ] ; net traversals - originator ; original mail - [ resent ] ; forwarded - SPACE = ; ( 40, 32.) - specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- - / "," / ";" / ":" / "\" / <"> ; string, to use - / "." / "[" / "]" ; within a word. - sub-domain = domain-ref / domain-literal - text = atoms, specials, - CR & bare LF, but NOT ; comments and - including CRLF> ; quoted-strings are - ; NOT recognized. - time = hour zone ; ANSI and Military - trace = return ; path to sender - 1*received ; receipt tags - user-defined-field = - - word = atom / quoted-string - - - - - August 13, 1982 - 46 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - zone = "UT" / "GMT" ; Universal Time - ; North American : UT - / "EST" / "EDT" ; Eastern: - 5/ - 4 - / "CST" / "CDT" ; Central: - 6/ - 5 - / "MST" / "MDT" ; Mountain: - 7/ - 6 - / "PST" / "PDT" ; Pacific: - 8/ - 7 - / 1ALPHA ; Military: Z = UT; - <"> = ; ( 42, 34.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 47 - RFC #822 - - - diff --git a/server/src/site/resources/rfclist/basic/rfc1123.txt b/server/src/site/resources/rfclist/basic/rfc1123.txt deleted file mode 100644 index 514528a43bc..00000000000 --- a/server/src/site/resources/rfclist/basic/rfc1123.txt +++ /dev/null @@ -1,5781 +0,0 @@ - - - - - -Network Working Group Internet Engineering Task Force -Request for Comments: 1123 R. Braden, Editor - October 1989 - - - Requirements for Internet Hosts -- Application and Support - -Status of This Memo - - This RFC is an official specification for the Internet community. It - incorporates by reference, amends, corrects, and supplements the - primary protocol standards documents relating to hosts. Distribution - of this document is unlimited. - -Summary - - This RFC is one of a pair that defines and discusses the requirements - for Internet host software. This RFC covers the application and - support protocols; its companion RFC-1122 covers the communication - protocol layers: link layer, IP layer, and transport layer. - - - - Table of Contents - - - - - 1. INTRODUCTION ............................................... 5 - 1.1 The Internet Architecture .............................. 6 - 1.2 General Considerations ................................. 6 - 1.2.1 Continuing Internet Evolution ..................... 6 - 1.2.2 Robustness Principle .............................. 7 - 1.2.3 Error Logging ..................................... 8 - 1.2.4 Configuration ..................................... 8 - 1.3 Reading this Document .................................. 10 - 1.3.1 Organization ...................................... 10 - 1.3.2 Requirements ...................................... 10 - 1.3.3 Terminology ....................................... 11 - 1.4 Acknowledgments ........................................ 12 - - 2. GENERAL ISSUES ............................................. 13 - 2.1 Host Names and Numbers ................................. 13 - 2.2 Using Domain Name Service .............................. 13 - 2.3 Applications on Multihomed hosts ....................... 14 - 2.4 Type-of-Service ........................................ 14 - 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15 - - - - -Internet Engineering Task Force [Page 1] - - - - -RFC1123 INTRODUCTION October 1989 - - - 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16 - 3.1 INTRODUCTION ........................................... 16 - 3.2 PROTOCOL WALK-THROUGH .................................. 16 - 3.2.1 Option Negotiation ................................ 16 - 3.2.2 Telnet Go-Ahead Function .......................... 16 - 3.2.3 Control Functions ................................. 17 - 3.2.4 Telnet "Synch" Signal ............................. 18 - 3.2.5 NVT Printer and Keyboard .......................... 19 - 3.2.6 Telnet Command Structure .......................... 20 - 3.2.7 Telnet Binary Option .............................. 20 - 3.2.8 Telnet Terminal-Type Option ....................... 20 - 3.3 SPECIFIC ISSUES ........................................ 21 - 3.3.1 Telnet End-of-Line Convention ..................... 21 - 3.3.2 Data Entry Terminals .............................. 23 - 3.3.3 Option Requirements ............................... 24 - 3.3.4 Option Initiation ................................. 24 - 3.3.5 Telnet Linemode Option ............................ 25 - 3.4 TELNET/USER INTERFACE .................................. 25 - 3.4.1 Character Set Transparency ........................ 25 - 3.4.2 Telnet Commands ................................... 26 - 3.4.3 TCP Connection Errors ............................. 26 - 3.4.4 Non-Default Telnet Contact Port ................... 26 - 3.4.5 Flushing Output ................................... 26 - 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27 - - 4. FILE TRANSFER .............................................. 29 - 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29 - 4.1.1 INTRODUCTION ...................................... 29 - 4.1.2. PROTOCOL WALK-THROUGH ............................ 29 - 4.1.2.1 LOCAL Type ................................... 29 - 4.1.2.2 Telnet Format Control ........................ 30 - 4.1.2.3 Page Structure ............................... 30 - 4.1.2.4 Data Structure Transformations ............... 30 - 4.1.2.5 Data Connection Management ................... 31 - 4.1.2.6 PASV Command ................................. 31 - 4.1.2.7 LIST and NLST Commands ....................... 31 - 4.1.2.8 SITE Command ................................. 32 - 4.1.2.9 STOU Command ................................. 32 - 4.1.2.10 Telnet End-of-line Code ..................... 32 - 4.1.2.11 FTP Replies ................................. 33 - 4.1.2.12 Connections ................................. 34 - 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34 - 4.1.3 SPECIFIC ISSUES ................................... 35 - 4.1.3.1 Non-standard Command Verbs ................... 35 - 4.1.3.2 Idle Timeout ................................. 36 - 4.1.3.3 Concurrency of Data and Control .............. 36 - 4.1.3.4 FTP Restart Mechanism ........................ 36 - 4.1.4 FTP/USER INTERFACE ................................ 39 - - - -Internet Engineering Task Force [Page 2] - - - - -RFC1123 INTRODUCTION October 1989 - - - 4.1.4.1 Pathname Specification ....................... 39 - 4.1.4.2 "QUOTE" Command .............................. 40 - 4.1.4.3 Displaying Replies to User ................... 40 - 4.1.4.4 Maintaining Synchronization .................. 40 - 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41 - 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44 - 4.2.1 INTRODUCTION ...................................... 44 - 4.2.2 PROTOCOL WALK-THROUGH ............................. 44 - 4.2.2.1 Transfer Modes ............................... 44 - 4.2.2.2 UDP Header ................................... 44 - 4.2.3 SPECIFIC ISSUES ................................... 44 - 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44 - 4.2.3.2 Timeout Algorithms ........................... 46 - 4.2.3.3 Extensions ................................... 46 - 4.2.3.4 Access Control ............................... 46 - 4.2.3.5 Broadcast Request ............................ 46 - 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47 - - 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48 - 5.1 INTRODUCTION ........................................... 48 - 5.2 PROTOCOL WALK-THROUGH .................................. 48 - 5.2.1 The SMTP Model .................................... 48 - 5.2.2 Canonicalization .................................. 49 - 5.2.3 VRFY and EXPN Commands ............................ 50 - 5.2.4 SEND, SOML, and SAML Commands ..................... 50 - 5.2.5 HELO Command ...................................... 50 - 5.2.6 Mail Relay ........................................ 51 - 5.2.7 RCPT Command ...................................... 52 - 5.2.8 DATA Command ...................................... 53 - 5.2.9 Command Syntax .................................... 54 - 5.2.10 SMTP Replies ..................................... 54 - 5.2.11 Transparency ..................................... 55 - 5.2.12 WKS Use in MX Processing ......................... 55 - 5.2.13 RFC-822 Message Specification .................... 55 - 5.2.14 RFC-822 Date and Time Specification .............. 55 - 5.2.15 RFC-822 Syntax Change ............................ 56 - 5.2.16 RFC-822 Local-part .............................. 56 - 5.2.17 Domain Literals .................................. 57 - 5.2.18 Common Address Formatting Errors ................. 58 - 5.2.19 Explicit Source Routes ........................... 58 - 5.3 SPECIFIC ISSUES ........................................ 59 - 5.3.1 SMTP Queueing Strategies .......................... 59 - 5.3.1.1 Sending Strategy .............................. 59 - 5.3.1.2 Receiving strategy ........................... 61 - 5.3.2 Timeouts in SMTP .................................. 61 - 5.3.3 Reliable Mail Receipt ............................. 63 - 5.3.4 Reliable Mail Transmission ........................ 63 - 5.3.5 Domain Name Support ............................... 65 - - - -Internet Engineering Task Force [Page 3] - - - - -RFC1123 INTRODUCTION October 1989 - - - 5.3.6 Mailing Lists and Aliases ......................... 65 - 5.3.7 Mail Gatewaying ................................... 66 - 5.3.8 Maximum Message Size .............................. 68 - 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69 - - 6. SUPPORT SERVICES ............................................ 72 - 6.1 DOMAIN NAME TRANSLATION ................................. 72 - 6.1.1 INTRODUCTION ....................................... 72 - 6.1.2 PROTOCOL WALK-THROUGH ............................. 72 - 6.1.2.1 Resource Records with Zero TTL ............... 73 - 6.1.2.2 QCLASS Values ................................ 73 - 6.1.2.3 Unused Fields ................................ 73 - 6.1.2.4 Compression .................................. 73 - 6.1.2.5 Misusing Configuration Info .................. 73 - 6.1.3 SPECIFIC ISSUES ................................... 74 - 6.1.3.1 Resolver Implementation ...................... 74 - 6.1.3.2 Transport Protocols .......................... 75 - 6.1.3.3 Efficient Resource Usage ..................... 77 - 6.1.3.4 Multihomed Hosts ............................. 78 - 6.1.3.5 Extensibility ................................ 79 - 6.1.3.6 Status of RR Types ........................... 79 - 6.1.3.7 Robustness ................................... 80 - 6.1.3.8 Local Host Table ............................. 80 - 6.1.4 DNS USER INTERFACE ................................ 81 - 6.1.4.1 DNS Administration ........................... 81 - 6.1.4.2 DNS User Interface ........................... 81 - 6.1.4.3 Interface Abbreviation Facilities ............. 82 - 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84 - 6.2 HOST INITIALIZATION .................................... 87 - 6.2.1 INTRODUCTION ...................................... 87 - 6.2.2 REQUIREMENTS ...................................... 87 - 6.2.2.1 Dynamic Configuration ........................ 87 - 6.2.2.2 Loading Phase ................................ 89 - 6.3 REMOTE MANAGEMENT ...................................... 90 - 6.3.1 INTRODUCTION ...................................... 90 - 6.3.2 PROTOCOL WALK-THROUGH ............................. 90 - 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92 - - 7. REFERENCES ................................................. 93 - - - - - - - - - - - - -Internet Engineering Task Force [Page 4] - - - - -RFC1123 INTRODUCTION October 1989 - - -1. INTRODUCTION - - This document is one of a pair that defines and discusses the - requirements for host system implementations of the Internet protocol - suite. This RFC covers the applications layer and support protocols. - Its companion RFC, "Requirements for Internet Hosts -- Communications - Layers" [INTRO:1] covers the lower layer protocols: transport layer, - IP layer, and link layer. - - These documents are intended to provide guidance for vendors, - implementors, and users of Internet communication software. They - represent the consensus of a large body of technical experience and - wisdom, contributed by members of the Internet research and vendor - communities. - - This RFC enumerates standard protocols that a host connected to the - Internet must use, and it incorporates by reference the RFCs and - other documents describing the current specifications for these - protocols. It corrects errors in the referenced documents and adds - additional discussion and guidance for an implementor. - - For each protocol, this document also contains an explicit set of - requirements, recommendations, and options. The reader must - understand that the list of requirements in this document is - incomplete by itself; the complete set of requirements for an - Internet host is primarily defined in the standard protocol - specification documents, with the corrections, amendments, and - supplements contained in this RFC. - - A good-faith implementation of the protocols that was produced after - careful reading of the RFC's and with some interaction with the - Internet technical community, and that followed good communications - software engineering practices, should differ from the requirements - of this document in only minor ways. Thus, in many cases, the - "requirements" in this RFC are already stated or implied in the - standard protocol documents, so that their inclusion here is, in a - sense, redundant. However, they were included because some past - implementation has made the wrong choice, causing problems of - interoperability, performance, and/or robustness. - - This document includes discussion and explanation of many of the - requirements and recommendations. A simple list of requirements - would be dangerous, because: - - o Some required features are more important than others, and some - features are optional. - - o There may be valid reasons why particular vendor products that - - - -Internet Engineering Task Force [Page 5] - - - - -RFC1123 INTRODUCTION October 1989 - - - are designed for restricted contexts might choose to use - different specifications. - - However, the specifications of this document must be followed to meet - the general goal of arbitrary host interoperation across the - diversity and complexity of the Internet system. Although most - current implementations fail to meet these requirements in various - ways, some minor and some major, this specification is the ideal - towards which we need to move. - - These requirements are based on the current level of Internet - architecture. This document will be updated as required to provide - additional clarifications or to include additional information in - those areas in which specifications are still evolving. - - This introductory section begins with general advice to host software - vendors, and then gives some guidance on reading the rest of the - document. Section 2 contains general requirements that may be - applicable to all application and support protocols. Sections 3, 4, - and 5 contain the requirements on protocols for the three major - applications: Telnet, file transfer, and electronic mail, - respectively. Section 6 covers the support applications: the domain - name system, system initialization, and management. Finally, all - references will be found in Section 7. - - 1.1 The Internet Architecture - - For a brief introduction to the Internet architecture from a host - viewpoint, see Section 1.1 of [INTRO:1]. That section also - contains recommended references for general background on the - Internet architecture. - - 1.2 General Considerations - - There are two important lessons that vendors of Internet host - software have learned and which a new vendor should consider - seriously. - - 1.2.1 Continuing Internet Evolution - - The enormous growth of the Internet has revealed problems of - management and scaling in a large datagram-based packet - communication system. These problems are being addressed, and - as a result there will be continuing evolution of the - specifications described in this document. These changes will - be carefully planned and controlled, since there is extensive - participation in this planning by the vendors and by the - organizations responsible for operations of the networks. - - - -Internet Engineering Task Force [Page 6] - - - - -RFC1123 INTRODUCTION October 1989 - - - Development, evolution, and revision are characteristic of - computer network protocols today, and this situation will - persist for some years. A vendor who develops computer - communication software for the Internet protocol suite (or any - other protocol suite!) and then fails to maintain and update - that software for changing specifications is going to leave a - trail of unhappy customers. The Internet is a large - communication network, and the users are in constant contact - through it. Experience has shown that knowledge of - deficiencies in vendor software propagates quickly through the - Internet technical community. - - 1.2.2 Robustness Principle - - At every layer of the protocols, there is a general rule whose - application can lead to enormous benefits in robustness and - interoperability: - - "Be liberal in what you accept, and - conservative in what you send" - - Software should be written to deal with every conceivable - error, no matter how unlikely; sooner or later a packet will - come in with that particular combination of errors and - attributes, and unless the software is prepared, chaos can - ensue. In general, it is best to assume that the network is - filled with malevolent entities that will send in packets - designed to have the worst possible effect. This assumption - will lead to suitable protective design, although the most - serious problems in the Internet have been caused by - unenvisaged mechanisms triggered by low-probability events; - mere human malice would never have taken so devious a course! - - Adaptability to change must be designed into all levels of - Internet host software. As a simple example, consider a - protocol specification that contains an enumeration of values - for a particular header field -- e.g., a type field, a port - number, or an error code; this enumeration must be assumed to - be incomplete. Thus, if a protocol specification defines four - possible error codes, the software must not break when a fifth - code shows up. An undefined code might be logged (see below), - but it must not cause a failure. - - The second part of the principle is almost as important: - software on other hosts may contain deficiencies that make it - unwise to exploit legal but obscure protocol features. It is - unwise to stray far from the obvious and simple, lest untoward - effects result elsewhere. A corollary of this is "watch out - - - -Internet Engineering Task Force [Page 7] - - - - -RFC1123 INTRODUCTION October 1989 - - - for misbehaving hosts"; host software should be prepared, not - just to survive other misbehaving hosts, but also to cooperate - to limit the amount of disruption such hosts can cause to the - shared communication facility. - - 1.2.3 Error Logging - - The Internet includes a great variety of host and gateway - systems, each implementing many protocols and protocol layers, - and some of these contain bugs and mis-features in their - Internet protocol software. As a result of complexity, - diversity, and distribution of function, the diagnosis of user - problems is often very difficult. - - Problem diagnosis will be aided if host implementations include - a carefully designed facility for logging erroneous or - "strange" protocol events. It is important to include as much - diagnostic information as possible when an error is logged. In - particular, it is often useful to record the header(s) of a - packet that caused an error. However, care must be taken to - ensure that error logging does not consume prohibitive amounts - of resources or otherwise interfere with the operation of the - host. - - There is a tendency for abnormal but harmless protocol events - to overflow error logging files; this can be avoided by using a - "circular" log, or by enabling logging only while diagnosing a - known failure. It may be useful to filter and count duplicate - successive messages. One strategy that seems to work well is: - (1) always count abnormalities and make such counts accessible - through the management protocol (see Section 6.3); and (2) - allow the logging of a great variety of events to be - selectively enabled. For example, it might useful to be able - to "log everything" or to "log everything for host X". - - Note that different managements may have differing policies - about the amount of error logging that they want normally - enabled in a host. Some will say, "if it doesn't hurt me, I - don't want to know about it", while others will want to take a - more watchful and aggressive attitude about detecting and - removing protocol abnormalities. - - 1.2.4 Configuration - - It would be ideal if a host implementation of the Internet - protocol suite could be entirely self-configuring. This would - allow the whole suite to be implemented in ROM or cast into - silicon, it would simplify diskless workstations, and it would - - - -Internet Engineering Task Force [Page 8] - - - - -RFC1123 INTRODUCTION October 1989 - - - be an immense boon to harried LAN administrators as well as - system vendors. We have not reached this ideal; in fact, we - are not even close. - - At many points in this document, you will find a requirement - that a parameter be a configurable option. There are several - different reasons behind such requirements. In a few cases, - there is current uncertainty or disagreement about the best - value, and it may be necessary to update the recommended value - in the future. In other cases, the value really depends on - external factors -- e.g., the size of the host and the - distribution of its communication load, or the speeds and - topology of nearby networks -- and self-tuning algorithms are - unavailable and may be insufficient. In some cases, - configurability is needed because of administrative - requirements. - - Finally, some configuration options are required to communicate - with obsolete or incorrect implementations of the protocols, - distributed without sources, that unfortunately persist in many - parts of the Internet. To make correct systems coexist with - these faulty systems, administrators often have to "mis- - configure" the correct systems. This problem will correct - itself gradually as the faulty systems are retired, but it - cannot be ignored by vendors. - - When we say that a parameter must be configurable, we do not - intend to require that its value be explicitly read from a - configuration file at every boot time. We recommend that - implementors set up a default for each parameter, so a - configuration file is only necessary to override those defaults - that are inappropriate in a particular installation. Thus, the - configurability requirement is an assurance that it will be - POSSIBLE to override the default when necessary, even in a - binary-only or ROM-based product. - - This document requires a particular value for such defaults in - some cases. The choice of default is a sensitive issue when - the configuration item controls the accommodation to existing - faulty systems. If the Internet is to converge successfully to - complete interoperability, the default values built into - implementations must implement the official protocol, not - "mis-configurations" to accommodate faulty implementations. - Although marketing considerations have led some vendors to - choose mis-configuration defaults, we urge vendors to choose - defaults that will conform to the standard. - - Finally, we note that a vendor needs to provide adequate - - - -Internet Engineering Task Force [Page 9] - - - - -RFC1123 INTRODUCTION October 1989 - - - documentation on all configuration parameters, their limits and - effects. - - - 1.3 Reading this Document - - 1.3.1 Organization - - In general, each major section is organized into the following - subsections: - - (1) Introduction - - (2) Protocol Walk-Through -- considers the protocol - specification documents section-by-section, correcting - errors, stating requirements that may be ambiguous or - ill-defined, and providing further clarification or - explanation. - - (3) Specific Issues -- discusses protocol design and - implementation issues that were not included in the walk- - through. - - (4) Interfaces -- discusses the service interface to the next - higher layer. - - (5) Summary -- contains a summary of the requirements of the - section. - - Under many of the individual topics in this document, there is - parenthetical material labeled "DISCUSSION" or - "IMPLEMENTATION". This material is intended to give - clarification and explanation of the preceding requirements - text. It also includes some suggestions on possible future - directions or developments. The implementation material - contains suggested approaches that an implementor may want to - consider. - - The summary sections are intended to be guides and indexes to - the text, but are necessarily cryptic and incomplete. The - summaries should never be used or referenced separately from - the complete RFC. - - 1.3.2 Requirements - - In this document, the words that are used to define the - significance of each particular requirement are capitalized. - These words are: - - - -Internet Engineering Task Force [Page 10] - - - - -RFC1123 INTRODUCTION October 1989 - - - * "MUST" - - This word or the adjective "REQUIRED" means that the item - is an absolute requirement of the specification. - - * "SHOULD" - - This word or the adjective "RECOMMENDED" means that there - may exist valid reasons in particular circumstances to - ignore this item, but the full implications should be - understood and the case carefully weighed before choosing - a different course. - - * "MAY" - - This word or the adjective "OPTIONAL" means that this item - is truly optional. One vendor may choose to include the - item because a particular marketplace requires it or - because it enhances the product, for example; another - vendor may omit the same item. - - - An implementation is not compliant if it fails to satisfy one - or more of the MUST requirements for the protocols it - implements. An implementation that satisfies all the MUST and - all the SHOULD requirements for its protocols is said to be - "unconditionally compliant"; one that satisfies all the MUST - requirements but not all the SHOULD requirements for its - protocols is said to be "conditionally compliant". - - 1.3.3 Terminology - - This document uses the following technical terms: - - Segment - A segment is the unit of end-to-end transmission in the - TCP protocol. A segment consists of a TCP header followed - by application data. A segment is transmitted by - encapsulation in an IP datagram. - - Message - This term is used by some application layer protocols - (particularly SMTP) for an application data unit. - - Datagram - A [UDP] datagram is the unit of end-to-end transmission in - the UDP protocol. - - - - -Internet Engineering Task Force [Page 11] - - - - -RFC1123 INTRODUCTION October 1989 - - - Multihomed - A host is said to be multihomed if it has multiple IP - addresses to connected networks. - - - - 1.4 Acknowledgments - - This document incorporates contributions and comments from a large - group of Internet protocol experts, including representatives of - university and research labs, vendors, and government agencies. - It was assembled primarily by the Host Requirements Working Group - of the Internet Engineering Task Force (IETF). - - The Editor would especially like to acknowledge the tireless - dedication of the following people, who attended many long - meetings and generated 3 million bytes of electronic mail over the - past 18 months in pursuit of this document: Philip Almquist, Dave - Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve - Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), - John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), - Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge - (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). - - In addition, the following people made major contributions to the - effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia - (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), - Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), - John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill - Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul - (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue - Technology), and Mike StJohns (DCA). The following also made - significant contributions to particular areas: Eric Allman - (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic - (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn - (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann - (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun - Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen - (Toronto). - - We are grateful to all, including any contributors who may have - been inadvertently omitted from this list. - - - - - - - - - -Internet Engineering Task Force [Page 12] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - -2. GENERAL ISSUES - - This section contains general requirements that may be applicable to - all application-layer protocols. - - 2.1 Host Names and Numbers - - The syntax of a legal Internet host name was specified in RFC-952 - [DNS:4]. One aspect of host name syntax is hereby changed: the - restriction on the first character is relaxed to allow either a - letter or a digit. Host software MUST support this more liberal - syntax. - - Host software MUST handle host names of up to 63 characters and - SHOULD handle host names of up to 255 characters. - - Whenever a user inputs the identity of an Internet host, it SHOULD - be possible to enter either (1) a host domain name or (2) an IP - address in dotted-decimal ("#.#.#.#") form. The host SHOULD check - the string syntactically for a dotted-decimal number before - looking it up in the Domain Name System. - - DISCUSSION: - This last requirement is not intended to specify the complete - syntactic form for entering a dotted-decimal host number; - that is considered to be a user-interface issue. For - example, a dotted-decimal number must be enclosed within - "[ ]" brackets for SMTP mail (see Section 5.2.17). This - notation could be made universal within a host system, - simplifying the syntactic checking for a dotted-decimal - number. - - If a dotted-decimal number can be entered without such - identifying delimiters, then a full syntactic check must be - made, because a segment of a host domain name is now allowed - to begin with a digit and could legally be entirely numeric - (see Section 6.1.2.4). However, a valid host name can never - have the dotted-decimal form #.#.#.#, since at least the - highest-level component label will be alphabetic. - - 2.2 Using Domain Name Service - - Host domain names MUST be translated to IP addresses as described - in Section 6.1. - - Applications using domain name services MUST be able to cope with - soft error conditions. Applications MUST wait a reasonable - interval between successive retries due to a soft error, and MUST - - - -Internet Engineering Task Force [Page 13] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - - allow for the possibility that network problems may deny service - for hours or even days. - - An application SHOULD NOT rely on the ability to locate a WKS - record containing an accurate listing of all services at a - particular host address, since the WKS RR type is not often used - by Internet sites. To confirm that a service is present, simply - attempt to use it. - - 2.3 Applications on Multihomed hosts - - When the remote host is multihomed, the name-to-address - translation will return a list of alternative IP addresses. As - specified in Section 6.1.3.4, this list should be in order of - decreasing preference. Application protocol implementations - SHOULD be prepared to try multiple addresses from the list until - success is obtained. More specific requirements for SMTP are - given in Section 5.3.4. - - When the local host is multihomed, a UDP-based request/response - application SHOULD send the response with an IP source address - that is the same as the specific destination address of the UDP - request datagram. The "specific destination address" is defined - in the "IP Addressing" section of the companion RFC [INTRO:1]. - - Similarly, a server application that opens multiple TCP - connections to the same client SHOULD use the same local IP - address for all. - - 2.4 Type-of-Service - - Applications MUST select appropriate TOS values when they invoke - transport layer services, and these values MUST be configurable. - Note that a TOS value contains 5 bits, of which only the most- - significant 3 bits are currently defined; the other two bits MUST - be zero. - - DISCUSSION: - As gateway algorithms are developed to implement Type-of- - Service, the recommended values for various application - protocols may change. In addition, it is likely that - particular combinations of users and Internet paths will want - non-standard TOS values. For these reasons, the TOS values - must be configurable. - - See the latest version of the "Assigned Numbers" RFC - [INTRO:5] for the recommended TOS values for the major - application protocols. - - - -Internet Engineering Task Force [Page 14] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - - 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -User interfaces: | | | | | | | - Allow host name to begin with digit |2.1 |x| | | | | - Host names of up to 635 characters |2.1 |x| | | | | - Host names of up to 255 characters |2.1 | |x| | | | - Support dotted-decimal host numbers |2.1 | |x| | | | - Check syntactically for dotted-dec first |2.1 | |x| | | | - | | | | | | | -Map domain names per Section 6.1 |2.2 |x| | | | | -Cope with soft DNS errors |2.2 |x| | | | | - Reasonable interval between retries |2.2 |x| | | | | - Allow for long outages |2.2 |x| | | | | -Expect WKS records to be available |2.2 | | | |x| | - | | | | | | | -Try multiple addr's for remote multihomed host |2.3 | |x| | | | -UDP reply src addr is specific dest of request |2.3 | |x| | | | -Use same IP addr for related TCP connections |2.3 | |x| | | | -Specify appropriate TOS values |2.4 |x| | | | | - TOS values configurable |2.4 |x| | | | | - Unused TOS bits zero |2.4 |x| | | | | - | | | | | | | - | | | | | | | - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 15] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - -3. REMOTE LOGIN -- TELNET PROTOCOL - - 3.1 INTRODUCTION - - Telnet is the standard Internet application protocol for remote - login. It provides the encoding rules to link a user's - keyboard/display on a client ("user") system with a command - interpreter on a remote server system. A subset of the Telnet - protocol is also incorporated within other application protocols, - e.g., FTP and SMTP. - - Telnet uses a single TCP connection, and its normal data stream - ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with - escape sequences to embed control functions. Telnet also allows - the negotiation of many optional modes and functions. - - The primary Telnet specification is to be found in RFC-854 - [TELNET:1], while the options are defined in many other RFCs; see - Section 7 for references. - - 3.2 PROTOCOL WALK-THROUGH - - 3.2.1 Option Negotiation: RFC-854, pp. 2-3 - - Every Telnet implementation MUST include option negotiation and - subnegotiation machinery [TELNET:2]. - - A host MUST carefully follow the rules of RFC-854 to avoid - option-negotiation loops. A host MUST refuse (i.e, reply - WONT/DONT to a DO/WILL) an unsupported option. Option - negotiation SHOULD continue to function (even if all requests - are refused) throughout the lifetime of a Telnet connection. - - If all option negotiations fail, a Telnet implementation MUST - default to, and support, an NVT. - - DISCUSSION: - Even though more sophisticated "terminals" and supporting - option negotiations are becoming the norm, all - implementations must be prepared to support an NVT for any - user-server communication. - - 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 - - On a host that never sends the Telnet command Go Ahead (GA), - the Telnet Server MUST attempt to negotiate the Suppress Go - Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or - Server Telnet MUST always accept negotiation of the Suppress Go - - - -Internet Engineering Task Force [Page 16] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Ahead option. - - When it is driving a full-duplex terminal for which GA has no - meaning, a User Telnet implementation MAY ignore GA commands. - - DISCUSSION: - Half-duplex ("locked-keyboard") line-at-a-time terminals - for which the Go-Ahead mechanism was designed have largely - disappeared from the scene. It turned out to be difficult - to implement sending the Go-Ahead signal in many operating - systems, even some systems that support native half-duplex - terminals. The difficulty is typically that the Telnet - server code does not have access to information about - whether the user process is blocked awaiting input from - the Telnet connection, i.e., it cannot reliably determine - when to send a GA command. Therefore, most Telnet Server - hosts do not send GA commands. - - The effect of the rules in this section is to allow either - end of a Telnet connection to veto the use of GA commands. - - There is a class of half-duplex terminals that is still - commercially important: "data entry terminals," which - interact in a full-screen manner. However, supporting - data entry terminals using the Telnet protocol does not - require the Go Ahead signal; see Section 3.3.2. - - 3.2.3 Control Functions: RFC-854, pp. 7-8 - - The list of Telnet commands has been extended to include EOR - (End-of-Record), with code 239 [TELNET:9]. - - Both User and Server Telnets MAY support the control functions - EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP, - SB, and SE. - - A host MUST be able to receive and ignore any Telnet control - functions that it does not support. - - DISCUSSION: - Note that a Server Telnet is required to support the - Telnet IP (Interrupt Process) function, even if the server - host has an equivalent in-stream function (e.g., Control-C - in many systems). The Telnet IP function may be stronger - than an in-stream interrupt command, because of the out- - of-band effect of TCP urgent data. - - The EOR control function may be used to delimit the - - - -Internet Engineering Task Force [Page 17] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - stream. An important application is data entry terminal - support (see Section 3.3.2). There was concern that since - EOR had not been defined in RFC-854, a host that was not - prepared to correctly ignore unknown Telnet commands might - crash if it received an EOR. To protect such hosts, the - End-of-Record option [TELNET:9] was introduced; however, a - properly implemented Telnet program will not require this - protection. - - 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10 - - When it receives "urgent" TCP data, a User or Server Telnet - MUST discard all data except Telnet commands until the DM (and - end of urgent) is reached. - - When it sends Telnet IP (Interrupt Process), a User Telnet - SHOULD follow it by the Telnet "Synch" sequence, i.e., send as - TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent - pointer points to the DM octet. - - When it receives a Telnet IP command, a Server Telnet MAY send - a Telnet "Synch" sequence back to the user, to flush the output - stream. The choice ought to be consistent with the way the - server operating system behaves when a local user interrupts a - process. - - When it receives a Telnet AO command, a Server Telnet MUST send - a Telnet "Synch" sequence back to the user, to flush the output - stream. - - A User Telnet SHOULD have the capability of flushing output - when it sends a Telnet IP; see also Section 3.4.5. - - DISCUSSION: - There are three possible ways for a User Telnet to flush - the stream of server output data: - - (1) Send AO after IP. - - This will cause the server host to send a "flush- - buffered-output" signal to its operating system. - However, the AO may not take effect locally, i.e., - stop terminal output at the User Telnet end, until - the Server Telnet has received and processed the AO - and has sent back a "Synch". - - (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard - all output locally until a WILL/WONT TIMING-MARK is - - - -Internet Engineering Task Force [Page 18] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - received from the Server Telnet. - - Since the DO TIMING-MARK will be processed after the - IP at the server, the reply to it should be in the - right place in the output data stream. However, the - TIMING-MARK will not send a "flush buffered output" - signal to the server operating system. Whether or - not this is needed is dependent upon the server - system. - - (3) Do both. - - The best method is not entirely clear, since it must - accommodate a number of existing server hosts that do not - follow the Telnet standards in various ways. The safest - approach is probably to provide a user-controllable option - to select (1), (2), or (3). - - 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11 - - In NVT mode, a Telnet SHOULD NOT send characters with the - high-order bit 1, and MUST NOT send it as a parity bit. - Implementations that pass the high-order bit to applications - SHOULD negotiate binary mode (see Section 3.2.6). - - - DISCUSSION: - Implementors should be aware that a strict reading of - RFC-854 allows a client or server expecting NVT ASCII to - ignore characters with the high-order bit set. In - general, binary mode is expected to be used for - transmission of an extended (beyond 7-bit) character set - with Telnet. - - However, there exist applications that really need an 8- - bit NVT mode, which is currently not defined, and these - existing applications do set the high-order bit during - part or all of the life of a Telnet connection. Note that - binary mode is not the same as 8-bit NVT mode, since - binary mode turns off end-of-line processing. For this - reason, the requirements on the high-order bit are stated - as SHOULD, not MUST. - - RFC-854 defines a minimal set of properties of a "network - virtual terminal" or NVT; this is not meant to preclude - additional features in a real terminal. A Telnet - connection is fully transparent to all 7-bit ASCII - characters, including arbitrary ASCII control characters. - - - -Internet Engineering Task Force [Page 19] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - For example, a terminal might support full-screen commands - coded as ASCII escape sequences; a Telnet implementation - would pass these sequences as uninterpreted data. Thus, - an NVT should not be conceived as a terminal type of a - highly-restricted device. - - 3.2.6 Telnet Command Structure: RFC-854, p. 13 - - Since options may appear at any point in the data stream, a - Telnet escape character (known as IAC, with the value 255) to - be sent as data MUST be doubled. - - 3.2.7 Telnet Binary Option: RFC-856 - - When the Binary option has been successfully negotiated, - arbitrary 8-bit characters are allowed. However, the data - stream MUST still be scanned for IAC characters, any embedded - Telnet commands MUST be obeyed, and data bytes equal to IAC - MUST be doubled. Other character processing (e.g., replacing - CR by CR NUL or by CR LF) MUST NOT be done. In particular, - there is no end-of-line convention (see Section 3.3.1) in - binary mode. - - DISCUSSION: - The Binary option is normally negotiated in both - directions, to change the Telnet connection from NVT mode - to "binary mode". - - The sequence IAC EOR can be used to delimit blocks of data - within a binary-mode Telnet stream. - - 3.2.8 Telnet Terminal-Type Option: RFC-1091 - - The Terminal-Type option MUST use the terminal type names - officially defined in the Assigned Numbers RFC [INTRO:5], when - they are available for the particular terminal. However, the - receiver of a Terminal-Type option MUST accept any name. - - DISCUSSION: - RFC-1091 [TELNET:10] updates an earlier version of the - Terminal-Type option defined in RFC-930. The earlier - version allowed a server host capable of supporting - multiple terminal types to learn the type of a particular - client's terminal, assuming that each physical terminal - had an intrinsic type. However, today a "terminal" is - often really a terminal emulator program running in a PC, - perhaps capable of emulating a range of terminal types. - Therefore, RFC-1091 extends the specification to allow a - - - -Internet Engineering Task Force [Page 20] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - more general terminal-type negotiation between User and - Server Telnets. - - 3.3 SPECIFIC ISSUES - - 3.3.1 Telnet End-of-Line Convention - - The Telnet protocol defines the sequence CR LF to mean "end- - of-line". For terminal input, this corresponds to a command- - completion or "end-of-line" key being pressed on a user - terminal; on an ASCII terminal, this is the CR key, but it may - also be labelled "Return" or "Enter". - - When a Server Telnet receives the Telnet end-of-line sequence - CR LF as input from a remote terminal, the effect MUST be the - same as if the user had pressed the "end-of-line" key on a - local terminal. On server hosts that use ASCII, in particular, - receipt of the Telnet sequence CR LF must cause the same effect - as a local user pressing the CR key on a local terminal. Thus, - CR LF and CR NUL MUST have the same effect on an ASCII server - host when received as input over a Telnet connection. - - A User Telnet MUST be able to send any of the forms: CR LF, CR - NUL, and LF. A User Telnet on an ASCII host SHOULD have a - user-controllable mode to send either CR LF or CR NUL when the - user presses the "end-of-line" key, and CR LF SHOULD be the - default. - - The Telnet end-of-line sequence CR LF MUST be used to send - Telnet data that is not terminal-to-computer (e.g., for Server - Telnet sending output, or the Telnet protocol incorporated - another application protocol). - - DISCUSSION: - To allow interoperability between arbitrary Telnet clients - and servers, the Telnet protocol defined a standard - representation for a line terminator. Since the ASCII - character set includes no explicit end-of-line character, - systems have chosen various representations, e.g., CR, LF, - and the sequence CR LF. The Telnet protocol chose the CR - LF sequence as the standard for network transmission. - - Unfortunately, the Telnet protocol specification in RFC- - 854 [TELNET:1] has turned out to be somewhat ambiguous on - what character(s) should be sent from client to server for - the "end-of-line" key. The result has been a massive and - continuing interoperability headache, made worse by - various faulty implementations of both User and Server - - - -Internet Engineering Task Force [Page 21] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Telnets. - - Although the Telnet protocol is based on a perfectly - symmetric model, in a remote login session the role of the - user at a terminal differs from the role of the server - host. For example, RFC-854 defines the meaning of CR, LF, - and CR LF as output from the server, but does not specify - what the User Telnet should send when the user presses the - "end-of-line" key on the terminal; this turns out to be - the point at issue. - - When a user presses the "end-of-line" key, some User - Telnet implementations send CR LF, while others send CR - NUL (based on a different interpretation of the same - sentence in RFC-854). These will be equivalent for a - correctly-implemented ASCII server host, as discussed - above. For other servers, a mode in the User Telnet is - needed. - - The existence of User Telnets that send only CR NUL when - CR is pressed creates a dilemma for non-ASCII hosts: they - can either treat CR NUL as equivalent to CR LF in input, - thus precluding the possibility of entering a "bare" CR, - or else lose complete interworking. - - Suppose a user on host A uses Telnet to log into a server - host B, and then execute B's User Telnet program to log - into server host C. It is desirable for the Server/User - Telnet combination on B to be as transparent as possible, - i.e., to appear as if A were connected directly to C. In - particular, correct implementation will make B transparent - to Telnet end-of-line sequences, except that CR LF may be - translated to CR NUL or vice versa. - - IMPLEMENTATION: - To understand Telnet end-of-line issues, one must have at - least a general model of the relationship of Telnet to the - local operating system. The Server Telnet process is - typically coupled into the terminal driver software of the - operating system as a pseudo-terminal. A Telnet end-of- - line sequence received by the Server Telnet must have the - same effect as pressing the end-of-line key on a real - locally-connected terminal. - - Operating systems that support interactive character-at- - a-time applications (e.g., editors) typically have two - internal modes for their terminal I/O: a formatted mode, - in which local conventions for end-of-line and other - - - -Internet Engineering Task Force [Page 22] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - formatting rules have been applied to the data stream, and - a "raw" mode, in which the application has direct access - to every character as it was entered. A Server Telnet - must be implemented in such a way that these modes have - the same effect for remote as for local terminals. For - example, suppose a CR LF or CR NUL is received by the - Server Telnet on an ASCII host. In raw mode, a CR - character is passed to the application; in formatted mode, - the local system's end-of-line convention is used. - - 3.3.2 Data Entry Terminals - - DISCUSSION: - In addition to the line-oriented and character-oriented - ASCII terminals for which Telnet was designed, there are - several families of video display terminals that are - sometimes known as "data entry terminals" or DETs. The - IBM 3270 family is a well-known example. - - Two Internet protocols have been designed to support - generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET - option [TELNET:18, TELNET:19]. The DET option drives a - data entry terminal over a Telnet connection using (sub-) - negotiation. SUPDUP is a completely separate terminal - protocol, which can be entered from Telnet by negotiation. - Although both SUPDUP and the DET option have been used - successfully in particular environments, neither has - gained general acceptance or wide implementation. - - A different approach to DET interaction has been developed - for supporting the IBM 3270 family through Telnet, - although the same approach would be applicable to any DET. - The idea is to enter a "native DET" mode, in which the - native DET input/output stream is sent as binary data. - The Telnet EOR command is used to delimit logical records - (e.g., "screens") within this binary stream. - - IMPLEMENTATION: - The rules for entering and leaving native DET mode are as - follows: - - o The Server uses the Terminal-Type option [TELNET:10] - to learn that the client is a DET. - - o It is conventional, but not required, that both ends - negotiate the EOR option [TELNET:9]. - - o Both ends negotiate the Binary option [TELNET:3] to - - - -Internet Engineering Task Force [Page 23] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - enter native DET mode. - - o When either end negotiates out of binary mode, the - other end does too, and the mode then reverts to - normal NVT. - - - 3.3.3 Option Requirements - - Every Telnet implementation MUST support the Binary option - [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and - SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of- - Record [TELNET:9], and Extended Options List [TELNET:8] - options. - - A User or Server Telnet SHOULD support the Window Size Option - [TELNET:12] if the local operating system provides the - corresponding capability. - - DISCUSSION: - Note that the End-of-Record option only signifies that a - Telnet can receive a Telnet EOR without crashing; - therefore, every Telnet ought to be willing to accept - negotiation of the End-of-Record option. See also the - discussion in Section 3.2.3. - - 3.3.4 Option Initiation - - When the Telnet protocol is used in a client/server situation, - the server SHOULD initiate negotiation of the terminal - interaction mode it expects. - - DISCUSSION: - The Telnet protocol was defined to be perfectly - symmetrical, but its application is generally asymmetric. - Remote login has been known to fail because NEITHER side - initiated negotiation of the required non-default terminal - modes. It is generally the server that determines the - preferred mode, so the server needs to initiate the - negotiation; since the negotiation is symmetric, the user - can also initiate it. - - A client (User Telnet) SHOULD provide a means for users to - enable and disable the initiation of option negotiation. - - DISCUSSION: - A user sometimes needs to connect to an application - service (e.g., FTP or SMTP) that uses Telnet for its - - - -Internet Engineering Task Force [Page 24] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - control stream but does not support Telnet options. User - Telnet may be used for this purpose if initiation of - option negotiation is disabled. - - 3.3.5 Telnet Linemode Option - - DISCUSSION: - An important new Telnet option, LINEMODE [TELNET:12], has - been proposed. The LINEMODE option provides a standard - way for a User Telnet and a Server Telnet to agree that - the client rather than the server will perform terminal - character processing. When the client has prepared a - complete line of text, it will send it to the server in - (usually) one TCP packet. This option will greatly - decrease the packet cost of Telnet sessions and will also - give much better user response over congested or long- - delay networks. - - The LINEMODE option allows dynamic switching between local - and remote character processing. For example, the Telnet - connection will automatically negotiate into single- - character mode while a full screen editor is running, and - then return to linemode when the editor is finished. - - We expect that when this RFC is released, hosts should - implement the client side of this option, and may - implement the server side of this option. To properly - implement the server side, the server needs to be able to - tell the local system not to do any input character - processing, but to remember its current terminal state and - notify the Server Telnet process whenever the state - changes. This will allow password echoing and full screen - editors to be handled properly, for example. - - 3.4 TELNET/USER INTERFACE - - 3.4.1 Character Set Transparency - - User Telnet implementations SHOULD be able to send or receive - any 7-bit ASCII character. Where possible, any special - character interpretations by the user host's operating system - SHOULD be bypassed so that these characters can conveniently be - sent and received on the connection. - - Some character value MUST be reserved as "escape to command - mode"; conventionally, doubling this character allows it to be - entered as data. The specific character used SHOULD be user - selectable. - - - -Internet Engineering Task Force [Page 25] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - On binary-mode connections, a User Telnet program MAY provide - an escape mechanism for entering arbitrary 8-bit values, if the - host operating system doesn't allow them to be entered directly - from the keyboard. - - IMPLEMENTATION: - The transparency issues are less pressing on servers, but - implementors should take care in dealing with issues like: - masking off parity bits (sent by an older, non-conforming - client) before they reach programs that expect only NVT - ASCII, and properly handling programs that request 8-bit - data streams. - - 3.4.2 Telnet Commands - - A User Telnet program MUST provide a user the capability of - entering any of the Telnet control functions IP, AO, or AYT, - and SHOULD provide the capability of entering EC, EL, and - Break. - - 3.4.3 TCP Connection Errors - - A User Telnet program SHOULD report to the user any TCP errors - that are reported by the transport layer (see "TCP/Application - Layer Interface" section in [INTRO:1]). - - 3.4.4 Non-Default Telnet Contact Port - - A User Telnet program SHOULD allow the user to optionally - specify a non-standard contact port number at the Server Telnet - host. - - 3.4.5 Flushing Output - - A User Telnet program SHOULD provide the user the ability to - specify whether or not output should be flushed when an IP is - sent; see Section 3.2.4. - - For any output flushing scheme that causes the User Telnet to - flush output locally until a Telnet signal is received from the - Server, there SHOULD be a way for the user to manually restore - normal output, in case the Server fails to send the expected - signal. - - - - - - - - -Internet Engineering Task Force [Page 26] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - 3.5. TELNET REQUIREMENTS SUMMARY - - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- - | | | | | | | -Option Negotiation |3.2.1 |x| | | | | - Avoid negotiation loops |3.2.1 |x| | | | | - Refuse unsupported options |3.2.1 |x| | | | | - Negotiation OK anytime on connection |3.2.1 | |x| | | | - Default to NVT |3.2.1 |x| | | | | - Send official name in Term-Type option |3.2.8 |x| | | | | - Accept any name in Term-Type option |3.2.8 |x| | | | | - Implement Binary, Suppress-GA options |3.3.3 |x| | | | | - Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | | - Implement Window-Size option if appropriate |3.3.3 | |x| | | | - Server initiate mode negotiations |3.3.4 | |x| | | | - User can enable/disable init negotiations |3.3.4 | |x| | | | - | | | | | | | -Go-Aheads | | | | | | | - Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | | - User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | | - User Telnet ignore GA's |3.2.2 | | |x| | | - | | | | | | | -Control Functions | | | | | | | - Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | | - Support EOR EC EL Break |3.2.3 | | |x| | | - Ignore unsupported control functions |3.2.3 |x| | | | | - User, Server discard urgent data up to DM |3.2.4 |x| | | | | - User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | | - Server Telnet reply Synch to IP |3.2.4 | | |x| | | - Server Telnet reply Synch to AO |3.2.4 |x| | | | | - User Telnet can flush output when send IP |3.2.4 | |x| | | | - | | | | | | | -Encoding | | | | | | | - Send high-order bit in NVT mode |3.2.5 | | | |x| | - Send high-order bit as parity bit |3.2.5 | | | | |x| - Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | | - Always double IAC data byte |3.2.6 |x| | | | | - - - -Internet Engineering Task Force [Page 27] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Double IAC data byte in binary mode |3.2.7 |x| | | | | - Obey Telnet cmds in binary mode |3.2.7 |x| | | | | - End-of-line, CR NUL in binary mode |3.2.7 | | | | |x| - | | | | | | | -End-of-Line | | | | | | | - EOL at Server same as local end-of-line |3.3.1 |x| | | | | - ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | | - User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | | - ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | | - User Telnet default mode is CR LF |3.3.1 | |x| | | | - Non-interactive uses CR LF for EOL |3.3.1 |x| | | | | - | | | | | | | -User Telnet interface | | | | | | | - Input & output all 7-bit characters |3.4.1 | |x| | | | - Bypass local op sys interpretation |3.4.1 | |x| | | | - Escape character |3.4.1 |x| | | | | - User-settable escape character |3.4.1 | |x| | | | - Escape to enter 8-bit values |3.4.1 | | |x| | | - Can input IP, AO, AYT |3.4.2 |x| | | | | - Can input EC, EL, Break |3.4.2 | |x| | | | - Report TCP connection errors to user |3.4.3 | |x| | | | - Optional non-default contact port |3.4.4 | |x| | | | - Can spec: output flushed when IP sent |3.4.5 | |x| | | | - Can manually restore output mode |3.4.5 | |x| | | | - | | | | | | | - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 28] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - -4. FILE TRANSFER - - 4.1 FILE TRANSFER PROTOCOL -- FTP - - 4.1.1 INTRODUCTION - - The File Transfer Protocol FTP is the primary Internet standard - for file transfer. The current specification is contained in - RFC-959 [FTP:1]. - - FTP uses separate simultaneous TCP connections for control and - for data transfer. The FTP protocol includes many features, - some of which are not commonly implemented. However, for every - feature in FTP, there exists at least one implementation. The - minimum implementation defined in RFC-959 was too small, so a - somewhat larger minimum implementation is defined here. - - Internet users have been unnecessarily burdened for years by - deficient FTP implementations. Protocol implementors have - suffered from the erroneous opinion that implementing FTP ought - to be a small and trivial task. This is wrong, because FTP has - a user interface, because it has to deal (correctly) with the - whole variety of communication and operating system errors that - may occur, and because it has to handle the great diversity of - real file systems in the world. - - 4.1.2. PROTOCOL WALK-THROUGH - - 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4 - - An FTP program MUST support TYPE I ("IMAGE" or binary type) - as well as TYPE L 8 ("LOCAL" type with logical byte size 8). - A machine whose memory is organized into m-bit words, where - m is not a multiple of 8, MAY also support TYPE L m. - - DISCUSSION: - The command "TYPE L 8" is often required to transfer - binary data between a machine whose memory is organized - into (e.g.) 36-bit words and a machine with an 8-bit - byte organization. For an 8-bit byte machine, TYPE L 8 - is equivalent to IMAGE. - - "TYPE L m" is sometimes specified to the FTP programs - on two m-bit word machines to ensure the correct - transfer of a native-mode binary file from one machine - to the other. However, this command should have the - same effect on these machines as "TYPE I". - - - - -Internet Engineering Task Force [Page 29] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2 - - A host that makes no distinction between TYPE N and TYPE T - SHOULD implement TYPE T to be identical to TYPE N. - - DISCUSSION: - This provision should ease interoperation with hosts - that do make this distinction. - - Many hosts represent text files internally as strings - of ASCII characters, using the embedded ASCII format - effector characters (LF, BS, FF, ...) to control the - format when a file is printed. For such hosts, there - is no distinction between "print" files and other - files. However, systems that use record structured - files typically need a special format for printable - files (e.g., ASA carriage control). For the latter - hosts, FTP allows a choice of TYPE N or TYPE T. - - 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I - - Implementation of page structure is NOT RECOMMENDED in - general. However, if a host system does need to implement - FTP for "random access" or "holey" files, it MUST use the - defined page structure format rather than define a new - private FTP format. - - 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2 - - An FTP transformation between record-structure and file- - structure SHOULD be invertible, to the extent possible while - making the result useful on the target host. - - DISCUSSION: - RFC-959 required strict invertibility between record- - structure and file-structure, but in practice, - efficiency and convenience often preclude it. - Therefore, the requirement is being relaxed. There are - two different objectives for transferring a file: - processing it on the target host, or just storage. For - storage, strict invertibility is important. For - processing, the file created on the target host needs - to be in the format expected by application programs on - that host. - - As an example of the conflict, imagine a record- - oriented operating system that requires some data files - to have exactly 80 bytes in each record. While STORing - - - -Internet Engineering Task Force [Page 30] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - a file on such a host, an FTP Server must be able to - pad each line or record to 80 bytes; a later retrieval - of such a file cannot be strictly invertible. - - 4.1.2.5 Data Connection Management: RFC-959 Section 3.3 - - A User-FTP that uses STREAM mode SHOULD send a PORT command - to assign a non-default data port before each transfer - command is issued. - - DISCUSSION: - This is required because of the long delay after a TCP - connection is closed until its socket pair can be - reused, to allow multiple transfers during a single FTP - session. Sending a port command can avoided if a - transfer mode other than stream is used, by leaving the - data transfer connection open between transfers. - - 4.1.2.6 PASV Command: RFC-959 Section 4.1.2 - - A server-FTP MUST implement the PASV command. - - If multiple third-party transfers are to be executed during - the same session, a new PASV command MUST be issued before - each transfer command, to obtain a unique port pair. - - IMPLEMENTATION: - The format of the 227 reply to a PASV command is not - well standardized. In particular, an FTP client cannot - assume that the parentheses shown on page 40 of RFC-959 - will be present (and in fact, Figure 3 on page 43 omits - them). Therefore, a User-FTP program that interprets - the PASV reply must scan the reply for the first digit - of the host and port numbers. - - Note that the host number h1,h2,h3,h4 is the IP address - of the server host that is sending the reply, and that - p1,p2 is a non-default data transfer port that PASV has - assigned. - - 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3 - - The data returned by an NLST command MUST contain only a - simple list of legal pathnames, such that the server can use - them directly as the arguments of subsequent data transfer - commands for the individual files. - - The data returned by a LIST or NLST command SHOULD use an - - - -Internet Engineering Task Force [Page 31] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - implied TYPE AN, unless the current type is EBCDIC, in which - case an implied TYPE EN SHOULD be used. - - DISCUSSION: - Many FTP clients support macro-commands that will get - or put files matching a wildcard specification, using - NLST to obtain a list of pathnames. The expansion of - "multiple-put" is local to the client, but "multiple- - get" requires cooperation by the server. - - The implied type for LIST and NLST is designed to - provide compatibility with existing User-FTPs, and in - particular with multiple-get commands. - - 4.1.2.8 SITE Command: RFC-959 Section 4.1.3 - - A Server-FTP SHOULD use the SITE command for non-standard - features, rather than invent new private commands or - unstandardized extensions to existing commands. - - 4.1.2.9 STOU Command: RFC-959 Section 4.1.3 - - The STOU command stores into a uniquely named file. When it - receives an STOU command, a Server-FTP MUST return the - actual file name in the "125 Transfer Starting" or the "150 - Opening Data Connection" message that precedes the transfer - (the 250 reply code mentioned in RFC-959 is incorrect). The - exact format of these messages is hereby defined to be as - follows: - - 125 FILE: pppp - 150 FILE: pppp - - where pppp represents the unique pathname of the file that - will be written. - - 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34 - - Implementors MUST NOT assume any correspondence between READ - boundaries on the control connection and the Telnet EOL - sequences (CR LF). - - DISCUSSION: - Thus, a server-FTP (or User-FTP) must continue reading - characters from the control connection until a complete - Telnet EOL sequence is encountered, before processing - the command (or response, respectively). Conversely, a - single READ from the control connection may include - - - -Internet Engineering Task Force [Page 32] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - more than one FTP command. - - 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35 - - A Server-FTP MUST send only correctly formatted replies on - the control connection. Note that RFC-959 (unlike earlier - versions of the FTP spec) contains no provision for a - "spontaneous" reply message. - - A Server-FTP SHOULD use the reply codes defined in RFC-959 - whenever they apply. However, a server-FTP MAY use a - different reply code when needed, as long as the general - rules of Section 4.2 are followed. When the implementor has - a choice between a 4xx and 5xx reply code, a Server-FTP - SHOULD send a 4xx (temporary failure) code when there is any - reasonable possibility that a failed FTP will succeed a few - hours later. - - A User-FTP SHOULD generally use only the highest-order digit - of a 3-digit reply code for making a procedural decision, to - prevent difficulties when a Server-FTP uses non-standard - reply codes. - - A User-FTP MUST be able to handle multi-line replies. If - the implementation imposes a limit on the number of lines - and if this limit is exceeded, the User-FTP MUST recover, - e.g., by ignoring the excess lines until the end of the - multi-line reply is reached. - - A User-FTP SHOULD NOT interpret a 421 reply code ("Service - not available, closing control connection") specially, but - SHOULD detect closing of the control connection by the - server. - - DISCUSSION: - Server implementations that fail to strictly follow the - reply rules often cause FTP user programs to hang. - Note that RFC-959 resolved ambiguities in the reply - rules found in earlier FTP specifications and must be - followed. - - It is important to choose FTP reply codes that properly - distinguish between temporary and permanent failures, - to allow the successful use of file transfer client - daemons. These programs depend on the reply codes to - decide whether or not to retry a failed transfer; using - a permanent failure code (5xx) for a temporary error - will cause these programs to give up unnecessarily. - - - -Internet Engineering Task Force [Page 33] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - When the meaning of a reply matches exactly the text - shown in RFC-959, uniformity will be enhanced by using - the RFC-959 text verbatim. However, a Server-FTP - implementor is encouraged to choose reply text that - conveys specific system-dependent information, when - appropriate. - - 4.1.2.12 Connections: RFC-959 Section 5.2 - - The words "and the port used" in the second paragraph of - this section of RFC-959 are erroneous (historical), and they - should be ignored. - - On a multihomed server host, the default data transfer port - (L-1) MUST be associated with the same local IP address as - the corresponding control connection to port L. - - A user-FTP MUST NOT send any Telnet controls other than - SYNCH and IP on an FTP control connection. In particular, it - MUST NOT attempt to negotiate Telnet options on the control - connection. However, a server-FTP MUST be capable of - accepting and refusing Telnet negotiations (i.e., sending - DONT/WONT). - - DISCUSSION: - Although the RFC says: "Server- and User- processes - should follow the conventions for the Telnet - protocol...[on the control connection]", it is not the - intent that Telnet option negotiation is to be - employed. - - 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1 - - The following commands and options MUST be supported by - every server-FTP and user-FTP, except in cases where the - underlying file system or operating system does not allow or - support a particular command. - - Type: ASCII Non-print, IMAGE, LOCAL 8 - Mode: Stream - Structure: File, Record* - Commands: - USER, PASS, ACCT, - PORT, PASV, - TYPE, MODE, STRU, - RETR, STOR, APPE, - RNFR, RNTO, DELE, - CWD, CDUP, RMD, MKD, PWD, - - - -Internet Engineering Task Force [Page 34] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - LIST, NLST, - SYST, STAT, - HELP, NOOP, QUIT. - - *Record structure is REQUIRED only for hosts whose file - systems support record structure. - - DISCUSSION: - Vendors are encouraged to implement a larger subset of - the protocol. For example, there are important - robustness features in the protocol (e.g., Restart, - ABOR, block mode) that would be an aid to some Internet - users but are not widely implemented. - - A host that does not have record structures in its file - system may still accept files with STRU R, recording - the byte stream literally. - - 4.1.3 SPECIFIC ISSUES - - 4.1.3.1 Non-standard Command Verbs - - FTP allows "experimental" commands, whose names begin with - "X". If these commands are subsequently adopted as - standards, there may still be existing implementations using - the "X" form. At present, this is true for the directory - commands: - - RFC-959 "Experimental" - - MKD XMKD - RMD XRMD - PWD XPWD - CDUP XCUP - CWD XCWD - - All FTP implementations SHOULD recognize both forms of these - commands, by simply equating them with extra entries in the - command lookup table. - - IMPLEMENTATION: - A User-FTP can access a server that supports only the - "X" forms by implementing a mode switch, or - automatically using the following procedure: if the - RFC-959 form of one of the above commands is rejected - with a 500 or 502 response code, then try the - experimental form; any other response would be passed - to the user. - - - -Internet Engineering Task Force [Page 35] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.3.2 Idle Timeout - - A Server-FTP process SHOULD have an idle timeout, which will - terminate the process and close the control connection if - the server is inactive (i.e., no command or data transfer in - progress) for a long period of time. The idle timeout time - SHOULD be configurable, and the default should be at least 5 - minutes. - - A client FTP process ("User-PI" in RFC-959) will need - timeouts on responses only if it is invoked from a program. - - DISCUSSION: - Without a timeout, a Server-FTP process may be left - pending indefinitely if the corresponding client - crashes without closing the control connection. - - 4.1.3.3 Concurrency of Data and Control - - DISCUSSION: - The intent of the designers of FTP was that a user - should be able to send a STAT command at any time while - data transfer was in progress and that the server-FTP - would reply immediately with status -- e.g., the number - of bytes transferred so far. Similarly, an ABOR - command should be possible at any time during a data - transfer. - - Unfortunately, some small-machine operating systems - make such concurrent programming difficult, and some - other implementers seek minimal solutions, so some FTP - implementations do not allow concurrent use of the data - and control connections. Even such a minimal server - must be prepared to accept and defer a STAT or ABOR - command that arrives during data transfer. - - 4.1.3.4 FTP Restart Mechanism - - The description of the 110 reply on pp. 40-41 of RFC-959 is - incorrect; the correct description is as follows. A restart - reply message, sent over the control connection from the - receiving FTP to the User-FTP, has the format: - - 110 MARK ssss = rrrr - - Here: - - * ssss is a text string that appeared in a Restart Marker - - - -Internet Engineering Task Force [Page 36] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - in the data stream and encodes a position in the - sender's file system; - - * rrrr encodes the corresponding position in the - receiver's file system. - - The encoding, which is specific to a particular file system - and network implementation, is always generated and - interpreted by the same system, either sender or receiver. - - When an FTP that implements restart receives a Restart - Marker in the data stream, it SHOULD force the data to that - point to be written to stable storage before encoding the - corresponding position rrrr. An FTP sending Restart Markers - MUST NOT assume that 110 replies will be returned - synchronously with the data, i.e., it must not await a 110 - reply before sending more data. - - Two new reply codes are hereby defined for errors - encountered in restarting a transfer: - - 554 Requested action not taken: invalid REST parameter. - - A 554 reply may result from a FTP service command that - follows a REST command. The reply indicates that the - existing file at the Server-FTP cannot be repositioned - as specified in the REST. - - 555 Requested action not taken: type or stru mismatch. - - A 555 reply may result from an APPE command or from any - FTP service command following a REST command. The - reply indicates that there is some mismatch between the - current transfer parameters (type and stru) and the - attributes of the existing file. - - DISCUSSION: - Note that the FTP Restart mechanism requires that Block - or Compressed mode be used for data transfer, to allow - the Restart Markers to be included within the data - stream. The frequency of Restart Markers can be low. - - Restart Markers mark a place in the data stream, but - the receiver may be performing some transformation on - the data as it is stored into stable storage. In - general, the receiver's encoding must include any state - information necessary to restart this transformation at - any point of the FTP data stream. For example, in TYPE - - - -Internet Engineering Task Force [Page 37] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - A transfers, some receiver hosts transform CR LF - sequences into a single LF character on disk. If a - Restart Marker happens to fall between CR and LF, the - receiver must encode in rrrr that the transfer must be - restarted in a "CR has been seen and discarded" state. - - Note that the Restart Marker is required to be encoded - as a string of printable ASCII characters, regardless - of the type of the data. - - RFC-959 says that restart information is to be returned - "to the user". This should not be taken literally. In - general, the User-FTP should save the restart - information (ssss,rrrr) in stable storage, e.g., append - it to a restart control file. An empty restart control - file should be created when the transfer first starts - and deleted automatically when the transfer completes - successfully. It is suggested that this file have a - name derived in an easily-identifiable manner from the - name of the file being transferred and the remote host - name; this is analogous to the means used by many text - editors for naming "backup" files. - - There are three cases for FTP restart. - - (1) User-to-Server Transfer - - The User-FTP puts Restart Markers at - convenient places in the data stream. When the - Server-FTP receives a Marker, it writes all prior - data to disk, encodes its file system position and - transformation state as rrrr, and returns a "110 - MARK ssss = rrrr" reply over the control - connection. The User-FTP appends the pair - (ssss,rrrr) to its restart control file. - - To restart the transfer, the User-FTP fetches the - last (ssss,rrrr) pair from the restart control - file, repositions its local file system and - transformation state using ssss, and sends the - command "REST rrrr" to the Server-FTP. - - (2) Server-to-User Transfer - - The Server-FTP puts Restart Markers at - convenient places in the data stream. When the - User-FTP receives a Marker, it writes all prior - data to disk, encodes its file system position and - - - -Internet Engineering Task Force [Page 38] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - transformation state as rrrr, and appends the pair - (rrrr,ssss) to its restart control file. - - To restart the transfer, the User-FTP fetches the - last (rrrr,ssss) pair from the restart control - file, repositions its local file system and - transformation state using rrrr, and sends the - command "REST ssss" to the Server-FTP. - - (3) Server-to-Server ("Third-Party") Transfer - - The sending Server-FTP puts Restart Markers - at convenient places in the data stream. When it - receives a Marker, the receiving Server-FTP writes - all prior data to disk, encodes its file system - position and transformation state as rrrr, and - sends a "110 MARK ssss = rrrr" reply over the - control connection to the User. The User-FTP - appends the pair (ssss,rrrr) to its restart - control file. - - To restart the transfer, the User-FTP fetches the - last (ssss,rrrr) pair from the restart control - file, sends "REST ssss" to the sending Server-FTP, - and sends "REST rrrr" to the receiving Server-FTP. - - - 4.1.4 FTP/USER INTERFACE - - This section discusses the user interface for a User-FTP - program. - - 4.1.4.1 Pathname Specification - - Since FTP is intended for use in a heterogeneous - environment, User-FTP implementations MUST support remote - pathnames as arbitrary character strings, so that their form - and content are not limited by the conventions of the local - operating system. - - DISCUSSION: - In particular, remote pathnames can be of arbitrary - length, and all the printing ASCII characters as well - as space (0x20) must be allowed. RFC-959 allows a - pathname to contain any 7-bit ASCII character except CR - or LF. - - - - - -Internet Engineering Task Force [Page 39] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.4.2 "QUOTE" Command - - A User-FTP program MUST implement a "QUOTE" command that - will pass an arbitrary character string to the server and - display all resulting response messages to the user. - - To make the "QUOTE" command useful, a User-FTP SHOULD send - transfer control commands to the server as the user enters - them, rather than saving all the commands and sending them - to the server only when a data transfer is started. - - DISCUSSION: - The "QUOTE" command is essential to allow the user to - access servers that require system-specific commands - (e.g., SITE or ALLO), or to invoke new or optional - features that are not implemented by the User-FTP. For - example, "QUOTE" may be used to specify "TYPE A T" to - send a print file to hosts that require the - distinction, even if the User-FTP does not recognize - that TYPE. - - 4.1.4.3 Displaying Replies to User - - A User-FTP SHOULD display to the user the full text of all - error reply messages it receives. It SHOULD have a - "verbose" mode in which all commands it sends and the full - text and reply codes it receives are displayed, for - diagnosis of problems. - - 4.1.4.4 Maintaining Synchronization - - The state machine in a User-FTP SHOULD be forgiving of - missing and unexpected reply messages, in order to maintain - command synchronization with the server. - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 40] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.5 FTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------|---------------|-|-|-|-|-|-- -Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | | -File/Record transform invertible if poss. |4.1.2.4 | |x| | | | -User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | | -Server-FTP implement PASV |4.1.2.6 |x| | | | | - PASV is per-transfer |4.1.2.6 |x| | | | | -NLST reply usable in RETR cmds |4.1.2.7 |x| | | | | -Implied type for LIST and NLST |4.1.2.7 | |x| | | | -SITE cmd for non-standard features |4.1.2.8 | |x| | | | -STOU cmd return pathname as specified |4.1.2.9 |x| | | | | -Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x| - | | | | | | | -Server-FTP send only correct reply format |4.1.2.11 |x| | | | | -Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | | - New reply code following Section 4.2 |4.1.2.11 | | |x| | | -User-FTP use only high digit of reply |4.1.2.11 | |x| | | | -User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | | -User-FTP handle 421 reply specially |4.1.2.11 | | | |x| | - | | | | | | | -Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | | -User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x| -User-FTP negotiate Telnet options |4.1.2.12 | | | | |x| -Server-FTP handle Telnet options |4.1.2.12 |x| | | | | -Handle "Experimental" directory cmds |4.1.3.1 | |x| | | | -Idle timeout in server-FTP |4.1.3.2 | |x| | | | - Configurable idle timeout |4.1.3.2 | |x| | | | -Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | | -Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x| - | | | | | | | -Support TYPE: | | | | | | | - ASCII - Non-Print (AN) |4.1.2.13 |x| | | | | - ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | | - ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | | - EBCDIC - (any form) |959 3.1.1.2 | | |x| | | - IMAGE |4.1.2.1 |x| | | | | - LOCAL 8 |4.1.2.1 |x| | | | | - - - -Internet Engineering Task Force [Page 41] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - LOCAL m |4.1.2.1 | | |x| | |2 - | | | | | | | -Support MODE: | | | | | | | - Stream |4.1.2.13 |x| | | | | - Block |959 3.4.2 | | |x| | | - | | | | | | | -Support STRUCTURE: | | | | | | | - File |4.1.2.13 |x| | | | | - Record |4.1.2.13 |x| | | | |3 - Page |4.1.2.3 | | | |x| | - | | | | | | | -Support commands: | | | | | | | - USER |4.1.2.13 |x| | | | | - PASS |4.1.2.13 |x| | | | | - ACCT |4.1.2.13 |x| | | | | - CWD |4.1.2.13 |x| | | | | - CDUP |4.1.2.13 |x| | | | | - SMNT |959 5.3.1 | | |x| | | - REIN |959 5.3.1 | | |x| | | - QUIT |4.1.2.13 |x| | | | | - | | | | | | | - PORT |4.1.2.13 |x| | | | | - PASV |4.1.2.6 |x| | | | | - TYPE |4.1.2.13 |x| | | | |1 - STRU |4.1.2.13 |x| | | | |1 - MODE |4.1.2.13 |x| | | | |1 - | | | | | | | - RETR |4.1.2.13 |x| | | | | - STOR |4.1.2.13 |x| | | | | - STOU |959 5.3.1 | | |x| | | - APPE |4.1.2.13 |x| | | | | - ALLO |959 5.3.1 | | |x| | | - REST |959 5.3.1 | | |x| | | - RNFR |4.1.2.13 |x| | | | | - RNTO |4.1.2.13 |x| | | | | - ABOR |959 5.3.1 | | |x| | | - DELE |4.1.2.13 |x| | | | | - RMD |4.1.2.13 |x| | | | | - MKD |4.1.2.13 |x| | | | | - PWD |4.1.2.13 |x| | | | | - LIST |4.1.2.13 |x| | | | | - NLST |4.1.2.13 |x| | | | | - SITE |4.1.2.8 | | |x| | | - STAT |4.1.2.13 |x| | | | | - SYST |4.1.2.13 |x| | | | | - HELP |4.1.2.13 |x| | | | | - NOOP |4.1.2.13 |x| | | | | - | | | | | | | - - - -Internet Engineering Task Force [Page 42] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - -User Interface: | | | | | | | - Arbitrary pathnames |4.1.4.1 |x| | | | | - Implement "QUOTE" command |4.1.4.2 |x| | | | | - Transfer control commands immediately |4.1.4.2 | |x| | | | - Display error messages to user |4.1.4.3 | |x| | | | - Verbose mode |4.1.4.3 | |x| | | | - Maintain synchronization with server |4.1.4.4 | |x| | | | - -Footnotes: - -(1) For the values shown earlier. - -(2) Here m is number of bits in a memory word. - -(3) Required for host with record-structured file system, optional - otherwise. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 43] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP - - 4.2.1 INTRODUCTION - - The Trivial File Transfer Protocol TFTP is defined in RFC-783 - [TFTP:1]. - - TFTP provides its own reliable delivery with UDP as its - transport protocol, using a simple stop-and-wait acknowledgment - system. Since TFTP has an effective window of only one 512 - octet segment, it can provide good performance only over paths - that have a small delay*bandwidth product. The TFTP file - interface is very simple, providing no access control or - security. - - TFTP's most important application is bootstrapping a host over - a local network, since it is simple and small enough to be - easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are - urged to support TFTP for booting. - - 4.2.2 PROTOCOL WALK-THROUGH - - The TFTP specification [TFTP:1] is written in an open style, - and does not fully specify many parts of the protocol. - - 4.2.2.1 Transfer Modes: RFC-783, Page 3 - - The transfer mode "mail" SHOULD NOT be supported. - - 4.2.2.2 UDP Header: RFC-783, Page 17 - - The Length field of a UDP header is incorrectly defined; it - includes the UDP header length (8). - - 4.2.3 SPECIFIC ISSUES - - 4.2.3.1 Sorcerer's Apprentice Syndrome - - There is a serious bug, known as the "Sorcerer's Apprentice - Syndrome," in the protocol specification. While it does not - cause incorrect operation of the transfer (the file will - always be transferred correctly if the transfer completes), - this bug may cause excessive retransmission, which may cause - the transfer to time out. - - Implementations MUST contain the fix for this problem: the - sender (i.e., the side originating the DATA packets) must - never resend the current DATA packet on receipt of a - - - -Internet Engineering Task Force [Page 44] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - duplicate ACK. - - DISCUSSION: - The bug is caused by the protocol rule that either - side, on receiving an old duplicate datagram, may - resend the current datagram. If a packet is delayed in - the network but later successfully delivered after - either side has timed out and retransmitted a packet, a - duplicate copy of the response may be generated. If - the other side responds to this duplicate with a - duplicate of its own, then every datagram will be sent - in duplicate for the remainder of the transfer (unless - a datagram is lost, breaking the repetition). Worse - yet, since the delay is often caused by congestion, - this duplicate transmission will usually causes more - congestion, leading to more delayed packets, etc. - - The following example may help to clarify this problem. - - TFTP A TFTP B - - (1) Receive ACK X-1 - Send DATA X - (2) Receive DATA X - Send ACK X - (ACK X is delayed in network, - and A times out): - (3) Retransmit DATA X - - (4) Receive DATA X again - Send ACK X again - (5) Receive (delayed) ACK X - Send DATA X+1 - (6) Receive DATA X+1 - Send ACK X+1 - (7) Receive ACK X again - Send DATA X+1 again - (8) Receive DATA X+1 again - Send ACK X+1 again - (9) Receive ACK X+1 - Send DATA X+2 - (10) Receive DATA X+2 - Send ACK X+3 - (11) Receive ACK X+1 again - Send DATA X+2 again - (12) Receive DATA X+2 again - Send ACK X+3 again - - - - -Internet Engineering Task Force [Page 45] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - Notice that once the delayed ACK arrives, the protocol - settles down to duplicate all further packets - (sequences 5-8 and 9-12). The problem is caused not by - either side timing out, but by both sides - retransmitting the current packet when they receive a - duplicate. - - The fix is to break the retransmission loop, as - indicated above. This is analogous to the behavior of - TCP. It is then possible to remove the retransmission - timer on the receiver, since the resent ACK will never - cause any action; this is a useful simplification where - TFTP is used in a bootstrap program. It is OK to allow - the timer to remain, and it may be helpful if the - retransmitted ACK replaces one that was genuinely lost - in the network. The sender still requires a retransmit - timer, of course. - - 4.2.3.2 Timeout Algorithms - - A TFTP implementation MUST use an adaptive timeout. - - IMPLEMENTATION: - TCP retransmission algorithms provide a useful base to - work from. At least an exponential backoff of - retransmission timeout is necessary. - - 4.2.3.3 Extensions - - A variety of non-standard extensions have been made to TFTP, - including additional transfer modes and a secure operation - mode (with passwords). None of these have been - standardized. - - 4.2.3.4 Access Control - - A server TFTP implementation SHOULD include some - configurable access control over what pathnames are allowed - in TFTP operations. - - 4.2.3.5 Broadcast Request - - A TFTP request directed to a broadcast address SHOULD be - silently ignored. - - DISCUSSION: - Due to the weak access control capability of TFTP, - directed broadcasts of TFTP requests to random networks - - - -Internet Engineering Task Force [Page 46] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - could create a significant security hole. - - 4.2.4 TFTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- -Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | | -Transfer modes: | | | | | | | - netascii |RFC-783 |x| | | | | - octet |RFC-783 |x| | | | | - mail |4.2.2.1 | | | |x| | - extensions |4.2.3.3 | | |x| | | -Use adaptive timeout |4.2.3.2 |x| | | | | -Configurable access control |4.2.3.4 | |x| | | | -Silently ignore broadcast request |4.2.3.5 | |x| | | | --------------------------------------------------|--------|-|-|-|-|-|-- --------------------------------------------------|--------|-|-|-|-|-|-- - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 47] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - -5. ELECTRONIC MAIL -- SMTP and RFC-822 - - 5.1 INTRODUCTION - - In the TCP/IP protocol suite, electronic mail in a format - specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail - Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1]. - - While SMTP has remained unchanged over the years, the Internet - community has made several changes in the way SMTP is used. In - particular, the conversion to the Domain Name System (DNS) has - caused changes in address formats and in mail routing. In this - section, we assume familiarity with the concepts and terminology - of the DNS, whose requirements are given in Section 6.1. - - RFC-822 specifies the Internet standard format for electronic mail - messages. RFC-822 supercedes an older standard, RFC-733, that may - still be in use in a few places, although it is obsolete. The two - formats are sometimes referred to simply by number ("822" and - "733"). - - RFC-822 is used in some non-Internet mail environments with - different mail transfer protocols than SMTP, and SMTP has also - been adapted for use in some non-Internet environments. Note that - this document presents the rules for the use of SMTP and RFC-822 - for the Internet environment only; other mail environments that - use these protocols may be expected to have their own rules. - - 5.2 PROTOCOL WALK-THROUGH - - This section covers both RFC-821 and RFC-822. - - The SMTP specification in RFC-821 is clear and contains numerous - examples, so implementors should not find it difficult to - understand. This section simply updates or annotates portions of - RFC-821 to conform with current usage. - - RFC-822 is a long and dense document, defining a rich syntax. - Unfortunately, incomplete or defective implementations of RFC-822 - are common. In fact, nearly all of the many formats of RFC-822 - are actually used, so an implementation generally needs to - recognize and correctly interpret all of the RFC-822 syntax. - - 5.2.1 The SMTP Model: RFC-821 Section 2 - - DISCUSSION: - Mail is sent by a series of request/response transactions - between a client, the "sender-SMTP," and a server, the - - - -Internet Engineering Task Force [Page 48] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - "receiver-SMTP". These transactions pass (1) the message - proper, which is composed of header and body, and (2) SMTP - source and destination addresses, referred to as the - "envelope". - - The SMTP programs are analogous to Message Transfer Agents - (MTAs) of X.400. There will be another level of protocol - software, closer to the end user, that is responsible for - composing and analyzing RFC-822 message headers; this - component is known as the "User Agent" in X.400, and we - use that term in this document. There is a clear logical - distinction between the User Agent and the SMTP - implementation, since they operate on different levels of - protocol. Note, however, that this distinction is may not - be exactly reflected the structure of typical - implementations of Internet mail. Often there is a - program known as the "mailer" that implements SMTP and - also some of the User Agent functions; the rest of the - User Agent functions are included in a user interface used - for entering and reading mail. - - The SMTP envelope is constructed at the originating site, - typically by the User Agent when the message is first - queued for the Sender-SMTP program. The envelope - addresses may be derived from information in the message - header, supplied by the user interface (e.g., to implement - a bcc: request), or derived from local configuration - information (e.g., expansion of a mailing list). The SMTP - envelope cannot in general be re-derived from the header - at a later stage in message delivery, so the envelope is - transmitted separately from the message itself using the - MAIL and RCPT commands of SMTP. - - The text of RFC-821 suggests that mail is to be delivered - to an individual user at a host. With the advent of the - domain system and of mail routing using mail-exchange (MX) - resource records, implementors should now think of - delivering mail to a user at a domain, which may or may - not be a particular host. This DOES NOT change the fact - that SMTP is a host-to-host mail exchange protocol. - - 5.2.2 Canonicalization: RFC-821 Section 3.1 - - The domain names that a Sender-SMTP sends in MAIL and RCPT - commands MUST have been "canonicalized," i.e., they must be - fully-qualified principal names or domain literals, not - nicknames or domain abbreviations. A canonicalized name either - identifies a host directly or is an MX name; it cannot be a - - - -Internet Engineering Task Force [Page 49] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - CNAME. - - 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3 - - A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN - (this requirement overrides RFC-821). However, there MAY be - configuration information to disable VRFY and EXPN in a - particular installation; this might even allow EXPN to be - disabled for selected lists. - - A new reply code is defined for the VRFY command: - - 252 Cannot VRFY user (e.g., info is not local), but will - take message for this user and attempt delivery. - - DISCUSSION: - SMTP users and administrators make regular use of these - commands for diagnosing mail delivery problems. With the - increasing use of multi-level mailing list expansion - (sometimes more than two levels), EXPN has been - increasingly important for diagnosing inadvertent mail - loops. On the other hand, some feel that EXPN represents - a significant privacy, and perhaps even a security, - exposure. - - 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4 - - An SMTP MAY implement the commands to send a message to a - user's terminal: SEND, SOML, and SAML. - - DISCUSSION: - It has been suggested that the use of mail relaying - through an MX record is inconsistent with the intent of - SEND to deliver a message immediately and directly to a - user's terminal. However, an SMTP receiver that is unable - to write directly to the user terminal can return a "251 - User Not Local" reply to the RCPT following a SEND, to - inform the originator of possibly deferred delivery. - - 5.2.5 HELO Command: RFC-821 Section 3.5 - - The sender-SMTP MUST ensure that the parameter in a - HELO command is a valid principal host domain name for the - client host. As a result, the receiver-SMTP will not have to - perform MX resolution on this name in order to validate the - HELO parameter. - - The HELO receiver MAY verify that the HELO parameter really - - - -Internet Engineering Task Force [Page 50] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - corresponds to the IP address of the sender. However, the - receiver MUST NOT refuse to accept a message, even if the - sender's HELO command fails verification. - - DISCUSSION: - Verifying the HELO parameter requires a domain name lookup - and may therefore take considerable time. An alternative - tool for tracking bogus mail sources is suggested below - (see "DATA Command"). - - Note also that the HELO argument is still required to have - valid syntax, since it will appear in a Received: - line; otherwise, a 501 error is to be sent. - - IMPLEMENTATION: - When HELO parameter validation fails, a suggested - procedure is to insert a note about the unknown - authenticity of the sender into the message header (e.g., - in the "Received:" line). - - 5.2.6 Mail Relay: RFC-821 Section 3.6 - - We distinguish three types of mail (store-and-) forwarding: - - (1) A simple forwarder or "mail exchanger" forwards a message - using private knowledge about the recipient; see section - 3.2 of RFC-821. - - (2) An SMTP mail "relay" forwards a message within an SMTP - mail environment as the result of an explicit source route - (as defined in section 3.6 of RFC-821). The SMTP relay - function uses the "@...:" form of source route from RFC- - 822 (see Section 5.2.19 below). - - (3) A mail "gateway" passes a message between different - environments. The rules for mail gateways are discussed - below in Section 5.3.7. - - An Internet host that is forwarding a message but is not a - gateway to a different mail environment (i.e., it falls under - (1) or (2)) SHOULD NOT alter any existing header fields, - although the host will add an appropriate Received: line as - required in Section 5.2.8. - - A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an - explicit source route using the "@...:" address form. Thus, - the relay function defined in section 3.6 of RFC-821 should - not be used. - - - -Internet Engineering Task Force [Page 51] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - The intent is to discourage all source routing and to - abolish explicit source routing for mail delivery within - the Internet environment. Source-routing is unnecessary; - the simple target address "user@domain" should always - suffice. This is the result of an explicit architectural - decision to use universal naming rather than source - routing for mail. Thus, SMTP provides end-to-end - connectivity, and the DNS provides globally-unique, - location-independent names. MX records handle the major - case where source routing might otherwise be needed. - - A receiver-SMTP MUST accept the explicit source route syntax in - the envelope, but it MAY implement the relay function as - defined in section 3.6 of RFC-821. If it does not implement - the relay function, it SHOULD attempt to deliver the message - directly to the host to the right of the right-most "@" sign. - - DISCUSSION: - For example, suppose a host that does not implement the - relay function receives a message with the SMTP command: - "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and - GAMMA represent domain names. Rather than immediately - refusing the message with a 550 error reply as suggested - on page 20 of RFC-821, the host should try to forward the - message to GAMMA directly, using: "RCPT TO:". - Since this host does not support relaying, it is not - required to update the reverse path. - - Some have suggested that source routing may be needed - occasionally for manually routing mail around failures; - however, the reality and importance of this need is - controversial. The use of explicit SMTP mail relaying for - this purpose is discouraged, and in fact it may not be - successful, as many host systems do not support it. Some - have used the "%-hack" (see Section 5.2.16) for this - purpose. - - 5.2.7 RCPT Command: RFC-821 Section 4.1.1 - - A host that supports a receiver-SMTP MUST support the reserved - mailbox "Postmaster". - - The receiver-SMTP MAY verify RCPT parameters as they arrive; - however, RCPT responses MUST NOT be delayed beyond a reasonable - time (see Section 5.3.2). - - Therefore, a "250 OK" response to a RCPT does not necessarily - - - -Internet Engineering Task Force [Page 52] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - imply that the delivery address(es) are valid. Errors found - after message acceptance will be reported by mailing a - notification message to an appropriate address (see Section - 5.3.3). - - DISCUSSION: - The set of conditions under which a RCPT parameter can be - validated immediately is an engineering design choice. - Reporting destination mailbox errors to the Sender-SMTP - before mail is transferred is generally desirable to save - time and network bandwidth, but this advantage is lost if - RCPT verification is lengthy. - - For example, the receiver can verify immediately any - simple local reference, such as a single locally- - registered mailbox. On the other hand, the "reasonable - time" limitation generally implies deferring verification - of a mailing list until after the message has been - transferred and accepted, since verifying a large mailing - list can take a very long time. An implementation might - or might not choose to defer validation of addresses that - are non-local and therefore require a DNS lookup. If a - DNS lookup is performed but a soft domain system error - (e.g., timeout) occurs, validity must be assumed. - - 5.2.8 DATA Command: RFC-821 Section 4.1.1 - - Every receiver-SMTP (not just one that "accepts a message for - relaying or for final delivery" [SMTP:1]) MUST insert a - "Received:" line at the beginning of a message. In this line, - called a "time stamp line" in RFC-821: - - * The FROM field SHOULD contain both (1) the name of the - source host as presented in the HELO command and (2) a - domain literal containing the IP address of the source, - determined from the TCP connection. - - * The ID field MAY contain an "@" as suggested in RFC-822, - but this is not required. - - * The FOR field MAY contain a list of entries when - multiple RCPT commands have been given. - - - An Internet mail program MUST NOT change a Received: line that - was previously added to the message header. - - - - - -Internet Engineering Task Force [Page 53] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - Including both the source host and the IP source address - in the Received: line may provide enough information for - tracking illicit mail sources and eliminate a need to - explicitly verify the HELO parameter. - - Received: lines are primarily intended for humans tracing - mail routes, primarily of diagnosis of faults. See also - the discussion under 5.3.7. - - When the receiver-SMTP makes "final delivery" of a message, - then it MUST pass the MAIL FROM: address from the SMTP envelope - with the message, for use if an error notification message must - be sent later (see Section 5.3.3). There is an analogous - requirement when gatewaying from the Internet into a different - mail environment; see Section 5.3.7. - - DISCUSSION: - Note that the final reply to the DATA command depends only - upon the successful transfer and storage of the message. - Any problem with the destination address(es) must either - (1) have been reported in an SMTP error reply to the RCPT - command(s), or (2) be reported in a later error message - mailed to the originator. - - IMPLEMENTATION: - The MAIL FROM: information may be passed as a parameter or - in a Return-Path: line inserted at the beginning of the - message. - - 5.2.9 Command Syntax: RFC-821 Section 4.1.2 - - The syntax shown in RFC-821 for the MAIL FROM: command omits - the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page - 15). An empty reverse path MUST be supported. - - 5.2.10 SMTP Replies: RFC-821 Section 4.2 - - A receiver-SMTP SHOULD send only the reply codes listed in - section 4.2.2 of RFC-821 or in this document. A receiver-SMTP - SHOULD use the text shown in examples in RFC-821 whenever - appropriate. - - A sender-SMTP MUST determine its actions only by the reply - code, not by the text (except for 251 and 551 replies); any - text, including no text at all, must be acceptable. The space - (blank) following the reply code is considered part of the - text. Whenever possible, a sender-SMTP SHOULD test only the - - - -Internet Engineering Task Force [Page 54] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - first digit of the reply code, as specified in Appendix E of - RFC-821. - - DISCUSSION: - Interoperability problems have arisen with SMTP systems - using reply codes that are not listed explicitly in RFC- - 821 Section 4.3 but are legal according to the theory of - reply codes explained in Appendix E. - - 5.2.11 Transparency: RFC-821 Section 4.5.2 - - Implementors MUST be sure that their mail systems always add - and delete periods to ensure message transparency. - - 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 - - RFC-974 [SMTP:3] recommended that the domain system be queried - for WKS ("Well-Known Service") records, to verify that each - proposed mail target does support SMTP. Later experience has - shown that WKS is not widely supported, so the WKS step in MX - processing SHOULD NOT be used. - - The following are notes on RFC-822, organized by section of that - document. - - 5.2.13 RFC-822 Message Specification: RFC-822 Section 4 - - The syntax shown for the Return-path line omits the possibility - of a null return path, which is used to prevent looping of - error notifications (see Section 5.3.3). The complete syntax - is: - - return = "Return-path" ":" route-addr - / "Return-path" ":" "<" ">" - - The set of optional header fields is hereby expanded to include - the Content-Type field defined in RFC-1049 [SMTP:7]. This - field "allows mail reading systems to automatically identify - the type of a structured message body and to process it for - display accordingly". [SMTP:7] A User Agent MAY support this - field. - - 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 - - The syntax for the date is hereby changed to: - - date = 1*2DIGIT month 2*4DIGIT - - - - -Internet Engineering Task Force [Page 55] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - All mail software SHOULD use 4-digit years in dates, to ease - the transition to the next century. - - There is a strong trend towards the use of numeric timezone - indicators, and implementations SHOULD use numeric timezones - instead of timezone names. However, all implementations MUST - accept either notation. If timezone names are used, they MUST - be exactly as defined in RFC-822. - - The military time zones are specified incorrectly in RFC-822: - they count the wrong way from UT (the signs are reversed). As - a result, military time zones in RFC-822 headers carry no - information. - - Finally, note that there is a typo in the definition of "zone" - in the syntax summary of appendix D; the correct definition - occurs in Section 3 of RFC-822. - - 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1 - - The syntactic definition of "mailbox" in RFC-822 is hereby - changed to: - - mailbox = addr-spec ; simple address - / [phrase] route-addr ; name & addr-spec - - That is, the phrase preceding a route address is now OPTIONAL. - This change makes the following header field legal, for - example: - - From: - - 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2 - - The basic mailbox address specification has the form: "local- - part@domain". Here "local-part", sometimes called the "left- - hand side" of the address, is domain-dependent. - - A host that is forwarding the message but is not the - destination host implied by the right-hand side "domain" MUST - NOT interpret or modify the "local-part" of the address. - - When mail is to be gatewayed from the Internet mail environment - into a foreign mail environment (see Section 5.3.7), routing - information for that foreign environment MAY be embedded within - the "local-part" of the address. The gateway will then - interpret this local part appropriately for the foreign mail - environment. - - - -Internet Engineering Task Force [Page 56] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - Although source routes are discouraged within the Internet - (see Section 5.2.6), there are non-Internet mail - environments whose delivery mechanisms do depend upon - source routes. Source routes for extra-Internet - environments can generally be buried in the "local-part" - of the address (see Section 5.2.16) while mail traverses - the Internet. When the mail reaches the appropriate - Internet mail gateway, the gateway will interpret the - local-part and build the necessary address or route for - the target mail environment. - - For example, an Internet host might send mail to: - "a!b!c!user@gateway-domain". The complex local part - "a!b!c!user" would be uninterpreted within the Internet - domain, but could be parsed and understood by the - specified mail gateway. - - An embedded source route is sometimes encoded in the - "local-part" using "%" as a right-binding routing - operator. For example, in: - - user%domain%relay3%relay2@relay1 - - the "%" convention implies that the mail is to be routed - from "relay1" through "relay2", "relay3", and finally to - "user" at "domain". This is commonly known as the "%- - hack". It is suggested that "%" have lower precedence - than any other routing operator (e.g., "!") hidden in the - local-part; for example, "a!b%c" would be interpreted as - "(a!b)%c". - - Only the target host (in this case, "relay1") is permitted - to analyze the local-part "user%domain%relay3%relay2". - - 5.2.17 Domain Literals: RFC-822 Section 6.2.3 - - A mailer MUST be able to accept and parse an Internet domain - literal whose content ("dtext"; see RFC-822) is a dotted- - decimal host address. This satisfies the requirement of - Section 2.1 for the case of mail. - - An SMTP MUST accept and recognize a domain literal for any of - its own IP addresses. - - - - - - - -Internet Engineering Task Force [Page 57] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 - - Errors in formatting or parsing 822 addresses are unfortunately - common. This section mentions only the most common errors. A - User Agent MUST accept all valid RFC-822 address formats, and - MUST NOT generate illegal address syntax. - - o A common error is to leave out the semicolon after a group - identifier. - - o Some systems fail to fully-qualify domain names in - messages they generate. The right-hand side of an "@" - sign in a header address field MUST be a fully-qualified - domain name. - - For example, some systems fail to fully-qualify the From: - address; this prevents a "reply" command in the user - interface from automatically constructing a return - address. - - DISCUSSION: - Although RFC-822 allows the local use of abbreviated - domain names within a domain, the application of - RFC-822 in Internet mail does not allow this. The - intent is that an Internet host must not send an SMTP - message header containing an abbreviated domain name - in an address field. This allows the address fields - of the header to be passed without alteration across - the Internet, as required in Section 5.2.6. - - o Some systems mis-parse multiple-hop explicit source routes - such as: - - @relay1,@relay2,@relay3:user@domain. - - - o Some systems over-qualify domain names by adding a - trailing dot to some or all domain names in addresses or - message-ids. This violates RFC-822 syntax. - - - 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7 - - Internet host software SHOULD NOT create an RFC-822 header - containing an address with an explicit source route, but MUST - accept such headers for compatibility with earlier systems. - - DISCUSSION: - - - -Internet Engineering Task Force [Page 58] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - In an understatement, RFC-822 says "The use of explicit - source routing is discouraged". Many hosts implemented - RFC-822 source routes incorrectly, so the syntax cannot be - used unambiguously in practice. Many users feel the - syntax is ugly. Explicit source routes are not needed in - the mail envelope for delivery; see Section 5.2.6. For - all these reasons, explicit source routes using the RFC- - 822 notations are not to be used in Internet mail headers. - - As stated in Section 5.2.16, it is necessary to allow an - explicit source route to be buried in the local-part of an - address, e.g., using the "%-hack", in order to allow mail - to be gatewayed into another environment in which explicit - source routing is necessary. The vigilant will observe - that there is no way for a User Agent to detect and - prevent the use of such implicit source routing when the - destination is within the Internet. We can only - discourage source routing of any kind within the Internet, - as unnecessary and undesirable. - - 5.3 SPECIFIC ISSUES - - 5.3.1 SMTP Queueing Strategies - - The common structure of a host SMTP implementation includes - user mailboxes, one or more areas for queueing messages in - transit, and one or more daemon processes for sending and - receiving mail. The exact structure will vary depending on the - needs of the users on the host and the number and size of - mailing lists supported by the host. We describe several - optimizations that have proved helpful, particularly for - mailers supporting high traffic levels. - - Any queueing strategy MUST include: - - o Timeouts on all activities. See Section 5.3.2. - - o Never sending error messages in response to error - messages. - - - 5.3.1.1 Sending Strategy - - The general model of a sender-SMTP is one or more processes - that periodically attempt to transmit outgoing mail. In a - typical system, the program that composes a message has some - method for requesting immediate attention for a new piece of - outgoing mail, while mail that cannot be transmitted - - - -Internet Engineering Task Force [Page 59] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - immediately MUST be queued and periodically retried by the - sender. A mail queue entry will include not only the - message itself but also the envelope information. - - The sender MUST delay retrying a particular destination - after one attempt has failed. In general, the retry - interval SHOULD be at least 30 minutes; however, more - sophisticated and variable strategies will be beneficial - when the sender-SMTP can determine the reason for non- - delivery. - - Retries continue until the message is transmitted or the - sender gives up; the give-up time generally needs to be at - least 4-5 days. The parameters to the retry algorithm MUST - be configurable. - - A sender SHOULD keep a list of hosts it cannot reach and - corresponding timeouts, rather than just retrying queued - mail items. - - DISCUSSION: - Experience suggests that failures are typically - transient (the target system has crashed), favoring a - policy of two connection attempts in the first hour the - message is in the queue, and then backing off to once - every two or three hours. - - The sender-SMTP can shorten the queueing delay by - cooperation with the receiver-SMTP. In particular, if - mail is received from a particular address, it is good - evidence that any mail queued for that host can now be - sent. - - The strategy may be further modified as a result of - multiple addresses per host (see Section 5.3.4), to - optimize delivery time vs. resource usage. - - A sender-SMTP may have a large queue of messages for - each unavailable destination host, and if it retried - all these messages in every retry cycle, there would be - excessive Internet overhead and the daemon would be - blocked for a long period. Note that an SMTP can - generally determine that a delivery attempt has failed - only after a timeout of a minute or more; a one minute - timeout per connection will result in a very large - delay if it is repeated for dozens or even hundreds of - queued messages. - - - - -Internet Engineering Task Force [Page 60] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - When the same message is to be delivered to several users on - the same host, only one copy of the message SHOULD be - transmitted. That is, the sender-SMTP should use the - command sequence: RCPT, RCPT,... RCPT, DATA instead of the - sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA. - Implementation of this efficiency feature is strongly urged. - - Similarly, the sender-SMTP MAY support multiple concurrent - outgoing mail transactions to achieve timely delivery. - However, some limit SHOULD be imposed to protect the host - from devoting all its resources to mail. - - The use of the different addresses of a multihomed host is - discussed below. - - 5.3.1.2 Receiving strategy - - The receiver-SMTP SHOULD attempt to keep a pending listen on - the SMTP port at all times. This will require the support - of multiple incoming TCP connections for SMTP. Some limit - MAY be imposed. - - IMPLEMENTATION: - When the receiver-SMTP receives mail from a particular - host address, it could notify the sender-SMTP to retry - any mail pending for that host address. - - 5.3.2 Timeouts in SMTP - - There are two approaches to timeouts in the sender-SMTP: (a) - limit the time for each SMTP command separately, or (b) limit - the time for the entire SMTP dialogue for a single mail - message. A sender-SMTP SHOULD use option (a), per-command - timeouts. Timeouts SHOULD be easily reconfigurable, preferably - without recompiling the SMTP code. - - DISCUSSION: - Timeouts are an essential feature of an SMTP - implementation. If the timeouts are too long (or worse, - there are no timeouts), Internet communication failures or - software bugs in receiver-SMTP programs can tie up SMTP - processes indefinitely. If the timeouts are too short, - resources will be wasted with attempts that time out part - way through message delivery. - - If option (b) is used, the timeout has to be very large, - e.g., an hour, to allow time to expand very large mailing - lists. The timeout may also need to increase linearly - - - -Internet Engineering Task Force [Page 61] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - with the size of the message, to account for the time to - transmit a very large message. A large fixed timeout - leads to two problems: a failure can still tie up the - sender for a very long time, and very large messages may - still spuriously time out (which is a wasteful failure!). - - Using the recommended option (a), a timer is set for each - SMTP command and for each buffer of the data transfer. - The latter means that the overall timeout is inherently - proportional to the size of the message. - - Based on extensive experience with busy mail-relay hosts, the - minimum per-command timeout values SHOULD be as follows: - - o Initial 220 Message: 5 minutes - - A Sender-SMTP process needs to distinguish between a - failed TCP connection and a delay in receiving the initial - 220 greeting message. Many receiver-SMTPs will accept a - TCP connection but delay delivery of the 220 message until - their system load will permit more mail to be processed. - - o MAIL Command: 5 minutes - - - o RCPT Command: 5 minutes - - A longer timeout would be required if processing of - mailing lists and aliases were not deferred until after - the message was accepted. - - o DATA Initiation: 2 minutes - - This is while awaiting the "354 Start Input" reply to a - DATA command. - - o Data Block: 3 minutes - - This is while awaiting the completion of each TCP SEND - call transmitting a chunk of data. - - o DATA Termination: 10 minutes. - - This is while awaiting the "250 OK" reply. When the - receiver gets the final period terminating the message - data, it typically performs processing to deliver the - message to a user mailbox. A spurious timeout at this - point would be very wasteful, since the message has been - - - -Internet Engineering Task Force [Page 62] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - successfully sent. - - A receiver-SMTP SHOULD have a timeout of at least 5 minutes - while it is awaiting the next command from the sender. - - 5.3.3 Reliable Mail Receipt - - When the receiver-SMTP accepts a piece of mail (by sending a - "250 OK" message in response to DATA), it is accepting - responsibility for delivering or relaying the message. It must - take this responsibility seriously, i.e., it MUST NOT lose the - message for frivolous reasons, e.g., because the host later - crashes or because of a predictable resource shortage. - - If there is a delivery failure after acceptance of a message, - the receiver-SMTP MUST formulate and mail a notification - message. This notification MUST be sent using a null ("<>") - reverse path in the envelope; see Section 3.6 of RFC-821. The - recipient of this notification SHOULD be the address from the - envelope return path (or the Return-Path: line). However, if - this address is null ("<>"), the receiver-SMTP MUST NOT send a - notification. If the address is an explicit source route, it - SHOULD be stripped down to its final hop. - - DISCUSSION: - For example, suppose that an error notification must be - sent for a message that arrived with: - "MAIL FROM:<@a,@b:user@d>". The notification message - should be sent to: "RCPT TO:". - - Some delivery failures after the message is accepted by - SMTP will be unavoidable. For example, it may be - impossible for the receiver-SMTP to validate all the - delivery addresses in RCPT command(s) due to a "soft" - domain system error or because the target is a mailing - list (see earlier discussion of RCPT). - - To avoid receiving duplicate messages as the result of - timeouts, a receiver-SMTP MUST seek to minimize the time - required to respond to the final "." that ends a message - transfer. See RFC-1047 [SMTP:4] for a discussion of this - problem. - - 5.3.4 Reliable Mail Transmission - - To transmit a message, a sender-SMTP determines the IP address - of the target host from the destination address in the - envelope. Specifically, it maps the string to the right of the - - - -Internet Engineering Task Force [Page 63] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - "@" sign into an IP address. This mapping or the transfer - itself may fail with a soft error, in which case the sender- - SMTP will requeue the outgoing mail for a later retry, as - required in Section 5.3.1.1. - - When it succeeds, the mapping can result in a list of - alternative delivery addresses rather than a single address, - because of (a) multiple MX records, (b) multihoming, or both. - To provide reliable mail transmission, the sender-SMTP MUST be - able to try (and retry) each of the addresses in this list in - order, until a delivery attempt succeeds. However, there MAY - also be a configurable limit on the number of alternate - addresses that can be tried. In any case, a host SHOULD try at - least two addresses. - - The following information is to be used to rank the host - addresses: - - (1) Multiple MX Records -- these contain a preference - indication that should be used in sorting. If there are - multiple destinations with the same preference and there - is no clear reason to favor one (e.g., by address - preference), then the sender-SMTP SHOULD pick one at - random to spread the load across multiple mail exchanges - for a specific organization; note that this is a - refinement of the procedure in [DNS:3]. - - (2) Multihomed host -- The destination host (perhaps taken - from the preferred MX record) may be multihomed, in which - case the domain name resolver will return a list of - alternative IP addresses. It is the responsibility of the - domain name resolver interface (see Section 6.1.3.4 below) - to have ordered this list by decreasing preference, and - SMTP MUST try them in the order presented. - - DISCUSSION: - Although the capability to try multiple alternative - addresses is required, there may be circumstances where - specific installations want to limit or disable the use of - alternative addresses. The question of whether a sender - should attempt retries using the different addresses of a - multihomed host has been controversial. The main argument - for using the multiple addresses is that it maximizes the - probability of timely delivery, and indeed sometimes the - probability of any delivery; the counter argument is that - it may result in unnecessary resource use. - - Note that resource use is also strongly determined by the - - - -Internet Engineering Task Force [Page 64] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - sending strategy discussed in Section 5.3.1. - - 5.3.5 Domain Name Support - - SMTP implementations MUST use the mechanism defined in Section - 6.1 for mapping between domain names and IP addresses. This - means that every Internet SMTP MUST include support for the - Internet DNS. - - In particular, a sender-SMTP MUST support the MX record scheme - [SMTP:3]. See also Section 7.4 of [DNS:2] for information on - domain name support for SMTP. - - 5.3.6 Mailing Lists and Aliases - - An SMTP-capable host SHOULD support both the alias and the list - form of address expansion for multiple delivery. When a - message is delivered or forwarded to each address of an - expanded list form, the return address in the envelope - ("MAIL FROM:") MUST be changed to be the address of a person - who administers the list, but the message header MUST be left - unchanged; in particular, the "From" field of the message is - unaffected. - - DISCUSSION: - An important mail facility is a mechanism for multi- - destination delivery of a single message, by transforming - or "expanding" a pseudo-mailbox address into a list of - destination mailbox addresses. When a message is sent to - such a pseudo-mailbox (sometimes called an "exploder"), - copies are forwarded or redistributed to each mailbox in - the expanded list. We classify such a pseudo-mailbox as - an "alias" or a "list", depending upon the expansion - rules: - - (a) Alias - - To expand an alias, the recipient mailer simply - replaces the pseudo-mailbox address in the envelope - with each of the expanded addresses in turn; the rest - of the envelope and the message body are left - unchanged. The message is then delivered or - forwarded to each expanded address. - - (b) List - - A mailing list may be said to operate by - "redistribution" rather than by "forwarding". To - - - -Internet Engineering Task Force [Page 65] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - expand a list, the recipient mailer replaces the - pseudo-mailbox address in the envelope with each of - the expanded addresses in turn. The return address in - the envelope is changed so that all error messages - generated by the final deliveries will be returned to - a list administrator, not to the message originator, - who generally has no control over the contents of the - list and will typically find error messages annoying. - - - 5.3.7 Mail Gatewaying - - Gatewaying mail between different mail environments, i.e., - different mail formats and protocols, is complex and does not - easily yield to standardization. See for example [SMTP:5a], - [SMTP:5b]. However, some general requirements may be given for - a gateway between the Internet and another mail environment. - - (A) Header fields MAY be rewritten when necessary as messages - are gatewayed across mail environment boundaries. - - DISCUSSION: - This may involve interpreting the local-part of the - destination address, as suggested in Section 5.2.16. - - The other mail systems gatewayed to the Internet - generally use a subset of RFC-822 headers, but some - of them do not have an equivalent to the SMTP - envelope. Therefore, when a message leaves the - Internet environment, it may be necessary to fold the - SMTP envelope information into the message header. A - possible solution would be to create new header - fields to carry the envelope information (e.g., "X- - SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would - require changes in mail programs in the foreign - environment. - - (B) When forwarding a message into or out of the Internet - environment, a gateway MUST prepend a Received: line, but - it MUST NOT alter in any way a Received: line that is - already in the header. - - DISCUSSION: - This requirement is a subset of the general - "Received:" line requirement of Section 5.2.8; it is - restated here for emphasis. - - Received: fields of messages originating from other - - - -Internet Engineering Task Force [Page 66] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - environments may not conform exactly to RFC822. - However, the most important use of Received: lines is - for debugging mail faults, and this debugging can be - severely hampered by well-meaning gateways that try - to "fix" a Received: line. - - The gateway is strongly encouraged to indicate the - environment and protocol in the "via" clauses of - Received field(s) that it supplies. - - (C) From the Internet side, the gateway SHOULD accept all - valid address formats in SMTP commands and in RFC-822 - headers, and all valid RFC-822 messages. Although a - gateway must accept an RFC-822 explicit source route - ("@...:" format) in either the RFC-822 header or in the - envelope, it MAY or may not act on the source route; see - Sections 5.2.6 and 5.2.19. - - DISCUSSION: - It is often tempting to restrict the range of - addresses accepted at the mail gateway to simplify - the translation into addresses for the remote - environment. This practice is based on the - assumption that mail users have control over the - addresses their mailers send to the mail gateway. In - practice, however, users have little control over the - addresses that are finally sent; their mailers are - free to change addresses into any legal RFC-822 - format. - - (D) The gateway MUST ensure that all header fields of a - message that it forwards into the Internet meet the - requirements for Internet mail. In particular, all - addresses in "From:", "To:", "Cc:", etc., fields must be - transformed (if necessary) to satisfy RFC-822 syntax, and - they must be effective and useful for sending replies. - - - (E) The translation algorithm used to convert mail from the - Internet protocols to another environment's protocol - SHOULD try to ensure that error messages from the foreign - mail environment are delivered to the return path from the - SMTP envelope, not to the sender listed in the "From:" - field of the RFC-822 message. - - DISCUSSION: - Internet mail lists usually place the address of the - mail list maintainer in the envelope but leave the - - - -Internet Engineering Task Force [Page 67] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - original message header intact (with the "From:" - field containing the original sender). This yields - the behavior the average recipient expects: a reply - to the header gets sent to the original sender, not - to a mail list maintainer; however, errors get sent - to the maintainer (who can fix the problem) and not - the sender (who probably cannot). - - (F) Similarly, when forwarding a message from another - environment into the Internet, the gateway SHOULD set the - envelope return path in accordance with an error message - return address, if any, supplied by the foreign - environment. - - - 5.3.8 Maximum Message Size - - Mailer software MUST be able to send and receive messages of at - least 64K bytes in length (including header), and a much larger - maximum size is highly desirable. - - DISCUSSION: - Although SMTP does not define the maximum size of a - message, many systems impose implementation limits. - - The current de facto minimum limit in the Internet is 64K - bytes. However, electronic mail is used for a variety of - purposes that create much larger messages. For example, - mail is often used instead of FTP for transmitting ASCII - files, and in particular to transmit entire documents. As - a result, messages can be 1 megabyte or even larger. We - note that the present document together with its lower- - layer companion contains 0.5 megabytes. - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 68] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - 5.4 SMTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -RECEIVER-SMTP: | | | | | | | - Implement VRFY |5.2.3 |x| | | | | - Implement EXPN |5.2.3 | |x| | | | - EXPN, VRFY configurable |5.2.3 | | |x| | | - Implement SEND, SOML, SAML |5.2.4 | | |x| | | - Verify HELO parameter |5.2.5 | | |x| | | - Refuse message with bad HELO |5.2.5 | | | | |x| - Accept explicit src-route syntax in env. |5.2.6 |x| | | | | - Support "postmaster" |5.2.7 |x| | | | | - Process RCPT when received (except lists) |5.2.7 | | |x| | | - Long delay of RCPT responses |5.2.7 | | | | |x| - | | | | | | | - Add Received: line |5.2.8 |x| | | | | - Received: line include domain literal |5.2.8 | |x| | | | - Change previous Received: line |5.2.8 | | | | |x| - Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | | - Support empty reverse path |5.2.9 |x| | | | | - Send only official reply codes |5.2.10 | |x| | | | - Send text from RFC-821 when appropriate |5.2.10 | |x| | | | - Delete "." for transparency |5.2.11 |x| | | | | - Accept and recognize self domain literal(s) |5.2.17 |x| | | | | - | | | | | | | - Error message about error message |5.3.1 | | | | |x| - Keep pending listen on SMTP port |5.3.1.2 | |x| | | | - Provide limit on recv concurrency |5.3.1.2 | | |x| | | - Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | | - Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x| - Send error notification msg after accept |5.3.3 |x| | | | | - Send using null return path |5.3.3 |x| | | | | - Send to envelope return path |5.3.3 | |x| | | | - Send to null address |5.3.3 | | | | |x| - Strip off explicit src route |5.3.3 | |x| | | | - Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | | ------------------------------------------------|----------|-|-|-|-|-|-- - - - -Internet Engineering Task Force [Page 69] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - | | | | | | | -SENDER-SMTP: | | | | | | | - Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | | - Implement SEND, SOML, SAML |5.2.4 | | |x| | | - Send valid principal host name in HELO |5.2.5 |x| | | | | - Send explicit source route in RCPT TO: |5.2.6 | | | |x| | - Use only reply code to determine action |5.2.10 |x| | | | | - Use only high digit of reply code when poss. |5.2.10 | |x| | | | - Add "." for transparency |5.2.11 |x| | | | | - | | | | | | | - Retry messages after soft failure |5.3.1.1 |x| | | | | - Delay before retry |5.3.1.1 |x| | | | | - Configurable retry parameters |5.3.1.1 |x| | | | | - Retry once per each queued dest host |5.3.1.1 | |x| | | | - Multiple RCPT's for same DATA |5.3.1.1 | |x| | | | - Support multiple concurrent transactions |5.3.1.1 | | |x| | | - Provide limit on concurrency |5.3.1.1 | |x| | | | - | | | | | | | - Timeouts on all activities |5.3.1 |x| | | | | - Per-command timeouts |5.3.2 | |x| | | | - Timeouts easily reconfigurable |5.3.2 | |x| | | | - Recommended times |5.3.2 | |x| | | | - Try alternate addr's in order |5.3.4 |x| | | | | - Configurable limit on alternate tries |5.3.4 | | |x| | | - Try at least two alternates |5.3.4 | |x| | | | - Load-split across equal MX alternates |5.3.4 | |x| | | | - Use the Domain Name System |5.3.5 |x| | | | | - Support MX records |5.3.5 |x| | | | | - Use WKS records in MX processing |5.2.12 | | | |x| | ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -MAIL FORWARDING: | | | | | | | - Alter existing header field(s) |5.2.6 | | | |x| | - Implement relay function: 821/section 3.6 |5.2.6 | | |x| | | - If not, deliver to RHS domain |5.2.6 | |x| | | | - Interpret 'local-part' of addr |5.2.16 | | | | |x| - | | | | | | | -MAILING LISTS AND ALIASES | | | | | | | - Support both |5.3.6 | |x| | | | - Report mail list error to local admin. |5.3.6 |x| | | | | - | | | | | | | -MAIL GATEWAYS: | | | | | | | - Embed foreign mail route in local-part |5.2.16 | | |x| | | - Rewrite header fields when necessary |5.3.7 | | |x| | | - Prepend Received: line |5.3.7 |x| | | | | - Change existing Received: line |5.3.7 | | | | |x| - Accept full RFC-822 on Internet side |5.3.7 | |x| | | | - Act on RFC-822 explicit source route |5.3.7 | | |x| | | - - - -Internet Engineering Task Force [Page 70] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - Send only valid RFC-822 on Internet side |5.3.7 |x| | | | | - Deliver error msgs to envelope addr |5.3.7 | |x| | | | - Set env return path from err return addr |5.3.7 | |x| | | | - | | | | | | | -USER AGENT -- RFC-822 | | | | | | | - Allow user to enter address |5.2.6 | | | |x| | - Support RFC-1049 Content Type field |5.2.13 | | |x| | | - Use 4-digit years |5.2.14 | |x| | | | - Generate numeric timezones |5.2.14 | |x| | | | - Accept all timezones |5.2.14 |x| | | | | - Use non-num timezones from RFC-822 |5.2.14 |x| | | | | - Omit phrase before route-addr |5.2.15 | | |x| | | - Accept and parse dot.dec. domain literals |5.2.17 |x| | | | | - Accept all RFC-822 address formats |5.2.18 |x| | | | | - Generate invalid RFC-822 address format |5.2.18 | | | | |x| - Fully-qualified domain names in header |5.2.18 |x| | | | | - Create explicit src route in header |5.2.19 | | | |x| | - Accept explicit src route in header |5.2.19 |x| | | | | - | | | | | | | -Send/recv at least 64KB messages |5.3.8 |x| | | | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 71] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - -6. SUPPORT SERVICES - - 6.1 DOMAIN NAME TRANSLATION - - 6.1.1 INTRODUCTION - - Every host MUST implement a resolver for the Domain Name System - (DNS), and it MUST implement a mechanism using this DNS - resolver to convert host names to IP addresses and vice-versa - [DNS:1, DNS:2]. - - In addition to the DNS, a host MAY also implement a host name - translation mechanism that searches a local Internet host - table. See Section 6.1.3.8 for more information on this - option. - - DISCUSSION: - Internet host name translation was originally performed by - searching local copies of a table of all hosts. This - table became too large to update and distribute in a - timely manner and too large to fit into many hosts, so the - DNS was invented. - - The DNS creates a distributed database used primarily for - the translation between host names and host addresses. - Implementation of DNS software is required. The DNS - consists of two logically distinct parts: name servers and - resolvers (although implementations often combine these - two logical parts in the interest of efficiency) [DNS:2]. - - Domain name servers store authoritative data about certain - sections of the database and answer queries about the - data. Domain resolvers query domain name servers for data - on behalf of user processes. Every host therefore needs a - DNS resolver; some host machines will also need to run - domain name servers. Since no name server has complete - information, in general it is necessary to obtain - information from more than one name server to resolve a - query. - - 6.1.2 PROTOCOL WALK-THROUGH - - An implementor must study references [DNS:1] and [DNS:2] - carefully. They provide a thorough description of the theory, - protocol, and implementation of the domain name system, and - reflect several years of experience. - - - - - -Internet Engineering Task Force [Page 72] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1 - - All DNS name servers and resolvers MUST properly handle RRs - with a zero TTL: return the RR to the client but do not - cache it. - - DISCUSSION: - Zero TTL values are interpreted to mean that the RR can - only be used for the transaction in progress, and - should not be cached; they are useful for extremely - volatile data. - - 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5 - - A query with "QCLASS=*" SHOULD NOT be used unless the - requestor is seeking data from more than one class. In - particular, if the requestor is only interested in Internet - data types, QCLASS=IN MUST be used. - - 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1 - - Unused fields in a query or response message MUST be zero. - - 6.1.2.4 Compression: RFC-1035 Section 4.1.4 - - Name servers MUST use compression in responses. - - DISCUSSION: - Compression is essential to avoid overflowing UDP - datagrams; see Section 6.1.3.2. - - 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2 - - Recursive name servers and full-service resolvers generally - have some configuration information containing hints about - the location of root or local name servers. An - implementation MUST NOT include any of these hints in a - response. - - DISCUSSION: - Many implementors have found it convenient to store - these hints as if they were cached data, but some - neglected to ensure that this "cached data" was not - included in responses. This has caused serious - problems in the Internet when the hints were obsolete - or incorrect. - - - - - -Internet Engineering Task Force [Page 73] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3 SPECIFIC ISSUES - - 6.1.3.1 Resolver Implementation - - A name resolver SHOULD be able to multiplex concurrent - requests if the host supports concurrent processes. - - In implementing a DNS resolver, one of two different models - MAY optionally be chosen: a full-service resolver, or a stub - resolver. - - - (A) Full-Service Resolver - - A full-service resolver is a complete implementation of - the resolver service, and is capable of dealing with - communication failures, failure of individual name - servers, location of the proper name server for a given - name, etc. It must satisfy the following requirements: - - o The resolver MUST implement a local caching - function to avoid repeated remote access for - identical requests, and MUST time out information - in the cache. - - o The resolver SHOULD be configurable with start-up - information pointing to multiple root name servers - and multiple name servers for the local domain. - This insures that the resolver will be able to - access the whole name space in normal cases, and - will be able to access local domain information - should the local network become disconnected from - the rest of the Internet. - - - (B) Stub Resolver - - A "stub resolver" relies on the services of a recursive - name server on the connected network or a "nearby" - network. This scheme allows the host to pass on the - burden of the resolver function to a name server on - another host. This model is often essential for less - capable hosts, such as PCs, and is also recommended - when the host is one of several workstations on a local - network, because it allows all of the workstations to - share the cache of the recursive name server and hence - reduce the number of domain requests exported by the - local network. - - - -Internet Engineering Task Force [Page 74] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - At a minimum, the stub resolver MUST be capable of - directing its requests to redundant recursive name - servers. Note that recursive name servers are allowed - to restrict the sources of requests that they will - honor, so the host administrator must verify that the - service will be provided. Stub resolvers MAY implement - caching if they choose, but if so, MUST timeout cached - information. - - - 6.1.3.2 Transport Protocols - - DNS resolvers and recursive servers MUST support UDP, and - SHOULD support TCP, for sending (non-zone-transfer) queries. - Specifically, a DNS resolver or server that is sending a - non-zone-transfer query MUST send a UDP query first. If the - Answer section of the response is truncated and if the - requester supports TCP, it SHOULD try the query again using - TCP. - - DNS servers MUST be able to service UDP queries and SHOULD - be able to service TCP queries. A name server MAY limit the - resources it devotes to TCP queries, but it SHOULD NOT - refuse to service a TCP query just because it would have - succeeded with UDP. - - Truncated responses MUST NOT be saved (cached) and later - used in such a way that the fact that they are truncated is - lost. - - DISCUSSION: - UDP is preferred over TCP for queries because UDP - queries have much lower overhead, both in packet count - and in connection state. The use of UDP is essential - for heavily-loaded servers, especially the root - servers. UDP also offers additional robustness, since - a resolver can attempt several UDP queries to different - servers for the cost of a single TCP query. - - It is possible for a DNS response to be truncated, - although this is a very rare occurrence in the present - Internet DNS. Practically speaking, truncation cannot - be predicted, since it is data-dependent. The - dependencies include the number of RRs in the answer, - the size of each RR, and the savings in space realized - by the name compression algorithm. As a rule of thumb, - truncation in NS and MX lists should not occur for - answers containing 15 or fewer RRs. - - - -Internet Engineering Task Force [Page 75] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Whether it is possible to use a truncated answer - depends on the application. A mailer must not use a - truncated MX response, since this could lead to mail - loops. - - Responsible practices can make UDP suffice in the vast - majority of cases. Name servers must use compression - in responses. Resolvers must differentiate truncation - of the Additional section of a response (which only - loses extra information) from truncation of the Answer - section (which for MX records renders the response - unusable by mailers). Database administrators should - list only a reasonable number of primary names in lists - of name servers, MX alternatives, etc. - - However, it is also clear that some new DNS record - types defined in the future will contain information - exceeding the 512 byte limit that applies to UDP, and - hence will require TCP. Thus, resolvers and name - servers should implement TCP services as a backup to - UDP today, with the knowledge that they will require - the TCP service in the future. - - By private agreement, name servers and resolvers MAY arrange - to use TCP for all traffic between themselves. TCP MUST be - used for zone transfers. - - A DNS server MUST have sufficient internal concurrency that - it can continue to process UDP queries while awaiting a - response or performing a zone transfer on an open TCP - connection [DNS:2]. - - A server MAY support a UDP query that is delivered using an - IP broadcast or multicast address. However, the Recursion - Desired bit MUST NOT be set in a query that is multicast, - and MUST be ignored by name servers receiving queries via a - broadcast or multicast address. A host that sends broadcast - or multicast DNS queries SHOULD send them only as occasional - probes, caching the IP address(es) it obtains from the - response(s) so it can normally send unicast queries. - - DISCUSSION: - Broadcast or (especially) IP multicast can provide a - way to locate nearby name servers without knowing their - IP addresses in advance. However, general broadcasting - of recursive queries can result in excessive and - unnecessary load on both network and servers. - - - - -Internet Engineering Task Force [Page 76] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3.3 Efficient Resource Usage - - The following requirements on servers and resolvers are very - important to the health of the Internet as a whole, - particularly when DNS services are invoked repeatedly by - higher level automatic servers, such as mailers. - - (1) The resolver MUST implement retransmission controls to - insure that it does not waste communication bandwidth, - and MUST impose finite bounds on the resources consumed - to respond to a single request. See [DNS:2] pages 43- - 44 for specific recommendations. - - (2) After a query has been retransmitted several times - without a response, an implementation MUST give up and - return a soft error to the application. - - (3) All DNS name servers and resolvers SHOULD cache - temporary failures, with a timeout period of the order - of minutes. - - DISCUSSION: - This will prevent applications that immediately - retry soft failures (in violation of Section 2.2 - of this document) from generating excessive DNS - traffic. - - (4) All DNS name servers and resolvers SHOULD cache - negative responses that indicate the specified name, or - data of the specified type, does not exist, as - described in [DNS:2]. - - (5) When a DNS server or resolver retries a UDP query, the - retry interval SHOULD be constrained by an exponential - backoff algorithm, and SHOULD also have upper and lower - bounds. - - IMPLEMENTATION: - A measured RTT and variance (if available) should - be used to calculate an initial retransmission - interval. If this information is not available, a - default of no less than 5 seconds should be used. - Implementations may limit the retransmission - interval, but this limit must exceed twice the - Internet maximum segment lifetime plus service - delay at the name server. - - (6) When a resolver or server receives a Source Quench for - - - -Internet Engineering Task Force [Page 77] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - a query it has issued, it SHOULD take steps to reduce - the rate of querying that server in the near future. A - server MAY ignore a Source Quench that it receives as - the result of sending a response datagram. - - IMPLEMENTATION: - One recommended action to reduce the rate is to - send the next query attempt to an alternate - server, if there is one available. Another is to - backoff the retry interval for the same server. - - - 6.1.3.4 Multihomed Hosts - - When the host name-to-address function encounters a host - with multiple addresses, it SHOULD rank or sort the - addresses using knowledge of the immediately connected - network number(s) and any other applicable performance or - history information. - - DISCUSSION: - The different addresses of a multihomed host generally - imply different Internet paths, and some paths may be - preferable to others in performance, reliability, or - administrative restrictions. There is no general way - for the domain system to determine the best path. A - recommended approach is to base this decision on local - configuration information set by the system - administrator. - - IMPLEMENTATION: - The following scheme has been used successfully: - - (a) Incorporate into the host configuration data a - Network-Preference List, that is simply a list of - networks in preferred order. This list may be - empty if there is no preference. - - (b) When a host name is mapped into a list of IP - addresses, these addresses should be sorted by - network number, into the same order as the - corresponding networks in the Network-Preference - List. IP addresses whose networks do not appear - in the Network-Preference List should be placed at - the end of the list. - - - - - - -Internet Engineering Task Force [Page 78] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3.5 Extensibility - - DNS software MUST support all well-known, class-independent - formats [DNS:2], and SHOULD be written to minimize the - trauma associated with the introduction of new well-known - types and local experimentation with non-standard types. - - DISCUSSION: - The data types and classes used by the DNS are - extensible, and thus new types will be added and old - types deleted or redefined. Introduction of new data - types ought to be dependent only upon the rules for - compression of domain names inside DNS messages, and - the translation between printable (i.e., master file) - and internal formats for Resource Records (RRs). - - Compression relies on knowledge of the format of data - inside a particular RR. Hence compression must only be - used for the contents of well-known, class-independent - RRs, and must never be used for class-specific RRs or - RR types that are not well-known. The owner name of an - RR is always eligible for compression. - - A name server may acquire, via zone transfer, RRs that - the server doesn't know how to convert to printable - format. A resolver can receive similar information as - the result of queries. For proper operation, this data - must be preserved, and hence the implication is that - DNS software cannot use textual formats for internal - storage. - - The DNS defines domain name syntax very generally -- a - string of labels each containing up to 63 8-bit octets, - separated by dots, and with a maximum total of 255 - octets. Particular applications of the DNS are - permitted to further constrain the syntax of the domain - names they use, although the DNS deployment has led to - some applications allowing more general names. In - particular, Section 2.1 of this document liberalizes - slightly the syntax of a legal Internet host name that - was defined in RFC-952 [DNS:4]. - - 6.1.3.6 Status of RR Types - - Name servers MUST be able to load all RR types except MD and - MF from configuration files. The MD and MF types are - obsolete and MUST NOT be implemented; in particular, name - servers MUST NOT load these types from configuration files. - - - -Internet Engineering Task Force [Page 79] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - DISCUSSION: - The RR types MB, MG, MR, NULL, MINFO and RP are - considered experimental, and applications that use the - DNS cannot expect these RR types to be supported by - most domains. Furthermore these types are subject to - redefinition. - - The TXT and WKS RR types have not been widely used by - Internet sites; as a result, an application cannot rely - on the the existence of a TXT or WKS RR in most - domains. - - 6.1.3.7 Robustness - - DNS software may need to operate in environments where the - root servers or other servers are unavailable due to network - connectivity or other problems. In this situation, DNS name - servers and resolvers MUST continue to provide service for - the reachable part of the name space, while giving temporary - failures for the rest. - - DISCUSSION: - Although the DNS is meant to be used primarily in the - connected Internet, it should be possible to use the - system in networks which are unconnected to the - Internet. Hence implementations must not depend on - access to root servers before providing service for - local names. - - 6.1.3.8 Local Host Table - - DISCUSSION: - A host may use a local host table as a backup or - supplement to the DNS. This raises the question of - which takes precedence, the DNS or the host table; the - most flexible approach would make this a configuration - option. - - Typically, the contents of such a supplementary host - table will be determined locally by the site. However, - a publically-available table of Internet hosts is - maintained by the DDN Network Information Center (DDN - NIC), with a format documented in [DNS:4]. This table - can be retrieved from the DDN NIC using a protocol - described in [DNS:5]. It must be noted that this table - contains only a small fraction of all Internet hosts. - Hosts using this protocol to retrieve the DDN NIC host - table should use the VERSION command to check if the - - - -Internet Engineering Task Force [Page 80] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - table has changed before requesting the entire table - with the ALL command. The VERSION identifier should be - treated as an arbitrary string and tested only for - equality; no numerical sequence may be assumed. - - The DDN NIC host table includes administrative - information that is not needed for host operation and - is therefore not currently included in the DNS - database; examples include network and gateway entries. - However, much of this additional information will be - added to the DNS in the future. Conversely, the DNS - provides essential services (in particular, MX records) - that are not available from the DDN NIC host table. - - 6.1.4 DNS USER INTERFACE - - 6.1.4.1 DNS Administration - - This document is concerned with design and implementation - issues in host software, not with administrative or - operational issues. However, administrative issues are of - particular importance in the DNS, since errors in particular - segments of this large distributed database can cause poor - or erroneous performance for many sites. These issues are - discussed in [DNS:6] and [DNS:7]. - - 6.1.4.2 DNS User Interface - - Hosts MUST provide an interface to the DNS for all - application programs running on the host. This interface - will typically direct requests to a system process to - perform the resolver function [DNS:1, 6.1:2]. - - At a minimum, the basic interface MUST support a request for - all information of a specific type and class associated with - a specific name, and it MUST return either all of the - requested information, a hard error code, or a soft error - indication. When there is no error, the basic interface - returns the complete response information without - modification, deletion, or ordering, so that the basic - interface will not need to be changed to accommodate new - data types. - - DISCUSSION: - The soft error indication is an essential part of the - interface, since it may not always be possible to - access particular information from the DNS; see Section - 6.1.3.3. - - - -Internet Engineering Task Force [Page 81] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - A host MAY provide other DNS interfaces tailored to - particular functions, transforming the raw domain data into - formats more suited to these functions. In particular, a - host MUST provide a DNS interface to facilitate translation - between host addresses and host names. - - 6.1.4.3 Interface Abbreviation Facilities - - User interfaces MAY provide a method for users to enter - abbreviations for commonly-used names. Although the - definition of such methods is outside of the scope of the - DNS specification, certain rules are necessary to insure - that these methods allow access to the entire DNS name space - and to prevent excessive use of Internet resources. - - If an abbreviation method is provided, then: - - (a) There MUST be some convention for denoting that a name - is already complete, so that the abbreviation method(s) - are suppressed. A trailing dot is the usual method. - - (b) Abbreviation expansion MUST be done exactly once, and - MUST be done in the context in which the name was - entered. - - - DISCUSSION: - For example, if an abbreviation is used in a mail - program for a destination, the abbreviation should be - expanded into a full domain name and stored in the - queued message with an indication that it is already - complete. Otherwise, the abbreviation might be - expanded with a mail system search list, not the - user's, or a name could grow due to repeated - canonicalizations attempts interacting with wildcards. - - The two most common abbreviation methods are: - - (1) Interface-level aliases - - Interface-level aliases are conceptually implemented as - a list of alias/domain name pairs. The list can be - per-user or per-host, and separate lists can be - associated with different functions, e.g. one list for - host name-to-address translation, and a different list - for mail domains. When the user enters a name, the - interface attempts to match the name to the alias - component of a list entry, and if a matching entry can - - - -Internet Engineering Task Force [Page 82] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - be found, the name is replaced by the domain name found - in the pair. - - Note that interface-level aliases and CNAMEs are - completely separate mechanisms; interface-level aliases - are a local matter while CNAMEs are an Internet-wide - aliasing mechanism which is a required part of any DNS - implementation. - - (2) Search Lists - - A search list is conceptually implemented as an ordered - list of domain names. When the user enters a name, the - domain names in the search list are used as suffixes to - the user-supplied name, one by one, until a domain name - with the desired associated data is found, or the - search list is exhausted. Search lists often contain - the name of the local host's parent domain or other - ancestor domains. Search lists are often per-user or - per-process. - - It SHOULD be possible for an administrator to disable a - DNS search-list facility. Administrative denial may be - warranted in some cases, to prevent abuse of the DNS. - - There is danger that a search-list mechanism will - generate excessive queries to the root servers while - testing whether user input is a complete domain name, - lacking a final period to mark it as complete. A - search-list mechanism MUST have one of, and SHOULD have - both of, the following two provisions to prevent this: - - (a) The local resolver/name server can implement - caching of negative responses (see Section - 6.1.3.3). - - (b) The search list expander can require two or more - interior dots in a generated domain name before it - tries using the name in a query to non-local - domain servers, such as the root. - - DISCUSSION: - The intent of this requirement is to avoid - excessive delay for the user as the search list is - tested, and more importantly to prevent excessive - traffic to the root and other high-level servers. - For example, if the user supplied a name "X" and - the search list contained the root as a component, - - - -Internet Engineering Task Force [Page 83] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - a query would have to consult a root server before - the next search list alternative could be tried. - The resulting load seen by the root servers and - gateways near the root would be multiplied by the - number of hosts in the Internet. - - The negative caching alternative limits the effect - to the first time a name is used. The interior - dot rule is simpler to implement but can prevent - easy use of some top-level names. - - - 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|-----------|-|-|-|-|-|-- -GENERAL ISSUES | | | | | | | - | | | | | | | -Implement DNS name-to-address conversion |6.1.1 |x| | | | | -Implement DNS address-to-name conversion |6.1.1 |x| | | | | -Support conversions using host table |6.1.1 | | |x| | | -Properly handle RR with zero TTL |6.1.2.1 |x| | | | | -Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | | - Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | | -Unused fields zero |6.1.2.3 |x| | | | | -Use compression in responses |6.1.2.4 |x| | | | | - | | | | | | | -Include config info in responses |6.1.2.5 | | | | |x| -Support all well-known, class-indep. types |6.1.3.5 |x| | | | | -Easily expand type list |6.1.3.5 | |x| | | | -Load all RR types (except MD and MF) |6.1.3.6 |x| | | | | -Load MD or MF type |6.1.3.6 | | | | |x| -Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -RESOLVER ISSUES: | | | | | | | - | | | | | | | -Resolver support multiple concurrent requests |6.1.3.1 | |x| | | | -Full-service resolver: |6.1.3.1 | | |x| | | - Local caching |6.1.3.1 |x| | | | | - - - -Internet Engineering Task Force [Page 84] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Information in local cache times out |6.1.3.1 |x| | | | | - Configurable with starting info |6.1.3.1 | |x| | | | -Stub resolver: |6.1.3.1 | | |x| | | - Use redundant recursive name servers |6.1.3.1 |x| | | | | - Local caching |6.1.3.1 | | |x| | | - Information in local cache times out |6.1.3.1 |x| | | | | -Support for remote multi-homed hosts: | | | | | | | - Sort multiple addresses by preference list |6.1.3.4 | |x| | | | - | | | | | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -TRANSPORT PROTOCOLS: | | | | | | | - | | | | | | | -Support UDP queries |6.1.3.2 |x| | | | | -Support TCP queries |6.1.3.2 | |x| | | | - Send query using UDP first |6.1.3.2 |x| | | | |1 - Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | | -Name server limit TCP query resources |6.1.3.2 | | |x| | | - Punish unnecessary TCP query |6.1.3.2 | | | |x| | -Use truncated data as if it were not |6.1.3.2 | | | | |x| -Private agreement to use only TCP |6.1.3.2 | | |x| | | -Use TCP for zone transfers |6.1.3.2 |x| | | | | -TCP usage not block UDP queries |6.1.3.2 |x| | | | | -Support broadcast or multicast queries |6.1.3.2 | | |x| | | - RD bit set in query |6.1.3.2 | | | | |x| - RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | | - Send only as occasional probe for addr's |6.1.3.2 | |x| | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -RESOURCE USAGE: | | | | | | | - | | | | | | | -Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | | - Finite bounds per request |6.1.3.3 |x| | | | | -Failure after retries => soft error |6.1.3.3 |x| | | | | -Cache temporary failures |6.1.3.3 | |x| | | | -Cache negative responses |6.1.3.3 | |x| | | | -Retries use exponential backoff |6.1.3.3 | |x| | | | - Upper, lower bounds |6.1.3.3 | |x| | | | -Client handle Source Quench |6.1.3.3 | |x| | | | -Server ignore Source Quench |6.1.3.3 | | |x| | | ------------------------------------------------|-----------|-|-|-|-|-|-- -USER INTERFACE: | | | | | | | - | | | | | | | -All programs have access to DNS interface |6.1.4.2 |x| | | | | -Able to request all info for given name |6.1.4.2 |x| | | | | -Returns complete info or error |6.1.4.2 |x| | | | | -Special interfaces |6.1.4.2 | | |x| | | - Name<->Address translation |6.1.4.2 |x| | | | | - | | | | | | | -Abbreviation Facilities: |6.1.4.3 | | |x| | | - - - -Internet Engineering Task Force [Page 85] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Convention for complete names |6.1.4.3 |x| | | | | - Conversion exactly once |6.1.4.3 |x| | | | | - Conversion in proper context |6.1.4.3 |x| | | | | - Search list: |6.1.4.3 | | |x| | | - Administrator can disable |6.1.4.3 | |x| | | | - Prevention of excessive root queries |6.1.4.3 |x| | | | | - Both methods |6.1.4.3 | |x| | | | ------------------------------------------------|-----------|-|-|-|-|-|-- ------------------------------------------------|-----------|-|-|-|-|-|-- - -1. Unless there is private agreement between particular resolver and - particular server. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 86] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - 6.2 HOST INITIALIZATION - - 6.2.1 INTRODUCTION - - This section discusses the initialization of host software - across a connected network, or more generally across an - Internet path. This is necessary for a diskless host, and may - optionally be used for a host with disk drives. For a diskless - host, the initialization process is called "network booting" - and is controlled by a bootstrap program located in a boot ROM. - - To initialize a diskless host across the network, there are two - distinct phases: - - (1) Configure the IP layer. - - Diskless machines often have no permanent storage in which - to store network configuration information, so that - sufficient configuration information must be obtained - dynamically to support the loading phase that follows. - This information must include at least the IP addresses of - the host and of the boot server. To support booting - across a gateway, the address mask and a list of default - gateways are also required. - - (2) Load the host system code. - - During the loading phase, an appropriate file transfer - protocol is used to copy the system code across the - network from the boot server. - - A host with a disk may perform the first step, dynamic - configuration. This is important for microcomputers, whose - floppy disks allow network configuration information to be - mistakenly duplicated on more than one host. Also, - installation of new hosts is much simpler if they automatically - obtain their configuration information from a central server, - saving administrator time and decreasing the probability of - mistakes. - - 6.2.2 REQUIREMENTS - - 6.2.2.1 Dynamic Configuration - - A number of protocol provisions have been made for dynamic - configuration. - - o ICMP Information Request/Reply messages - - - -Internet Engineering Task Force [Page 87] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - This obsolete message pair was designed to allow a host - to find the number of the network it is on. - Unfortunately, it was useful only if the host already - knew the host number part of its IP address, - information that hosts requiring dynamic configuration - seldom had. - - o Reverse Address Resolution Protocol (RARP) [BOOT:4] - - RARP is a link-layer protocol for a broadcast medium - that allows a host to find its IP address given its - link layer address. Unfortunately, RARP does not work - across IP gateways and therefore requires a RARP server - on every network. In addition, RARP does not provide - any other configuration information. - - o ICMP Address Mask Request/Reply messages - - These ICMP messages allow a host to learn the address - mask for a particular network interface. - - o BOOTP Protocol [BOOT:2] - - This protocol allows a host to determine the IP - addresses of the local host and the boot server, the - name of an appropriate boot file, and optionally the - address mask and list of default gateways. To locate a - BOOTP server, the host broadcasts a BOOTP request using - UDP. Ad hoc gateway extensions have been used to - transmit the BOOTP broadcast through gateways, and in - the future the IP Multicasting facility will provide a - standard mechanism for this purpose. - - - The suggested approach to dynamic configuration is to use - the BOOTP protocol with the extensions defined in "BOOTP - Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 - defines some important general (not vendor-specific) - extensions. In particular, these extensions allow the - address mask to be supplied in BOOTP; we RECOMMEND that the - address mask be supplied in this manner. - - DISCUSSION: - Historically, subnetting was defined long after IP, and - so a separate mechanism (ICMP Address Mask messages) - was designed to supply the address mask to a host. - However, the IP address mask and the corresponding IP - address conceptually form a pair, and for operational - - - -Internet Engineering Task Force [Page 88] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - simplicity they ought to be defined at the same time - and by the same mechanism, whether a configuration file - or a dynamic mechanism like BOOTP. - - Note that BOOTP is not sufficiently general to specify - the configurations of all interfaces of a multihomed - host. A multihomed host must either use BOOTP - separately for each interface, or configure one - interface using BOOTP to perform the loading, and - perform the complete initialization from a file later. - - Application layer configuration information is expected - to be obtained from files after loading of the system - code. - - 6.2.2.2 Loading Phase - - A suggested approach for the loading phase is to use TFTP - [BOOT:1] between the IP addresses established by BOOTP. - - TFTP to a broadcast address SHOULD NOT be used, for reasons - explained in Section 4.2.3.4. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 89] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - 6.3 REMOTE MANAGEMENT - - 6.3.1 INTRODUCTION - - The Internet community has recently put considerable effort - into the development of network management protocols. The - result has been a two-pronged approach [MGT:1, MGT:6]: the - Simple Network Management Protocol (SNMP) [MGT:4] and the - Common Management Information Protocol over TCP (CMOT) [MGT:5]. - - In order to be managed using SNMP or CMOT, a host will need to - implement an appropriate management agent. An Internet host - SHOULD include an agent for either SNMP or CMOT. - - Both SNMP and CMOT operate on a Management Information Base - (MIB) that defines a collection of management values. By - reading and setting these values, a remote application may - query and change the state of the managed system. - - A standard MIB [MGT:3] has been defined for use by both - management protocols, using data types defined by the Structure - of Management Information (SMI) defined in [MGT:2]. Additional - MIB variables can be introduced under the "enterprises" and - "experimental" subtrees of the MIB naming space [MGT:2]. - - Every protocol module in the host SHOULD implement the relevant - MIB variables. A host SHOULD implement the MIB variables as - defined in the most recent standard MIB, and MAY implement - other MIB variables when appropriate and useful. - - 6.3.2 PROTOCOL WALK-THROUGH - - The MIB is intended to cover both hosts and gateways, although - there may be detailed differences in MIB application to the two - cases. This section contains the appropriate interpretation of - the MIB for hosts. It is likely that later versions of the MIB - will include more entries for host management. - - A managed host must implement the following groups of MIB - object definitions: System, Interfaces, Address Translation, - IP, ICMP, TCP, and UDP. - - The following specific interpretations apply to hosts: - - o ipInHdrErrors - - Note that the error "time-to-live exceeded" can occur in a - host only when it is forwarding a source-routed datagram. - - - -Internet Engineering Task Force [Page 90] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - o ipOutNoRoutes - - This object counts datagrams discarded because no route - can be found. This may happen in a host if all the - default gateways in the host's configuration are down. - - o ipFragOKs, ipFragFails, ipFragCreates - - A host that does not implement intentional fragmentation - (see "Fragmentation" section of [INTRO:1]) MUST return the - value zero for these three objects. - - o icmpOutRedirects - - For a host, this object MUST always be zero, since hosts - do not send Redirects. - - o icmpOutAddrMaskReps - - For a host, this object MUST always be zero, unless the - host is an authoritative source of address mask - information. - - o ipAddrTable - - For a host, the "IP Address Table" object is effectively a - table of logical interfaces. - - o ipRoutingTable - - For a host, the "IP Routing Table" object is effectively a - combination of the host's Routing Cache and the static - route table described in "Routing Outbound Datagrams" - section of [INTRO:1]. - - Within each ipRouteEntry, ipRouteMetric1...4 normally will - have no meaning for a host and SHOULD always be -1, while - ipRouteType will normally have the value "remote". - - If destinations on the connected network do not appear in - the Route Cache (see "Routing Outbound Datagrams section - of [INTRO:1]), there will be no entries with ipRouteType - of "direct". - - - DISCUSSION: - The current MIB does not include Type-of-Service in an - ipRouteEntry, but a future revision is expected to make - - - -Internet Engineering Task Force [Page 91] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - this addition. - - We also expect the MIB to be expanded to allow the remote - management of applications (e.g., the ability to partially - reconfigure mail systems). Network service applications - such as mail systems should therefore be written with the - "hooks" for remote management. - - 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|-----------|-|-|-|-|-|-- -Support SNMP or CMOT agent |6.3.1 | |x| | | | -Implement specified objects in standard MIB |6.3.1 | |x| | | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 92] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - -7. REFERENCES - - This section lists the primary references with which every - implementer must be thoroughly familiar. It also lists some - secondary references that are suggested additional reading. - - INTRODUCTORY REFERENCES: - - - [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," - IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, - October 1989. - - [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, - (three volumes), SRI International, December 1985. - - [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, - RFC-1011, May 1987. - - This document is republished periodically with new RFC numbers; - the latest version must be used. - - [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. - Postel, RFC-980, March 1986. - - [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, - May 1987. - - This document is republished periodically with new RFC numbers; - the latest version must be used. - - - TELNET REFERENCES: - - - [TELNET:1] "Telnet Protocol Specification," J. Postel and J. - Reynolds, RFC-854, May 1983. - - [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, - RFC-855, May 1983. - - [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, - RFC-856, May 1983. - - [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, - May 1983. - - [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. - - - -Internet Engineering Task Force [Page 93] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - Reynolds, RFC-858, May 1983. - - [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC- - 859, May 1983. - - [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, - RFC-860, May 1983. - - [TELNET:8] "Telnet Extended Options List," J. Postel and J. - Reynolds, RFC-861, May 1983. - - [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, - December 1983. - - [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, - February 1989. - - This document supercedes RFC-930. - - [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, - October 1988. - - [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August - 1989. - - [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, - December 1988. - - [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC- - 1080, November 1988. - - - SECONDARY TELNET REFERENCES: - - - [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of - Defense, May 1984. - - This document is intended to describe the same protocol as RFC- - 854. In case of conflict, RFC-854 takes precedence, and the - present document takes precedence over both. - - [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977. - - [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October - 1977. - - [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977. - - - -Internet Engineering Task Force [Page 94] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS - Implementation," A. Yasuda and T. Thompson, RFC-1043, February - 1988. - - - FTP REFERENCES: - - - [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC- - 959, October 1985. - - [FTP:2] "Document File Format Standards," J. Postel, RFC-678, - December 1974. - - [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of - Defense, May 1984. - - This document is based on an earlier version of the FTP - specification (RFC-765) and is obsolete. - - - TFTP REFERENCES: - - - [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June - 1981. - - - MAIL REFERENCES: - - - [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August - 1982. - - [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," - D. Crocker, RFC-822, August 1982. - - This document obsoleted an earlier specification, RFC-733. - - [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC- - 974, January 1986. - - This RFC describes the use of MX records, a mandatory extension - to the mail delivery process. - - [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, - February 1988. - - - - -Internet Engineering Task Force [Page 95] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, - June 1986. - - [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. - - The two preceding RFC's define a proposed standard for - gatewaying mail between the Internet and the X.400 environments. - - [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. - Department of Defense, May 1984. - - This specification is intended to describe the same protocol as - does RFC-821. However, MIL-STD-1781 is incomplete; in - particular, it does not include MX records [SMTP:3]. - - [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, - RFC-1049, March 1988. - - - DOMAIN NAME SYSTEM REFERENCES: - - - [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, - RFC-1034, November 1987. - - This document and the following one obsolete RFC-882, RFC-883, - and RFC-973. - - [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, - P. Mockapetris, November 1987. - - - [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, - January 1986. - - - [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, - RFC-952, M. Stahl, E. Feinler, October 1985. - - SECONDARY DNS REFERENCES: - - - [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, - RFC-953, October 1985. - - [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November - 1987. - - - - -Internet Engineering Task Force [Page 96] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC- - 1033, November 1987. - - [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet - Protocol Handbook, NIC 50007, SRI Network Information Center, - August 1989. - - - SYSTEM INITIALIZATION REFERENCES: - - - [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June - 1984. - - [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC- - 951, September 1985. - - [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC- - 1084, December 1988. - - Note: this RFC revised and obsoleted RFC-1048. - - [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. - Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. - - - MANAGEMENT REFERENCES: - - - [MGT:1] "IAB Recommendations for the Development of Internet Network - Management Standards," V. Cerf, RFC-1052, April 1988. - - [MGT:2] "Structure and Identification of Management Information for - TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, - August 1988. - - [MGT:3] "Management Information Base for Network Management of - TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, - August 1988. - - [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, - M. Schoffstall, and C. Davin, RFC-1098, April 1989. - - [MGT:5] "The Common Management Information Services and Protocol - over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. - - [MGT:6] "Report of the Second Ad Hoc Network Management Review - Group," V. Cerf, RFC-1109, August 1989. - - - -Internet Engineering Task Force [Page 97] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - -Security Considerations - - There are many security issues in the application and support - programs of host software, but a full discussion is beyond the scope - of this RFC. Security-related issues are mentioned in sections - concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and - EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the - SMTP DATA command (Section 5.2.8). - -Author's Address - - Robert Braden - USC/Information Sciences Institute - 4676 Admiralty Way - Marina del Rey, CA 90292-6695 - - Phone: (213) 822 1511 - - EMail: Braden@ISI.EDU - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 98] - diff --git a/server/src/site/resources/rfclist/basic/rfc2045.txt b/server/src/site/resources/rfclist/basic/rfc2045.txt deleted file mode 100644 index 0179984eae5..00000000000 --- a/server/src/site/resources/rfclist/basic/rfc2045.txt +++ /dev/null @@ -1,1740 +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 := - - x-token := - - subtype := extension-token / iana-token - - iana-token := - - parameter := attribute "=" value - - attribute := token - ; Matching of attributes - ; is ALWAYS case-insensitive. - - value := token / quoted-string - - token := 1* - - 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 := - ; 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 := - -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 := - - - - -Freed & Borenstein Standards Track [Page 29] - -RFC 2045 Internet Message Bodies November 1996 - - - ietf-token := - - id := "Content-ID" ":" msg-id - - mechanism := "7bit" / "8bit" / "binary" / - "quoted-printable" / "base64" / - ietf-token / x-token - - MIME-extension-field := - - 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 := - ; Characters not listed as "mail-safe" in - ; RFC 2049 are also not recommended. - - subtype := extension-token / iana-token - - token := 1* - - 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 := - - - - - - - - - - - - - - - - - - - - -Freed & Borenstein Standards Track [Page 31] - - - diff --git a/server/src/site/resources/rfclist/basic/rfc2046.txt b/server/src/site/resources/rfclist/basic/rfc2046.txt deleted file mode 100644 index ee204a53722..00000000000 --- a/server/src/site/resources/rfclist/basic/rfc2046.txt +++ /dev/null @@ -1,2468 +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 - To: Ned Freed - 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 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 := - - 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 - To: Ned Freed - 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: - 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: - 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: - 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: - 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: - 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: - Content-Type: multipart/alternative; boundary=42 - Content-ID: - - --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: - - --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: - - --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: - - 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 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/server/src/site/resources/rfclist/basic/rfc2822.txt b/server/src/site/resources/rfclist/basic/rfc2822.txt deleted file mode 100644 index 92b3ec28ba7..00000000000 --- a/server/src/site/resources/rfclist/basic/rfc2822.txt +++ /dev/null @@ -1,2858 +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 -To: Mary Smith -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 -Sender: Michael Jones -To: Mary Smith -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" -To: Mary Smith , jdoe@example.org, Who? -Cc: , "Giant; \"Big\" Box" -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 -To: A Group:Chris Jones ,joe@where.test,John ; -Cc: Undisclosed recipients:; -Date: Thu, 13 Feb 1969 23:32:54 -0330 -Message-ID: - -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 -To: Mary Smith -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 -To: John Doe -Reply-To: "Mary Smith: Personal Account" -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" -From: John Doe -Subject: Re: Saying Hello -Date: Fri, 21 Nov 1997 11:00:00 -0600 -Message-ID: -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 -To: Mary Smith -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 -Resent-To: Jane Brown -Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 -Resent-Message-ID: <78910@example.net> -From: John Doe -To: Mary Smith -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 ; 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 -To: Mary Smith -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) -To:A Group(Some people) - :Chris Jones , - joe@example.org, - John (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: - -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 -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 -To: Mary Smith -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 -To : Mary Smith -__ - -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/server/src/site/resources/rfclist/imap4/rfc1731.txt b/server/src/site/resources/rfclist/imap4/rfc1731.txt deleted file mode 100644 index 7c3f9535163..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc1731.txt +++ /dev/null @@ -1,340 +0,0 @@ - - - - - -Network Working Group J. Myers -Request for Comments: 1731 Carnegie Mellon -Category: Standards Track December 1994 - - - IMAP4 Authentication Mechanisms - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - - -1. Introduction - - The Internet Message Access Protocol, Version 4 [IMAP4] contains the - AUTHENTICATE command, for identifying and authenticating a user to an - IMAP4 server and for optionally negotiating a protection mechanism - for subsequent protocol interactions. This document describes - several authentication mechanisms for use by the IMAP4 AUTHENTICATE - command. - - -2. Kerberos version 4 authentication mechanism - - The authentication type associated with Kerberos version 4 is - "KERBEROS_V4". - - The data encoded in the first ready response contains a random 32-bit - number in network byte order. The client should respond with a - Kerberos ticket and an authenticator for the principal - "imap.hostname@realm", where "hostname" is the first component of the - host name of the server with all letters in lower case and where - "realm" is the Kerberos realm of the server. The encrypted checksum - field included within the Kerberos authenticator should contain the - server provided 32-bit number in network byte order. - - Upon decrypting and verifying the ticket and authenticator, the - server should verify that the contained checksum field equals the - original server provided random 32-bit number. Should the - verification be successful, the server must add one to the checksum - and construct 8 octets of data, with the first four octets containing - the incremented checksum in network byte order, the fifth octet - containing a bit-mask specifying the protection mechanisms supported - by the server, and the sixth through eighth octets containing, in - - - -Myers [Page 1] - -RFC 1731 IMAP4 Authentication Mechanisms December 1994 - - - network byte order, the maximum cipher-text buffer size the server is - able to receive. The server must encrypt the 8 octets of data in the - session key and issue that encrypted data in a second ready response. - The client should consider the server authenticated if the first four - octets the un-encrypted data is equal to one plus the checksum it - previously sent. - - The client must construct data with the first four octets containing - the original server-issued checksum in network byte order, the fifth - octet containing the bit-mask specifying the selected protection - mechanism, the sixth through eighth octets containing in network byte - order the maximum cipher-text buffer size the client is able to - receive, and the following octets containing a user name string. The - client must then append from one to eight octets so that the length - of the data is a multiple of eight octets. The client must then PCBC - encrypt the data with the session key and respond to the second ready - response with the encrypted data. The server decrypts the data and - verifies the contained checksum. The username field identifies the - user for whom subsequent IMAP operations are to be performed; the - server must verify that the principal identified in the Kerberos - ticket is authorized to connect as that user. After these - verifications, the authentication process is complete. - - The protection mechanisms and their corresponding bit-masks are as - follows: - - 1 No protection mechanism - 2 Integrity (krb_mk_safe) protection - 4 Privacy (krb_mk_priv) protection - - - EXAMPLE: The following are two Kerberos version 4 login scenarios - (note that the line breaks in the sample authenticators are for - editorial clarity and are not in real authenticators) - - S: * OK IMAP4 Server - C: A001 AUTHENTICATE KERBEROS_V4 - S: + AmFYig== - C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT - +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd - WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh - S: + or//EoAADZI= - C: DiAF5A4gA+oOIALuBkAAmw== - S: A001 OK Kerberos V4 authentication successful - - - - - - - -Myers [Page 2] - -RFC 1731 IMAP4 Authentication Mechanisms December 1994 - - - S: * OK IMAP4 Server - C: A001 AUTHENTICATE KERBEROS_V4 - S: + gcfgCA== - C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT - +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd - WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh - S: A001 NO Kerberos V4 authentication failed - - -3. GSSAPI authentication mechanism - - The authentication type associated with all mechanisms employing the - GSSAPI [RFC1508] is "GSSAPI". - - The first ready response issued by the server contains no data. The - client should call GSS_Init_sec_context, passing in 0 for - input_context_handle (initially) and a targ_name equal to output_name - from GSS_Import_Name called with input_name_type of NULL and - input_name_string of "SERVICE:imap@hostname" where "hostname" is the - fully qualified host name of the server with all letters in lower - case. The client must then respond with the resulting output_token. - If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client - should expect the server to issue a token in a subsequent ready - response. The client must pass the token to another call to - GSS_Init_sec_context. - - If GSS_Init_sec_context returns GSS_COMPLETE, then the client should - respond with any resulting output_token. If there is no - output_token, the client should respond with no data. The client - should then expect the server to issue a token in a subsequent ready - response. The client should pass this token to GSS_Unseal and - interpret the first octet of resulting cleartext as a bit-mask - specifying the protection mechanisms supported by the server and the - second through fourth octets as the maximum size output_message to - send to the server. The client should construct data, with the first - octet containing the bit-mask specifying the selected protection - mechanism, the second through fourth octets containing in network - byte order the maximum size output_message the client is able to - receive, and the remaining octets containing a user name string. The - client must pass the data to GSS_Seal with conf_flag set to FALSE, - and respond with the generated output_message. The client can then - consider the server authenticated. - - The server must issue a ready response with no data and pass the - resulting client supplied token to GSS_Accept_sec_context as - input_token, setting acceptor_cred_handle to NULL (for "use default - credentials"), and 0 for input_context_handle (initially). If - GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should - - - -Myers [Page 3] - -RFC 1731 IMAP4 Authentication Mechanisms December 1994 - - - return the generated output_token to the client in a ready response - and pass the resulting client supplied token to another call to - GSS_Accept_sec_context. - - If GSS_Accept_sec_context returns GSS_COMPLETE, then if an - output_token is returned, the server should return it to the client - in a ready response and expect a reply from the client with no data. - Whether or not an output_token was returned, the server then should - then construct 4 octets of data, with the first octet containing a - bit-mask specifying the protection mechanisms supported by the server - and the second through fourth octets containing in network byte order - the maximum size output_token the server is able to receive. The - server must then pass the plaintext to GSS_Seal with conf_flag set to - FALSE and issue the generated output_message to the client in a ready - response. The server must then pass the resulting client supplied - token to GSS_Unseal and interpret the first octet of resulting - cleartext as the bit-mask for the selected protection mechanism, the - second through fourth octets as the maximum size output_message to - send to the client, and the remaining octets as the user name. Upon - verifying the src_name is authorized to authenticate as the user - name, The server should then consider the client authenticated. - - The protection mechanisms and their corresponding bit-masks are as - follows: - - 1 No protection mechanism - 2 Integrity protection. - Sender calls GSS_Seal with conf_flag set to FALSE - 4 Privacy protection. - Sender calls GSS_Seal with conf_flag set to TRUE - - -4. S/Key authentication mechanism - - The authentication type associated with S/Key [SKEY] is "SKEY". - - The first ready response issued by the server contains no data. The - client responds with the user name string. - - The data encoded in the second ready response contains the decimal - sequence number followed by a single space and the seed string for - the indicated user. The client responds with the one-time-password, - as either a 64-bit value in network byte order or encoded in the "six - English words" format. - - Upon successful verification of the one-time-password, the server - should consider the client authenticated. - - - - -Myers [Page 4] - -RFC 1731 IMAP4 Authentication Mechanisms December 1994 - - - S/Key authentication does not provide for any protection mechanisms. - - - EXAMPLE: The following are two S/Key login scenarios. - - S: * OK IMAP4 Server - C: A001 AUTHENTICATE SKEY - S: + - C: bW9yZ2Fu - S: + OTUgUWE1ODMwOA== - C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== - S: A001 OK S/Key authentication successful - - - S: * OK IMAP4 Server - C: A001 AUTHENTICATE SKEY - S: + - C: c21pdGg= - S: + OTUgUWE1ODMwOA== - C: BsAY3g4gBNo= - S: A001 NO S/Key authentication failed - - -5. References - - [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", - RFC 1730, University of Washington, December 1994. - - [RFC1508] Linn, J., "Generic Security Service Application Program - Interface", RFC 1508, Geer Zolot Associates, September 1993. - - [SKEY] Haller, Neil M. "The S/Key One-Time Password System", - Bellcore, Morristown, New Jersey, October 1993, - thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps - - - - - - - - - - - - - - - - - -Myers [Page 5] - -RFC 1731 IMAP4 Authentication Mechanisms December 1994 - - -6. Security Considerations - - Security issues are discussed throughout this memo. - - -7. Author's Address - - John G. Myers - Carnegie-Mellon University - 5000 Forbes Ave. - Pittsburgh PA, 15213-3890 - - EMail: jgm+@cmu.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers [Page 6] - - - diff --git a/server/src/site/resources/rfclist/imap4/rfc2060.txt b/server/src/site/resources/rfclist/imap4/rfc2060.txt deleted file mode 100644 index 5c31eb99642..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2060.txt +++ /dev/null @@ -1,4596 +0,0 @@ - - - - - -Network Working Group M. Crispin -Request for Comments: 2060 University of Washington -Obsoletes: 1730 December 1996 -Category: Standards Track - - - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) - allows a client to access and manipulate electronic mail messages on - a server. IMAP4rev1 permits manipulation of remote message folders, - called "mailboxes", in a way that is functionally equivalent to local - mailboxes. IMAP4rev1 also provides the capability for an offline - client to resynchronize with the server (see also [IMAP-DISC]). - - IMAP4rev1 includes operations for creating, deleting, and renaming - mailboxes; checking for new messages; permanently removing messages; - setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; - searching; and selective fetching of message attributes, texts, and - portions thereof. Messages in IMAP4rev1 are accessed by the use of - numbers. These numbers are either message sequence numbers or unique - identifiers. - - IMAP4rev1 supports a single server. A mechanism for accessing - configuration information to support multiple IMAP4rev1 servers is - discussed in [ACAP]. - - IMAP4rev1 does not specify a means of posting mail; this function is - handled by a mail transfer protocol such as [SMTP]. - - IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and - unpublished IMAP2bis protocols. In the course of the evolution of - IMAP4rev1, some aspects in the earlier protocol have become obsolete. - Obsolete commands, responses, and data formats which an IMAP4rev1 - implementation may encounter when used with an earlier implementation - are described in [IMAP-OBSOLETE]. - - - - - -Crispin Standards Track [Page 1] - -RFC 2060 IMAP4rev1 December 1996 - - - Other compatibility issues with IMAP2bis, the most common variant of - the earlier protocol, are discussed in [IMAP-COMPAT]. A full - discussion of compatibility issues with rare (and presumed extinct) - variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is - primarily of historical interest. - -Table of Contents - -IMAP4rev1 Protocol Specification .................................. 4 -1. How to Read This Document ................................. 4 -1.1. Organization of This Document ............................. 4 -1.2. Conventions Used in This Document ......................... 4 -2. Protocol Overview ......................................... 5 -2.1. Link Level ................................................ 5 -2.2. Commands and Responses .................................... 6 -2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 6 -2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 7 -2.3. Message Attributes ........................................ 7 -2.3.1. Message Numbers ........................................... 7 -2.3.1.1. Unique Identifier (UID) Message Attribute ......... 7 -2.3.1.2. Message Sequence Number Message Attribute ......... 9 -2.3.2. Flags Message Attribute .................................... 9 -2.3.3. Internal Date Message Attribute ........................... 10 -2.3.4. [RFC-822] Size Message Attribute .......................... 11 -2.3.5. Envelope Structure Message Attribute ...................... 11 -2.3.6. Body Structure Message Attribute .......................... 11 -2.4. Message Texts ............................................. 11 -3. State and Flow Diagram .................................... 11 -3.1. Non-Authenticated State ................................... 11 -3.2. Authenticated State ....................................... 11 -3.3. Selected State ............................................ 12 -3.4. Logout State .............................................. 12 -4. Data Formats .............................................. 12 -4.1. Atom ...................................................... 13 -4.2. Number .................................................... 13 -4.3. String ..................................................... 13 -4.3.1. 8-bit and Binary Strings .................................. 13 -4.4. Parenthesized List ........................................ 14 -4.5. NIL ....................................................... 14 -5. Operational Considerations ................................ 14 -5.1. Mailbox Naming ............................................ 14 -5.1.1. Mailbox Hierarchy Naming .................................. 14 -5.1.2. Mailbox Namespace Naming Convention ....................... 14 -5.1.3. Mailbox International Naming Convention ................... 15 -5.2. Mailbox Size and Message Status Updates ................... 16 -5.3. Response when no Command in Progress ...................... 16 -5.4. Autologout Timer .......................................... 16 -5.5. Multiple Commands in Progress ............................. 17 - - - -Crispin Standards Track [Page 2] - -RFC 2060 IMAP4rev1 December 1996 - - -6. Client Commands ........................................... 17 -6.1. Client Commands - Any State ............................... 18 -6.1.1. CAPABILITY Command ........................................ 18 -6.1.2. NOOP Command .............................................. 19 -6.1.3. LOGOUT Command ............................................ 20 -6.2. Client Commands - Non-Authenticated State ................. 20 -6.2.1. AUTHENTICATE Command ...................................... 21 -6.2.2. LOGIN Command ............................................. 22 -6.3. Client Commands - Authenticated State ..................... 22 -6.3.1. SELECT Command ............................................ 23 -6.3.2. EXAMINE Command ........................................... 24 -6.3.3. CREATE Command ............................................ 25 -6.3.4. DELETE Command ............................................ 26 -6.3.5. RENAME Command ............................................ 27 -6.3.6. SUBSCRIBE Command ......................................... 29 -6.3.7. UNSUBSCRIBE Command ....................................... 30 -6.3.8. LIST Command .............................................. 30 -6.3.9. LSUB Command .............................................. 32 -6.3.10. STATUS Command ............................................ 33 -6.3.11. APPEND Command ............................................ 34 -6.4. Client Commands - Selected State .......................... 35 -6.4.1. CHECK Command ............................................. 36 -6.4.2. CLOSE Command ............................................. 36 -6.4.3. EXPUNGE Command ........................................... 37 -6.4.4. SEARCH Command ............................................ 37 -6.4.5. FETCH Command ............................................. 41 -6.4.6. STORE Command ............................................. 45 -6.4.7. COPY Command .............................................. 46 -6.4.8. UID Command ............................................... 47 -6.5. Client Commands - Experimental/Expansion .................. 48 -6.5.1. X Command ........................................... 48 -7. Server Responses .......................................... 48 -7.1. Server Responses - Status Responses ....................... 49 -7.1.1. OK Response ............................................... 51 -7.1.2. NO Response ............................................... 51 -7.1.3. BAD Response .............................................. 52 -7.1.4. PREAUTH Response .......................................... 52 -7.1.5. BYE Response .............................................. 52 -7.2. Server Responses - Server and Mailbox Status .............. 53 -7.2.1. CAPABILITY Response ....................................... 53 -7.2.2. LIST Response .............................................. 54 -7.2.3. LSUB Response ............................................. 55 -7.2.4 STATUS Response ........................................... 55 -7.2.5. SEARCH Response ........................................... 55 -7.2.6. FLAGS Response ............................................ 56 -7.3. Server Responses - Mailbox Size ........................... 56 -7.3.1. EXISTS Response ........................................... 56 -7.3.2. RECENT Response ........................................... 57 - - - -Crispin Standards Track [Page 3] - -RFC 2060 IMAP4rev1 December 1996 - - -7.4. Server Responses - Message Status ......................... 57 -7.4.1. EXPUNGE Response .......................................... 57 -7.4.2. FETCH Response ............................................ 58 -7.5. Server Responses - Command Continuation Request ........... 63 -8. Sample IMAP4rev1 connection ............................... 63 -9. Formal Syntax ............................................. 64 -10. Author's Note ............................................. 74 -11. Security Considerations ................................... 74 -12. Author's Address .......................................... 75 -Appendices ........................................................ 76 -A. References ................................................ 76 -B. Changes from RFC 1730 ..................................... 77 -C. Key Word Index ............................................ 79 - - -IMAP4rev1 Protocol Specification - -1. How to Read This Document - -1.1. Organization of This Document - - This document is written from the point of view of the implementor of - an IMAP4rev1 client or server. Beyond the protocol overview in - section 2, it is not optimized for someone trying to understand the - operation of the protocol. The material in sections 3 through 5 - provides the general context and definitions with which IMAP4rev1 - operates. - - Sections 6, 7, and 9 describe the IMAP commands, responses, and - syntax, respectively. The relationships among these are such that it - is almost impossible to understand any of them separately. In - particular, do not attempt to deduce command syntax from the command - section alone; instead refer to the Formal Syntax section. - -1.2. Conventions Used in This Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - - The following terms are used in this document to signify the - requirements of this specification. - - 1) MUST, or the adjective REQUIRED, means that the definition is - an absolute requirement of the specification. - - 2) MUST NOT that the definition is an absolute prohibition of the - specification. - - - - -Crispin Standards Track [Page 4] - -RFC 2060 IMAP4rev1 December 1996 - - - 3) SHOULD means that there may exist valid reasons in particular - circumstances to ignore a particular item, but the full - implications MUST be understood and carefully weighed before - choosing a different course. - - 4) SHOULD NOT means that there may exist valid reasons in - particular circumstances when the particular behavior is - acceptable or even useful, but the full implications SHOULD be - understood and the case carefully weighed before implementing - any behavior described with this label. - - 5) MAY, or the adjective OPTIONAL, means that an item is truly - optional. One vendor may choose to include the item because a - particular marketplace requires it or because the vendor feels - that it enhances the product while another vendor may omit the - same item. An implementation which does not include a - particular option MUST be prepared to interoperate with another - implementation which does include the option. - - "Can" is used instead of "may" when referring to a possible - circumstance or situation, as opposed to an optional facility of - the protocol. - - "User" is used to refer to a human user, whereas "client" refers - to the software being run by the user. - - "Connection" refers to the entire sequence of client/server - interaction from the initial establishment of the network - connection until its termination. "Session" refers to the - sequence of client/server interaction from the time that a mailbox - is selected (SELECT or EXAMINE command) until the time that - selection ends (SELECT or EXAMINE of another mailbox, CLOSE - command, or connection termination). - - Characters are 7-bit US-ASCII unless otherwise specified. Other - character sets are indicated using a "CHARSET", as described in - [MIME-IMT] and defined in [CHARSET]. CHARSETs have important - additional semantics in addition to defining character set; refer - to these documents for more detail. - -2. Protocol Overview - -2.1. Link Level - - The IMAP4rev1 protocol assumes a reliable data stream such as - provided by TCP. When TCP is used, an IMAP4rev1 server listens on - port 143. - - - - -Crispin Standards Track [Page 5] - -RFC 2060 IMAP4rev1 December 1996 - - -2.2. Commands and Responses - - An IMAP4rev1 connection consists of the establishment of a - client/server network connection, an initial greeting from the - server, and client/server interactions. These client/server - interactions consist of a client command, server data, and a server - completion result response. - - All interactions transmitted by client and server are in the form of - lines; that is, strings that end with a CRLF. The protocol receiver - of an IMAP4rev1 client or server is either reading a line, or is - reading a sequence of octets with a known count followed by a line. - -2.2.1. Client Protocol Sender and Server Protocol Receiver - - The client command begins an operation. Each client command is - prefixed with an identifier (typically a short alphanumeric string, - e.g. A0001, A0002, etc.) called a "tag". A different tag is - generated by the client for each command. - - There are two cases in which a line from the client does not - represent a complete command. In one case, a command argument is - quoted with an octet count (see the description of literal in String - under Data Formats); in the other case, the command arguments require - server feedback (see the AUTHENTICATE command). In either case, the - server sends a command continuation request response if it is ready - for the octets (if appropriate) and the remainder of the command. - This response is prefixed with the token "+". - - Note: If, instead, the server detected an error in the command, it - sends a BAD completion response with tag matching the command (as - described below) to reject the command and prevent the client from - sending any more of the command. - - It is also possible for the server to send a completion response - for some other command (if multiple commands are in progress), or - untagged data. In either case, the command continuation request - is still pending; the client takes the appropriate action for the - response, and reads another response from the server. In all - cases, the client MUST send a complete command (including - receiving all command continuation request responses and command - continuations for the command) before initiating a new command. - - The protocol receiver of an IMAP4rev1 server reads a command line - from the client, parses the command and its arguments, and transmits - server data and a server command completion result response. - - - - - -Crispin Standards Track [Page 6] - -RFC 2060 IMAP4rev1 December 1996 - - -2.2.2. Server Protocol Sender and Client Protocol Receiver - - Data transmitted by the server to the client and status responses - that do not indicate command completion are prefixed with the token - "*", and are called untagged responses. - - Server data MAY be sent as a result of a client command, or MAY be - sent unilaterally by the server. There is no syntactic difference - between server data that resulted from a specific command and server - data that were sent unilaterally. - - The server completion result response indicates the success or - failure of the operation. It is tagged with the same tag as the - client command which began the operation. Thus, if more than one - command is in progress, the tag in a server completion response - identifies the command to which the response applies. There are - three possible server completion responses: OK (indicating success), - NO (indicating failure), or BAD (indicating protocol error such as - unrecognized command or command syntax error). - - The protocol receiver of an IMAP4rev1 client reads a response line - from the server. It then takes action on the response based upon the - first token of the response, which can be a tag, a "*", or a "+". - - A client MUST be prepared to accept any server response at all times. - This includes server data that was not requested. Server data SHOULD - be recorded, so that the client can reference its recorded copy - rather than sending a command to the server to request the data. In - the case of certain server data, the data MUST be recorded. - - This topic is discussed in greater detail in the Server Responses - section. - -2.3. Message Attributes - - In addition to message text, each message has several attributes - associated with it. These attributes may be retrieved individually - or in conjunction with other attributes or message texts. - -2.3.1. Message Numbers - - Messages in IMAP4rev1 are accessed by one of two numbers; the unique - identifier and the message sequence number. - -2.3.1.1. Unique Identifier (UID) Message Attribute - - A 32-bit value assigned to each message, which when used with the - unique identifier validity value (see below) forms a 64-bit value - - - -Crispin Standards Track [Page 7] - -RFC 2060 IMAP4rev1 December 1996 - - - that is permanently guaranteed not to refer to any other message in - the mailbox. Unique identifiers are assigned in a strictly ascending - fashion in the mailbox; as each message is added to the mailbox it is - assigned a higher UID than the message(s) which were added - previously. - - Unlike message sequence numbers, unique identifiers are not - necessarily contiguous. Unique identifiers also persist across - sessions. This permits a client to resynchronize its state from a - previous session with the server (e.g. disconnected or offline access - clients); this is discussed further in [IMAP-DISC]. - - Associated with every mailbox is a unique identifier validity value, - which is sent in an UIDVALIDITY response code in an OK untagged - response at mailbox selection time. If unique identifiers from an - earlier session fail to persist to this session, the unique - identifier validity value MUST be greater than the one used in the - earlier session. - - Note: Unique identifiers MUST be strictly ascending in the mailbox - at all times. If the physical message store is re-ordered by a - non-IMAP agent, this requires that the unique identifiers in the - mailbox be regenerated, since the former unique identifers are no - longer strictly ascending as a result of the re-ordering. Another - instance in which unique identifiers are regenerated is if the - message store has no mechanism to store unique identifiers. - Although this specification recognizes that this may be - unavoidable in certain server environments, it STRONGLY ENCOURAGES - message store implementation techniques that avoid this problem. - - Another cause of non-persistance is if the mailbox is deleted and - a new mailbox with the same name is created at a later date, Since - the name is the same, a client may not know that this is a new - mailbox unless the unique identifier validity is different. A - good value to use for the unique identifier validity value is a - 32-bit representation of the creation date/time of the mailbox. - It is alright to use a constant such as 1, but only if it - guaranteed that unique identifiers will never be reused, even in - the case of a mailbox being deleted (or renamed) and a new mailbox - by the same name created at some future time. - - The unique identifier of a message MUST NOT change during the - session, and SHOULD NOT change between sessions. However, if it is - not possible to preserve the unique identifier of a message in a - subsequent session, each subsequent session MUST have a new unique - identifier validity value that is larger than any that was used - previously. - - - - -Crispin Standards Track [Page 8] - -RFC 2060 IMAP4rev1 December 1996 - - -2.3.1.2. Message Sequence Number Message Attribute - - A relative position from 1 to the number of messages in the mailbox. - This position MUST be ordered by ascending unique identifier. As - each new message is added, it is assigned a message sequence number - that is 1 higher than the number of messages in the mailbox before - that new message was added. - - Message sequence numbers can be reassigned during the session. For - example, when a message is permanently removed (expunged) from the - mailbox, the message sequence number for all subsequent messages is - decremented. Similarly, a new message can be assigned a message - sequence number that was once held by some other message prior to an - expunge. - - In addition to accessing messages by relative position in the - mailbox, message sequence numbers can be used in mathematical - calculations. For example, if an untagged "EXISTS 11" is received, - and previously an untagged "8 EXISTS" was received, three new - messages have arrived with message sequence numbers of 9, 10, and 11. - Another example; if message 287 in a 523 message mailbox has UID - 12345, there are exactly 286 messages which have lesser UIDs and 236 - messages which have greater UIDs. - -2.3.2. Flags Message Attribute - - A list of zero or more named tokens associated with the message. A - flag is set by its addition to this list, and is cleared by its - removal. There are two types of flags in IMAP4rev1. A flag of - either type may be permanent or session-only. - - A system flag is a flag name that is pre-defined in this - specification. All system flags begin with "\". Certain system - flags (\Deleted and \Seen) have special semantics described - elsewhere. The currently-defined system flags are: - - \Seen Message has been read - - \Answered Message has been answered - - \Flagged Message is "flagged" for urgent/special attention - - \Deleted Message is "deleted" for removal by later EXPUNGE - - \Draft Message has not completed composition (marked as a - draft). - - - - - -Crispin Standards Track [Page 9] - -RFC 2060 IMAP4rev1 December 1996 - - - \Recent Message is "recently" arrived in this mailbox. This - session is the first session to have been notified - about this message; subsequent sessions will not see - \Recent set for this message. This flag can not be - altered by the client. - - If it is not possible to determine whether or not - this session is the first session to be notified - about a message, then that message SHOULD be - considered recent. - - If multiple connections have the same mailbox - selected simultaneously, it is undefined which of - these connections will see newly-arrives messages - with \Recent set and which will see it without - \Recent set. - - A keyword is defined by the server implementation. Keywords do - not begin with "\". Servers MAY permit the client to define new - keywords in the mailbox (see the description of the - PERMANENTFLAGS response code for more information). - - A flag may be permanent or session-only on a per-flag basis. - Permanent flags are those which the client can add or remove - from the message flags permanently; that is, subsequent sessions - will see any change in permanent flags. Changes to session - flags are valid only in that session. - - Note: The \Recent system flag is a special case of a - session flag. \Recent can not be used as an argument in a - STORE command, and thus can not be changed at all. - -2.3.3. Internal Date Message Attribute - - The internal date and time of the message on the server. This is not - the date and time in the [RFC-822] header, but rather a date and time - which reflects when the message was received. In the case of - messages delivered via [SMTP], this SHOULD be the date and time of - final delivery of the message as defined by [SMTP]. In the case of - messages delivered by the IMAP4rev1 COPY command, this SHOULD be the - internal date and time of the source message. In the case of - messages delivered by the IMAP4rev1 APPEND command, this SHOULD be - the date and time as specified in the APPEND command description. - All other cases are implementation defined. - - - - - - - -Crispin Standards Track [Page 10] - -RFC 2060 IMAP4rev1 December 1996 - - -2.3.4. [RFC-822] Size Message Attribute - - The number of octets in the message, as expressed in [RFC-822] - format. - -2.3.5. Envelope Structure Message Attribute - - A parsed representation of the [RFC-822] envelope information (not to - be confused with an [SMTP] envelope) of the message. - -2.3.6. Body Structure Message Attribute - - A parsed representation of the [MIME-IMB] body structure information - of the message. - -2.4. Message Texts - - In addition to being able to fetch the full [RFC-822] text of a - message, IMAP4rev1 permits the fetching of portions of the full - message text. Specifically, it is possible to fetch the [RFC-822] - message header, [RFC-822] message body, a [MIME-IMB] body part, or a - [MIME-IMB] header. - -3. State and Flow Diagram - - An IMAP4rev1 server is in one of four states. Most commands are - valid in only certain states. It is a protocol error for the client - to attempt a command while the command is in an inappropriate state. - In this case, a server will respond with a BAD or NO (depending upon - server implementation) command completion result. - -3.1. Non-Authenticated State - - In non-authenticated state, the client MUST supply authentication - credentials before most commands will be permitted. This state is - entered when a connection starts unless the connection has been pre- - authenticated. - -3.2. Authenticated State - - In authenticated state, the client is authenticated and MUST select a - mailbox to access before commands that affect messages will be - permitted. This state is entered when a pre-authenticated connection - starts, when acceptable authentication credentials have been - provided, or after an error in selecting a mailbox. - - - - - - -Crispin Standards Track [Page 11] - -RFC 2060 IMAP4rev1 December 1996 - - -3.3. Selected State - - In selected state, a mailbox has been selected to access. This state - is entered when a mailbox has been successfully selected. - -3.4. Logout State - - In logout state, the connection is being terminated, and the server - will close the connection. This state can be entered as a result of - a client request or by unilateral server decision. - - +--------------------------------------+ - |initial connection and server greeting| - +--------------------------------------+ - || (1) || (2) || (3) - VV || || - +-----------------+ || || - |non-authenticated| || || - +-----------------+ || || - || (7) || (4) || || - || VV VV || - || +----------------+ || - || | authenticated |<=++ || - || +----------------+ || || - || || (7) || (5) || (6) || - || || VV || || - || || +--------+ || || - || || |selected|==++ || - || || +--------+ || - || || || (7) || - VV VV VV VV - +--------------------------------------+ - | logout and close connection | - +--------------------------------------+ - - (1) connection without pre-authentication (OK greeting) - (2) pre-authenticated connection (PREAUTH greeting) - (3) rejected connection (BYE greeting) - (4) successful LOGIN or AUTHENTICATE command - (5) successful SELECT or EXAMINE command - (6) CLOSE command, or failed SELECT or EXAMINE command - (7) LOGOUT command, server shutdown, or connection closed - -4. Data Formats - - IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can - be in one of several forms: atom, number, string, parenthesized list, - or NIL. - - - -Crispin Standards Track [Page 12] - -RFC 2060 IMAP4rev1 December 1996 - - -4.1. Atom - - An atom consists of one or more non-special characters. - -4.2. Number - - A number consists of one or more digit characters, and represents a - numeric value. - -4.3. String - - A string is in one of two forms: literal and quoted string. The - literal form is the general form of string. The quoted string form - is an alternative that avoids the overhead of processing a literal at - the cost of limitations of characters that can be used in a quoted - string. - - A literal is a sequence of zero or more octets (including CR and LF), - prefix-quoted with an octet count in the form of an open brace ("{"), - the number of octets, close brace ("}"), and CRLF. In the case of - literals transmitted from server to client, the CRLF is immediately - followed by the octet data. In the case of literals transmitted from - client to server, the client MUST wait to receive a command - continuation request (described later in this document) before - sending the octet data (and the remainder of the command). - - A quoted string is a sequence of zero or more 7-bit characters, - excluding CR and LF, with double quote (<">) characters at each end. - - The empty string is represented as either "" (a quoted string with - zero characters between double quotes) or as {0} followed by CRLF (a - literal with an octet count of 0). - - Note: Even if the octet count is 0, a client transmitting a - literal MUST wait to receive a command continuation request. - -4.3.1. 8-bit and Binary Strings - - 8-bit textual and binary mail is supported through the use of a - [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY - transmit 8-bit or multi-octet characters in literals, but SHOULD do - so only when the [CHARSET] is identified. - - - - - - - - - -Crispin Standards Track [Page 13] - -RFC 2060 IMAP4rev1 December 1996 - - - Although a BINARY body encoding is defined, unencoded binary strings - are not permitted. A "binary string" is any string with NUL - characters. Implementations MUST encode binary data into a textual - form such as BASE64 before transmitting the data. A string with an - excessive amount of CTL characters MAY also be considered to be - binary. - -4.4. Parenthesized List - - Data structures are represented as a "parenthesized list"; a sequence - of data items, delimited by space, and bounded at each end by - parentheses. A parenthesized list can contain other parenthesized - lists, using multiple levels of parentheses to indicate nesting. - - The empty list is represented as () -- a parenthesized list with no - members. - -4.5. NIL - - The special atom "NIL" represents the non-existence of a particular - data item that is represented as a string or parenthesized list, as - distinct from the empty string "" or the empty parenthesized list (). - -5. Operational Considerations - -5.1. Mailbox Naming - - The interpretation of mailbox names is implementation-dependent. - However, the case-insensitive mailbox name INBOX is a special name - reserved to mean "the primary mailbox for this user on this server". - -5.1.1. Mailbox Hierarchy Naming - - If it is desired to export hierarchical mailbox names, mailbox names - MUST be left-to-right hierarchical using a single character to - separate levels of hierarchy. The same hierarchy separator character - is used for all levels of hierarchy within a single name. - -5.1.2. Mailbox Namespace Naming Convention - - By convention, the first hierarchical element of any mailbox name - which begins with "#" identifies the "namespace" of the remainder of - the name. This makes it possible to disambiguate between different - types of mailbox stores, each of which have their own namespaces. - - - - - - - -Crispin Standards Track [Page 14] - -RFC 2060 IMAP4rev1 December 1996 - - - For example, implementations which offer access to USENET - newsgroups MAY use the "#news" namespace to partition the USENET - newsgroup namespace from that of other mailboxes. Thus, the - comp.mail.misc newsgroup would have an mailbox name of - "#news.comp.mail.misc", and the name "comp.mail.misc" could refer - to a different object (e.g. a user's private mailbox). - -5.1.3. Mailbox International Naming Convention - - By convention, international mailbox names are specified using a - modified version of the UTF-7 encoding described in [UTF-7]. The - purpose of these modifications is to correct the following problems - with UTF-7: - - 1) UTF-7 uses the "+" character for shifting; this conflicts with - the common use of "+" in mailbox names, in particular USENET - newsgroup names. - - 2) UTF-7's encoding is BASE64 which uses the "/" character; this - conflicts with the use of "/" as a popular hierarchy delimiter. - - 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with - the use of "\" as a popular hierarchy delimiter. - - 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with - the use of "~" in some servers as a home directory indicator. - - 5) UTF-7 permits multiple alternate forms to represent the same - string; in particular, printable US-ASCII chararacters can be - represented in encoded form. - - In modified UTF-7, printable US-ASCII characters except for "&" - represent themselves; that is, characters with octet values 0x20-0x25 - and 0x27-0x7e. The character "&" (0x26) is represented by the two- - octet sequence "&-". - - All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all - Unicode 16-bit octets) are represented in modified BASE64, with a - further modification from [UTF-7] that "," is used instead of "/". - Modified BASE64 MUST NOT be used to represent any printing US-ASCII - character which can represent itself. - - "&" is used to shift to modified BASE64 and "-" to shift back to US- - ASCII. All names start in US-ASCII, and MUST end in US-ASCII (that - is, a name that ends with a Unicode 16-bit octet MUST end with a "- - "). - - - - - -Crispin Standards Track [Page 15] - -RFC 2060 IMAP4rev1 December 1996 - - - For example, here is a mailbox name which mixes English, Japanese, - and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw- - -5.2. Mailbox Size and Message Status Updates - - At any time, a server can send data that the client did not request. - Sometimes, such behavior is REQUIRED. For example, agents other than - the server MAY add messages to the mailbox (e.g. new mail delivery), - change the flags of message in the mailbox (e.g. simultaneous access - to the same mailbox by multiple agents), or even remove messages from - the mailbox. A server MUST send mailbox size updates automatically - if a mailbox size change is observed during the processing of a - command. A server SHOULD send message flag updates automatically, - without requiring the client to request such updates explicitly. - Special rules exist for server notification of a client about the - removal of messages to prevent synchronization errors; see the - description of the EXPUNGE response for more detail. - - Regardless of what implementation decisions a client makes on - remembering data from the server, a client implementation MUST record - mailbox size updates. It MUST NOT assume that any command after - initial mailbox selection will return the size of the mailbox. - -5.3. Response when no Command in Progress - - Server implementations are permitted to send an untagged response - (except for EXPUNGE) while there is no command in progress. Server - implementations that send such responses MUST deal with flow control - considerations. Specifically, they MUST either (1) verify that the - size of the data does not exceed the underlying transport's available - window size, or (2) use non-blocking writes. - -5.4. Autologout Timer - - If a server has an inactivity autologout timer, that timer MUST be of - at least 30 minutes' duration. The receipt of ANY command from the - client during that interval SHOULD suffice to reset the autologout - timer. - - - - - - - - - - - - - -Crispin Standards Track [Page 16] - -RFC 2060 IMAP4rev1 December 1996 - - -5.5. Multiple Commands in Progress - - The client MAY send another command without waiting for the - completion result response of a command, subject to ambiguity rules - (see below) and flow control constraints on the underlying data - stream. Similarly, a server MAY begin processing another command - before processing the current command to completion, subject to - ambiguity rules. However, any command continuation request responses - and command continuations MUST be negotiated before any subsequent - command is initiated. - - The exception is if an ambiguity would result because of a command - that would affect the results of other commands. Clients MUST NOT - send multiple commands without waiting if an ambiguity would result. - If the server detects a possible ambiguity, it MUST execute commands - to completion in the order given by the client. - - The most obvious example of ambiguity is when a command would affect - the results of another command; for example, a FETCH of a message's - flags and a STORE of that same message's flags. - - A non-obvious ambiguity occurs with commands that permit an untagged - EXPUNGE response (commands other than FETCH, STORE, and SEARCH), - since an untagged EXPUNGE response can invalidate sequence numbers in - a subsequent command. This is not a problem for FETCH, STORE, or - SEARCH commands because servers are prohibited from sending EXPUNGE - responses while any of those commands are in progress. Therefore, if - the client sends any command other than FETCH, STORE, or SEARCH, it - MUST wait for a response before sending a command with message - sequence numbers. - - For example, the following non-waiting command sequences are invalid: - - FETCH + NOOP + STORE - STORE + COPY + FETCH - COPY + COPY - CHECK + FETCH - - The following are examples of valid non-waiting command sequences: - - FETCH + STORE + SEARCH + CHECK - STORE + COPY + EXPUNGE - -6. Client Commands - - IMAP4rev1 commands are described in this section. Commands are - organized by the state in which the command is permitted. Commands - which are permitted in multiple states are listed in the minimum - - - -Crispin Standards Track [Page 17] - -RFC 2060 IMAP4rev1 December 1996 - - - permitted state (for example, commands valid in authenticated and - selected state are listed in the authenticated state commands). - - Command arguments, identified by "Arguments:" in the command - descriptions below, are described by function, not by syntax. The - precise syntax of command arguments is described in the Formal Syntax - section. - - Some commands cause specific server responses to be returned; these - are identified by "Responses:" in the command descriptions below. - See the response descriptions in the Responses section for - information on these responses, and the Formal Syntax section for the - precise syntax of these responses. It is possible for server data to - be transmitted as a result of any command; thus, commands that do not - specifically require server data specify "no specific responses for - this command" instead of "none". - - The "Result:" in the command description refers to the possible - tagged status responses to a command, and any special interpretation - of these status responses. - -6.1. Client Commands - Any State - - The following commands are valid in any state: CAPABILITY, NOOP, and - LOGOUT. - -6.1.1. CAPABILITY Command - - Arguments: none - - Responses: REQUIRED untagged response: CAPABILITY - - Result: OK - capability completed - BAD - command unknown or arguments invalid - - The CAPABILITY command requests a listing of capabilities that the - server supports. The server MUST send a single untagged - CAPABILITY response with "IMAP4rev1" as one of the listed - capabilities before the (tagged) OK response. This listing of - capabilities is not dependent upon connection state or user. It - is therefore not necessary to issue a CAPABILITY command more than - once in a connection. - - - - - - - - - -Crispin Standards Track [Page 18] - -RFC 2060 IMAP4rev1 December 1996 - - - A capability name which begins with "AUTH=" indicates that the - server supports that particular authentication mechanism. All - such names are, by definition, part of this specification. For - example, the authorization capability for an experimental - "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not - "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP". - - Other capability names refer to extensions, revisions, or - amendments to this specification. See the documentation of the - CAPABILITY response for additional information. No capabilities, - beyond the base IMAP4rev1 set defined in this specification, are - enabled without explicit client action to invoke the capability. - - See the section entitled "Client Commands - - Experimental/Expansion" for information about the form of site or - implementation-specific capabilities. - - Example: C: abcd CAPABILITY - S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 - S: abcd OK CAPABILITY completed - -6.1.2. NOOP Command - - Arguments: none - - Responses: no specific responses for this command (but see below) - - Result: OK - noop completed - BAD - command unknown or arguments invalid - - The NOOP command always succeeds. It does nothing. - - Since any command can return a status update as untagged data, the - NOOP command can be used as a periodic poll for new messages or - message status updates during a period of inactivity. The NOOP - command can also be used to reset any inactivity autologout timer - on the server. - - Example: C: a002 NOOP - S: a002 OK NOOP completed - . . . - C: a047 NOOP - S: * 22 EXPUNGE - S: * 23 EXISTS - S: * 3 RECENT - S: * 14 FETCH (FLAGS (\Seen \Deleted)) - S: a047 OK NOOP completed - - - - -Crispin Standards Track [Page 19] - -RFC 2060 IMAP4rev1 December 1996 - - -6.1.3. LOGOUT Command - - Arguments: none - - Responses: REQUIRED untagged response: BYE - - Result: OK - logout completed - BAD - command unknown or arguments invalid - - The LOGOUT command informs the server that the client is done with - the connection. The server MUST send a BYE untagged response - before the (tagged) OK response, and then close the network - connection. - - Example: C: A023 LOGOUT - S: * BYE IMAP4rev1 Server logging out - S: A023 OK LOGOUT completed - (Server and client then close the connection) - -6.2. Client Commands - Non-Authenticated State - - In non-authenticated state, the AUTHENTICATE or LOGIN command - establishes authentication and enter authenticated state. The - AUTHENTICATE command provides a general mechanism for a variety of - authentication techniques, whereas the LOGIN command uses the - traditional user name and plaintext password pair. - - Server implementations MAY allow non-authenticated access to certain - mailboxes. The convention is to use a LOGIN command with the userid - "anonymous". A password is REQUIRED. It is implementation-dependent - what requirements, if any, are placed on the password and what access - restrictions are placed on anonymous users. - - Once authenticated (including as anonymous), it is not possible to - re-enter non-authenticated state. - - In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), - the following commands are valid in non-authenticated state: - AUTHENTICATE and LOGIN. - - - - - - - - - - - - -Crispin Standards Track [Page 20] - -RFC 2060 IMAP4rev1 December 1996 - - -6.2.1. AUTHENTICATE Command - - Arguments: authentication mechanism name - - Responses: continuation data can be requested - - Result: OK - authenticate completed, now in authenticated state - NO - authenticate failure: unsupported authentication - mechanism, credentials rejected - BAD - command unknown or arguments invalid, - authentication exchange cancelled - - The AUTHENTICATE command indicates an authentication mechanism, - such as described in [IMAP-AUTH], to the server. If the server - supports the requested authentication mechanism, it performs an - authentication protocol exchange to authenticate and identify the - client. It MAY also negotiate an OPTIONAL protection mechanism - for subsequent protocol interactions. If the requested - authentication mechanism is not supported, the server SHOULD - reject the AUTHENTICATE command by sending a tagged NO response. - - The authentication protocol exchange consists of a series of - server challenges and client answers that are specific to the - authentication mechanism. A server challenge consists of a - command continuation request response with the "+" token followed - by a BASE64 encoded string. The client answer consists of a line - consisting of a BASE64 encoded string. If the client wishes to - cancel an authentication exchange, it issues a line with a single - "*". If the server receives such an answer, it MUST reject the - AUTHENTICATE command by sending a tagged BAD response. - - A protection mechanism provides integrity and privacy protection - to the connection. If a protection mechanism is negotiated, it is - applied to all subsequent data sent over the connection. The - protection mechanism takes effect immediately following the CRLF - that concludes the authentication exchange for the client, and the - CRLF of the tagged OK response for the server. Once the - protection mechanism is in effect, the stream of command and - response octets is processed into buffers of ciphertext. Each - buffer is transferred over the connection as a stream of octets - prepended with a four octet field in network byte order that - represents the length of the following data. The maximum - ciphertext buffer length is defined by the protection mechanism. - - Authentication mechanisms are OPTIONAL. Protection mechanisms are - also OPTIONAL; an authentication mechanism MAY be implemented - without any protection mechanism. If an AUTHENTICATE command - fails with a NO response, the client MAY try another - - - -Crispin Standards Track [Page 21] - -RFC 2060 IMAP4rev1 December 1996 - - - authentication mechanism by issuing another AUTHENTICATE command, - or MAY attempt to authenticate by using the LOGIN command. In - other words, the client MAY request authentication types in - decreasing order of preference, with the LOGIN command as a last - resort. - - Example: S: * OK KerberosV4 IMAP4rev1 Server - C: A001 AUTHENTICATE KERBEROS_V4 - S: + AmFYig== - C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT - +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd - WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh - S: + or//EoAADZI= - C: DiAF5A4gA+oOIALuBkAAmw== - S: A001 OK Kerberos V4 authentication successful - - Note: the line breaks in the first client answer are for editorial - clarity and are not in real authenticators. - -6.2.2. LOGIN Command - - Arguments: user name - password - - Responses: no specific responses for this command - - Result: OK - login completed, now in authenticated state - NO - login failure: user name or password rejected - BAD - command unknown or arguments invalid - - The LOGIN command identifies the client to the server and carries - the plaintext password authenticating this user. - - Example: C: a001 LOGIN SMITH SESAME - S: a001 OK LOGIN completed - -6.3. Client Commands - Authenticated State - - In authenticated state, commands that manipulate mailboxes as atomic - entities are permitted. Of these commands, the SELECT and EXAMINE - commands will select a mailbox for access and enter selected state. - - In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), - the following commands are valid in authenticated state: SELECT, - EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, - STATUS, and APPEND. - - - - - -Crispin Standards Track [Page 22] - -RFC 2060 IMAP4rev1 December 1996 - - -6.3.1. SELECT Command - - Arguments: mailbox name - - Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT - OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS - - Result: OK - select completed, now in selected state - NO - select failure, now in authenticated state: no - such mailbox, can't access mailbox - BAD - command unknown or arguments invalid - - The SELECT command selects a mailbox so that messages in the - mailbox can be accessed. Before returning an OK to the client, - the server MUST send the following untagged data to the client: - - FLAGS Defined flags in the mailbox. See the description - of the FLAGS response for more detail. - - EXISTS The number of messages in the mailbox. See the - description of the EXISTS response for more detail. - - RECENT The number of messages with the \Recent flag set. - See the description of the RECENT response for more - detail. - - OK [UIDVALIDITY ] - The unique identifier validity value. See the - description of the UID command for more detail. - - to define the initial state of the mailbox at the client. - - The server SHOULD also send an UNSEEN response code in an OK - untagged response, indicating the message sequence number of the - first unseen message in the mailbox. - - If the client can not change the permanent state of one or more of - the flags listed in the FLAGS untagged response, the server SHOULD - send a PERMANENTFLAGS response code in an OK untagged response, - listing the flags that the client can change permanently. - - Only one mailbox can be selected at a time in a connection; - simultaneous access to multiple mailboxes requires multiple - connections. The SELECT command automatically deselects any - currently selected mailbox before attempting the new selection. - Consequently, if a mailbox is selected and a SELECT command that - fails is attempted, no mailbox is selected. - - - - -Crispin Standards Track [Page 23] - -RFC 2060 IMAP4rev1 December 1996 - - - If the client is permitted to modify the mailbox, the server - SHOULD prefix the text of the tagged OK response with the - "[READ-WRITE]" response code. - - If the client is not permitted to modify the mailbox but is - permitted read access, the mailbox is selected as read-only, and - the server MUST prefix the text of the tagged OK response to - SELECT with the "[READ-ONLY]" response code. Read-only access - through SELECT differs from the EXAMINE command in that certain - read-only mailboxes MAY permit the change of permanent state on a - per-user (as opposed to global) basis. Netnews messages marked in - a server-based .newsrc file are an example of such per-user - permanent state that can be modified with read-only mailboxes. - - Example: C: A142 SELECT INBOX - S: * 172 EXISTS - S: * 1 RECENT - S: * OK [UNSEEN 12] Message 12 is first unseen - S: * OK [UIDVALIDITY 3857529045] UIDs valid - S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) - S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited - S: A142 OK [READ-WRITE] SELECT completed - -6.3.2. EXAMINE Command - - Arguments: mailbox name - - Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT - OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS - - Result: OK - examine completed, now in selected state - NO - examine failure, now in authenticated state: no - such mailbox, can't access mailbox - BAD - command unknown or arguments invalid - - The EXAMINE command is identical to SELECT and returns the same - output; however, the selected mailbox is identified as read-only. - No changes to the permanent state of the mailbox, including - per-user state, are permitted. - - - - - - - - - - - - -Crispin Standards Track [Page 24] - -RFC 2060 IMAP4rev1 December 1996 - - - The text of the tagged OK response to the EXAMINE command MUST - begin with the "[READ-ONLY]" response code. - - Example: C: A932 EXAMINE blurdybloop - S: * 17 EXISTS - S: * 2 RECENT - S: * OK [UNSEEN 8] Message 8 is first unseen - S: * OK [UIDVALIDITY 3857529045] UIDs valid - S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) - S: * OK [PERMANENTFLAGS ()] No permanent flags permitted - S: A932 OK [READ-ONLY] EXAMINE completed - -6.3.3. CREATE Command - - Arguments: mailbox name - - Responses: no specific responses for this command - - Result: OK - create completed - NO - create failure: can't create mailbox with that name - BAD - command unknown or arguments invalid - - The CREATE command creates a mailbox with the given name. An OK - response is returned only if a new mailbox with that name has been - created. It is an error to attempt to create INBOX or a mailbox - with a name that refers to an extant mailbox. Any error in - creation will return a tagged NO response. - - If the mailbox name is suffixed with the server's hierarchy - separator character (as returned from the server by a LIST - command), this is a declaration that the client intends to create - mailbox names under this name in the hierarchy. Server - implementations that do not require this declaration MUST ignore - it. - - If the server's hierarchy separator character appears elsewhere in - the name, the server SHOULD create any superior hierarchical names - that are needed for the CREATE command to complete successfully. - In other words, an attempt to create "foo/bar/zap" on a server in - which "/" is the hierarchy separator character SHOULD create foo/ - and foo/bar/ if they do not already exist. - - If a new mailbox is created with the same name as a mailbox which - was deleted, its unique identifiers MUST be greater than any - unique identifiers used in the previous incarnation of the mailbox - UNLESS the new incarnation has a different unique identifier - validity value. See the description of the UID command for more - detail. - - - -Crispin Standards Track [Page 25] - -RFC 2060 IMAP4rev1 December 1996 - - - Example: C: A003 CREATE owatagusiam/ - S: A003 OK CREATE completed - C: A004 CREATE owatagusiam/blurdybloop - S: A004 OK CREATE completed - - Note: the interpretation of this example depends on whether "/" - was returned as the hierarchy separator from LIST. If "/" is the - hierarchy separator, a new level of hierarchy named "owatagusiam" - with a member called "blurdybloop" is created. Otherwise, two - mailboxes at the same hierarchy level are created. - -6.3.4. DELETE Command - - Arguments: mailbox name - - Responses: no specific responses for this command - - Result: OK - delete completed - NO - delete failure: can't delete mailbox with that name - BAD - command unknown or arguments invalid - - The DELETE command permanently removes the mailbox with the given - name. A tagged OK response is returned only if the mailbox has - been deleted. It is an error to attempt to delete INBOX or a - mailbox name that does not exist. - - The DELETE command MUST NOT remove inferior hierarchical names. - For example, if a mailbox "foo" has an inferior "foo.bar" - (assuming "." is the hierarchy delimiter character), removing - "foo" MUST NOT remove "foo.bar". It is an error to attempt to - delete a name that has inferior hierarchical names and also has - the \Noselect mailbox name attribute (see the description of the - LIST response for more details). - - It is permitted to delete a name that has inferior hierarchical - names and does not have the \Noselect mailbox name attribute. In - this case, all messages in that mailbox are removed, and the name - will acquire the \Noselect mailbox name attribute. - - The value of the highest-used unique identifier of the deleted - mailbox MUST be preserved so that a new mailbox created with the - same name will not reuse the identifiers of the former - incarnation, UNLESS the new incarnation has a different unique - identifier validity value. See the description of the UID command - for more detail. - - - - - - -Crispin Standards Track [Page 26] - -RFC 2060 IMAP4rev1 December 1996 - - - Examples: C: A682 LIST "" * - S: * LIST () "/" blurdybloop - S: * LIST (\Noselect) "/" foo - S: * LIST () "/" foo/bar - S: A682 OK LIST completed - C: A683 DELETE blurdybloop - S: A683 OK DELETE completed - C: A684 DELETE foo - S: A684 NO Name "foo" has inferior hierarchical names - C: A685 DELETE foo/bar - S: A685 OK DELETE Completed - C: A686 LIST "" * - S: * LIST (\Noselect) "/" foo - S: A686 OK LIST completed - C: A687 DELETE foo - S: A687 OK DELETE Completed - - - C: A82 LIST "" * - S: * LIST () "." blurdybloop - S: * LIST () "." foo - S: * LIST () "." foo.bar - S: A82 OK LIST completed - C: A83 DELETE blurdybloop - S: A83 OK DELETE completed - C: A84 DELETE foo - S: A84 OK DELETE Completed - C: A85 LIST "" * - S: * LIST () "." foo.bar - S: A85 OK LIST completed - C: A86 LIST "" % - S: * LIST (\Noselect) "." foo - S: A86 OK LIST completed - -6.3.5. RENAME Command - - Arguments: existing mailbox name - new mailbox name - - Responses: no specific responses for this command - - Result: OK - rename completed - NO - rename failure: can't rename mailbox with that name, - can't rename to mailbox with that name - BAD - command unknown or arguments invalid - - The RENAME command changes the name of a mailbox. A tagged OK - response is returned only if the mailbox has been renamed. It is - - - -Crispin Standards Track [Page 27] - -RFC 2060 IMAP4rev1 December 1996 - - - an error to attempt to rename from a mailbox name that does not - exist or to a mailbox name that already exists. Any error in - renaming will return a tagged NO response. - - If the name has inferior hierarchical names, then the inferior - hierarchical names MUST also be renamed. For example, a rename of - "foo" to "zap" will rename "foo/bar" (assuming "/" is the - hierarchy delimiter character) to "zap/bar". - - The value of the highest-used unique identifier of the old mailbox - name MUST be preserved so that a new mailbox created with the same - name will not reuse the identifiers of the former incarnation, - UNLESS the new incarnation has a different unique identifier - validity value. See the description of the UID command for more - detail. - - Renaming INBOX is permitted, and has special behavior. It moves - all messages in INBOX to a new mailbox with the given name, - leaving INBOX empty. If the server implementation supports - inferior hierarchical names of INBOX, these are unaffected by a - rename of INBOX. - - Examples: C: A682 LIST "" * - S: * LIST () "/" blurdybloop - S: * LIST (\Noselect) "/" foo - S: * LIST () "/" foo/bar - S: A682 OK LIST completed - C: A683 RENAME blurdybloop sarasoop - S: A683 OK RENAME completed - C: A684 RENAME foo zowie - S: A684 OK RENAME Completed - C: A685 LIST "" * - S: * LIST () "/" sarasoop - S: * LIST (\Noselect) "/" zowie - S: * LIST () "/" zowie/bar - S: A685 OK LIST completed - - - - - - - - - - - - - - - -Crispin Standards Track [Page 28] - -RFC 2060 IMAP4rev1 December 1996 - - - C: Z432 LIST "" * - S: * LIST () "." INBOX - S: * LIST () "." INBOX.bar - S: Z432 OK LIST completed - C: Z433 RENAME INBOX old-mail - S: Z433 OK RENAME completed - C: Z434 LIST "" * - S: * LIST () "." INBOX - S: * LIST () "." INBOX.bar - S: * LIST () "." old-mail - S: Z434 OK LIST completed - -6.3.6. SUBSCRIBE Command - - Arguments: mailbox - - Responses: no specific responses for this command - - Result: OK - subscribe completed - NO - subscribe failure: can't subscribe to that name - BAD - command unknown or arguments invalid - - The SUBSCRIBE command adds the specified mailbox name to the - server's set of "active" or "subscribed" mailboxes as returned by - the LSUB command. This command returns a tagged OK response only - if the subscription is successful. - - A server MAY validate the mailbox argument to SUBSCRIBE to verify - that it exists. However, it MUST NOT unilaterally remove an - existing mailbox name from the subscription list even if a mailbox - by that name no longer exists. - - Note: this requirement is because some server sites may routinely - remove a mailbox with a well-known name (e.g. "system-alerts") - after its contents expire, with the intention of recreating it - when new contents are appropriate. - - Example: C: A002 SUBSCRIBE #news.comp.mail.mime - S: A002 OK SUBSCRIBE completed - - - - - - - - - - - - -Crispin Standards Track [Page 29] - -RFC 2060 IMAP4rev1 December 1996 - - -6.3.7. UNSUBSCRIBE Command - - Arguments: mailbox name - - Responses: no specific responses for this command - - Result: OK - unsubscribe completed - NO - unsubscribe failure: can't unsubscribe that name - BAD - command unknown or arguments invalid - - The UNSUBSCRIBE command removes the specified mailbox name from - the server's set of "active" or "subscribed" mailboxes as returned - by the LSUB command. This command returns a tagged OK response - only if the unsubscription is successful. - - Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime - S: A002 OK UNSUBSCRIBE completed - -6.3..8. LIST Command - - Arguments: reference name - mailbox name with possible wildcards - - Responses: untagged responses: LIST - - Result: OK - list completed - NO - list failure: can't list that reference or name - BAD - command unknown or arguments invalid - - The LIST command returns a subset of names from the complete set - of all names available to the client. Zero or more untagged LIST - replies are returned, containing the name attributes, hierarchy - delimiter, and name; see the description of the LIST reply for - more detail. - - The LIST command SHOULD return its data quickly, without undue - delay. For example, it SHOULD NOT go to excess trouble to - calculate \Marked or \Unmarked status or perform other processing; - if each name requires 1 second of processing, then a list of 1200 - names would take 20 minutes! - - An empty ("" string) reference name argument indicates that the - mailbox name is interpreted as by SELECT. The returned mailbox - names MUST match the supplied mailbox name pattern. A non-empty - reference name argument is the name of a mailbox or a level of - mailbox hierarchy, and indicates a context in which the mailbox - name is interpreted in an implementation-defined manner. - - - - -Crispin Standards Track [Page 30] - -RFC 2060 IMAP4rev1 December 1996 - - - An empty ("" string) mailbox name argument is a special request to - return the hierarchy delimiter and the root name of the name given - in the reference. The value returned as the root MAY be null if - the reference is non-rooted or is null. In all cases, the - hierarchy delimiter is returned. This permits a client to get the - hierarchy delimiter even when no mailboxes by that name currently - exist. - - The reference and mailbox name arguments are interpreted, in an - implementation-dependent fashion, into a canonical form that - represents an unambiguous left-to-right hierarchy. The returned - mailbox names will be in the interpreted form. - - Any part of the reference argument that is included in the - interpreted form SHOULD prefix the interpreted form. It SHOULD - also be in the same form as the reference name argument. This - rule permits the client to determine if the returned mailbox name - is in the context of the reference argument, or if something about - the mailbox argument overrode the reference argument. Without - this rule, the client would have to have knowledge of the server's - naming semantics including what characters are "breakouts" that - override a naming context. - - For example, here are some examples of how references and mailbox - names might be interpreted on a UNIX-based server: - - Reference Mailbox Name Interpretation - ------------ ------------ -------------- - ~smith/Mail/ foo.* ~smith/Mail/foo.* - archive/ % archive/% - #news. comp.mail.* #news.comp.mail.* - ~smith/Mail/ /usr/doc/foo /usr/doc/foo - archive/ ~fred/Mail/* ~fred/Mail/* - - The first three examples demonstrate interpretations in the - context of the reference argument. Note that "~smith/Mail" SHOULD - NOT be transformed into something like "/u2/users/smith/Mail", or - it would be impossible for the client to determine that the - interpretation was in the context of the reference. - - The character "*" is a wildcard, and matches zero or more - characters at this position. The character "%" is similar to "*", - but it does not match a hierarchy delimiter. If the "%" wildcard - is the last character of a mailbox name argument, matching levels - of hierarchy are also returned. If these levels of hierarchy are - not also selectable mailboxes, they are returned with the - \Noselect mailbox name attribute (see the description of the LIST - response for more details). - - - -Crispin Standards Track [Page 31] - -RFC 2060 IMAP4rev1 December 1996 - - - Server implementations are permitted to "hide" otherwise - accessible mailboxes from the wildcard characters, by preventing - certain characters or names from matching a wildcard in certain - situations. For example, a UNIX-based server might restrict the - interpretation of "*" so that an initial "/" character does not - match. - - The special name INBOX is included in the output from LIST, if - INBOX is supported by this server for this user and if the - uppercase string "INBOX" matches the interpreted reference and - mailbox name arguments with wildcards as described above. The - criteria for omitting INBOX is whether SELECT INBOX will return - failure; it is not relevant whether the user's real INBOX resides - on this or some other server. - - Example: C: A101 LIST "" "" - S: * LIST (\Noselect) "/" "" - S: A101 OK LIST Completed - C: A102 LIST #news.comp.mail.misc "" - S: * LIST (\Noselect) "." #news. - S: A102 OK LIST Completed - C: A103 LIST /usr/staff/jones "" - S: * LIST (\Noselect) "/" / - S: A103 OK LIST Completed - C: A202 LIST ~/Mail/ % - S: * LIST (\Noselect) "/" ~/Mail/foo - S: * LIST () "/" ~/Mail/meetings - S: A202 OK LIST completed - -6.3.9. LSUB Command - - Arguments: reference name - mailbox name with possible wildcards - - Responses: untagged responses: LSUB - - Result: OK - lsub completed - NO - lsub failure: can't list that reference or name - BAD - command unknown or arguments invalid - - The LSUB command returns a subset of names from the set of names - that the user has declared as being "active" or "subscribed". - Zero or more untagged LSUB replies are returned. The arguments to - LSUB are in the same form as those for LIST. - - A server MAY validate the subscribed names to see if they still - exist. If a name does not exist, it SHOULD be flagged with the - \Noselect attribute in the LSUB response. The server MUST NOT - - - -Crispin Standards Track [Page 32] - -RFC 2060 IMAP4rev1 December 1996 - - - unilaterally remove an existing mailbox name from the subscription - list even if a mailbox by that name no longer exists. - - Example: C: A002 LSUB "#news." "comp.mail.*" - S: * LSUB () "." #news.comp.mail.mime - S: * LSUB () "." #news.comp.mail.misc - S: A002 OK LSUB completed - -6.3.10. STATUS Command - - Arguments: mailbox name - status data item names - - Responses: untagged responses: STATUS - - Result: OK - status completed - NO - status failure: no status for that name - BAD - command unknown or arguments invalid - - The STATUS command requests the status of the indicated mailbox. - It does not change the currently selected mailbox, nor does it - affect the state of any messages in the queried mailbox (in - particular, STATUS MUST NOT cause messages to lose the \Recent - flag). - - The STATUS command provides an alternative to opening a second - IMAP4rev1 connection and doing an EXAMINE command on a mailbox to - query that mailbox's status without deselecting the current - mailbox in the first IMAP4rev1 connection. - - Unlike the LIST command, the STATUS command is not guaranteed to - be fast in its response. In some implementations, the server is - obliged to open the mailbox read-only internally to obtain certain - status information. Also unlike the LIST command, the STATUS - command does not accept wildcards. - - The currently defined status data items that can be requested are: - - MESSAGES The number of messages in the mailbox. - - RECENT The number of messages with the \Recent flag set. - - UIDNEXT The next UID value that will be assigned to a new - message in the mailbox. It is guaranteed that this - value will not change unless new messages are added - to the mailbox; and that it will change when new - messages are added even if those new messages are - subsequently expunged. - - - -Crispin Standards Track [Page 33] - -RFC 2060 IMAP4rev1 December 1996 - - - UIDVALIDITY The unique identifier validity value of the - mailbox. - - UNSEEN The number of messages which do not have the \Seen - flag set. - - - Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) - S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) - S: A042 OK STATUS completed - -6.3.11. APPEND Command - - Arguments: mailbox name - OPTIONAL flag parenthesized list - OPTIONAL date/time string - message literal - - Responses: no specific responses for this command - - Result: OK - append completed - NO - append error: can't append to that mailbox, error - in flags or date/time or message text - BAD - command unknown or arguments invalid - - The APPEND command appends the literal argument as a new message - to the end of the specified destination mailbox. This argument - SHOULD be in the format of an [RFC-822] message. 8-bit characters - are permitted in the message. A server implementation that is - unable to preserve 8-bit data properly MUST be able to reversibly - convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content - transfer encoding. - - Note: There MAY be exceptions, e.g. draft messages, in which - required [RFC-822] header lines are omitted in the message literal - argument to APPEND. The full implications of doing so MUST be - understood and carefully weighed. - - If a flag parenthesized list is specified, the flags SHOULD be set in - the resulting message; otherwise, the flag list of the resulting - message is set empty by default. - - If a date_time is specified, the internal date SHOULD be set in the - resulting message; otherwise, the internal date of the resulting - message is set to the current date and time by default. - - - - - - -Crispin Standards Track [Page 34] - -RFC 2060 IMAP4rev1 December 1996 - - - If the append is unsuccessful for any reason, the mailbox MUST be - restored to its state before the APPEND attempt; no partial appending - is permitted. - - If the destination mailbox does not exist, a server MUST return an - error, and MUST NOT automatically create the mailbox. Unless it is - certain that the destination mailbox can not be created, the server - MUST send the response code "[TRYCREATE]" as the prefix of the text - of the tagged NO response. This gives a hint to the client that it - can attempt a CREATE command and retry the APPEND if the CREATE is - successful. - - If the mailbox is currently selected, the normal new mail actions - SHOULD occur. Specifically, the server SHOULD notify the client - immediately via an untagged EXISTS response. If the server does not - do so, the client MAY issue a NOOP command (or failing that, a CHECK - command) after one or more APPEND commands. - - Example: C: A003 APPEND saved-messages (\Seen) {310} - C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) - C: From: Fred Foobar - C: Subject: afternoon meeting - C: To: mooch@owatagu.siam.edu - C: Message-Id: - C: MIME-Version: 1.0 - C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII - C: - C: Hello Joe, do you think we can meet at 3:30 tomorrow? - C: - S: A003 OK APPEND completed - - Note: the APPEND command is not used for message delivery, because - it does not provide a mechanism to transfer [SMTP] envelope - information. - -6.4. Client Commands - Selected State - - In selected state, commands that manipulate messages in a mailbox are - permitted. - - In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), - and the authenticated state commands (SELECT, EXAMINE, CREATE, - DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and - APPEND), the following commands are valid in the selected state: - CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID. - - - - - - -Crispin Standards Track [Page 35] - -RFC 2060 IMAP4rev1 December 1996 - - -6.4.1. CHECK Command - - Arguments: none - - Responses: no specific responses for this command - - Result: OK - check completed - BAD - command unknown or arguments invalid - - The CHECK command requests a checkpoint of the currently selected - mailbox. A checkpoint refers to any implementation-dependent - housekeeping associated with the mailbox (e.g. resolving the - server's in-memory state of the mailbox with the state on its - disk) that is not normally executed as part of each command. A - checkpoint MAY take a non-instantaneous amount of real time to - complete. If a server implementation has no such housekeeping - considerations, CHECK is equivalent to NOOP. - - There is no guarantee that an EXISTS untagged response will happen - as a result of CHECK. NOOP, not CHECK, SHOULD be used for new - mail polling. - - Example: C: FXXZ CHECK - S: FXXZ OK CHECK Completed - -6.4.2. CLOSE Command - - Arguments: none - - Responses: no specific responses for this command - - Result: OK - close completed, now in authenticated state - NO - close failure: no mailbox selected - BAD - command unknown or arguments invalid - - The CLOSE command permanently removes from the currently selected - mailbox all messages that have the \Deleted flag set, and returns - to authenticated state from selected state. No untagged EXPUNGE - responses are sent. - - No messages are removed, and no error is given, if the mailbox is - selected by an EXAMINE command or is otherwise selected read-only. - - Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT - command MAY be issued without previously issuing a CLOSE command. - The SELECT, EXAMINE, and LOGOUT commands implicitly close the - currently selected mailbox without doing an expunge. However, - when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT - - - -Crispin Standards Track [Page 36] - -RFC 2060 IMAP4rev1 December 1996 - - - sequence is considerably faster than an EXPUNGE-LOGOUT or - EXPUNGE-SELECT because no untagged EXPUNGE responses (which the - client would probably ignore) are sent. - - Example: C: A341 CLOSE - S: A341 OK CLOSE completed - -6.4.3. EXPUNGE Command - - Arguments: none - - Responses: untagged responses: EXPUNGE - - Result: OK - expunge completed - NO - expunge failure: can't expunge (e.g. permission - denied) - BAD - command unknown or arguments invalid - - The EXPUNGE command permanently removes from the currently - selected mailbox all messages that have the \Deleted flag set. - Before returning an OK to the client, an untagged EXPUNGE response - is sent for each message that is removed. - - Example: C: A202 EXPUNGE - S: * 3 EXPUNGE - S: * 3 EXPUNGE - S: * 5 EXPUNGE - S: * 8 EXPUNGE - S: A202 OK EXPUNGE completed - - Note: in this example, messages 3, 4, 7, and 11 had the - \Deleted flag set. See the description of the EXPUNGE - response for further explanation. - -6.4.4. SEARCH Command - - Arguments: OPTIONAL [CHARSET] specification - searching criteria (one or more) - - Responses: REQUIRED untagged response: SEARCH - - Result: OK - search completed - NO - search error: can't search that [CHARSET] or - criteria - BAD - command unknown or arguments invalid - - - - - - -Crispin Standards Track [Page 37] - -RFC 2060 IMAP4rev1 December 1996 - - - The SEARCH command searches the mailbox for messages that match - the given searching criteria. Searching criteria consist of one - or more search keys. The untagged SEARCH response from the server - contains a listing of message sequence numbers corresponding to - those messages that match the searching criteria. - - When multiple keys are specified, the result is the intersection - (AND function) of all the messages that match those keys. For - example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers - to all deleted messages from Smith that were placed in the mailbox - since February 1, 1994. A search key can also be a parenthesized - list of one or more search keys (e.g. for use with the OR and NOT - keys). - - Server implementations MAY exclude [MIME-IMB] body parts with - terminal content media types other than TEXT and MESSAGE from - consideration in SEARCH matching. - - The OPTIONAL [CHARSET] specification consists of the word - "CHARSET" followed by a registered [CHARSET]. It indicates the - [CHARSET] of the strings that appear in the search criteria. - [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in - [RFC-822]/[MIME-IMB] headers, MUST be decoded before comparing - text in a [CHARSET] other than US-ASCII. US-ASCII MUST be - supported; other [CHARSET]s MAY be supported. If the server does - not support the specified [CHARSET], it MUST return a tagged NO - response (not a BAD). - - In all search keys that use strings, a message matches the key if - the string is a substring of the field. The matching is case- - insensitive. - - The defined search keys are as follows. Refer to the Formal - Syntax section for the precise syntactic definitions of the - arguments. - - Messages with message sequence numbers - corresponding to the specified message sequence - number set - - ALL All messages in the mailbox; the default initial - key for ANDing. - - ANSWERED Messages with the \Answered flag set. - - BCC Messages that contain the specified string in the - envelope structure's BCC field. - - - - -Crispin Standards Track [Page 38] - -RFC 2060 IMAP4rev1 December 1996 - - - BEFORE Messages whose internal date is earlier than the - specified date. - - BODY Messages that contain the specified string in the - body of the message. - - CC Messages that contain the specified string in the - envelope structure's CC field. - - DELETED Messages with the \Deleted flag set. - - DRAFT Messages with the \Draft flag set. - - FLAGGED Messages with the \Flagged flag set. - - FROM Messages that contain the specified string in the - envelope structure's FROM field. - - HEADER - Messages that have a header with the specified - field-name (as defined in [RFC-822]) and that - contains the specified string in the [RFC-822] - field-body. - - KEYWORD Messages with the specified keyword set. - - LARGER Messages with an [RFC-822] size larger than the - specified number of octets. - - NEW Messages that have the \Recent flag set but not the - \Seen flag. This is functionally equivalent to - "(RECENT UNSEEN)". - - NOT - Messages that do not match the specified search - key. - - OLD Messages that do not have the \Recent flag set. - This is functionally equivalent to "NOT RECENT" (as - opposed to "NOT NEW"). - - ON Messages whose internal date is within the - specified date. - - OR - Messages that match either search key. - - RECENT Messages that have the \Recent flag set. - - - -Crispin Standards Track [Page 39] - -RFC 2060 IMAP4rev1 December 1996 - - - SEEN Messages that have the \Seen flag set. - - SENTBEFORE - Messages whose [RFC-822] Date: header is earlier - than the specified date. - - SENTON Messages whose [RFC-822] Date: header is within the - specified date. - - SENTSINCE - Messages whose [RFC-822] Date: header is within or - later than the specified date. - - SINCE Messages whose internal date is within or later - than the specified date. - - SMALLER Messages with an [RFC-822] size smaller than the - specified number of octets. - - SUBJECT - Messages that contain the specified string in the - envelope structure's SUBJECT field. - - TEXT Messages that contain the specified string in the - header or body of the message. - - TO Messages that contain the specified string in the - envelope structure's TO field. - - UID - Messages with unique identifiers corresponding to - the specified unique identifier set. - - UNANSWERED Messages that do not have the \Answered flag set. - - UNDELETED Messages that do not have the \Deleted flag set. - - UNDRAFT Messages that do not have the \Draft flag set. - - UNFLAGGED Messages that do not have the \Flagged flag set. - - UNKEYWORD - Messages that do not have the specified keyword - set. - - UNSEEN Messages that do not have the \Seen flag set. - - - - - -Crispin Standards Track [Page 40] - -RFC 2060 IMAP4rev1 December 1996 - - - Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" - S: * SEARCH 2 84 882 - S: A282 OK SEARCH completed - -6.4.5. FETCH Command - - Arguments: message set - message data item names - - Responses: untagged responses: FETCH - - Result: OK - fetch completed - NO - fetch error: can't fetch that data - BAD - command unknown or arguments invalid - - The FETCH command retrieves data associated with a message in the - mailbox. The data items to be fetched can be either a single atom - or a parenthesized list. - - The currently defined data items that can be fetched are: - - ALL Macro equivalent to: (FLAGS INTERNALDATE - RFC822.SIZE ENVELOPE) - - BODY Non-extensible form of BODYSTRUCTURE. - - BODY[
]<> - The text of a particular body section. The section - specification is a set of zero or more part - specifiers delimited by periods. A part specifier - is either a part number or one of the following: - HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and - TEXT. An empty section specification refers to the - entire message, including the header. - - Every message has at least one part number. - Non-[MIME-IMB] messages, and non-multipart - [MIME-IMB] messages with no encapsulated message, - only have a part 1. - - Multipart messages are assigned consecutive part - numbers, as they occur in the message. If a - particular part is of type message or multipart, - its parts MUST be indicated by a period followed by - the part number within that nested multipart part. - - - - - - -Crispin Standards Track [Page 41] - -RFC 2060 IMAP4rev1 December 1996 - - - A part of type MESSAGE/RFC822 also has nested part - numbers, referring to parts of the MESSAGE part's - body. - - The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and - TEXT part specifiers can be the sole part specifier - or can be prefixed by one or more numeric part - specifiers, provided that the numeric part - specifier refers to a part of type MESSAGE/RFC822. - The MIME part specifier MUST be prefixed by one or - more numeric part specifiers. - - The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT - part specifiers refer to the [RFC-822] header of - the message or of an encapsulated [MIME-IMT] - MESSAGE/RFC822 message. HEADER.FIELDS and - HEADER.FIELDS.NOT are followed by a list of - field-name (as defined in [RFC-822]) names, and - return a subset of the header. The subset returned - by HEADER.FIELDS contains only those header fields - with a field-name that matches one of the names in - the list; similarly, the subset returned by - HEADER.FIELDS.NOT contains only the header fields - with a non-matching field-name. The field-matching - is case-insensitive but otherwise exact. In all - cases, the delimiting blank line between the header - and the body is always included. - - The MIME part specifier refers to the [MIME-IMB] - header for this part. - - The TEXT part specifier refers to the text body of - the message, omitting the [RFC-822] header. - - - - - - - - - - - - - - - - - - -Crispin Standards Track [Page 42] - -RFC 2060 IMAP4rev1 December 1996 - - - Here is an example of a complex message - with some of its part specifiers: - - HEADER ([RFC-822] header of the message) - TEXT MULTIPART/MIXED - 1 TEXT/PLAIN - 2 APPLICATION/OCTET-STREAM - 3 MESSAGE/RFC822 - 3.HEADER ([RFC-822] header of the message) - 3.TEXT ([RFC-822] text body of the message) - 3.1 TEXT/PLAIN - 3.2 APPLICATION/OCTET-STREAM - 4 MULTIPART/MIXED - 4.1 IMAGE/GIF - 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) - 4.2 MESSAGE/RFC822 - 4.2.HEADER ([RFC-822] header of the message) - 4.2.TEXT ([RFC-822] text body of the message) - 4.2.1 TEXT/PLAIN - 4.2.2 MULTIPART/ALTERNATIVE - 4.2.2.1 TEXT/PLAIN - 4.2.2.2 TEXT/RICHTEXT - - - It is possible to fetch a substring of the - designated text. This is done by appending an open - angle bracket ("<"), the octet position of the - first desired octet, a period, the maximum number - of octets desired, and a close angle bracket (">") - to the part specifier. If the starting octet is - beyond the end of the text, an empty string is - returned. - - Any partial fetch that attempts to read beyond the - end of the text is truncated as appropriate. A - partial fetch that starts at octet 0 is returned as - a partial fetch, even if this truncation happened. - - Note: this means that BODY[]<0.2048> of a - 1500-octet message will return BODY[]<0> - with a literal of size 1500, not BODY[]. - - Note: a substring fetch of a - HEADER.FIELDS or HEADER.FIELDS.NOT part - specifier is calculated after subsetting - the header. - - - - - -Crispin Standards Track [Page 43] - -RFC 2060 IMAP4rev1 December 1996 - - - The \Seen flag is implicitly set; if this causes - the flags to change they SHOULD be included as part - of the FETCH responses. - - BODY.PEEK[
]<> - An alternate form of BODY[
] that does not - implicitly set the \Seen flag. - - BODYSTRUCTURE The [MIME-IMB] body structure of the message. This - is computed by the server by parsing the [MIME-IMB] - header fields in the [RFC-822] header and - [MIME-IMB] headers. - - ENVELOPE The envelope structure of the message. This is - computed by the server by parsing the [RFC-822] - header into the component parts, defaulting various - fields as necessary. - - FAST Macro equivalent to: (FLAGS INTERNALDATE - RFC822.SIZE) - - FLAGS The flags that are set for this message. - - FULL Macro equivalent to: (FLAGS INTERNALDATE - RFC822.SIZE ENVELOPE BODY) - - INTERNALDATE The internal date of the message. - - RFC822 Functionally equivalent to BODY[], differing in the - syntax of the resulting untagged FETCH data (RFC822 - is returned). - - RFC822.HEADER Functionally equivalent to BODY.PEEK[HEADER], - differing in the syntax of the resulting untagged - FETCH data (RFC822.HEADER is returned). - - RFC822.SIZE The [RFC-822] size of the message. - - RFC822.TEXT Functionally equivalent to BODY[TEXT], differing in - the syntax of the resulting untagged FETCH data - (RFC822.TEXT is returned). - - UID The unique identifier for the message. - - - - - - - - -Crispin Standards Track [Page 44] - -RFC 2060 IMAP4rev1 December 1996 - - - Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) - S: * 2 FETCH .... - S: * 3 FETCH .... - S: * 4 FETCH .... - S: A654 OK FETCH completed - -6.4.6. STORE Command - - Arguments: message set - message data item name - value for message data item - - Responses: untagged responses: FETCH - - Result: OK - store completed - NO - store error: can't store that data - BAD - command unknown or arguments invalid - - The STORE command alters data associated with a message in the - mailbox. Normally, STORE will return the updated value of the - data with an untagged FETCH response. A suffix of ".SILENT" in - the data item name prevents the untagged FETCH, and the server - SHOULD assume that the client has determined the updated value - itself or does not care about the updated value. - - Note: regardless of whether or not the ".SILENT" suffix was - used, the server SHOULD send an untagged FETCH response if a - change to a message's flags from an external source is - observed. The intent is that the status of the flags is - determinate without a race condition. - - The currently defined data items that can be stored are: - - FLAGS - Replace the flags for the message with the - argument. The new value of the flags are returned - as if a FETCH of those flags was done. - - FLAGS.SILENT - Equivalent to FLAGS, but without returning a new - value. - - +FLAGS - Add the argument to the flags for the message. The - new value of the flags are returned as if a FETCH - of those flags was done. - - - - - -Crispin Standards Track [Page 45] - -RFC 2060 IMAP4rev1 December 1996 - - - +FLAGS.SILENT - Equivalent to +FLAGS, but without returning a new - value. - - -FLAGS - Remove the argument from the flags for the message. - The new value of the flags are returned as if a - FETCH of those flags was done. - - -FLAGS.SILENT - Equivalent to -FLAGS, but without returning a new - value. - - Example: C: A003 STORE 2:4 +FLAGS (\Deleted) - S: * 2 FETCH FLAGS (\Deleted \Seen) - S: * 3 FETCH FLAGS (\Deleted) - S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) - S: A003 OK STORE completed - -6.4.7. COPY Command - - Arguments: message set - mailbox name - - Responses: no specific responses for this command - - Result: OK - copy completed - NO - copy error: can't copy those messages or to that - name - BAD - command unknown or arguments invalid - - The COPY command copies the specified message(s) to the end of the - specified destination mailbox. The flags and internal date of the - message(s) SHOULD be preserved in the copy. - - If the destination mailbox does not exist, a server SHOULD return - an error. It SHOULD NOT automatically create the mailbox. Unless - it is certain that the destination mailbox can not be created, the - server MUST send the response code "[TRYCREATE]" as the prefix of - the text of the tagged NO response. This gives a hint to the - client that it can attempt a CREATE command and retry the COPY if - the CREATE is successful. - - - - - - - - - -Crispin Standards Track [Page 46] - -RFC 2060 IMAP4rev1 December 1996 - - - If the COPY command is unsuccessful for any reason, server - implementations MUST restore the destination mailbox to its state - before the COPY attempt. - - Example: C: A003 COPY 2:4 MEETING - S: A003 OK COPY completed - -6.4.8. UID Command - - Arguments: command name - command arguments - - Responses: untagged responses: FETCH, SEARCH - - Result: OK - UID command completed - NO - UID command error - BAD - command unknown or arguments invalid - - The UID command has two forms. In the first form, it takes as its - arguments a COPY, FETCH, or STORE command with arguments - appropriate for the associated command. However, the numbers in - the message set argument are unique identifiers instead of message - sequence numbers. - - In the second form, the UID command takes a SEARCH command with - SEARCH command arguments. The interpretation of the arguments is - the same as with SEARCH; however, the numbers returned in a SEARCH - response for a UID SEARCH command are unique identifiers instead - of message sequence numbers. For example, the command UID SEARCH - 1:100 UID 443:557 returns the unique identifiers corresponding to - the intersection of the message sequence number set 1:100 and the - UID set 443:557. - - Message set ranges are permitted; however, there is no guarantee - that unique identifiers be contiguous. A non-existent unique - identifier within a message set range is ignored without any error - message generated. - - The number after the "*" in an untagged FETCH response is always a - message sequence number, not a unique identifier, even for a UID - command response. However, server implementations MUST implicitly - include the UID message data item as part of any FETCH response - caused by a UID command, regardless of whether a UID was specified - as a message data item to the FETCH. - - - - - - - -Crispin Standards Track [Page 47] - -RFC 2060 IMAP4rev1 December 1996 - - - Example: C: A999 UID FETCH 4827313:4828442 FLAGS - S: * 23 FETCH (FLAGS (\Seen) UID 4827313) - S: * 24 FETCH (FLAGS (\Seen) UID 4827943) - S: * 25 FETCH (FLAGS (\Seen) UID 4828442) - S: A999 UID FETCH completed - -6.5. Client Commands - Experimental/Expansion - -6.5.1. X Command - - Arguments: implementation defined - - Responses: implementation defined - - Result: OK - command completed - NO - failure - BAD - command unknown or arguments invalid - - Any command prefixed with an X is an experimental command. - Commands which are not part of this specification, a standard or - standards-track revision of this specification, or an IESG- - approved experimental protocol, MUST use the X prefix. - - Any added untagged responses issued by an experimental command - MUST also be prefixed with an X. Server implementations MUST NOT - send any such untagged responses, unless the client requested it - by issuing the associated experimental command. - - Example: C: a441 CAPABILITY - S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN - S: a441 OK CAPABILITY completed - C: A442 XPIG-LATIN - S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay - S: A442 OK XPIG-LATIN ompleted-cay - -7. Server Responses - - Server responses are in three forms: status responses, server data, - and command continuation request. The information contained in a - server response, identified by "Contents:" in the response - descriptions below, is described by function, not by syntax. The - precise syntax of server responses is described in the Formal Syntax - section. - - The client MUST be prepared to accept any response at all times. - - - - - - -Crispin Standards Track [Page 48] - -RFC 2060 IMAP4rev1 December 1996 - - - Status responses can be tagged or untagged. Tagged status responses - indicate the completion result (OK, NO, or BAD status) of a client - command, and have a tag matching the command. - - Some status responses, and all server data, are untagged. An - untagged response is indicated by the token "*" instead of a tag. - Untagged status responses indicate server greeting, or server status - that does not indicate the completion of a command (for example, an - impending system shutdown alert). For historical reasons, untagged - server data responses are also called "unsolicited data", although - strictly speaking only unilateral server data is truly "unsolicited". - - Certain server data MUST be recorded by the client when it is - received; this is noted in the description of that data. Such data - conveys critical information which affects the interpretation of all - subsequent commands and responses (e.g. updates reflecting the - creation or destruction of messages). - - Other server data SHOULD be recorded for later reference; if the - client does not need to record the data, or if recording the data has - no obvious purpose (e.g. a SEARCH response when no SEARCH command is - in progress), the data SHOULD be ignored. - - An example of unilateral untagged server data occurs when the IMAP - connection is in selected state. In selected state, the server - checks the mailbox for new messages as part of command execution. - Normally, this is part of the execution of every command; hence, a - NOOP command suffices to check for new messages. If new messages are - found, the server sends untagged EXISTS and RECENT responses - reflecting the new size of the mailbox. Server implementations that - offer multiple simultaneous access to the same mailbox SHOULD also - send appropriate unilateral untagged FETCH and EXPUNGE responses if - another agent changes the state of any message flags or expunges any - messages. - - Command continuation request responses use the token "+" instead of a - tag. These responses are sent by the server to indicate acceptance - of an incomplete client command and readiness for the remainder of - the command. - -7.1. Server Responses - Status Responses - - Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD - may be tagged or untagged. PREAUTH and BYE are always untagged. - - Status responses MAY include an OPTIONAL "response code". A response - code consists of data inside square brackets in the form of an atom, - possibly followed by a space and arguments. The response code - - - -Crispin Standards Track [Page 49] - -RFC 2060 IMAP4rev1 December 1996 - - - contains additional information or status codes for client software - beyond the OK/NO/BAD condition, and are defined when there is a - specific action that a client can take based upon the additional - information. - - The currently defined response codes are: - - ALERT The human-readable text contains a special alert - that MUST be presented to the user in a fashion - that calls the user's attention to the message. - - NEWNAME Followed by a mailbox name and a new mailbox name. - A SELECT or EXAMINE is failing because the target - mailbox name no longer exists because it was - renamed to the new mailbox name. This is a hint to - the client that the operation can succeed if the - SELECT or EXAMINE is reissued with the new mailbox - name. - - PARSE The human-readable text represents an error in - parsing the [RFC-822] header or [MIME-IMB] headers - of a message in the mailbox. - - PERMANENTFLAGS Followed by a parenthesized list of flags, - indicates which of the known flags that the client - can change permanently. Any flags that are in the - FLAGS untagged response, but not the PERMANENTFLAGS - list, can not be set permanently. If the client - attempts to STORE a flag that is not in the - PERMANENTFLAGS list, the server will either reject - it with a NO reply or store the state for the - remainder of the current session only. The - PERMANENTFLAGS list can also include the special - flag \*, which indicates that it is possible to - create new keywords by attempting to store those - flags in the mailbox. - - READ-ONLY The mailbox is selected read-only, or its access - while selected has changed from read-write to - read-only. - - READ-WRITE The mailbox is selected read-write, or its access - while selected has changed from read-only to - read-write. - - - - - - - -Crispin Standards Track [Page 50] - -RFC 2060 IMAP4rev1 December 1996 - - - TRYCREATE An APPEND or COPY attempt is failing because the - target mailbox does not exist (as opposed to some - other reason). This is a hint to the client that - the operation can succeed if the mailbox is first - created by the CREATE command. - - UIDVALIDITY Followed by a decimal number, indicates the unique - identifier validity value. - - UNSEEN Followed by a decimal number, indicates the number - of the first message without the \Seen flag set. - - Additional response codes defined by particular client or server - implementations SHOULD be prefixed with an "X" until they are - added to a revision of this protocol. Client implementations - SHOULD ignore response codes that they do not recognize. - -7.1.1. OK Response - - Contents: OPTIONAL response code - human-readable text - - The OK response indicates an information message from the server. - When tagged, it indicates successful completion of the associated - command. The human-readable text MAY be presented to the user as - an information message. The untagged form indicates an - information-only message; the nature of the information MAY be - indicated by a response code. - - The untagged form is also used as one of three possible greetings - at connection startup. It indicates that the connection is not - yet authenticated and that a LOGIN command is needed. - - Example: S: * OK IMAP4rev1 server ready - C: A001 LOGIN fred blurdybloop - S: * OK [ALERT] System shutdown in 10 minutes - S: A001 OK LOGIN Completed - -7.1.2. NO Response - - Contents: OPTIONAL response code - human-readable text - - The NO response indicates an operational error message from the - server. When tagged, it indicates unsuccessful completion of the - associated command. The untagged form indicates a warning; the - command can still complete successfully. The human-readable text - describes the condition. - - - -Crispin Standards Track [Page 51] - -RFC 2060 IMAP4rev1 December 1996 - - - Example: C: A222 COPY 1:2 owatagusiam - S: * NO Disk is 98% full, please delete unnecessary data - S: A222 OK COPY completed - C: A223 COPY 3:200 blurdybloop - S: * NO Disk is 98% full, please delete unnecessary data - S: * NO Disk is 99% full, please delete unnecessary data - S: A223 NO COPY failed: disk is full - -7.1.3. BAD Response - - Contents: OPTIONAL response code - human-readable text - - The BAD response indicates an error message from the server. When - tagged, it reports a protocol-level error in the client's command; - the tag indicates the command that caused the error. The untagged - form indicates a protocol-level error for which the associated - command can not be determined; it can also indicate an internal - server failure. The human-readable text describes the condition. - - Example: C: ...very long command line... - S: * BAD Command line too long - C: ...empty line... - S: * BAD Empty command line - C: A443 EXPUNGE - S: * BAD Disk crash, attempting salvage to a new disk! - S: * OK Salvage successful, no data lost - S: A443 OK Expunge completed - -7.1.4. PREAUTH Response - - Contents: OPTIONAL response code - human-readable text - - The PREAUTH response is always untagged, and is one of three - possible greetings at connection startup. It indicates that the - connection has already been authenticated by external means and - thus no LOGIN command is needed. - - Example: S: * PREAUTH IMAP4rev1 server logged in as Smith - -7.1.5. BYE Response - - Contents: OPTIONAL response code - human-readable text - - - - - - -Crispin Standards Track [Page 52] - -RFC 2060 IMAP4rev1 December 1996 - - - The BYE response is always untagged, and indicates that the server - is about to close the connection. The human-readable text MAY be - displayed to the user in a status report by the client. The BYE - response is sent under one of four conditions: - - 1) as part of a normal logout sequence. The server will close - the connection after sending the tagged OK response to the - LOGOUT command. - - 2) as a panic shutdown announcement. The server closes the - connection immediately. - - 3) as an announcement of an inactivity autologout. The server - closes the connection immediately. - - 4) as one of three possible greetings at connection startup, - indicating that the server is not willing to accept a - connection from this client. The server closes the - connection immediately. - - The difference between a BYE that occurs as part of a normal - LOGOUT sequence (the first case) and a BYE that occurs because of - a failure (the other three cases) is that the connection closes - immediately in the failure case. - - Example: S: * BYE Autologout; idle for too long - -7.2. Server Responses - Server and Mailbox Status - - These responses are always untagged. This is how server and mailbox - status data are transmitted from the server to the client. Many of - these responses typically result from a command with the same name. - -7.2.1. CAPABILITY Response - - Contents: capability listing - - The CAPABILITY response occurs as a result of a CAPABILITY - command. The capability listing contains a space-separated - listing of capability names that the server supports. The - capability listing MUST include the atom "IMAP4rev1". - - A capability name which begins with "AUTH=" indicates that the - server supports that particular authentication mechanism. - - - - - - - -Crispin Standards Track [Page 53] - -RFC 2060 IMAP4rev1 December 1996 - - - Other capability names indicate that the server supports an - extension, revision, or amendment to the IMAP4rev1 protocol. - Server responses MUST conform to this document until the client - issues a command that uses the associated capability. - - Capability names MUST either begin with "X" or be standard or - standards-track IMAP4rev1 extensions, revisions, or amendments - registered with IANA. A server MUST NOT offer unregistered or - non-standard capability names, unless such names are prefixed with - an "X". - - Client implementations SHOULD NOT require any capability name - other than "IMAP4rev1", and MUST ignore any unknown capability - names. - - Example: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN - -7.2.2. LIST Response - - Contents: name attributes - hierarchy delimiter - name - - The LIST response occurs as a result of a LIST command. It - returns a single name that matches the LIST specification. There - can be multiple LIST responses for a single LIST command. - - Four name attributes are defined: - - \Noinferiors It is not possible for any child levels of - hierarchy to exist under this name; no child levels - exist now and none can be created in the future. - - \Noselect It is not possible to use this name as a selectable - mailbox. - - \Marked The mailbox has been marked "interesting" by the - server; the mailbox probably contains messages that - have been added since the last time the mailbox was - selected. - - \Unmarked The mailbox does not contain any additional - messages since the last time the mailbox was - selected. - - If it is not feasible for the server to determine whether the - mailbox is "interesting" or not, or if the name is a \Noselect - name, the server SHOULD NOT send either \Marked or \Unmarked. - - - -Crispin Standards Track [Page 54] - -RFC 2060 IMAP4rev1 December 1996 - - - The hierarchy delimiter is a character used to delimit levels of - hierarchy in a mailbox name. A client can use it to create child - mailboxes, and to search higher or lower levels of naming - hierarchy. All children of a top-level hierarchy node MUST use - the same separator character. A NIL hierarchy delimiter means - that no hierarchy exists; the name is a "flat" name. - - The name represents an unambiguous left-to-right hierarchy, and - MUST be valid for use as a reference in LIST and LSUB commands. - Unless \Noselect is indicated, the name MUST also be valid as an - argument for commands, such as SELECT, that accept mailbox - names. - - Example: S: * LIST (\Noselect) "/" ~/Mail/foo - -7.2.3. LSUB Response - - Contents: name attributes - hierarchy delimiter - name - - The LSUB response occurs as a result of an LSUB command. It - returns a single name that matches the LSUB specification. There - can be multiple LSUB responses for a single LSUB command. The - data is identical in format to the LIST response. - - Example: S: * LSUB () "." #news.comp.mail.misc - -7.2.4 STATUS Response - - Contents: name - status parenthesized list - - The STATUS response occurs as a result of an STATUS command. It - returns the mailbox name that matches the STATUS specification and - the requested mailbox status information. - - Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) - -7.2.5. SEARCH Response - - Contents: zero or more numbers - - - - - - - - - -Crispin Standards Track [Page 55] - -RFC 2060 IMAP4rev1 December 1996 - - - The SEARCH response occurs as a result of a SEARCH or UID SEARCH - command. The number(s) refer to those messages that match the - search criteria. For SEARCH, these are message sequence numbers; - for UID SEARCH, these are unique identifiers. Each number is - delimited by a space. - - Example: S: * SEARCH 2 3 6 - -7.2.6. FLAGS Response - - Contents: flag parenthesized list - - The FLAGS response occurs as a result of a SELECT or EXAMINE - command. The flag parenthesized list identifies the flags (at a - minimum, the system-defined flags) that are applicable for this - mailbox. Flags other than the system flags can also exist, - depending on server implementation. - - The update from the FLAGS response MUST be recorded by the client. - - Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) - -7.3. Server Responses - Mailbox Size - - These responses are always untagged. This is how changes in the size - of the mailbox are trasnmitted from the server to the client. - Immediately following the "*" token is a number that represents a - message count. - -7.3.1. EXISTS Response - - Contents: none - - The EXISTS response reports the number of messages in the mailbox. - This response occurs as a result of a SELECT or EXAMINE command, - and if the size of the mailbox changes (e.g. new mail). - - The update from the EXISTS response MUST be recorded by the - client. - - Example: S: * 23 EXISTS - - - - - - - - - - -Crispin Standards Track [Page 56] - -RFC 2060 IMAP4rev1 December 1996 - - -7.3.2. RECENT Response - - Contents: none - - The RECENT response reports the number of messages with the - \Recent flag set. This response occurs as a result of a SELECT or - EXAMINE command, and if the size of the mailbox changes (e.g. new - mail). - - Note: It is not guaranteed that the message sequence numbers of - recent messages will be a contiguous range of the highest n - messages in the mailbox (where n is the value reported by the - RECENT response). Examples of situations in which this is not - the case are: multiple clients having the same mailbox open - (the first session to be notified will see it as recent, others - will probably see it as non-recent), and when the mailbox is - re-ordered by a non-IMAP agent. - - The only reliable way to identify recent messages is to look at - message flags to see which have the \Recent flag set, or to do - a SEARCH RECENT. - - The update from the RECENT response MUST be recorded by the - client. - - Example: S: * 5 RECENT - -7.4. Server Responses - Message Status - - These responses are always untagged. This is how message data are - transmitted from the server to the client, often as a result of a - command with the same name. Immediately following the "*" token is a - number that represents a message sequence number. - -7.4.1. EXPUNGE Response - - Contents: none - - The EXPUNGE response reports that the specified message sequence - number has been permanently removed from the mailbox. The message - sequence number for each successive message in the mailbox is - immediately decremented by 1, and this decrement is reflected in - message sequence numbers in subsequent responses (including other - untagged EXPUNGE responses). - - As a result of the immediate decrement rule, message sequence - numbers that appear in a set of successive EXPUNGE responses - depend upon whether the messages are removed starting from lower - - - -Crispin Standards Track [Page 57] - -RFC 2060 IMAP4rev1 December 1996 - - - numbers to higher numbers, or from higher numbers to lower - numbers. For example, if the last 5 messages in a 9-message - mailbox are expunged; a "lower to higher" server will send five - untagged EXPUNGE responses for message sequence number 5, whereas - a "higher to lower server" will send successive untagged EXPUNGE - responses for message sequence numbers 9, 8, 7, 6, and 5. - - An EXPUNGE response MUST NOT be sent when no command is in - progress; nor while responding to a FETCH, STORE, or SEARCH - command. This rule is necessary to prevent a loss of - synchronization of message sequence numbers between client and - server. - - The update from the EXPUNGE response MUST be recorded by the - client. - - Example: S: * 44 EXPUNGE - -7.4.2. FETCH Response - - Contents: message data - - The FETCH response returns data about a message to the client. - The data are pairs of data item names and their values in - parentheses. This response occurs as the result of a FETCH or - STORE command, as well as by unilateral server decision (e.g. flag - updates). - - The current data items are: - - BODY A form of BODYSTRUCTURE without extension data. - - BODY[
]<> - A string expressing the body contents of the - specified section. The string SHOULD be - interpreted by the client according to the content - transfer encoding, body type, and subtype. - - If the origin octet is specified, this string is a - substring of the entire body contents, starting at - that origin octet. This means that BODY[]<0> MAY - be truncated, but BODY[] is NEVER truncated. - - 8-bit textual data is permitted if a [CHARSET] - identifier is part of the body parameter - parenthesized list for this section. Note that - headers (part specifiers HEADER or MIME, or the - header portion of a MESSAGE/RFC822 part), MUST be - - - -Crispin Standards Track [Page 58] - -RFC 2060 IMAP4rev1 December 1996 - - - 7-bit; 8-bit characters are not permitted in - headers. Note also that the blank line at the end - of the header is always included in header data. - - Non-textual data such as binary data MUST be - transfer encoded into a textual form such as BASE64 - prior to being sent to the client. To derive the - original binary data, the client MUST decode the - transfer encoded string. - - BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB] - body structure of a message. This is computed by - the server by parsing the [MIME-IMB] header fields, - defaulting various fields as necessary. - - For example, a simple text message of 48 lines and - 2279 octets can have a body structure of: ("TEXT" - "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 - 48) - - Multiple parts are indicated by parenthesis - nesting. Instead of a body type as the first - element of the parenthesized list there is a nested - body. The second element of the parenthesized list - is the multipart subtype (mixed, digest, parallel, - alternative, etc.). - - For example, a two part message consisting of a - text and a BASE645-encoded text attachment can have - a body structure of: (("TEXT" "PLAIN" ("CHARSET" - "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" - ("CHARSET" "US-ASCII" "NAME" "cc.diff") - "<960723163407.20117h@cac.washington.edu>" - "Compiler diff" "BASE64" 4554 73) "MIXED")) - - Extension data follows the multipart subtype. - Extension data is never returned with the BODY - fetch, but can be returned with a BODYSTRUCTURE - fetch. Extension data, if present, MUST be in the - defined order. - - The extension data of a multipart body part are in - the following order: - - body parameter parenthesized list - A parenthesized list of attribute/value pairs - [e.g. ("foo" "bar" "baz" "rag") where "bar" is - the value of "foo" and "rag" is the value of - - - -Crispin Standards Track [Page 59] - -RFC 2060 IMAP4rev1 December 1996 - - - "baz"] as defined in [MIME-IMB]. - - body disposition - A parenthesized list, consisting of a - disposition type string followed by a - parenthesized list of disposition - attribute/value pairs. The disposition type and - attribute names will be defined in a future - standards-track revision to [DISPOSITION]. - - body language - A string or parenthesized list giving the body - language value as defined in [LANGUAGE-TAGS]. - - Any following extension data are not yet defined in - this version of the protocol. Such extension data - can consist of zero or more NILs, strings, numbers, - or potentially nested parenthesized lists of such - data. Client implementations that do a - BODYSTRUCTURE fetch MUST be prepared to accept such - extension data. Server implementations MUST NOT - send such extension data until it has been defined - by a revision of this protocol. - - The basic fields of a non-multipart body part are - in the following order: - - body type - A string giving the content media type name as - defined in [MIME-IMB]. - - body subtype - A string giving the content subtype name as - defined in [MIME-IMB]. - - body parameter parenthesized list - A parenthesized list of attribute/value pairs - [e.g. ("foo" "bar" "baz" "rag") where "bar" is - the value of "foo" and "rag" is the value of - "baz"] as defined in [MIME-IMB]. - - body id - A string giving the content id as defined in - [MIME-IMB]. - - body description - A string giving the content description as - defined in [MIME-IMB]. - - - -Crispin Standards Track [Page 60] - -RFC 2060 IMAP4rev1 December 1996 - - - body encoding - A string giving the content transfer encoding as - defined in [MIME-IMB]. - - body size - A number giving the size of the body in octets. - Note that this size is the size in its transfer - encoding and not the resulting size after any - decoding. - - A body type of type MESSAGE and subtype RFC822 - contains, immediately after the basic fields, the - envelope structure, body structure, and size in - text lines of the encapsulated message. - - A body type of type TEXT contains, immediately - after the basic fields, the size of the body in - text lines. Note that this size is the size in its - content transfer encoding and not the resulting - size after any decoding. - - Extension data follows the basic fields and the - type-specific fields listed above. Extension data - is never returned with the BODY fetch, but can be - returned with a BODYSTRUCTURE fetch. Extension - data, if present, MUST be in the defined order. - - The extension data of a non-multipart body part are - in the following order: - - body MD5 - A string giving the body MD5 value as defined in - [MD5]. - - body disposition - A parenthesized list with the same content and - function as the body disposition for a multipart - body part. - - body language - A string or parenthesized list giving the body - language value as defined in [LANGUAGE-TAGS]. - - Any following extension data are not yet defined in - this version of the protocol, and would be as - described above under multipart extension data. - - - - - -Crispin Standards Track [Page 61] - -RFC 2060 IMAP4rev1 December 1996 - - - ENVELOPE A parenthesized list that describes the envelope - structure of a message. This is computed by the - server by parsing the [RFC-822] header into the - component parts, defaulting various fields as - necessary. - - The fields of the envelope structure are in the - following order: date, subject, from, sender, - reply-to, to, cc, bcc, in-reply-to, and message-id. - The date, subject, in-reply-to, and message-id - fields are strings. The from, sender, reply-to, - to, cc, and bcc fields are parenthesized lists of - address structures. - - An address structure is a parenthesized list that - describes an electronic mail address. The fields - of an address structure are in the following order: - personal name, [SMTP] at-domain-list (source - route), mailbox name, and host name. - - [RFC-822] group syntax is indicated by a special - form of address structure in which the host name - field is NIL. If the mailbox name field is also - NIL, this is an end of group marker (semi-colon in - RFC 822 syntax). If the mailbox name field is - non-NIL, this is a start of group marker, and the - mailbox name field holds the group name phrase. - - Any field of an envelope or address structure that - is not applicable is presented as NIL. Note that - the server MUST default the reply-to and sender - fields from the from field; a client is not - expected to know to do this. - - FLAGS A parenthesized list of flags that are set for this - message. - - INTERNALDATE A string representing the internal date of the - message. - - RFC822 Equivalent to BODY[]. - - RFC822.HEADER Equivalent to BODY.PEEK[HEADER]. - - RFC822.SIZE A number expressing the [RFC-822] size of the - message. - - RFC822.TEXT Equivalent to BODY[TEXT]. - - - -Crispin Standards Track [Page 62] - -RFC 2060 IMAP4rev1 December 1996 - - - UID A number expressing the unique identifier of the - message. - - - Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) - -7.5. Server Responses - Command Continuation Request - - The command continuation request response is indicated by a "+" token - instead of a tag. This form of response indicates that the server is - ready to accept the continuation of a command from the client. The - remainder of this response is a line of text. - - This response is used in the AUTHORIZATION command to transmit server - data to the client, and request additional client data. This - response is also used if an argument to any command is a literal. - - The client is not permitted to send the octets of the literal unless - the server indicates that it expects it. This permits the server to - process commands and reject errors on a line-by-line basis. The - remainder of the command, including the CRLF that terminates a - command, follows the octets of the literal. If there are any - additional command arguments the literal octets are followed by a - space and those arguments. - - Example: C: A001 LOGIN {11} - S: + Ready for additional command text - C: FRED FOOBAR {7} - S: + Ready for additional command text - C: fat man - S: A001 OK LOGIN completed - C: A044 BLURDYBLOOP {102856} - S: A044 BAD No such command as "BLURDYBLOOP" - -8. Sample IMAP4rev1 connection - - The following is a transcript of an IMAP4rev1 connection. A long - line in this sample is broken for editorial clarity. - -S: * OK IMAP4rev1 Service Ready -C: a001 login mrc secret -S: a001 OK LOGIN completed -C: a002 select inbox -S: * 18 EXISTS -S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) -S: * 2 RECENT -S: * OK [UNSEEN 17] Message 17 is the first unseen message -S: * OK [UIDVALIDITY 3857529045] UIDs valid - - - -Crispin Standards Track [Page 63] - -RFC 2060 IMAP4rev1 December 1996 - - -S: a002 OK [READ-WRITE] SELECT completed -C: a003 fetch 12 full -S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" - RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" - "IMAP4rev1 WG mtg summary and minutes" - (("Terry Gray" NIL "gray" "cac.washington.edu")) - (("Terry Gray" NIL "gray" "cac.washington.edu")) - (("Terry Gray" NIL "gray" "cac.washington.edu")) - ((NIL NIL "imap" "cac.washington.edu")) - ((NIL NIL "minutes" "CNRI.Reston.VA.US") - ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL - "") - BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) -S: a003 OK FETCH completed -C: a004 fetch 12 body[header] -S: * 12 FETCH (BODY[HEADER] {350} -S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) -S: From: Terry Gray -S: Subject: IMAP4rev1 WG mtg summary and minutes -S: To: imap@cac.washington.edu -S: cc: minutes@CNRI.Reston.VA.US, John Klensin -S: Message-Id: -S: MIME-Version: 1.0 -S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII -S: -S: ) -S: a004 OK FETCH completed -C: a005 store 12 +flags \deleted -S: * 12 FETCH (FLAGS (\Seen \Deleted)) -S: a005 OK +FLAGS completed -C: a006 logout -S: * BYE IMAP4rev1 server terminating connection -S: a006 OK LOGOUT completed - -9. Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) notation as specified in [RFC-822] with one exception; the - delimiter used with the "#" construct is a single space (SPACE) and - not one or more commas. - - In the case of alternative or optional rules in which a later rule - overlaps an earlier rule, the rule which is listed earlier MUST take - priority. For example, "\Seen" when parsed as a flag is the \Seen - flag name and not a flag_extension, even though "\Seen" could be - parsed as a flag_extension. Some, but not all, instances of this - rule are noted below. - - - - -Crispin Standards Track [Page 64] - -RFC 2060 IMAP4rev1 December 1996 - - - Except as noted otherwise, all alphabetic characters are case- - insensitive. The use of upper or lower case characters to define - token strings is for editorial clarity only. Implementations MUST - accept these strings in a case-insensitive fashion. - -address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox - SPACE addr_host ")" - -addr_adl ::= nstring - ;; Holds route from [RFC-822] route-addr if - ;; non-NIL - -addr_host ::= nstring - ;; NIL indicates [RFC-822] group syntax. - ;; Otherwise, holds [RFC-822] domain name - -addr_mailbox ::= nstring - ;; NIL indicates end of [RFC-822] group; if - ;; non-NIL and addr_host is NIL, holds - ;; [RFC-822] group name. - ;; Otherwise, holds [RFC-822] local-part - -addr_name ::= nstring - ;; Holds phrase from [RFC-822] mailbox if - ;; non-NIL - -alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / - "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / - "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / - "Y" / "Z" / - "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / - "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / - "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / - "y" / "z" - ;; Case-sensitive - -append ::= "APPEND" SPACE mailbox [SPACE flag_list] - [SPACE date_time] SPACE literal - -astring ::= atom / string - -atom ::= 1*ATOM_CHAR - -ATOM_CHAR ::= - -atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards / - quoted_specials - - - - -Crispin Standards Track [Page 65] - -RFC 2060 IMAP4rev1 December 1996 - - -authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) - -auth_type ::= atom - ;; Defined by [IMAP-AUTH] - -base64 ::= *(4base64_char) [base64_terminal] - -base64_char ::= alpha / digit / "+" / "/" - -base64_terminal ::= (2base64_char "==") / (3base64_char "=") - -body ::= "(" body_type_1part / body_type_mpart ")" - -body_extension ::= nstring / number / "(" 1#body_extension ")" - ;; Future expansion. Client implementations - ;; MUST accept body_extension fields. Server - ;; implementations MUST NOT generate - ;; body_extension fields except as defined by - ;; future standard or standards-track - ;; revisions of this specification. - -body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp - [SPACE body_fld_lang - [SPACE 1#body_extension]]] - ;; MUST NOT be returned on non-extensible - ;; "BODY" fetch - -body_ext_mpart ::= body_fld_param - [SPACE body_fld_dsp SPACE body_fld_lang - [SPACE 1#body_extension]] - ;; MUST NOT be returned on non-extensible - ;; "BODY" fetch - -body_fields ::= body_fld_param SPACE body_fld_id SPACE - body_fld_desc SPACE body_fld_enc SPACE - body_fld_octets - -body_fld_desc ::= nstring - -body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil - -body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ - "QUOTED-PRINTABLE") <">) / string - -body_fld_id ::= nstring - -body_fld_lang ::= nstring / "(" 1#string ")" - - - - -Crispin Standards Track [Page 66] - -RFC 2060 IMAP4rev1 December 1996 - - -body_fld_lines ::= number - -body_fld_md5 ::= nstring - -body_fld_octets ::= number - -body_fld_param ::= "(" 1#(string SPACE string) ")" / nil - -body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) - [SPACE body_ext_1part] - -body_type_basic ::= media_basic SPACE body_fields - ;; MESSAGE subtype MUST NOT be "RFC822" - -body_type_mpart ::= 1*body SPACE media_subtype - [SPACE body_ext_mpart] - -body_type_msg ::= media_message SPACE body_fields SPACE envelope - SPACE body SPACE body_fld_lines - -body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines - -capability ::= "AUTH=" auth_type / atom - ;; New capabilities MUST begin with "X" or be - ;; registered with IANA as standard or - ;; standards-track - -capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1" - [SPACE 1#capability] - ;; IMAP4rev1 servers which offer RFC 1730 - ;; compatibility MUST list "IMAP4" as the first - ;; capability. - -CHAR ::= - -CHAR8 ::= - -command ::= tag SPACE (command_any / command_auth / - command_nonauth / command_select) CRLF - ;; Modal based on state - -command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command - ;; Valid in all states - -command_auth ::= append / create / delete / examine / list / lsub / - rename / select / status / subscribe / unsubscribe - ;; Valid only in Authenticated or Selected state - - - -Crispin Standards Track [Page 67] - -RFC 2060 IMAP4rev1 December 1996 - - -command_nonauth ::= login / authenticate - ;; Valid only when in Non-Authenticated state - -command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / - copy / fetch / store / uid / search - ;; Valid only when in Selected state - -continue_req ::= "+" SPACE (resp_text / base64) - -copy ::= "COPY" SPACE set SPACE mailbox - -CR ::= - -create ::= "CREATE" SPACE mailbox - ;; Use of INBOX gives a NO error - -CRLF ::= CR LF - -CTL ::= - -date ::= date_text / <"> date_text <"> - -date_day ::= 1*2digit - ;; Day of month - -date_day_fixed ::= (SPACE digit) / 2digit - ;; Fixed-format version of date_day - -date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / - "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" - -date_text ::= date_day "-" date_month "-" date_year - -date_year ::= 4digit - -date_time ::= <"> date_day_fixed "-" date_month "-" date_year - SPACE time SPACE zone <"> - -delete ::= "DELETE" SPACE mailbox - ;; Use of INBOX gives a NO error - -digit ::= "0" / digit_nz - -digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / - "9" - - - - - -Crispin Standards Track [Page 68] - -RFC 2060 IMAP4rev1 December 1996 - - -envelope ::= "(" env_date SPACE env_subject SPACE env_from - SPACE env_sender SPACE env_reply_to SPACE env_to - SPACE env_cc SPACE env_bcc SPACE env_in_reply_to - SPACE env_message_id ")" - -env_bcc ::= "(" 1*address ")" / nil - -env_cc ::= "(" 1*address ")" / nil - -env_date ::= nstring - -env_from ::= "(" 1*address ")" / nil - -env_in_reply_to ::= nstring - -env_message_id ::= nstring - -env_reply_to ::= "(" 1*address ")" / nil - -env_sender ::= "(" 1*address ")" / nil - -env_subject ::= nstring - -env_to ::= "(" 1*address ")" / nil - -examine ::= "EXAMINE" SPACE mailbox - -fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / - "FAST" / fetch_att / "(" 1#fetch_att ")") - -fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / - "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] / - "BODY" ["STRUCTURE"] / "UID" / - "BODY" [".PEEK"] section - ["<" number "." nz_number ">"] - -flag ::= "\Answered" / "\Flagged" / "\Deleted" / - "\Seen" / "\Draft" / flag_keyword / flag_extension - -flag_extension ::= "\" atom - ;; Future expansion. Client implementations - ;; MUST accept flag_extension flags. Server - ;; implementations MUST NOT generate - ;; flag_extension flags except as defined by - ;; future standard or standards-track - ;; revisions of this specification. - -flag_keyword ::= atom - - - -Crispin Standards Track [Page 69] - -RFC 2060 IMAP4rev1 December 1996 - - -flag_list ::= "(" #flag ")" - -greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF - -header_fld_name ::= astring - -header_list ::= "(" 1#header_fld_name ")" - -LF ::= - -list ::= "LIST" SPACE mailbox SPACE list_mailbox - -list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string - -list_wildcards ::= "%" / "*" - -literal ::= "{" number "}" CRLF *CHAR8 - ;; Number represents the number of CHAR8 octets - -login ::= "LOGIN" SPACE userid SPACE password - -lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox - -mailbox ::= "INBOX" / astring - ;; INBOX is case-insensitive. All case variants of - ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX - ;; not as an astring. Refer to section 5.1 for - ;; further semantic details of mailbox names. - -mailbox_data ::= "FLAGS" SPACE flag_list / - "LIST" SPACE mailbox_list / - "LSUB" SPACE mailbox_list / - "MAILBOX" SPACE text / - "SEARCH" [SPACE 1#nz_number] / - "STATUS" SPACE mailbox SPACE - "(" # QUOTED_CHAR <"> / nil) SPACE mailbox - -media_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / - "MESSAGE" / "VIDEO") <">) / string) - SPACE media_subtype - ;; Defined in [MIME-IMT] - -media_message ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> - - - -Crispin Standards Track [Page 70] - -RFC 2060 IMAP4rev1 December 1996 - - - ;; Defined in [MIME-IMT] - -media_subtype ::= string - ;; Defined in [MIME-IMT] - -media_text ::= <"> "TEXT" <"> SPACE media_subtype - ;; Defined in [MIME-IMT] - -message_data ::= nz_number SPACE ("EXPUNGE" / - ("FETCH" SPACE msg_att)) - -msg_att ::= "(" 1#("ENVELOPE" SPACE envelope / - "FLAGS" SPACE "(" #(flag / "\Recent") ")" / - "INTERNALDATE" SPACE date_time / - "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / - "RFC822.SIZE" SPACE number / - "BODY" ["STRUCTURE"] SPACE body / - "BODY" section ["<" number ">"] SPACE nstring / - "UID" SPACE uniqueid) ")" - -nil ::= "NIL" - -nstring ::= string / nil - -number ::= 1*digit - ;; Unsigned 32-bit integer - ;; (0 <= n < 4,294,967,296) - -nz_number ::= digit_nz *digit - ;; Non-zero unsigned 32-bit integer - ;; (0 < n < 4,294,967,296) - -password ::= astring - -quoted ::= <"> *QUOTED_CHAR <"> - -QUOTED_CHAR ::= / - "\" quoted_specials - -quoted_specials ::= <"> / "\" - -rename ::= "RENAME" SPACE mailbox SPACE mailbox - ;; Use of INBOX as a destination gives a NO error - -response ::= *(continue_req / response_data) response_done - -response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / - mailbox_data / message_data / capability_data) - - - -Crispin Standards Track [Page 71] - -RFC 2060 IMAP4rev1 December 1996 - - - CRLF - -response_done ::= response_tagged / response_fatal - -response_fatal ::= "*" SPACE resp_cond_bye CRLF - ;; Server closes connection immediately - -response_tagged ::= tag SPACE resp_cond_state CRLF - -resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text - ;; Authentication condition - -resp_cond_bye ::= "BYE" SPACE resp_text - -resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text - ;; Status condition - -resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) - ;; text SHOULD NOT begin with "[" or "=" - -resp_text_code ::= "ALERT" / "PARSE" / - "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / - "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / - "UIDVALIDITY" SPACE nz_number / - "UNSEEN" SPACE nz_number / - atom [SPACE 1*] - -search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] - 1#search_key - ;; [CHARSET] MUST be registered with IANA - -search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / - "BEFORE" SPACE date / "BODY" SPACE astring / - "CC" SPACE astring / "DELETED" / "FLAGGED" / - "FROM" SPACE astring / - "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / - "ON" SPACE date / "RECENT" / "SEEN" / - "SINCE" SPACE date / "SUBJECT" SPACE astring / - "TEXT" SPACE astring / "TO" SPACE astring / - "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / - "UNKEYWORD" SPACE flag_keyword / "UNSEEN" / - ;; Above this line were in [IMAP2] - "DRAFT" / - "HEADER" SPACE header_fld_name SPACE astring / - "LARGER" SPACE number / "NOT" SPACE search_key / - "OR" SPACE search_key SPACE search_key / - "SENTBEFORE" SPACE date / "SENTON" SPACE date / - "SENTSINCE" SPACE date / "SMALLER" SPACE number / - - - -Crispin Standards Track [Page 72] - -RFC 2060 IMAP4rev1 December 1996 - - - "UID" SPACE set / "UNDRAFT" / set / - "(" 1#search_key ")" - -section ::= "[" [section_text / (nz_number *["." nz_number] - ["." (section_text / "MIME")])] "]" - -section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"] - SPACE header_list / "TEXT" - -select ::= "SELECT" SPACE mailbox - -sequence_num ::= nz_number / "*" - ;; * is the largest number in use. For message - ;; sequence numbers, it is the number of messages - ;; in the mailbox. For unique identifiers, it is - ;; the unique identifier of the last message in - ;; the mailbox. - -set ::= sequence_num / (sequence_num ":" sequence_num) / - (set "," set) - ;; Identifies a set of messages. For message - ;; sequence numbers, these are consecutive - ;; numbers from 1 to the number of messages in - ;; the mailbox - ;; Comma delimits individual numbers, colon - ;; delimits between two numbers inclusive. - ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, - ;; 14,15 for a mailbox with 15 messages. - -SPACE ::= - -status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")" - -status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / - "UNSEEN" - -store ::= "STORE" SPACE set SPACE store_att_flags - -store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE - (flag_list / #flag) - -string ::= quoted / literal - -subscribe ::= "SUBSCRIBE" SPACE mailbox - -tag ::= 1* - -text ::= 1*TEXT_CHAR - - - -Crispin Standards Track [Page 73] - -RFC 2060 IMAP4rev1 December 1996 - - -text_mime2 ::= "=?" "?" "?" - "?=" - ;; Syntax defined in [MIME-HDRS] - -TEXT_CHAR ::= - -time ::= 2digit ":" 2digit ":" 2digit - ;; Hours minutes seconds - -uid ::= "UID" SPACE (copy / fetch / search / store) - ;; Unique identifiers used instead of message - ;; sequence numbers - -uniqueid ::= nz_number - ;; Strictly ascending - -unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox - -userid ::= astring - -x_command ::= "X" atom - -zone ::= ("+" / "-") 4digit - ;; Signed four-digit value of hhmm representing - ;; hours and minutes west of Greenwich (that is, - ;; (the amount that the given time differs from - ;; Universal Time). Subtracting the timezone - ;; from the given time will give the UT form. - ;; The Universal Time zone is "+0000". - -10. Author's Note - - This document is a revision or rewrite of earlier documents, and - supercedes the protocol specification in those documents: RFC 1730, - unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064. - -11. Security Considerations - - IMAP4rev1 protocol transactions, including electronic mail data, are - sent in the clear over the network unless privacy protection is - negotiated in the AUTHENTICATE command. - - A server error message for an AUTHENTICATE command which fails due to - invalid credentials SHOULD NOT detail why the credentials are - invalid. - - Use of the LOGIN command sends passwords in the clear. This can be - avoided by using the AUTHENTICATE command instead. - - - -Crispin Standards Track [Page 74] - -RFC 2060 IMAP4rev1 December 1996 - - - A server error message for a failing LOGIN command SHOULD NOT specify - that the user name, as opposed to the password, is invalid. - - Additional security considerations are discussed in the section - discussing the AUTHENTICATE and LOGIN commands. - -12. Author's Address - - Mark R. Crispin - Networks and Distributed Computing - University of Washington - 4545 15th Aveneue NE - Seattle, WA 98105-4527 - - Phone: (206) 543-5762 - - EMail: MRC@CAC.Washington.EDU - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Crispin Standards Track [Page 75] - -RFC 2060 IMAP4rev1 December 1996 - - -Appendices - -A. References - -[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol", -Work in Progress. - -[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, -RFC 1700, USC/Information Sciences Institute, October 1994. - -[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation -Information in Internet Messages: The Content-Disposition Header", -RFC 1806, June 1995. - -[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. -Carnegie-Mellon University, December 1994. - -[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC -2061, University of Washington, November 1996. - -[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected -IMAP4 Clients", Work in Progress. - -[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and -IMAP2bis", RFC 1732, University of Washington, December 1994. - -[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in -IMAP4", RFC 1733, University of Washington, December 1994. - -[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - -Obsolete Syntax", RFC 2062, University of Washington, November 1996. - -[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", -RFC 1176, University of Washington, August 1990. - -[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of -Languages", RFC 1766, March 1995. - -[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC -1864, October 1995. - -[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet -Mail Extensions) Part One: Format of Internet Message Bodies", RFC -2045, November 1996. - -[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose -Internet Mail Extensions) Part Two: Media Types", RFC 2046, -November 1996. - - - -Crispin Standards Track [Page 76] - -RFC 2060 IMAP4rev1 December 1996 - - -[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) -Part Three: Message Header Extensions for Non-ASCII Text", RFC -2047, November 1996. - -[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text -Messages", STD 11, RFC 822, University of Delaware, August 1982. - -[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, -RFC 821, USC/Information Sciences Institute, August 1982. - -[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe -Transformation Format of Unicode", RFC 1642, July 1994. - -B. Changes from RFC 1730 - -1) The STATUS command has been added. - -2) Clarify in the formal syntax that the "#" construct can never -refer to multiple spaces. - -3) Obsolete syntax has been moved to a separate document. - -4) The PARTIAL command has been obsoleted. - -5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and -RFC822.TEXT.PEEK fetch attributes have been obsoleted. - -6) The "<" origin "." size ">" suffix for BODY text attributes has -been added. - -7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part -specifiers have been added. - -8) Support for Content-Disposition and Content-Language has been -added. - -9) The restriction on fetching nested MULTIPART parts has been -removed. - -10) Body part number 0 has been obsoleted. - -11) Server-supported authenticators are now identified by -capabilities. - - - - - - - - -Crispin Standards Track [Page 77] - -RFC 2060 IMAP4rev1 December 1996 - - -12) The capability that identifies this protocol is now called -"IMAP4rev1". A server that provides backwards support for RFC 1730 -SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its -CAPABILITY response. Because RFC-1730 required "IMAP4" to appear as -the first capability, it MUST listed first in the response. - -13) A description of the mailbox name namespace convention has been -added. - -14) A description of the international mailbox name convention has -been added. - -15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT -and UIDVALIDITY. This is a change from the IMAP STATUS -Work in Progress and not from RFC-1730 - -16) Add a clarification that a null mailbox name argument to the LIST -command returns an untagged LIST response with the hierarchy -delimiter and root of the reference argument. - -17) Define terms such as "MUST", "SHOULD", and "MUST NOT". - -18) Add a section which defines message attributes and more -thoroughly details the semantics of message sequence numbers, UIDs, -and flags. - -19) Add a clarification detailing the circumstances when a client may -send multiple commands without waiting for a response, and the -circumstances in which ambiguities may result. - -20) Add a recommendation on server behavior for DELETE and RENAME -when inferior hierarchical names of the given name exist. - -21) Add a clarification that a mailbox name may not be unilaterally -unsubscribed by the server, even if that mailbox name no longer -exists. - -22) Add a clarification that LIST should return its results quickly -without undue delay. - -23) Add a clarification that the date_time argument to APPEND sets -the internal date of the message. - -24) Add a clarification on APPEND behavior when the target mailbox is -the currently selected mailbox. - - - - - - -Crispin Standards Track [Page 78] - -RFC 2060 IMAP4rev1 December 1996 - - -25) Add a clarification that external changes to flags should be -always announced via an untagged FETCH even if the current command is -a STORE with the ".SILENT" suffix. - -26) Add a clarification that COPY appends to the target mailbox. - -27) Add the NEWNAME response code. - -28) Rewrite the description of the untagged BYE response to clarify -its semantics. - -29) Change the reference for the body MD5 to refer to the proper RFC. - -30) Clarify that the formal syntax contains rules which may overlap, -and that in the event of such an overlap the rule which occurs first -takes precedence. - -31) Correct the definition of body_fld_param. - -32) More formal syntax for capability_data. - -33) Clarify that any case variant of "INBOX" must be interpreted as -INBOX. - -34) Clarify that the human-readable text in resp_text should not -begin with "[" or "=". - -35) Change MIME references to Draft Standard documents. - -36) Clarify \Recent semantics. - -37) Additional examples. - -C. Key Word Index - - +FLAGS (store command data item) ............... 45 - +FLAGS.SILENT (store command data item) ........ 46 - -FLAGS (store command data item) ............... 46 - -FLAGS.SILENT (store command data item) ........ 46 - ALERT (response code) ...................................... 50 - ALL (fetch item) ........................................... 41 - ALL (search key) ........................................... 38 - ANSWERED (search key) ...................................... 38 - APPEND (command) ........................................... 34 - AUTHENTICATE (command) ..................................... 20 - BAD (response) ............................................. 52 - BCC (search key) .................................. 38 - BEFORE (search key) ................................. 39 - - - -Crispin Standards Track [Page 79] - -RFC 2060 IMAP4rev1 December 1996 - - - BODY (fetch item) .......................................... 41 - BODY (fetch result) ........................................ 58 - BODY (search key) ................................. 39 - BODY.PEEK[
]<> (fetch item) ............... 44 - BODYSTRUCTURE (fetch item) ................................. 44 - BODYSTRUCTURE (fetch result) ............................... 59 - BODY[
]<> (fetch result) ............. 58 - BODY[
]<> (fetch item) .................... 41 - BYE (response) ............................................. 52 - Body Structure (message attribute) ......................... 11 - CAPABILITY (command) ....................................... 18 - CAPABILITY (response) ...................................... 53 - CC (search key) ................................... 39 - CHECK (command) ............................................ 36 - CLOSE (command) ............................................ 36 - COPY (command) ............................................. 46 - CREATE (command) ........................................... 25 - DELETE (command) ........................................... 26 - DELETED (search key) ....................................... 39 - DRAFT (search key) ......................................... 39 - ENVELOPE (fetch item) ...................................... 44 - ENVELOPE (fetch result) .................................... 62 - EXAMINE (command) .......................................... 24 - EXISTS (response) .......................................... 56 - EXPUNGE (command) .......................................... 37 - EXPUNGE (response) ......................................... 57 - Envelope Structure (message attribute) ..................... 11 - FAST (fetch item) .......................................... 44 - FETCH (command) ............................................ 41 - FETCH (response) ........................................... 58 - FLAGGED (search key) ....................................... 39 - FLAGS (fetch item) ......................................... 44 - FLAGS (fetch result) ....................................... 62 - FLAGS (response) ........................................... 56 - FLAGS (store command data item) ................ 45 - FLAGS.SILENT (store command data item) ......... 45 - FROM (search key) ................................. 39 - FULL (fetch item) .......................................... 44 - Flags (message attribute) .................................. 9 - HEADER (part specifier) .................................... 41 - HEADER (search key) .................. 39 - HEADER.FIELDS (part specifier) ............... 41 - HEADER.FIELDS.NOT (part specifier) ........... 41 - INTERNALDATE (fetch item) .................................. 44 - INTERNALDATE (fetch result) ................................ 62 - Internal Date (message attribute) .......................... 10 - KEYWORD (search key) ................................ 39 - Keyword (type of flag) ..................................... 10 - - - -Crispin Standards Track [Page 80] - -RFC 2060 IMAP4rev1 December 1996 - - - LARGER (search key) .................................... 39 - LIST (command) ............................................. 30 - LIST (response) ............................................ 54 - LOGIN (command) ............................................ 22 - LOGOUT (command) ........................................... 20 - LSUB (command) ............................................. 32 - LSUB (response) ............................................ 55 - MAY (specification requirement term) ....................... 5 - MESSAGES (status item) ..................................... 33 - MIME (part specifier) ...................................... 42 - MUST (specification requirement term) ...................... 4 - MUST NOT (specification requirement term) .................. 4 - Message Sequence Number (message attribute) ................ 9 - NEW (search key) ........................................... 39 - NEWNAME (response code) .................................... 50 - NO (response) .............................................. 51 - NOOP (command) ............................................. 19 - NOT (search key) .............................. 39 - OK (response) .............................................. 51 - OLD (search key) ........................................... 39 - ON (search key) ..................................... 39 - OPTIONAL (specification requirement term) .................. 5 - OR (search key) ................ 39 - PARSE (response code) ...................................... 50 - PERMANENTFLAGS (response code) ............................. 50 - PREAUTH (response) ......................................... 52 - Permanent Flag (class of flag) ............................. 10 - READ-ONLY (response code) .................................. 50 - READ-WRITE (response code) ................................. 50 - RECENT (response) .......................................... 57 - RECENT (search key) ........................................ 39 - RECENT (status item) ....................................... 33 - RENAME (command) ........................................... 27 - REQUIRED (specification requirement term) .................. 4 - RFC822 (fetch item) ........................................ 44 - RFC822 (fetch result) ...................................... 63 - RFC822.HEADER (fetch item) ................................. 44 - RFC822.HEADER (fetch result) ............................... 62 - RFC822.SIZE (fetch item) ................................... 44 - RFC822.SIZE (fetch result) ................................. 62 - RFC822.TEXT (fetch item) ................................... 44 - RFC822.TEXT (fetch result) ................................. 62 - SEARCH (command) ........................................... 37 - SEARCH (response) .......................................... 55 - SEEN (search key) .......................................... 40 - SELECT (command) ........................................... 23 - SENTBEFORE (search key) ............................. 40 - SENTON (search key) ................................. 40 - - - -Crispin Standards Track [Page 81] - -RFC 2060 IMAP4rev1 December 1996 - - - SENTSINCE (search key) .............................. 40 - SHOULD (specification requirement term) .................... 5 - SHOULD NOT (specification requirement term) ................ 5 - SINCE (search key) .................................. 40 - SMALLER (search key) ................................... 40 - STATUS (command) ........................................... 33 - STATUS (response) .......................................... 55 - STORE (command) ............................................ 45 - SUBJECT (search key) .............................. 40 - SUBSCRIBE (command) ........................................ 29 - Session Flag (class of flag) ............................... 10 - System Flag (type of flag) ................................. 9 - TEXT (part specifier) ...................................... 42 - TEXT (search key) ................................. 40 - TO (search key) ................................... 40 - TRYCREATE (response code) .................................. 51 - UID (command) .............................................. 47 - UID (fetch item) ........................................... 44 - UID (fetch result) ......................................... 63 - UID (search key) ............................. 40 - UIDNEXT (status item) ...................................... 33 - UIDVALIDITY (response code) ................................ 51 - UIDVALIDITY (status item) .................................. 34 - UNANSWERED (search key) .................................... 40 - UNDELETED (search key) ..................................... 40 - UNDRAFT (search key) ....................................... 40 - UNFLAGGED (search key) ..................................... 40 - UNKEYWORD (search key) .............................. 40 - UNSEEN (response code) ..................................... 51 - UNSEEN (search key) ........................................ 40 - UNSEEN (status item) ....................................... 34 - UNSUBSCRIBE (command) ...................................... 30 - Unique Identifier (UID) (message attribute) ................ 7 - X (command) .......................................... 48 - [RFC-822] Size (message attribute) ......................... 11 - \Answered (system flag) .................................... 9 - \Deleted (system flag) ..................................... 9 - \Draft (system flag) ....................................... 9 - \Flagged (system flag) ..................................... 9 - \Marked (mailbox name attribute) ........................... 54 - \Noinferiors (mailbox name attribute) ...................... 54 - \Noselect (mailbox name attribute) ......................... 54 - \Recent (system flag) ...................................... 10 - \Seen (system flag) ........................................ 9 - \Unmarked (mailbox name attribute) ......................... 54 - - - - - - -Crispin Standards Track [Page 82] - - - diff --git a/server/src/site/resources/rfclist/imap4/rfc2086.txt b/server/src/site/resources/rfclist/imap4/rfc2086.txt deleted file mode 100644 index 7a58f0b06c1..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2086.txt +++ /dev/null @@ -1,452 +0,0 @@ - - - - - -Network Working Group J. Myers -Request for Comments: 2086 Carnegie Mellon -Category: Standards Track January 1997 - - - IMAP4 ACL extension - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - The ACL extension of the Internet Message Access Protocol [IMAP4] - permits access control lists to be manipulated through the IMAP - protocol. - -Table of Contents - - 1. Abstract............................................... 1 - 2. Conventions Used in this Document...................... 1 - 3. Introduction and Overview.............................. 2 - 4. Commands............................................... 3 - 4.1. SETACL................................................. 3 - 4.2. DELETEACL.............................................. 4 - 4.3. GETACL................................................. 4 - 4.4. LISTRIGHTS............................................. 4 - 4.5. MYRIGHTS............................................... 5 - 5. Responses.............................................. 5 - 5.1. ACL.................................................... 5 - 5.2. LISTRIGHTS............................................. 6 - 5.3. MYRIGHTS............................................... 6 - 6. Formal Syntax.......................................... 6 - 7. References............................................. 7 - 8. Security Considerations................................ 7 - 9. Author's Address....................................... 8 - -2. Conventions Used in this Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - - - - - - -Myers Standards Track [Page 1] - -RFC 2086 ACL extension January 1997 - - -3. Introduction and Overview - - The ACL extension is present in any IMAP4 implementation which - returns "ACL" as one of the supported capabilities to the CAPABILITY - command. - - An access control list is a set of pairs. - - Identifier is a US-ASCII string. The identifier anyone is reserved - to refer to the universal identity (all authentications, including - anonymous). All user name strings accepted by the LOGIN or - AUTHENTICATE commands to authenticate to the IMAP server are reserved - as identifiers for the corresponding user. Identifiers starting with - a dash ("-") are reserved for "negative rights", described below. - All other identifier strings are interpreted in an implementation- - defined manner. - - Rights is a string listing a (possibly empty) set of alphanumeric - characters, each character listing a set of operations which is being - controlled. Letters are reserved for ``standard'' rights, listed - below. The set of standard rights may only be extended by a - standards-track document. Digits are reserved for implementation or - site defined rights. The currently defined standard rights are: - - l - lookup (mailbox is visible to LIST/LSUB commands) - r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, - SEARCH, COPY from mailbox) - s - keep seen/unseen information across sessions (STORE SEEN flag) - w - write (STORE flags other than SEEN and DELETED) - i - insert (perform APPEND, COPY into mailbox) - p - post (send mail to submission address for mailbox, - not enforced by IMAP4 itself) - c - create (CREATE new sub-mailboxes in any implementation-defined - hierarchy) - d - delete (STORE DELETED flag, perform EXPUNGE) - a - administer (perform SETACL) - - An implementation may tie rights together or may force rights to - always or never be granted to particular identifiers. For example, - in an implementation that uses unix mode bits, the rights "wisd" are - tied, the "a" right is always granted to the owner of a mailbox and - is never granted to another user. If rights are tied in an - implementation, the implementation must be conservative in granting - rights in response to SETACL commands--unless all rights in a tied - set are specified, none of that set should be included in the ACL - entry for that identifier. A client may discover the set of rights - which may be granted to a given identifier in the ACL for a given - mailbox by using the LISTRIGHTS command. - - - -Myers Standards Track [Page 2] - -RFC 2086 ACL extension January 1997 - - - It is possible for multiple identifiers in an access control list to - apply to a given user (or other authentication identity). For - example, an ACL may include rights to be granted to the identifier - matching the user, one or more implementation-defined identifiers - matching groups which include the user, and/or the identifier - "anyone". How these rights are combined to determine the user's - access is implementation-defined. An implementation may choose, for - example, to use the union of the rights granted to the applicable - identifiers. An implementation may instead choose, for example, to - only use those rights granted to the most specific identifier present - in the ACL. A client may determine the set of rights granted to the - logged-in user for a given mailbox by using the MYRIGHTS command. - - When an identifier in an ACL starts with a dash ("-"), that indicates - that associated rights are to be removed from the identifier that is - prefixed by the dash. For example, if the identifier "-fred" is - granted the "w" right, that indicates that the "w" right is to be - removed from users matching the identifier "fred". Implementations - need not support having identifiers which start with a dash in ACLs. - -4. Commands - -4.1. SETACL - - Arguments: mailbox name - authentication identifier - access right modification - - Data: no specific data for this command - - Result: OK - setacl completed - NO - setacl failure: can't set acl - BAD - command unknown or arguments invalid - - The SETACL command changes the access control list on the - specified mailbox so that the specified identifier is granted - permissions as specified in the third argument. - - The third argument is a string containing an optional plus ("+") - or minus ("-") prefix, followed by zero or more rights characters. - If the string starts with a plus, the following rights are added - to any existing rights for the identifier. If the string starts - with a minus, the following rights are removed from any existing - rights for the identifier. If the string does not start with a - plus or minus, the rights replace any existing rights for the - identifier. - - - - - -Myers Standards Track [Page 3] - -RFC 2086 ACL extension January 1997 - - -4.2. DELETEACL - - Arguments: mailbox name - authentication identifier - - Data: no specific data for this command - - Result: OK - deleteacl completed - NO - deleteacl failure: can't delete acl - BAD - command unknown or arguments invalid - - The DELETEACL command removes any pair for the - specified identifier from the access control list for the specified - mailbox. - -4.3. GETACL - - Arguments: mailbox name - - Data: untagged responses: ACL - - Result: OK - getacl completed - NO - getacl failure: can't get acl - BAD - command unknown or arguments invalid - - The GETACL command returns the access control list for mailbox in - an untagged ACL reply. - - Example: C: A002 GETACL INBOX - S: * ACL INBOX Fred rwipslda - S: A002 OK Getacl complete - -4.4. LISTRIGHTS - - Arguments: mailbox name - authentication identifier - - Data: untagged responses: LISTRIGHTS - - Result: OK - listrights completed - NO - listrights failure: can't get rights list - BAD - command unknown or arguments invalid - - The LISTRIGHTS command takes a mailbox name and an identifier and - returns information about what rights may be granted to the identifier - in the ACL for the mailbox. - - - - - -Myers Standards Track [Page 4] - -RFC 2086 ACL extension January 1997 - - - Example: C: a001 LISTRIGHTS ~/Mail/saved smith - S: * LISTRIGHTS ~/Mail/saved smith la r swicd - S: a001 OK Listrights completed - - - C: a005 LISTRIGHTS archive.imap anyone - S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a - 0 1 2 3 4 5 6 7 8 9 - -4.5. MYRIGHTS - - Arguments: mailbox name - - Data: untagged responses: MYRIGHTS - - Result: OK - myrights completed - NO - myrights failure: can't get rights - BAD - command unknown or arguments invalid - - The MYRIGHTS command returns the set of rights that the user has - to mailbox in an untagged MYRIGHTS reply. - - Example: C: A003 MYRIGHTS INBOX - S: * MYRIGHTS INBOX rwipslda - S: A003 OK Myrights complete - -5. Responses - -5.1. ACL - - Data: mailbox name - zero or more identifier rights pairs - - The ACL response occurs as a result of a GETACL command. The first - string is the mailbox name for which this ACL applies. This is - followed by zero or more pairs of strings, each pair contains the - identifier for which the entry applies followed by the set of - rights that the identifier has. - - - - - - - - - - - - - -Myers Standards Track [Page 5] - -RFC 2086 ACL extension January 1997 - - -5.2. LISTRIGHTS - - Data: mailbox name - identifier - required rights - list of optional rights - - The LISTRIGHTS response occurs as a result of a LISTRIGHTS - command. The first two strings are the mailbox name and identifier - for which this rights list applies. Following the identifier is a - string containing the (possibly empty) set of rights the - identifier will always be granted in the mailbox. - - Following this are zero or more strings each containing a set of - rights the identifier may be granted in the mailbox. Rights - mentioned in the same string are tied together--either all must be - granted to the identifier in the mailbox or none may be granted. - - The same right may not be listed more than once in the LISTRIGHTS - command. - -5.3. MYRIGHTS - - Data: mailbox name - rights - - The MYRIGHTS response occurs as a result of a MYRIGHTS command. - The first string is the mailbox name for which these rights apply. - The second string is the set of rights that the client has. - -6. 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. - - - - - - - - - - -Myers Standards Track [Page 6] - -RFC 2086 ACL extension January 1997 - - - acl_data ::= "ACL" SPACE mailbox *(SPACE identifier SPACE - rights) - - deleteacl ::= "DELETEACL" SPACE mailbox SPACE identifier - - getacl ::= "GETACL" SPACE mailbox - - identifier ::= astring - - listrights ::= "LISTRIGHTS" SPACE mailbox SPACE identifier - - listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier - SPACE rights *(SPACE rights) - - mod_rights ::= astring - ;; +rights to add, -rights to remove - ;; rights to replace - - myrights ::= "MYRIGHTS" SPACE mailbox - - myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE rights - - rights ::= astring - - setacl ::= "SETACL" SPACE mailbox SPACE identifier - SPACE mod_rights - -7. References - - [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", - RFC 1730, University of Washington, December 1994. - - [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822. - -8. Security Considerations - - An implementation must make sure the ACL commands themselves do not - give information about mailboxes with appropriately restricted ACL's. - For example, a GETACL command on a mailbox for which the user has - insufficient rights should not admit the mailbox exists, much less - return the mailbox's ACL. - - - - - - - - - -Myers Standards Track [Page 7] - -RFC 2086 ACL extension January 1997 - - -9. Author's Address - - John G. Myers - Carnegie-Mellon University - 5000 Forbes Ave. - Pittsburgh PA, 15213-3890 - - Email: jgm+@cmu.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers Standards Track [Page 8] - - - diff --git a/server/src/site/resources/rfclist/imap4/rfc2087.txt b/server/src/site/resources/rfclist/imap4/rfc2087.txt deleted file mode 100644 index 979c8ecec87..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2087.txt +++ /dev/null @@ -1,284 +0,0 @@ - - - - - -Network Working Group J. Myers -Request for Comments: 2087 Carnegie Mellon -Category: Standards Track January 1997 - - - IMAP4 QUOTA extension - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - The QUOTA extension of the Internet Message Access Protocol [IMAP4] - permits administrative limits on resource usage (quotas) to be - manipulated through the IMAP protocol. - -Table of Contents - - 1. Abstract........................................... 1 - 2. Conventions Used in this Document.................. 1 - 3. Introduction and Overview.......................... 2 - 4. Commands........................................... 2 - 4.1. SETQUOTA Command................................... 2 - 4.2. GETQUOTA Command................................... 2 - 4.3. GETQUOTAROOT Command............................... 3 - 5. Responses.......................................... 3 - 5.1. QUOTA Response..................................... 3 - 5.2. QUOTAROOT Response................................. 4 - 6. Formal syntax...................................... 4 - 7. References......................................... 5 - 8. Security Considerations............................ 5 - 9. Author's Address................................... 5 - - -2. Conventions Used in this Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - - - - - - - - -Myers Standards Track [Page 1] - -RFC 2087 QUOTA January 1997 - - -3. Introduction and Overview - - The QUOTA extension is present in any IMAP4 implementation which - returns "QUOTA" as one of the supported capabilities to the - CAPABILITY command. - - An IMAP4 server which supports the QUOTA capability may support - limits on any number of resources. Each resource has an atom name - and an implementation-defined interpretation which evaluates to an - integer. Examples of such resources are: - - Name Interpretation - - STORAGE Sum of messages' RFC822.SIZE, in units of 1024 octets - MESSAGE Number of messages - - - Each mailbox has zero or more implementation-defined named "quota - roots". Each quota root has zero or more resource limits. All - mailboxes that share the same named quota root share the resource - limits of the quota root. - - Quota root names do not necessarily have to match the names of - existing mailboxes. - -4. Commands - -4.1. SETQUOTA Command - - Arguments: quota root - list of resource limits - - Data: untagged responses: QUOTA - - Result: OK - setquota completed - NO - setquota error: can't set that data - BAD - command unknown or arguments invalid - - The SETQUOTA command takes the name of a mailbox quota root and a - list of resource limits. The resource limits for the named quota root - are changed to be the specified limits. Any previous resource limits - for the named quota root are discarded. - - If the named quota root did not previously exist, an implementation - may optionally create it and change the quota roots for any number of - existing mailboxes in an implementation-defined manner. - - - - - -Myers Standards Track [Page 2] - -RFC 2087 QUOTA January 1997 - - - Example: C: A001 SETQUOTA "" (STORAGE 512) - S: * QUOTA "" (STORAGE 10 512) - S: A001 OK Setquota completed - -4.2. GETQUOTA Command - - Arguments: quota root - - Data: untagged responses: QUOTA - - Result: OK - getquota completed - NO - getquota error: no such quota root, permission - denied - BAD - command unknown or arguments invalid - - The GETQUOTA command takes the name of a quota root and returns the - quota root's resource usage and limits in an untagged QUOTA response. - - Example: C: A003 GETQUOTA "" - S: * QUOTA "" (STORAGE 10 512) - S: A003 OK Getquota completed - -4.3. GETQUOTAROOT Command - - Arguments: mailbox name - - Data: untagged responses: QUOTAROOT, QUOTA - - Result: OK - getquota completed - NO - getquota error: no such mailbox, permission denied - BAD - command unknown or arguments invalid - - The GETQUOTAROOT command takes the name of a mailbox and returns the - list of quota roots for the mailbox in an untagged QUOTAROOT - response. For each listed quota root, it also returns the quota - root's resource usage and limits in an untagged QUOTA response. - - Example: C: A003 GETQUOTAROOT INBOX - S: * QUOTAROOT INBOX "" - S: * QUOTA "" (STORAGE 10 512) - S: A003 OK Getquota completed - - - - - - - - - - -Myers Standards Track [Page 3] - -RFC 2087 QUOTA January 1997 - - -5. Responses - -5.1. QUOTA Response - - Data: quota root name - list of resource names, usages, and limits - - This response occurs as a result of a GETQUOTA or GETQUOTAROOT - command. The first string is the name of the quota root for which - this quota applies. - - The name is followed by a S-expression format list of the resource - usage and limits of the quota root. The list contains zero or - more triplets. Each triplet conatins a resource name, the current - usage of the resource, and the resource limit. - - Resources not named in the list are not limited in the quota root. - Thus, an empty list means there are no administrative resource - limits in the quota root. - - Example: S: * QUOTA "" (STORAGE 10 512) - -5.2. QUOTAROOT Response - - Data: mailbox name - zero or more quota root names - - This response occurs as a result of a GETQUOTAROOT command. The - first string is the mailbox and the remaining strings are the - names of the quota roots for the mailbox. - - Example: S: * QUOTAROOT INBOX "" - S: * QUOTAROOT comp.mail.mime - -6. Formal syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) notation as specified in RFC 822 with one exception; the - delimiter used with the "#" construct is a single space (SP) and not - one or more commas. - - Except as noted otherwise, all alphabetic characters are case- - insensitive. The use of upper or lower case characters to define - token strings is for editorial clarity only. Implementations MUST - accept these strings in a case-insensitive fashion. - - - - - - -Myers Standards Track [Page 4] - -RFC 2087 QUOTA January 1997 - - - getquota ::= "GETQUOTA" SP astring - - getquotaroot ::= "GETQUOTAROOT" SP astring - - quota_list ::= "(" #quota_resource ")" - - quota_resource ::= atom SP number SP number - - quota_response ::= "QUOTA" SP astring SP quota_list - - quotaroot_response - ::= "QUOTAROOT" SP astring *(SP astring) - - setquota ::= "SETQUOTA" SP astring SP setquota_list - - setquota_list ::= "(" 0#setquota_resource ")" - - setquota_resource ::= atom SP number - -7. References - - [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", - RFC 1730, University of Washington, December 1994. - - [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet - Text Messages", STD 11, RFC 822. - -8. Security Considerations - - Implementors should be careful to make sure the implementation of - these commands does not violate the site's security policy. The - resource usage of other users is likely to be considered confidential - information and should not be divulged to unauthorized persons. - -9. Author's Address - - John G. Myers - Carnegie-Mellon University - 5000 Forbes Ave. - Pittsburgh PA, 15213-3890 - - EMail: jgm+@cmu.edu - - - - - - - - - -Myers Standards Track [Page 5] - - - diff --git a/server/src/site/resources/rfclist/imap4/rfc2088.txt b/server/src/site/resources/rfclist/imap4/rfc2088.txt deleted file mode 100644 index 2cd02f561fe..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2088.txt +++ /dev/null @@ -1,116 +0,0 @@ - - - - - -Network Working Group J. Myers -Request for Comments: 2088 Carnegie Mellon -Cateogry: Standards Track January 1997 - - - IMAP4 non-synchronizing literals - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - The Internet Message Access Protocol [IMAP4] contains the "literal" - syntactic construct for communicating strings. When sending a - literal from client to server, IMAP4 requires the client to wait for - the server to send a command continuation request between sending the - octet count and the string data. This document specifies an - alternate form of literal which does not require this network round - trip. - -2. Conventions Used in this Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - -3. Specification - - The non-synchronizing literal is added an alternate form of literal, - and may appear in communication from client to server instead of the - IMAP4 form of literal. The IMAP4 form of literal, used in - communication from client to server, is referred to as a - synchronizing literal. - - Non-synchronizing literals may be used with any IMAP4 server - implementation which returns "LITERAL+" as one of the supported - capabilities to the CAPABILITY command. If the server does not - advertise the LITERAL+ capability, the client must use synchronizing - literals instead. - - The non-synchronizing literal is distinguished from the original - synchronizing literal by having a plus ('+') between the octet count - and the closing brace ('}'). The server does not generate a command - continuation request in response to a non-synchronizing literal, and - - - -Myers Standards Track [Page 1] - -RFC 2088 LITERAL January 1997 - - - clients are not required to wait before sending the octets of a non- - synchronizing literal. - - The protocol receiver of an IMAP4 server must check the end of every - received line for an open brace ('{') followed by an octet count, a - plus ('+'), and a close brace ('}') immediately preceeding the CRLF. - If it finds this sequence, it is the octet count of a non- - synchronizing literal and the server MUST treat the specified number - of following octets and the following line as part of the same - command. A server MAY still process commands and reject errors on a - line-by-line basis, as long as it checks for non-synchronizing - literals at the end of each line. - - Example: C: A001 LOGIN {11+} - C: FRED FOOBAR {7+} - C: fat man - S: A001 OK LOGIN completed - -4. Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. - Non-terminals referenced but not defined below are as defined by - [IMAP4]. - - literal ::= "{" number ["+"] "}" CRLF *CHAR8 - ;; Number represents the number of CHAR8 octets - -6. References - - [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", - draft-crispin-imap-base-XX.txt, University of Washington, April 1996. - - [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822. - -7. Security Considerations - - There are no known security issues with this extension. - -8. Author's Address - - John G. Myers - Carnegie-Mellon University - 5000 Forbes Ave. - Pittsburgh PA, 15213-3890 - - Email: jgm+@cmu.edu - - - -Myers Standards Track [Page 2] - - - diff --git a/server/src/site/resources/rfclist/imap4/rfc2177.txt b/server/src/site/resources/rfclist/imap4/rfc2177.txt deleted file mode 100644 index 80393f6f4e6..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2177.txt +++ /dev/null @@ -1,228 +0,0 @@ - - - - - -Network Working Group B. Leiba -Request for Comments: 2177 IBM T.J. Watson Research Center -Category: Standards Track June 1997 - - - IMAP4 IDLE command - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - The Internet Message Access Protocol [IMAP4] requires a client to - poll the server for changes to the selected mailbox (new mail, - deletions). It's often more desirable to have the server transmit - updates to the client in real time. This allows a user to see new - mail immediately. It also helps some real-time applications based on - IMAP, which might otherwise need to poll extremely often (such as - every few seconds). (While the spec actually does allow a server to - push EXISTS responses aysynchronously, a client can't expect this - behaviour and must poll.) - - This document specifies the syntax of an IDLE command, which will - allow a client to tell the server that it's ready to accept such - real-time updates. - -2. Conventions Used in this Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" - in this document are to be interpreted as described in RFC 2060 - [IMAP4]. - -3. Specification - - IDLE Command - - Arguments: none - - Responses: continuation data will be requested; the client sends - the continuation data "DONE" to end the command - - - -Leiba Standards Track [Page 1] - -RFC 2177 IMAP4 IDLE command June 1997 - - - - Result: OK - IDLE completed after client sent "DONE" - NO - failure: the server will not allow the IDLE - command at this time - BAD - command unknown or arguments invalid - - The IDLE command may be used with any IMAP4 server implementation - that returns "IDLE" as one of the supported capabilities to the - CAPABILITY command. If the server does not advertise the IDLE - capability, the client MUST NOT use the IDLE command and must poll - for mailbox updates. In particular, the client MUST continue to be - able to accept unsolicited untagged responses to ANY command, as - specified in the base IMAP specification. - - The IDLE command is sent from the client to the server when the - client is ready to accept unsolicited mailbox update messages. The - server requests a response to the IDLE command using the continuation - ("+") response. The IDLE command remains active until the client - responds to the continuation, and as long as an IDLE command is - active, the server is now free to send untagged EXISTS, EXPUNGE, and - other messages at any time. - - The IDLE command is terminated by the receipt of a "DONE" - continuation from the client; such response satisfies the server's - continuation request. At that point, the server MAY send any - remaining queued untagged responses and then MUST immediately send - the tagged response to the IDLE command and prepare to process other - commands. As in the base specification, the processing of any new - command may cause the sending of unsolicited untagged responses, - subject to the ambiguity limitations. The client MUST NOT send a - command while the server is waiting for the DONE, since the server - will not be able to distinguish a command from a continuation. - - The server MAY consider a client inactive if it has an IDLE command - running, and if such a server has an inactivity timeout it MAY log - the client off implicitly at the end of its timeout period. Because - of that, clients using IDLE are advised to terminate the IDLE and - re-issue it at least every 29 minutes to avoid being logged off. - This still allows a client to receive immediate mailbox updates even - though it need only "poll" at half hour intervals. - - - - - - - - - - - -Leiba Standards Track [Page 2] - -RFC 2177 IMAP4 IDLE command June 1997 - - - Example: C: A001 SELECT INBOX - S: * FLAGS (Deleted Seen) - S: * 3 EXISTS - S: * 0 RECENT - S: * OK [UIDVALIDITY 1] - S: A001 OK SELECT completed - C: A002 IDLE - S: + idling - ...time passes; new mail arrives... - S: * 4 EXISTS - C: DONE - S: A002 OK IDLE terminated - ...another client expunges message 2 now... - C: A003 FETCH 4 ALL - S: * 4 FETCH (...) - S: A003 OK FETCH completed - C: A004 IDLE - S: * 2 EXPUNGE - S: * 3 EXISTS - S: + idling - ...time passes; another client expunges message 3... - S: * 3 EXPUNGE - S: * 2 EXISTS - ...time passes; new mail arrives... - S: * 3 EXISTS - C: DONE - S: A004 OK IDLE terminated - C: A005 FETCH 3 ALL - S: * 3 FETCH (...) - S: A005 OK FETCH completed - C: A006 IDLE - -4. Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. - Non-terminals referenced but not defined below are as defined by - [IMAP4]. - - command_auth ::= append / create / delete / examine / list / lsub / - rename / select / status / subscribe / unsubscribe - / idle - ;; Valid only in Authenticated or Selected state - - idle ::= "IDLE" CRLF "DONE" - - - - - - -Leiba Standards Track [Page 3] - -RFC 2177 IMAP4 IDLE command June 1997 - - -5. References - - [IMAP4] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, December 1996. - -6. Security Considerations - - There are no known security issues with this extension. - -7. Author's Address - - Barry Leiba - IBM T.J. Watson Research Center - 30 Saw Mill River Road - Hawthorne, NY 10532 - - Email: leiba@watson.ibm.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Leiba Standards Track [Page 4] - - - diff --git a/server/src/site/resources/rfclist/imap4/rfc2180.txt b/server/src/site/resources/rfclist/imap4/rfc2180.txt deleted file mode 100644 index 57607002fa3..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2180.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -Network Working Group M. Gahrns -Request for Comments: 2180 Microsoft -Category: Informational July 1997 - - - IMAP4 Multi-Accessed Mailbox Practice - -Status of this Memo - - This memo provides information for the Internet community. This memo - does not specify an Internet standard of any kind. Distribution of - this memo is unlimited. - -1. Abstract - - IMAP4[RFC-2060] is rich client/server protocol that allows a client - to access and manipulate electronic mail messages on a server. - Within the protocol framework, it is possible to have differing - results for particular client/server interactions. If a protocol does - not allow for this, it is often unduly restrictive. - - For example, when multiple clients are accessing a mailbox and one - attempts to delete the mailbox, an IMAP4 server may choose to - implement a solution based upon server architectural constraints or - individual preference. - - With this flexibility comes greater client responsibility. It is not - sufficient for a client to be written based upon the behavior of a - particular IMAP server. Rather the client must be based upon the - behavior allowed by the protocol. - - By documenting common IMAP4 server practice for the case of - simultaneous client access to a mailbox, we hope to ensure the widest - amount of inter-operation between IMAP4 clients and servers. - - The behavior described in this document reflects the practice of some - existing servers or behavior that the consensus of the IMAP mailing - list has deemed to be reasonable. The behavior described within this - document is believed to be [RFC-2060] compliant. However, this - document is not meant to define IMAP4 compliance, nor is it an - exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be - consulted to determine IMAP4 compliance, especially for server - behavior not described within this document. - - - - - - - - -Gahrns Informational [Page 1] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - -2. Conventions used in this document - - In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different - clients (client #1, client #2 and client #3) that are connected to a - server. "S1:", "S2:" and "S3:" indicated lines sent by the server to - client #1, client #2 and client #3 respectively. - - A shared mailbox, is a mailbox that can be used by multiple users. - - A multi-accessed mailbox, is a mailbox that has multiple clients - simultaneously accessing it. - - A client is said to have accessed a mailbox after a successful SELECT - or EXAMINE command. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC-2119]. - - -3. Deletion/Renaming of a multi-accessed mailbox - - If an external agent or multiple clients are accessing a mailbox, - care must be taken when handling the deletion or renaming of the - mailbox. Following are some strategies an IMAP server may choose to - use when dealing with this situation. - - -3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed - mailbox - - In some cases, this behavior may not be practical. For example, if a - large number of clients are accessing a shared mailbox, the window in - which no clients have the mailbox accessed may be small or non- - existent, effectively rendering the mailbox undeletable or - unrenamable. - - Example: - - - - C1: A001 DELETE FOO - S1: A001 NO Mailbox FOO is in use by another user. - - - - - - - -Gahrns Informational [Page 2] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - -3.2. The server MAY allow the DELETE command of a multi-accessed - mailbox, but keep the information in the mailbox available for - those clients that currently have access to the mailbox. - - When all clients have finished accessing the mailbox, it is - permanently removed. For clients that do not already have access to - the mailbox, the 'ghosted' mailbox would not be available. For - example, it would not be returned to these clients in a subsequent - LIST or LSUB command and would not be a valid mailbox argument to any - other IMAP command until the reference count of clients accessing the - mailbox reached 0. - - In some cases, this behavior may not be desirable. For example if - someone created a mailbox with offensive or sensitive information, - one might prefer to have the mailbox deleted and all access to the - information contained within removed immediately, rather than - continuing to allow access until the client closes the mailbox. - - Furthermore, this behavior, may prevent 'recycling' of the same - mailbox name until all clients have finished accessing the original - mailbox. - - Example: - - - - C1: A001 DELETE FOO - S1: A001 OK Mailbox FOO is deleted. - - - - C2: B001 STORE 1 +FLAGS (\Seen) - S2: * 1 FETCH FLAGS (\Seen) - S2: B001 OK STORE completed - - - - C3: C001 STATUS FOO (MESSAGES) - S3: C001 NO Mailbox does not exist - - - - C3: C002 CREATE FOO - S3: C002 NO Mailbox FOO is still in use. Try again later. - - - - -Gahrns Informational [Page 3] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - - - - C2: B002 CLOSE - S2: B002 OK CLOSE Completed - - - - C3: C003 CREATE FOO - S3: C003 OK CREATE Completed - - -3.3. The server MAY allow the DELETE/RENAME of a multi-accessed - mailbox, but disconnect all other clients who have the mailbox - accessed by sending a untagged BYE response. - - A server may often choose to disconnect clients in the DELETE case, - but may choose to implement a "friendlier" method for the RENAME - case. - - Example: - - - - C1: A002 DELETE FOO - S1: A002 OK DELETE completed. - - - S2: * BYE Mailbox FOO has been deleted. - - -3.4. The server MAY allow the RENAME of a multi-accessed mailbox by - simply changing the name attribute on the mailbox. - - Other clients that have access to the mailbox can continue issuing - commands such as FETCH that do not reference the mailbox name. - Clients would discover the renaming the next time they referred to - the old mailbox name. Some servers MAY choose to include the - [NEWNAME] response code in their tagged NO response to a command that - contained the old mailbox name, as a hint to the client that the - operation can succeed if the command is issued with the new mailbox - name. - - - - - - - -Gahrns Informational [Page 4] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - - Example: - - - - C1: A001 RENAME FOO BAR - S1: A001 OK RENAME completed. - - - - C2: B001 FETCH 2:4 (FLAGS) - S2: * 2 FETCH . . . - S2: * 3 FETCH . . . - S2: * 4 FETCH . . . - S2: B001 OK FETCH completed - - - - C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994 - 21:52:25 0800 (PST) C2: . . . S2: B002 NO [NEWNAME FOO - BAR] Mailbox has been renamed - - -4. Expunging of messages on a multi-accessed mailbox - - If an external agent or multiple clients are accessing a mailbox, - care must be taken when handling the EXPUNGE of messages. Other - clients accessing the mailbox may be in the midst of issuing a - command that depends upon message sequence numbers. Because an - EXPUNGE response can not be sent while responding to a FETCH, STORE - or SEARCH command, it is not possible to immediately notify the - client of the EXPUNGE. This can result in ambiguity if the client - issues a FETCH, STORE or SEARCH operation on a message that has been - EXPUNGED. - - -4.1. Fetching of expunged messages - - Following are some strategies an IMAP server may choose to use when - dealing with a FETCH command on expunged messages. - - - - - - - - - -Gahrns Informational [Page 5] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - - Consider the following scenario: - - - Client #1 and Client #2 have mailbox FOO selected. - - There are 7 messages in the mailbox. - - Messages 4:7 are marked for deletion. - - Client #1 issues an EXPUNGE, to expunge messages 4:7 - - -4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but - keep the messages available to satisfy subsequent FETCH commands - until it is able to send an EXPUNGE response to each client. - - In some cases, the behavior of keeping "ghosted" messages may not be - desirable. For example if a message contained offensive or sensitive - information, one might prefer to instantaneously remove all access to - the information, regardless of whether another client is in the midst - of accessing it. - - Example: (Building upon the scenario outlined in 4.1.) - - - - C2: B001 FETCH 4:7 RFC822 - S2: * 4 FETCH RFC822 . . . (RFC822 info returned) - S2: * 5 FETCH RFC822 . . . (RFC822 info returned) - S2: * 6 FETCH RFC822 . . . (RFC822 info returned) - S2: * 7 FETCH RFC822 . . . (RFC822 info returned) - S2: B001 OK FETCH Completed - - - - C2: B002 NOOP - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 3 EXISTS - S2: B002 OK NOOP Complete - - - - C2: B003 FETCH 4:7 RFC822 - S2: B003 NO Messages 4:7 are no longer available. - - - - - - -Gahrns Informational [Page 6] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - -4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox, - and on subsequent FETCH commands return FETCH responses only for - non-expunged messages and a tagged NO. - - After receiving a tagged NO FETCH response, the client SHOULD issue a - NOOP command so that it will be informed of any pending EXPUNGE - responses. The client may then either reissue the failed FETCH - command, or by examining the EXPUNGE response from the NOOP and the - FETCH response from the FETCH, determine that the FETCH failed - because of pending expunges. - - Example: (Building upon the scenario outlined in 4.1.) - - - - C2: B001 FETCH 3:5 ENVELOPE - S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) - S2: B001 NO Some of the requested messages no longer exist - - - - C2: B002 NOOP - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 3 EXISTS - S2: B002 OK NOOP Completed. - - - - - - - - - - - - - - - - - - -Gahrns Informational [Page 7] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - -4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and - on subsequent FETCH commands return the usual FETCH responses for - non-expunged messages, "NIL FETCH Responses" for expunged - messages, and a tagged OK response. - - If all of the messages in the subsequent FETCH command have been - expunged, the server SHOULD return only a tagged NO. In this case, - the client SHOULD issue a NOOP command so that it will be informed of - any pending EXPUNGE responses. The client may then either reissue - the failed FETCH command, or by examining the EXPUNGE response from - the NOOP, determine that the FETCH failed because of pending - expunges. - - "NIL FETCH responses" are a representation of empty data as - appropriate for the FETCH argument specified. - - Example: - - * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL)) - * 1 FETCH (FLAGS ()) - * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000") - * 1 FETCH (RFC822 "") - * 1 FETCH (RFC822.HEADER "") - * 1 FETCH (RFC822.TEXT "") - * 1 FETCH (RFC822.SIZE 0) - * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) - * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) - * 1 FETCH (BODY[
] "") - * 1 FETCH (BODY[
] "") - - In some cases, a client may not be able to distinguish between "NIL - FETCH responses" received because a message was expunged and those - received because the data actually was NIL. For example, a * 5 - FETCH (FLAGS ()) response could be received if no flags were set on - message 5, or because message 5 was expunged. In a case of potential - ambiguity, the client SHOULD issue a command such as NOOP to force - the sending of the EXPUNGE responses to resolve any ambiguity. - - Example: (Building upon the scenario outlined in 4.1.) - - - - - - - - - - -Gahrns Informational [Page 8] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - - C2: B002 FETCH 3:5 ENVELOPE - S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) - S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL - NIL NIL) - S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL - NIL NIL) - S2: B002 OK FETCH Completed - - - - C2: B002 FETCH 4:7 ENVELOPE - S2: B002 NO Messages 4:7 have been expunged. - - -4.1.4 To avoid the situation altogether, the server MAY fail the - EXPUNGE of a multi-accessed mailbox - - In some cases, this behavior may not be practical. For example, if a - large number of clients are accessing a shared mailbox, the window in - which no clients have the mailbox accessed may be small or non- - existent, effectively rendering the message unexpungeable. - - -4.2. Storing of expunged messages - - Following are some strategies an IMAP server may choose to use when - dealing with a STORE command on expunged messages. - - -4.2.1 If the ".SILENT" suffix is used, and the STORE completed - successfully for all the non-expunged messages, the server SHOULD - return a tagged OK. - - Example: (Building upon the scenario outlined in 4.1.) - - - - C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN) - S2: B001 OK - - - - - - - - - -Gahrns Informational [Page 9] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - -4.2.2. If the ".SILENT" suffix is not used, and only expunged messages - are referenced, the server SHOULD return only a tagged NO. - - Example: (Building upon the scenario outlined in 4.1.) - - - - C2: B001 STORE 5:7 +FLAGS (\SEEN) - S2: B001 NO Messages have been expunged - - -4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged - and non-expunged messages are referenced, the server MAY set the - flags and return a FETCH response for the non-expunged messages - along with a tagged NO. - - After receiving a tagged NO STORE response, the client SHOULD issue a - NOOP command so that it will be informed of any pending EXPUNGE - responses. The client may then either reissue the failed STORE - command, or by examining the EXPUNGE responses from the NOOP and - FETCH responses from the STORE, determine that the STORE failed - because of pending expunges. - - Example: (Building upon the scenario outlined in 4.1.) - - - - C2: B001 STORE 1:7 +FLAGS (\SEEN) - S2: * FETCH 1 FLAGS (\SEEN) - S2: * FETCH 2 FLAGS (\SEEN) - S2: * FETCH 3 FLAGS (\SEEN) - S2: B001 NO Some of the messages no longer exist. - - C2: B002 NOOP - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 3 EXISTS - S2: B002 OK NOOP Completed. - - - - - - - - -Gahrns Informational [Page 10] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - -4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged - and non-expunged messages are referenced, the server MAY return - an untagged NO and not set any flags. - - After receiving a tagged NO STORE response, the client SHOULD issue a - NOOP command so that it will be informed of any pending EXPUNGE - responses. The client would then re-issue the STORE command after - updating its message list per any EXPUNGE response. - - If a large number of clients are accessing a shared mailbox, the - window in which there are no pending expunges may be small or non- - existent, effectively disallowing a client from setting the flags on - all messages at once. - - Example: (Building upon the scenario outlined in 4.1.) - - - - C2: B001 STORE 1:7 +FLAGS (\SEEN) - S2: B001 NO Some of the messages no longer exist. - - - - C2: B002 NOOP - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 4 EXPUNGE - S2: * 3 EXISTS - S2: B002 OK NOOP Completed. - - - - C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS - (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS - (\SEEN) S2: B003 OK STORE Completed - - -4.3. Searching of expunged messages - - A server MAY simply not return a search response for messages that - have been expunged and it has not been able to inform the client - about. If a client was expecting a particular message to be returned - in a search result, and it was not, the client SHOULD issue a NOOP - command to see if the message was expunged by another client. - - - - -Gahrns Informational [Page 11] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - -4.4 Copying of expunged messages - - COPY is the only IMAP4 sequence number command that is safe to allow - an EXPUNGE response on. This is because a client is not permitted to - cascade several COPY commands together. A client is required to wait - and confirm that the copy worked before issuing another one. - -4.4.1 The server MAY disallow the COPY of messages in a multi-access - mailbox that contains expunged messages. - - Pending EXPUNGE response(s) MUST be returned to the COPY command. - - Example: - - C: A001 COPY 2,4,6,8 FRED - S: * 4 EXPUNGE - S: A001 NO COPY rejected, because some of the requested - messages were expunged - - Note: Non of the above messages are copied because if a COPY command - is unsuccessful, the server MUST restore the destination mailbox to - its state before the COPY attempt. - - -4.4.2 The server MAY allow the COPY of messages in a multi-access - mailbox that contains expunged messages. - - Pending EXPUNGE response(s) MUST be returned to the COPY command. - Messages that are copied are messages corresponding to sequence - numbers before any EXPUNGE response. - - Example: - - C: A001 COPY 2,4,6,8 FRED - S: * 3 EXPUNGE - S: A001 OK COPY completed - - In the above example, the messages that are copied to FRED are - messages 2,4,6,8 at the start of the COPY command. These are - equivalent to messages 2,3,5,7 at the end of the COPY command. The - EXPUNGE response can't take place until after the messages from the - COPY command are identified (because of the "no expunge while no - commands in progress" rule). - - - - - - - - -Gahrns Informational [Page 12] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - - Example: - - C: A001 COPY 2,4,6,8 FRED - S: * 4 EXPUNGE - S: A001 OK COPY completed - - In the above example, message 4 was copied before it was expunged, - and MUST appear in the destination mailbox FRED. - - -5. Security Considerations - - This document describes behavior of servers that use the IMAP4 - protocol, and as such, has the same security considerations as - described in [RFC-2060]. - - In particular, some described server behavior does not allow for the - immediate deletion of information when a mailbox is accessed by - multiple clients. This may be a consideration when dealing with - sensitive information where immediate deletion would be preferred. - - -6. References - - [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, University of Washington, December 1996. - - [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, Harvard University, March 1997. - - -7. Acknowledgments - - This document is the result of discussions on the IMAP4 mailing list - and is meant to reflect consensus of this group. In particular, - Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole, - Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry - Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De - Winter were active participants in this discussion or made - suggestions to this document. - - - - - - - - - - - -Gahrns Informational [Page 13] - -RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 - - -8. Author's Address - - Mike Gahrns - Microsoft - One Microsoft Way - Redmond, WA, 98072 - - Phone: (206) 936-9833 - EMail: mikega@microsoft.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gahrns Informational [Page 14] - diff --git a/server/src/site/resources/rfclist/imap4/rfc2192.txt b/server/src/site/resources/rfclist/imap4/rfc2192.txt deleted file mode 100644 index a8ac12d04a4..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2192.txt +++ /dev/null @@ -1,900 +0,0 @@ - - - - - -Network Working Group C. Newman -Request for Comments: 2192 Innosoft -Category: Standards Track September 1997 - - - IMAP URL Scheme - - -Status of this memo - - This document specifies an Internet standards track protocol for - the Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is - unlimited. - - -Abstract - - IMAP [IMAP4] is a rich protocol for accessing remote message - stores. It provides an ideal mechanism for accessing public - mailing list archives as well as private and shared message stores. - This document defines a URL scheme for referencing objects on an - IMAP server. - - -1. Conventions used in this document - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" - in this document are to be interpreted as defined in "Key words for - use in RFCs to Indicate Requirement Levels" [KEYWORDS]. - - -2. IMAP scheme - - The IMAP URL scheme is used to designate IMAP servers, mailboxes, - messages, MIME bodies [MIME], and search programs on Internet hosts - accessible using the IMAP protocol. - - The IMAP URL follows the common Internet scheme syntax as defined - in RFC 1738 [BASIC-URL] except that clear text passwords are not - permitted. If : is omitted, the port defaults to 143. - - - - - - - - -Newman Standards Track [Page 1] - -RFC 2192 IMAP URL Scheme September 1997 - - - An IMAP URL takes one of the following forms: - - imap:/// - imap:///;TYPE= - imap:///[uidvalidity][?] - imap:///[uidvalidity][isection] - - The first form is used to refer to an IMAP server, the second form - refers to a list of mailboxes, the third form refers to the - contents of a mailbox or a set of messages resulting from a search, - and the final form refers to a specific message or message part. - Note that the syntax here is informal. The authoritative formal - syntax for IMAP URLs is defined in section 11. - - -3. IMAP User Name and Authentication Mechanism - - A user name and/or authentication mechanism may be supplied. They - are used in the "LOGIN" or "AUTHENTICATE" commands after making the - connection to the IMAP server. If no user name or authentication - mechanism is supplied, the user name "anonymous" is used with the - "LOGIN" command and the password is supplied as the Internet e-mail - address of the end user accessing the resource. If the URL doesn't - supply a user name, the program interpreting the IMAP URL SHOULD - request one from the user if necessary. - - An authentication mechanism can be expressed by adding - ";AUTH=" to the end of the user name. When such an - is indicated, the client SHOULD request appropriate - credentials from that mechanism and use the "AUTHENTICATE" command - instead of the "LOGIN" command. If no user name is specified, one - SHOULD be obtained from the mechanism or requested from the user as - appropriate. - - The string ";AUTH=*" indicates that the client SHOULD select an - appropriate authentication mechanism. It MAY use any mechanism - listed in the CAPABILITY command or use an out of band security - service resulting in a PREAUTH connection. If no user name is - specified and no appropriate authentication mechanisms are - available, the client SHOULD fall back to anonymous login as - described above. This allows a URL which grants read-write access - to authorized users, and read-only anonymous access to other users. - - If a user name is included with no authentication mechanism, then - ";AUTH=*" is assumed. - - - - - - -Newman Standards Track [Page 2] - -RFC 2192 IMAP URL Scheme September 1997 - - - Since URLs can easily come from untrusted sources, care must be - taken when resolving a URL which requires or requests any sort of - authentication. If authentication credentials are supplied to the - wrong server, it may compromise the security of the user's account. - The program resolving the URL should make sure it meets at least - one of the following criteria in this case: - - (1) The URL comes from a trusted source, such as a referral server - which the client has validated and trusts according to site policy. - Note that user entry of the URL may or may not count as a trusted - source, depending on the experience level of the user and site - policy. - (2) Explicit local site policy permits the client to connect to the - server in the URL. For example, if the client knows the site - domain name, site policy may dictate that any hostname ending in - that domain is trusted. - (3) The user confirms that connecting to that domain name with the - specified credentials and/or mechanism is permitted. - (4) A mechanism is used which validates the server before passing - potentially compromising client credentials. - (5) An authentication mechanism is used which will not reveal - information to the server which could be used to compromise future - connections. - - URLs which do not include a user name must be treated with extra - care, since they are more likely to compromise the user's primary - account. A URL containing ";AUTH=*" must also be treated with - extra care since it might fall back on a weaker security mechanism. - Finally, clients are discouraged from using a plain text password - as a fallback with ";AUTH=*" unless the connection has strong - encryption (e.g. a key length of greater than 56 bits). - - A program interpreting IMAP URLs MAY cache open connections to an - IMAP server for later re-use. If a URL contains a user name, only - connections authenticated as that user may be re-used. If a URL - does not contain a user name or authentication mechanism, then only - an anonymous connection may be re-used. If a URL contains an - authentication mechanism without a user name, then any non- - anonymous connection may be re-used. - - Note that if unsafe or reserved characters such as " " or ";" are - present in the user name or authentication mechanism, they MUST be - encoded as described in RFC 1738 [BASIC-URL]. - - - - - - - - -Newman Standards Track [Page 3] - -RFC 2192 IMAP URL Scheme September 1997 - - -4. IMAP server - - An IMAP URL referring to an IMAP server has the following form: - - imap:/// - - A program interpreting this URL would issue the standard set of - commands it uses to present a view of the contents of an IMAP - server. This is likely to be semanticly equivalent to one of the - following URLs: - - imap:///;TYPE=LIST - imap:///;TYPE=LSUB - - The program interpreting this URL SHOULD use the LSUB form if it - supports mailbox subscriptions. - - -5. Lists of mailboxes - - An IMAP URL referring to a list of mailboxes has the following - form: - - imap:///;TYPE= - - The may be either "LIST" or "LSUB", and is case - insensitive. The field ";TYPE=" MUST be included. - - The is any argument suitable for the - list_mailbox field of the IMAP [IMAP4] LIST or LSUB commands. The - field may be omitted, in which case the program - interpreting the IMAP URL may use "*" or "%" as the - . The program SHOULD use "%" if it supports a - hierarchical view, otherwise it SHOULD use "*". - - Note that if unsafe or reserved characters such as " " or "%" are - present in they MUST be encoded as described in - RFC 1738 [BASIC-URL]. If the character "/" is present in - enc_list_mailbox, it SHOULD NOT be encoded. - - -6. Lists of messages - - An IMAP URL referring to a list of messages has the following form: - - imap:///[uidvalidity][?] - - - - - -Newman Standards Track [Page 4] - -RFC 2192 IMAP URL Scheme September 1997 - - - The field is used as the argument to the IMAP4 - "SELECT" command. Note that if unsafe or reserved characters such - as " ", ";", or "?" are present in they MUST be - encoded as described in RFC 1738 [BASIC-URL]. If the character "/" - is present in enc_mailbox, it SHOULD NOT be encoded. - - The [uidvalidity] field is optional. If it is present, it MUST be - the argument to the IMAP4 UIDVALIDITY status response at the time - the URL was created. This SHOULD be used by the program - interpreting the IMAP URL to determine if the URL is stale. - - The [?] field is optional. If it is not present, the - contents of the mailbox SHOULD be presented by the program - interpreting the URL. If it is present, it SHOULD be used as the - arguments following an IMAP4 SEARCH command with unsafe characters - such as " " (which are likely to be present in the ) - encoded as described in RFC 1738 [BASIC-URL]. - - -7. A specific message or message part - - An IMAP URL referring to a specific message or message part has the - following form: - - imap:///[uidvalidity][isection] - - The and [uidvalidity] are as defined above. - - If [uidvalidity] is present in this form, it SHOULD be used by the - program interpreting the URL to determine if the URL is stale. - - The refers to an IMAP4 message UID, and SHOULD be used as - the argument to the IMAP4 "UID FETCH" command. - - The [isection] field is optional. If not present, the URL refers - to the entire Internet message as returned by the IMAP command "UID - FETCH BODY.PEEK[]". If present, the URL refers to the object - returned by a "UID FETCH BODY.PEEK[
]" command. The - type of the object may be determined with a "UID FETCH - BODYSTRUCTURE" command and locating the appropriate part in the - resulting BODYSTRUCTURE. Note that unsafe characters in [isection] - MUST be encoded as described in [BASIC-URL]. - - - - - - - - - -Newman Standards Track [Page 5] - -RFC 2192 IMAP URL Scheme September 1997 - - -8. Relative IMAP URLs - - Relative IMAP URLs are permitted and are resolved according to the - rules defined in RFC 1808 [REL-URL] with one exception. In IMAP - URLs, parameters are treated as part of the normal path with - respect to relative URL resolution. This is believed to be the - behavior of the installed base and is likely to be documented in a - future revision of the relative URL specification. - - The following observations are also important: - - The grammar element is considered part of the user name for - purposes of resolving relative IMAP URLs. This means that unless a - new login/server specification is included in the relative URL, the - authentication mechanism is inherited from a base IMAP URL. - - URLs always use "/" as the hierarchy delimiter for the purpose of - resolving paths in relative URLs. IMAP4 permits the use of any - hierarchy delimiter in mailbox names. For this reason, relative - mailbox paths will only work if the mailbox uses "/" as the - hierarchy delimiter. Relative URLs may be used on mailboxes which - use other delimiters, but in that case, the entire mailbox name - MUST be specified in the relative URL or inherited as a whole from - the base URL. - - The base URL for a list of mailboxes or messages which was referred - to by an IMAP URL is always the referring IMAP URL itself. The - base URL for a message or message part which was referred to by an - IMAP URL may be more complicated to determine. The program - interpreting the relative URL will have to check the headers of the - MIME entity and any enclosing MIME entities in order to locate the - "Content-Base" and "Content-Location" headers. These headers are - used to determine the base URL as defined in [HTTP]. For example, - if the referring IMAP URL contains a "/;SECTION=1.2" parameter, - then the MIME headers for section 1.2, for section 1, and for the - enclosing message itself SHOULD be checked in that order for - "Content-Base" or "Content-Location" headers. - - -9. Multinational Considerations - - IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding - non-US-ASCII characters in IMAP mailbox names. Because this - convention is private to IMAP, it is necessary to convert IMAP's - encoding to one that can be more easily interpreted by a URL - display program. For this reason, IMAP's modified UTF-7 encoding - for mailboxes MUST be converted to UTF-8 [UTF8]. Since 8-bit - characters are not permitted in URLs, the UTF-8 characters are - - - -Newman Standards Track [Page 6] - -RFC 2192 IMAP URL Scheme September 1997 - - - encoded as required by the URL specification [BASIC-URL]. Sample - code is included in Appendix A to demonstrate this conversion. - - -10. Examples - - The following examples demonstrate how an IMAP4 client program - might translate various IMAP4 URLs into a series of IMAP4 commands. - Commands sent from the client to the server are prefixed with "C:", - and responses sent from the server to the client are prefixed with - "S:". - - The URL: - - - - Results in the following client commands: - - - C: A001 LOGIN ANONYMOUS sheridan@babylon5.org - C: A002 SELECT gray-council - - C: A003 UID FETCH 20 BODY.PEEK[] - - The URL: - - - - Results in the following client commands: - - - - C: A001 LOGIN MICHAEL zipper - C: A002 LIST "" users.* - - The URL: - - - - Results in the following client commands: - - - C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.org - C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw- - - - - - - -Newman Standards Track [Page 7] - -RFC 2192 IMAP URL Scheme September 1997 - - - The URL: - - - - Results in the following client commands: - - - C: A001 AUTHENTICATE KERBEROS_V4 - - C: A002 SELECT gray-council - C: A003 UID FETCH 20 BODY.PEEK[1.2] - - If the following relative URL is located in that body part: - - <;section=1.4> - - This could result in the following client commands: - - C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME] - BODY.PEEK[1.MIME] - BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)]) - - C: A005 UID FETCH 20 BODY.PEEK[1.4] - - The URL: - - - - Could result in the following: - - - C: A001 CAPABILITY - S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI - S: A001 OK - C: A002 AUTHENTICATE GSSAPI - - S: A002 OK user lennier authenticated - C: A003 SELECT "gray council" - ... - C: A004 SEARCH SUBJECT shadows - S: * SEARCH 8 10 13 14 15 16 - S: A004 OK SEARCH completed - C: A005 FETCH 8,10,13:16 ALL - ... - - - - - -Newman Standards Track [Page 8] - -RFC 2192 IMAP URL Scheme September 1997 - - - NOTE: In this final example, the client has implementation - dependent choices. The authentication mechanism could be anything, - including PREAUTH. And the final FETCH command could fetch more or - less information about the messages, depending on what it wishes to - display to the user. - - -11. Security Considerations - - Security considerations discussed in the IMAP specification [IMAP4] - and the URL specification [BASIC-URL] are relevant. Security - considerations related to authenticated URLs are discussed in - section 3 of this document. - - Many email clients store the plain text password for later use - after logging into an IMAP server. Such clients MUST NOT use a - stored password in response to an IMAP URL without explicit - permission from the user to supply that password to the specified - host name. - - -12. ABNF for IMAP URL scheme - - This uses ABNF as defined in RFC 822 [IMAIL]. Terminals from the - BNF for IMAP [IMAP4] and URLs [BASIC-URL] are also used. Strings - are not case sensitive and free insertion of linear-white-space is - not permitted. - - achar = uchar / "&" / "=" / "~" - ; see [BASIC-URL] for "uchar" definition - - bchar = achar / ":" / "@" / "/" - - enc_auth_type = 1*achar - ; encoded version of [IMAP-AUTH] "auth_type" - - enc_list_mailbox = 1*bchar - ; encoded version of [IMAP4] "list_mailbox" - - enc_mailbox = 1*bchar - ; encoded version of [IMAP4] "mailbox" - - enc_search = 1*bchar - ; encoded version of search_program below - - enc_section = 1*bchar - ; encoded version of section below - - - - -Newman Standards Track [Page 9] - -RFC 2192 IMAP URL Scheme September 1997 - - - enc_user = 1*achar - ; encoded version of [IMAP4] "userid" - - imapurl = "imap://" iserver "/" [ icommand ] - - iauth = ";AUTH=" ( "*" / enc_auth_type ) - - icommand = imailboxlist / imessagelist / imessagepart - - imailboxlist = [enc_list_mailbox] ";TYPE=" list_type - - imessagelist = enc_mailbox [ "?" enc_search ] [uidvalidity] - - imessagepart = enc_mailbox [uidvalidity] iuid [isection] - - isection = "/;SECTION=" enc_section - - iserver = [iuserauth "@"] hostport - ; See [BASIC-URL] for "hostport" definition - - iuid = "/;UID=" nz_number - ; See [IMAP4] for "nz_number" definition - - iuserauth = enc_user [iauth] / [enc_user] iauth - - list_type = "LIST" / "LSUB" - - search_program = ["CHARSET" SPACE astring SPACE] - search_key *(SPACE search_key) - ; IMAP4 literals may not be used - ; See [IMAP4] for "astring" and "search_key" - - section = section_text / (nz_number *["." nz_number] - ["." (section_text / "MIME")]) - ; See [IMAP4] for "section_text" and "nz_number" - - uidvalidity = ";UIDVALIDITY=" nz_number - ; See [IMAP4] for "nz_number" definition - -13. References - - [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource - Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of - Minnesota, December 1994. - - - - - - - -Newman Standards Track [Page 10] - -RFC 2192 IMAP URL Scheme September 1997 - - - [IMAP4] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, University of Washington, December 1996. - - - - [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, - Carnegie-Mellon University, December 1994. - - - - [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext - Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS, - January 1997. - - - - [IMAIL] Crocker, "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, University of Delaware, August 1982. - - - - [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, Harvard University, March 1997. - - - - [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail - Extensions", RFC 2045, Innosoft, First Virtual, November 1996. - - - - [REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808, - UC Irvine, June 1995. - - - - [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and - ISO 10646", RFC 2044, Alis Technologies, October 1996. - - - -14. Author's Address - - Chris Newman - Innosoft International, Inc. - 1050 Lakes Drive - West Covina, CA 91790 USA - EMail: chris.newman@innosoft.com - - - -Newman Standards Track [Page 11] - -RFC 2192 IMAP URL Scheme September 1997 - - -Appendix A. Sample code - -Here is sample C source code to convert between URL paths and IMAP -mailbox names, taking into account mapping between IMAP's modified UTF-7 -[IMAP4] and hex-encoded UTF-8 which is more appropriate for URLs. This -code has not been rigorously tested nor does it necessarily behave -reasonably with invalid input, but it should serve as a useful example. -This code just converts the mailbox portion of the URL and does not deal -with parameters, query or server components of the URL. - -#include -#include - -/* hexadecimal lookup table */ -static char hex[] = "0123456789ABCDEF"; - -/* URL unsafe printable characters */ -static char urlunsafe[] = " \"#%&+:;<=>?@[\\]^`{|}"; - -/* UTF7 modified base64 alphabet */ -static char base64chars[] = - "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,"; -#define UNDEFINED 64 - -/* UTF16 definitions */ -#define UTF16MASK 0x03FFUL -#define UTF16SHIFT 10 -#define UTF16BASE 0x10000UL -#define UTF16HIGHSTART 0xD800UL -#define UTF16HIGHEND 0xDBFFUL -#define UTF16LOSTART 0xDC00UL -#define UTF16LOEND 0xDFFFUL - -/* Convert an IMAP mailbox to a URL path - * dst needs to have roughly 4 times the storage space of src - * Hex encoding can triple the size of the input - * UTF-7 can be slightly denser than UTF-8 - * (worst case: 8 octets UTF-7 becomes 9 octets UTF-8) - */ -void MailboxToURL(char *dst, char *src) -{ - unsigned char c, i, bitcount; - unsigned long ucs4, utf16, bitbuf; - unsigned char base64[256], utf8[6]; - - - - - - - -Newman Standards Track [Page 12] - -RFC 2192 IMAP URL Scheme September 1997 - - - /* initialize modified base64 decoding table */ - memset(base64, UNDEFINED, sizeof (base64)); - for (i = 0; i < sizeof (base64chars); ++i) { - base64[base64chars[i]] = i; - } - - /* loop until end of string */ - while (*src != '\0') { - c = *src++; - /* deal with literal characters and &- */ - if (c != '&' || *src == '-') { - if (c < ' ' || c > '~' || strchr(urlunsafe, c) != NULL) { - /* hex encode if necessary */ - dst[0] = '%'; - dst[1] = hex[c >> 4]; - dst[2] = hex[c & 0x0f]; - dst += 3; - } else { - /* encode literally */ - *dst++ = c; - } - /* skip over the '-' if this is an &- sequence */ - if (c == '&') ++src; - } else { - /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */ - bitbuf = 0; - bitcount = 0; - ucs4 = 0; - while ((c = base64[(unsigned char) *src]) != UNDEFINED) { - ++src; - bitbuf = (bitbuf << 6) | c; - bitcount += 6; - /* enough bits for a UTF-16 character? */ - if (bitcount >= 16) { - bitcount -= 16; - utf16 = (bitcount ? bitbuf >> bitcount - : bitbuf) & 0xffff; - /* convert UTF16 to UCS4 */ - if - (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) { - ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT; - continue; - } else if - (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) { - ucs4 += utf16 - UTF16LOSTART + UTF16BASE; - } else { - ucs4 = utf16; - } - - - -Newman Standards Track [Page 13] - -RFC 2192 IMAP URL Scheme September 1997 - - - /* convert UTF-16 range of UCS4 to UTF-8 */ - if (ucs4 <= 0x7fUL) { - utf8[0] = ucs4; - i = 1; - } else if (ucs4 <= 0x7ffUL) { - utf8[0] = 0xc0 | (ucs4 >> 6); - utf8[1] = 0x80 | (ucs4 & 0x3f); - i = 2; - } else if (ucs4 <= 0xffffUL) { - utf8[0] = 0xe0 | (ucs4 >> 12); - utf8[1] = 0x80 | ((ucs4 >> 6) & 0x3f); - utf8[2] = 0x80 | (ucs4 & 0x3f); - i = 3; - } else { - utf8[0] = 0xf0 | (ucs4 >> 18); - utf8[1] = 0x80 | ((ucs4 >> 12) & 0x3f); - utf8[2] = 0x80 | ((ucs4 >> 6) & 0x3f); - utf8[3] = 0x80 | (ucs4 & 0x3f); - i = 4; - } - /* convert utf8 to hex */ - for (c = 0; c < i; ++c) { - dst[0] = '%'; - dst[1] = hex[utf8[c] >> 4]; - dst[2] = hex[utf8[c] & 0x0f]; - dst += 3; - } - } - } - /* skip over trailing '-' in modified UTF-7 encoding */ - if (*src == '-') ++src; - } - } - /* terminate destination string */ - *dst = '\0'; -} - -/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox - * dst should be about twice the length of src to deal with non-hex - * coded URLs - */ -void URLtoMailbox(char *dst, char *src) -{ - unsigned int utf8pos, utf8total, i, c, utf7mode, bitstogo, utf16flag; - unsigned long ucs4, bitbuf; - unsigned char hextab[256]; - - /* initialize hex lookup table */ - - - -Newman Standards Track [Page 14] - -RFC 2192 IMAP URL Scheme September 1997 - - - memset(hextab, 0, sizeof (hextab)); - for (i = 0; i < sizeof (hex); ++i) { - hextab[hex[i]] = i; - if (isupper(hex[i])) hextab[tolower(hex[i])] = i; - } - - utf7mode = 0; - utf8total = 0; - bitstogo = 0; - while ((c = *src) != '\0') { - ++src; - /* undo hex-encoding */ - if (c == '%' && src[0] != '\0' && src[1] != '\0') { - c = (hextab[src[0]] << 4) | hextab[src[1]]; - src += 2; - } - /* normal character? */ - if (c >= ' ' && c <= '~') { - /* switch out of UTF-7 mode */ - if (utf7mode) { - if (bitstogo) { - *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; - } - *dst++ = '-'; - utf7mode = 0; - } - *dst++ = c; - /* encode '&' as '&-' */ - if (c == '&') { - *dst++ = '-'; - } - continue; - } - /* switch to UTF-7 mode */ - if (!utf7mode) { - *dst++ = '&'; - utf7mode = 1; - } - /* Encode US-ASCII characters as themselves */ - if (c < 0x80) { - ucs4 = c; - utf8total = 1; - } else if (utf8total) { - /* save UTF8 bits into UCS4 */ - ucs4 = (ucs4 << 6) | (c & 0x3FUL); - if (++utf8pos < utf8total) { - continue; - } - - - -Newman Standards Track [Page 15] - -RFC 2192 IMAP URL Scheme September 1997 - - - } else { - utf8pos = 1; - if (c < 0xE0) { - utf8total = 2; - ucs4 = c & 0x1F; - } else if (c < 0xF0) { - utf8total = 3; - ucs4 = c & 0x0F; - } else { - /* NOTE: can't convert UTF8 sequences longer than 4 */ - utf8total = 4; - ucs4 = c & 0x03; - } - continue; - } - /* loop to split ucs4 into two utf16 chars if necessary */ - utf8total = 0; - do { - if (ucs4 >= UTF16BASE) { - ucs4 -= UTF16BASE; - bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT) - + UTF16HIGHSTART); - ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART; - utf16flag = 1; - } else { - bitbuf = (bitbuf << 16) | ucs4; - utf16flag = 0; - } - bitstogo += 16; - /* spew out base64 */ - while (bitstogo >= 6) { - bitstogo -= 6; - *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo) - : bitbuf) - & 0x3F]; - } - } while (utf16flag); - } - /* if in UTF-7 mode, finish in ASCII */ - if (utf7mode) { - if (bitstogo) { - *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; - } - *dst++ = '-'; - } - /* tie off string */ - *dst = '\0'; -} - - - -Newman Standards Track [Page 16] - - - diff --git a/server/src/site/resources/rfclist/imap4/rfc2193.txt b/server/src/site/resources/rfclist/imap4/rfc2193.txt deleted file mode 100644 index 09dd90f79f1..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2193.txt +++ /dev/null @@ -1,508 +0,0 @@ - - - - - -Network Working Group M. Gahrns -Request for Comments: 2193 Microsoft -Category: Standards Track September 1997 - - - IMAP4 Mailbox Referrals - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - When dealing with large amounts of users, messages and geographically - dispersed IMAP4 [RFC-2060] servers, it is often desirable to - distribute messages amongst different servers within an organization. - For example an administrator may choose to store user's personal - mailboxes on a local IMAP4 server, while storing shared mailboxes - remotely on another server. This type of configuration is common - when it is uneconomical to store all data centrally due to limited - bandwidth or disk resources. - - Mailbox referrals allow clients to seamlessly access mailboxes that - are distributed across several IMAP4 servers. - - A referral mechanism can provide efficiencies over the alternative - "proxy method", in which the local IMAP4 server contacts the remote - server on behalf of the client, and then transfers the data from the - remote server to itself, and then on to the client. The referral - mechanism's direct client connection to the remote server is often a - more efficient use of bandwidth, and does not require the local - server to impersonate the client when authenticating to the remote - server. - -2. Conventions used in this document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - - A home server, is an IMAP4 server that contains the user's inbox. - - A remote mailbox is a mailbox that is not hosted on the user's home - server. - - - - -Gahrns Standards Track [Page 1] - -RFC 2193 IMAP4 Mailbox Referrals September 1997 - - - A remote server is a server that contains remote mailboxes. - - A shared mailbox, is a mailbox that multiple users have access to. - - An IMAP mailbox referral is when the server directs the client to - another IMAP mailbox. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC-2119]. - -3. Introduction and Overview - - IMAP4 servers that support this extension MUST list the keyword - MAILBOX-REFERRALS in their CAPABILITY response. No client action is - needed to invoke the MAILBOX-REFERRALS capability in a server. - - A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals - that result in a referrals loop. - - A referral response consists of a tagged NO response and a REFERRAL - response code. The REFERRAL response code MUST contain as an - argument a one or more valid URLs separated by a space as defined in - [RFC-1738]. If a server replies with multiple URLs for a particular - object, they MUST all be of the same type. In this case, the URL MUST - be an IMAP URL as defined in [RFC-2192]. A client that supports the - REFERRALS extension MUST be prepared for a URL of any type, but it - need only be able to process IMAP URLs. - - A server MAY respond with multiple IMAP mailbox referrals if there is - more than one replica of the mailbox. This allows the implementation - of a load balancing or failover scheme. How a server keeps multiple - replicas of a mailbox in sync is not addressed by this document. - - If the server has a preferred order in which the client should - attempt to access the URLs, the preferred URL SHOULD be listed in the - first, with the remaining URLs presented in descending order of - preference. If multiple referrals are given for a mailbox, a server - should be aware that there are synchronization issues for a client if - the UIDVALIDITY of the referred mailboxes are different. - - An IMAP mailbox referral may be given in response to an IMAP command - that specifies a mailbox as an argument. - - - - - - - - -Gahrns Standards Track [Page 2] - -RFC 2193 IMAP4 Mailbox Referrals September 1997 - - - Example: - - A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox - - NOTE: user;AUTH=* is specified as required by [RFC-2192] to avoid a - client falling back to anonymous login. - - Remote mailboxes and their inferiors, that are accessible only via - referrals SHOULD NOT appear in LIST and LSUB responses issued against - the user's home server. They MUST appear in RLIST and RLSUB - responses issued against the user's home server. Hierarchy referrals, - in which a client would be required to connect to the remote server - to issue a LIST to discover the inferiors of a mailbox are not - addressed in this document. - - For example, if shared mailboxes were only accessible via referrals - on a remote server, a RLIST "" "#SHARED/%" command would return the - same response if issued against the user's home server or the remote - server. - - Note: Mailboxes that are available on the user's home server do not - need to be available on the remote server. In addition, there may be - additional mailboxes available on the remote server, but they will - not accessible to the client via referrals unless they appear in the - LIST response to the RLIST command against the user's home server. - - A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB - commands in lieu of LIST and LSUB. The RLIST and RLSUB commands - behave identically to their LIST and LSUB counterparts, except remote - mailboxes are returned in addition to local mailboxes in the LIST and - LSUB responses. This avoids displaying to a non MAILBOX-REFERRALS - enabled client inaccessible remote mailboxes. - -4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND - Referrals - - An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE, - SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more - IMAP mailbox referrals to indicate to the client that the mailbox is - hosted on a remote server. - - When a client processes an IMAP mailbox referral, it will open a new - connection or use an existing connection to the remote server so that - it is able to issue the commands necessary to process the remote - mailbox. - - - - - - -Gahrns Standards Track [Page 3] - -RFC 2193 IMAP4 Mailbox Referrals September 1997 - - - Example: - - C: A001 DELETE "SHARED/FOO" - S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] - Remote mailbox. Try SERVER2. - - - - S: * OK IMAP4rev1 server ready - C: B001 AUTHENTICATE KERBEROS_V4 - - S: B001 OK user is authenticated - - C: B002 DELETE "SHARED/FOO" - S: B002 OK DELETE completed - - Example: - - C: A001 SELECT REMOTE - S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE - IMAP://user;AUTH=*@SERVER3/REMOTE] Remote mailbox. - Try SERVER2 or SERVER3. - - - - S: * OK IMAP4rev1 server ready - C: B001 AUTHENTICATE KERBEROS_V4 - - S: B001 OK user is authenticated - - C: B002 SELECT REMOTE - S: * 12 EXISTS - S: * 1 RECENT - S: * OK [UNSEEN 10] Message 10 is first unseen - S: * OK [UIDVALIDITY 123456789] - S: * FLAGS (Answered Flagged Deleted Seen Draft) - S: * OK [PERMANENTFLAGS (Answered Deleted Seen ] - S: B002 OK [READ-WRITE] Selected completed - - C: B003 FETCH 10:12 RFC822 - S: * 10 FETCH . . . - S: * 11 FETCH . . . - S: * 12 FETCH . . . - S: B003 OK FETCH Completed - - - - -Gahrns Standards Track [Page 4] - -RFC 2193 IMAP4 Mailbox Referrals September 1997 - - - - - C: B004 LOGOUT - S: * BYE IMAP4rev1 server logging out - S: B004 OK LOGOUT Completed - - - - C: A002 SELECT INBOX - S: * 16 EXISTS - S: * 2 RECENT - S: * OK [UNSEEN 10] Message 10 is first unseen - S: * OK [UIDVALIDITY 123456789] - S: * FLAGS (Answered Flagged Deleted Seen Draft) - S: * OK [PERMANENTFLAGS (Answered Deleted Seen ] - S: A002 OK [READ-WRITE] Selected completed - -4.2. CREATE Referrals - - An IMAP4 server MAY respond to the CREATE command with one or more - IMAP mailbox referrals, if it wishes to direct the client to issue - the CREATE against another server. The server can employ any means, - such as examining the hierarchy of the specified mailbox name, in - determining which server the mailbox should be created on. - - Example: - - C: A001 CREATE "SHARED/FOO" - S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] - Mailbox should be created on remote server - - Alternatively, because a home server is required to maintain a - listing of referred remote mailboxes, a server MAY allow the creation - of a mailbox that will ultimately reside on a remote server against - the home server, and provide referrals on subsequent commands that - manipulate the mailbox. - - Example: - - C: A001 CREATE "SHARED/FOO" - S: A001 OK CREATE succeeded - - C: A002 SELECT "SHARED/FOO" - S: A002 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] - Remote mailbox. Try SERVER2 - - - - - -Gahrns Standards Track [Page 5] - -RFC 2193 IMAP4 Mailbox Referrals September 1997 - - -4.3. RENAME Referrals - - An IMAP4 server MAY respond to the RENAME command with one or more - pairs of IMAP mailbox referrals. In each pair of IMAP mailbox - referrals, the first one is an URL to the existing mailbox name and - the second is an URL to the requested new mailbox name. - - If within an IMAP mailbox referral pair, the existing and new mailbox - URLs are on different servers, the remote servers are unable to - perform the RENAME operation. To achieve the same behavior of - server RENAME, the client MAY issue the constituent CREATE, FETCH, - APPEND, and DELETE commands against both servers. - - If within an IMAP mailbox referral pair, the existing and new mailbox - URLs are on the same server it is an indication that the currently - connected server is unable to perform the operation. The client can - simply re-issue the RENAME command on the remote server. - - Example: - - C: A001 RENAME FOO BAR - S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER1/FOO - IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox - across servers - - Since the existing and new mailbox names are on different servers, - the client would be required to make a connection to both servers and - issue the constituent commands require to achieve the RENAME. - - Example: - - C: A001 RENAME FOO BAR - S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/FOO - IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox - located on SERVER2 - - Since both the existing and new mailbox are on the same remote - server, the client can simply make a connection to the remote server - and re-issue the RENAME command. - -4.4. COPY Referrals - - An IMAP4 server MAY respond to the COPY command with one or more IMAP - mailbox referrals. This indicates that the destination mailbox is on - a remote server. To achieve the same behavior of a server COPY, the - client MAY issue the constituent FETCH and APPEND commands against - both servers. - - - - -Gahrns Standards Track [Page 6] - -RFC 2193 IMAP4 Mailbox Referrals September 1997 - - - Example: - - C: A001 COPY 1 "SHARED/STUFF" - S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/STUFF] - Unable to copy message(s) to SERVER2. - -5.1 RLIST command - - Arguments: reference name - mailbox name with possible wildcards - - Responses: untagged responses: LIST - - Result: OK - RLIST Completed - NO - RLIST Failure - BAD - command unknown or arguments invalid - - The RLIST command behaves identically to its LIST counterpart, except - remote mailboxes are returned in addition to local mailboxes in the - LIST responses. - -5.2 RLSUB Command - - Arguments: reference name - mailbox name with possible wildcards - - Responses: untagged responses: LSUB - - Result: OK - RLSUB Completed - NO - RLSUB Failure - BAD - command unknown or arguments invalid - - The RLSUB command behaves identically to its LSUB counterpart, except - remote mailboxes are returned in addition to local mailboxes in the - LSUB responses. - -6. Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) as described in [ABNF]. - - list_mailbox = as defined in [RFC-2060] - - mailbox = as defined in [RFC-2060] - - mailbox_referral = SPACE "NO" SPACE - (text / text_mime2) - ; See [RFC-2060] for , text and text_mime2 definition - - - -Gahrns Standards Track [Page 7] - -RFC 2193 IMAP4 Mailbox Referrals September 1997 - - - referral_response_code = "[" "REFERRAL" 1*(SPACE ) "]" - ; See [RFC-1738] for definition - - rlist = "RLIST" SPACE mailbox SPACE list_mailbox - - rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox - -6. Security Considerations - - The IMAP4 referral mechanism makes use of IMAP URLs, and as such, - have the same security considerations as general internet URLs [RFC- - 1738], and in particular IMAP URLs [RFC-2192]. - - With the MAILBOX-REFERRALS capability, it is potentially easier to - write a rogue server that injects a bogus referral response that - directs a user to an incorrect mailbox. Although referrals reduce - the effort to write such a server, the referral response makes - detection of the intrusion easier. - -7. References - - [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, University of Washington, December 1996. - - [RFC-2192], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, - September 1997. - - [RFC-1738], Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, - University of Minnesota, December 1994. - - [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, Harvard University, March 1997. - - [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for - Syntax Specifications: ABNF", Work in Progress, Internet Mail - Consortium, April 1997. - -8. Acknowledgments - - Many valuable suggestions were received from private discussions and - the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin, - Mark Keasling, Chris Newman and Larry Osterman made significant - contributions to this document. - - - - - - - -Gahrns Standards Track [Page 8] - -RFC 2193 IMAP4 Mailbox Referrals September 1997 - - -9. Author's Address - - Mike Gahrns - Microsoft - One Microsoft Way - Redmond, WA, 98072 - - Phone: (206) 936-9833 - EMail: mikega@microsoft.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gahrns Standards Track [Page 9] - - - diff --git a/server/src/site/resources/rfclist/imap4/rfc2195.txt b/server/src/site/resources/rfclist/imap4/rfc2195.txt deleted file mode 100644 index 479fa28f674..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2195.txt +++ /dev/null @@ -1,284 +0,0 @@ - - - - - -Network Working Group J. Klensin -Request for Comments: 2195 R. Catoe -Category: Standards Track P. Krumviede -Obsoletes: 2095 MCI - September 1997 - - - IMAP/POP AUTHorize Extension for Simple Challenge/Response - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - While IMAP4 supports a number of strong authentication mechanisms as - described in RFC 1731, it lacks any mechanism that neither passes - cleartext, reusable passwords across the network nor requires either - a significant security infrastructure or that the mail server update - a mail-system-wide user authentication file on each mail access. - This specification provides a simple challenge-response - authentication protocol that is suitable for use with IMAP4. Since - it utilizes Keyed-MD5 digests and does not require that the secret be - stored in the clear on the server, it may also constitute an - improvement on APOP for POP3 use as specified in RFC 1734. - -1. Introduction - - Existing Proposed Standards specify an AUTHENTICATE mechanism for the - IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for - the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is - intended to be extensible; the four methods specified in [IMAP-AUTH] - are all fairly powerful and require some security infrastructure to - support. The base POP3 specification [POP3] also contains a - lightweight challenge-response mechanism called APOP. APOP is - associated with most of the risks associated with such protocols: in - particular, it requires that both the client and server machines have - access to the shared secret in cleartext form. CRAM offers a method - for avoiding such cleartext storage while retaining the algorithmic - simplicity of APOP in using only MD5, though in a "keyed" method. - - - - - - - -Klensin, Catoe & Krumviede Standards Track [Page 1] - -RFC 2195 IMAP/POP AUTHorize Extension September 1997 - - - At present, IMAP [IMAP] lacks any facility corresponding to APOP. - The only alternative to the strong mechanisms identified in [IMAP- - AUTH] is a presumably cleartext username and password, supported - through the LOGIN command in [IMAP]. This document describes a - simple challenge-response mechanism, similar to APOP and PPP CHAP - [PPP], that can be used with IMAP (and, in principle, with POP3). - - This mechanism also has the advantage over some possible alternatives - of not requiring that the server maintain information about email - "logins" on a per-login basis. While mechanisms that do require such - per-login history records may offer enhanced security, protocols such - as IMAP, which may have several connections between a given client - and server open more or less simultaneous, may make their - implementation particularly challenging. - -2. Challenge-Response Authentication Mechanism (CRAM) - - The authentication type associated with CRAM is "CRAM-MD5". - - The data encoded in the first ready response contains an - presumptively arbitrary string of random digits, a timestamp, and the - fully-qualified primary host name of the server. The syntax of the - unencoded form must correspond to that of an RFC 822 'msg-id' - [RFC822] as described in [POP3]. - - The client makes note of the data and then responds with a string - consisting of the user name, a space, and a 'digest'. The latter is - computed by applying the keyed MD5 algorithm from [KEYED-MD5] where - the key is a shared secret and the digested text is the timestamp - (including angle-brackets). - - This shared secret is a string known only to the client and server. - The `digest' parameter itself is a 16-octet value which is sent in - hexadecimal format, using lower-case ASCII characters. - - When the server receives this client response, it verifies the digest - provided. If the digest is correct, the server should consider the - client authenticated and respond appropriately. - - Keyed MD5 is chosen for this application because of the greater - security imparted to authentication of short messages. In addition, - the use of the techniques described in [KEYED-MD5] for precomputation - of intermediate results make it possible to avoid explicit cleartext - storage of the shared secret on the server system by instead storing - the intermediate results which are known as "contexts". - - - - - - -Klensin, Catoe & Krumviede Standards Track [Page 2] - -RFC 2195 IMAP/POP AUTHorize Extension September 1997 - - - CRAM does not support a protection mechanism. - - Example: - - The examples in this document show the use of the CRAM mechanism with - the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of - the challenges and responses is part of the IMAP4 AUTHENTICATE - command, not part of the CRAM specification itself. - - S: * OK IMAP4 Server - C: A0001 AUTHENTICATE CRAM-MD5 - S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ - C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw - S: A0001 OK CRAM authentication successful - - In this example, the shared secret is the string - 'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by - calculating - - MD5((tanstaaftanstaaf XOR opad), - MD5((tanstaaftanstaaf XOR ipad), - <1896.697170952@postoffice.reston.mci.net>)) - - where ipad and opad are as defined in the keyed-MD5 Work in - Progress [KEYED-MD5] and the string shown in the challenge is the - base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The - shared secret is null-padded to a length of 64 bytes. If the - shared secret is longer than 64 bytes, the MD5 digest of the - shared secret is used as a 16 byte input to the keyed MD5 - calculation. - - This produces a digest value (in hexadecimal) of - - b913a602c7eda7a495b4e6e7334d3890 - - The user name is then prepended to it, forming - - tim b913a602c7eda7a495b4e6e7334d3890 - - Which is then base64 encoded to meet the requirements of the IMAP4 - AUTHENTICATE command (or the similar POP3 AUTH command), yielding - - dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw - - - - - - - - -Klensin, Catoe & Krumviede Standards Track [Page 3] - -RFC 2195 IMAP/POP AUTHorize Extension September 1997 - - -3. References - - [CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", - RFC 1334, October 1992. - - [IMAP] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, University of Washington, December 1996. - - [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", - RFC 1731, Carnegie Mellon, December 1994. - - [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for - Message Authentication", RFC 2104, February 1997. - - [MD5] Rivest, R., "The MD5 Message Digest Algorithm", - RFC 1321, MIT Laboratory for Computer Science, April 1992. - - [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3", - STD 53, RFC 1939, Carnegie Mellon, May 1996. - - [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, - Carnegie Mellon, December, 1994. - -4. Security Considerations - - It is conjectured that use of the CRAM authentication mechanism - provides origin identification and replay protection for a session. - Accordingly, a server that implements both a cleartext password - command and this authentication type should not allow both methods of - access for a given user. - - While the saving, on the server, of "contexts" (see section 2) is - marginally better than saving the shared secrets in cleartext as is - required by CHAP [CHAP] and APOP [POP3], it is not sufficient to - protect the secrets if the server itself is compromised. - Consequently, servers that store the secrets or contexts must both be - protected to a level appropriate to the potential information value - in user mailboxes and identities. - - As the length of the shared secret increases, so does the difficulty - of deriving it. - - While there are now suggestions in the literature that the use of MD5 - and keyed MD5 in authentication procedures probably has a limited - effective lifetime, the technique is now widely deployed and widely - understood. It is believed that this general understanding may - assist with the rapid replacement, by CRAM-MD5, of the current uses - of permanent cleartext passwords in IMAP. This document has been - - - -Klensin, Catoe & Krumviede Standards Track [Page 4] - -RFC 2195 IMAP/POP AUTHorize Extension September 1997 - - - deliberately written to permit easy upgrading to use SHA (or whatever - alternatives emerge) when they are considered to be widely available - and adequately safe. - - Even with the use of CRAM, users are still vulnerable to active - attacks. An example of an increasingly common active attack is 'TCP - Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95]. - - See section 1 above for additional discussion. - -5. Acknowledgements - - This memo borrows ideas and some text liberally from [POP3] and - [RFC-1731] and thanks are due the authors of those documents. Ran - Atkinson made a number of valuable technical and editorial - contributions to the document. - -6. Authors' Addresses - - John C. Klensin - MCI Telecommunications - 800 Boylston St, 7th floor - Boston, MA 02199 - USA - - EMail: klensin@mci.net - Phone: +1 617 960 1011 - - Randy Catoe - MCI Telecommunications - 2100 Reston Parkway - Reston, VA 22091 - USA - - EMail: randy@mci.net - Phone: +1 703 715 7366 - - Paul Krumviede - MCI Telecommunications - 2100 Reston Parkway - Reston, VA 22091 - USA - - EMail: paul@mci.net - Phone: +1 703 715 7251 - - - - - - -Klensin, Catoe & Krumviede Standards Track [Page 5] - - - diff --git a/server/src/site/resources/rfclist/imap4/rfc2221.txt b/server/src/site/resources/rfclist/imap4/rfc2221.txt deleted file mode 100644 index 78f73c90289..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2221.txt +++ /dev/null @@ -1,284 +0,0 @@ - - - - - -Network Working Group M. Gahrns -Request for Comments: 2221 Microsoft -Category: Standards Track October 1997 - - - IMAP4 Login Referrals - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -1. Abstract - - When dealing with large amounts of users and many IMAP4 [RFC-2060] - servers, it is often necessary to move users from one IMAP4 server to - another. For example, hardware failures or organizational changes - may dictate such a move. - - Login referrals allow clients to transparently connect to an - alternate IMAP4 server, if their home IMAP4 server has changed. - - A referral mechanism can provide efficiencies over the alternative - 'proxy method', in which the local IMAP4 server contacts the remote - server on behalf of the client, and then transfers the data from the - remote server to itself, and then on to the client. The referral - mechanism's direct client connection to the remote server is often a - more efficient use of bandwidth, and does not require the local - server to impersonate the client when authenticating to the remote - server. - -2. Conventions used in this document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - - A home server, is an IMAP4 server that contains the user's inbox. - - A remote server is a server that contains remote mailboxes. - - - - - -Gahrns Standards Track [Page 1] - -RFC 2221 IMAP4 Login Referrals October 1997 - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC-2119]. - -3. Introduction and Overview - - IMAP4 servers that support this extension MUST list the keyword - LOGIN-REFERRALS in their CAPABILITY response. No client action is - needed to invoke the LOGIN-REFERRALS capability in a server. - - A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral - to a server that will return a referral. A client MUST NOT follow - more than 10 levels of referral without consulting the user. - - A LOGIN-REFERRALS response code MUST contain as an argument a valid - IMAP server URL as defined in [IMAP-URL]. - - A home server referral consists of either a tagged NO or OK, or an - untagged BYE response that contains a LOGIN-REFERRALS response code. - - Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server - - NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a - client falling back to anonymous login. - -4. Home Server Referrals - - A home server referral may be returned in response to an AUTHENTICATE - or LOGIN command, or it may appear in the connection startup banner. - If a server returns a home server referral in a tagged NO response, - that server does not contain any mailboxes that are accessible to the - user. If a server returns a home server referral in a tagged OK - response, it indicates that the user's personal mailboxes are - elsewhere, but the server contains public mailboxes which are - readable by the user. After receiving a home server referral, the - client can not make any assumptions as to whether this was a - permanent or temporary move of the user. - -4.1. LOGIN and AUTHENTICATE Referrals - - An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a - home server referral if it wishes to direct the user to another IMAP4 - server. - - Example: C: A001 LOGIN MIKE PASSWORD - S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user - is invalid on this server. Try SERVER2. - - - - -Gahrns Standards Track [Page 2] - -RFC 2221 IMAP4 Login Referrals October 1997 - - - Example: C: A001 LOGIN MATTHEW PASSWORD - S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified - user's personal mailboxes located on Server2, but - public mailboxes are available. - - Example: C: A001 AUTHENTICATE GSSAPI - - S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/] - Specified user is invalid on this server. Try - SERVER2. - -4.2. BYE at connection startup referral - - An IMAP4 server MAY respond with an untagged BYE and a REFERRAL - response code that contains an IMAP URL to a home server if it is not - willing to accept connections and wishes to direct the client to - another IMAP4 server. - - Example: S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not - accepting connections. Try SERVER2 - -5. Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) as described in [ABNF]. - - This amends the "resp_text_code" element of the IMAP4 grammar - described in [RFC-2060] - - resp_text_code =/ "REFERRAL" SPACE - ; See [IMAP-URL] for definition of - ; See [RFC-2060] for base definition of resp_text_code - -6. Security Considerations - - The IMAP4 login referral mechanism makes use of IMAP URLs, and as - such, have the same security considerations as general internet URLs - [RFC-1738], and in particular IMAP URLs [IMAP-URL]. - - A server MUST NOT give a login referral if authentication for that - user fails. This is to avoid revealing information about the user's - account to an unauthorized user. - - With the LOGIN-REFERRALS capability, it is potentially easier to - write a rogue 'password catching' server that collects login data and - then refers the client to their actual IMAP4 server. Although - referrals reduce the effort to write such a server, the referral - response makes detection of the intrusion easier. - - - -Gahrns Standards Track [Page 3] - -RFC 2221 IMAP4 Login Referrals October 1997 - - -7. References - - [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, December 1996. - - [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, - September 1997. - - [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, December 1994. - - [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, March 1997. - - [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for - Syntax Specifications: ABNF", Work in Progress. - -8. Acknowledgments - - Many valuable suggestions were received from private discussions and - the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin, - Mark Keasling Chris Newman and Larry Osterman made significant - contributions to this document. - -9. Author's Address - - Mike Gahrns - Microsoft - One Microsoft Way - Redmond, WA, 98072 - - Phone: (206) 936-9833 - EMail: mikega@microsoft.com - - - - - - - - - - - - - - - - - - -Gahrns Standards Track [Page 4] - -RFC 2221 IMAP4 Login Referrals October 1997 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation may be prepared, copied, published - andand distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - - - - - - - - - - - - - - - - - - - - - - - - -Gahrns Standards Track [Page 5] - - - diff --git a/server/src/site/resources/rfclist/imap4/rfc2342.txt b/server/src/site/resources/rfclist/imap4/rfc2342.txt deleted file mode 100644 index f1c8c409412..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2342.txt +++ /dev/null @@ -1,564 +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 , where 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 , - where 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 = - ; 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 = - ; as defined in [RFC-2060] - - QUOTED_CHAR = - ; as defined in [RFC-2060] - - 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/server/src/site/resources/rfclist/imap4/rfc2359.txt b/server/src/site/resources/rfclist/imap4/rfc2359.txt deleted file mode 100644 index ad938a42c5a..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2359.txt +++ /dev/null @@ -1,340 +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 - C: Subject: afternoon meeting - C: To: mooch@owatagu.siam.edu - C: Message-Id: - C: MIME-Version: 1.0 - C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII - C: - C: Hello Joe, do you think we can meet at 3:30 tomorrow? - C: - S: A003 OK [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/server/src/site/resources/rfclist/imap4/rfc2595.txt b/server/src/site/resources/rfclist/imap4/rfc2595.txt deleted file mode 100644 index 66897cd6c97..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2595.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -Network Working Group C. Newman -Request for Comments: 2595 Innosoft -Category: Standards Track June 1999 - - - Using TLS with IMAP, POP3 and ACAP - - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -1. Motivation - - The TLS protocol (formerly known as SSL) provides a way to secure an - application protocol from tampering and eavesdropping. The option of - using such security is desirable for IMAP, POP and ACAP due to common - connection eavesdropping and hijacking attacks [AUTH]. Although - advanced SASL authentication mechanisms can provide a lightweight - version of this service, TLS is complimentary to simple - authentication-only SASL mechanisms or deployed clear-text password - login commands. - - Many sites have a high investment in authentication infrastructure - (e.g., a large database of a one-way-function applied to user - passwords), so a privacy layer which is not tightly bound to user - authentication can protect against network eavesdropping attacks - without requiring a new authentication infrastructure and/or forcing - all users to change their password. Recognizing that such sites will - desire simple password authentication in combination with TLS - encryption, this specification defines the PLAIN SASL mechanism for - use with protocols which lack a simple password authentication - command such as ACAP and SMTP. (Note there is a separate RFC for the - STARTTLS command in SMTP [SMTPTLS].) - - There is a strong desire in the IETF to eliminate the transmission of - clear-text passwords over unencrypted channels. While SASL can be - used for this purpose, TLS provides an additional tool with different - deployability characteristics. A server supporting both TLS with - - - - -Newman Standards Track [Page 1] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - - simple passwords and a challenge/response SASL mechanism is likely to - interoperate with a wide variety of clients without resorting to - unencrypted clear-text passwords. - - The STARTTLS command rectifies a number of the problems with using a - separate port for a "secure" protocol variant. Some of these are - mentioned in section 7. - -1.1. Conventions Used in this Document - - The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", - "MAY", and "OPTIONAL" in this document are to be interpreted as - described in "Key words for use in RFCs to Indicate Requirement - Levels" [KEYWORDS]. - - Terms related to authentication are defined in "On Internet - Authentication" [AUTH]. - - Formal syntax is defined using ABNF [ABNF]. - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - -2. Basic Interoperability and Security Requirements - - The following requirements apply to all implementations of the - STARTTLS extension for IMAP, POP3 and ACAP. - -2.1. Cipher Suite Requirements - - Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher - suite is REQUIRED. This is important as it assures that any two - compliant implementations can be configured to interoperate. - - All other cipher suites are OPTIONAL. - -2.2. Privacy Operational Mode Security Requirements - - Both clients and servers SHOULD have a privacy operational mode which - refuses authentication unless successful activation of an encryption - layer (such as that provided by TLS) occurs prior to or at the time - of authentication and which will terminate the connection if that - encryption layer is deactivated. Implementations are encouraged to - have flexability with respect to the minimal encryption strength or - cipher suites permitted. A minimalist approach to this - recommendation would be an operational mode where the - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to - permitting authentication. - - - -Newman Standards Track [Page 2] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - - Clients MAY have an operational mode which uses encryption only when - it is advertised by the server, but authentication continues - regardless. For backwards compatibility, servers SHOULD have an - operational mode where only the authentication mechanisms required by - the relevant base protocol specification are needed to successfully - authenticate. - -2.3. Clear-Text Password Requirements - - Clients and servers which implement STARTTLS MUST be configurable to - refuse all clear-text login commands or mechanisms (including both - standards-track and nonstandard mechanisms) unless an encryption - layer of adequate strength is active. Servers which allow - unencrypted clear-text logins SHOULD be configurable to refuse - clear-text logins both for the entire server, and on a per-user - basis. - -2.4. Server Identity Check - - During the TLS negotiation, the client MUST check its understanding - of the server hostname against the server's identity as presented in - the server Certificate message, in order to prevent man-in-the-middle - attacks. Matching is performed according to these rules: - - - The client MUST use the server hostname it used to open the - connection as the value to compare against the server name as - expressed in the server certificate. The client MUST NOT use any - form of the server hostname derived from an insecure remote source - (e.g., insecure DNS lookup). CNAME canonicalization is not done. - - - If a subjectAltName extension of type dNSName is present in the - certificate, it SHOULD be used as the source of the server's - identity. - - - Matching is case-insensitive. - - - A "*" wildcard character MAY be used as the left-most name - component in the certificate. For example, *.example.com would - match a.example.com, foo.example.com, etc. but would not match - example.com. - - - If the certificate contains multiple names (e.g. more than one - dNSName field), then a match with any one of the fields is - considered acceptable. - - If the match fails, the client SHOULD either ask for explicit user - confirmation, or terminate the connection and indicate the server's - identity is suspect. - - - -Newman Standards Track [Page 3] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - -2.5. TLS Security Policy Check - - Both the client and server MUST check the result of the STARTTLS - command and subsequent TLS negotiation to see whether acceptable - authentication or privacy was achieved. Ignoring this step - completely invalidates using TLS for security. The decision about - whether acceptable authentication or privacy was achieved is made - locally, is implementation-dependent, and is beyond the scope of this - document. - -3. IMAP STARTTLS extension - - When the TLS extension is present in IMAP, "STARTTLS" is listed as a - capability in response to the CAPABILITY command. This extension - adds a single command, "STARTTLS" to the IMAP protocol which is used - to begin a TLS negotiation. - -3.1. STARTTLS Command - - Arguments: none - - Responses: no specific responses for this command - - Result: OK - begin TLS negotiation - BAD - command unknown or arguments invalid - - A TLS negotiation begins immediately after the CRLF at the end of - the tagged OK response from the server. Once a client issues a - STARTTLS command, it MUST NOT issue further commands until a - server response is seen and the TLS negotiation is complete. - - The STARTTLS command is only valid in non-authenticated state. - The server remains in non-authenticated state, even if client - credentials are supplied during the TLS negotiation. The SASL - [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS - client credentials are successfully exchanged, but servers - supporting the STARTTLS command are not required to support the - EXTERNAL mechanism. - - Once TLS has been started, the client MUST discard cached - information about server capabilities and SHOULD re-issue the - CAPABILITY command. This is necessary to protect against - man-in-the-middle attacks which alter the capabilities list prior - to STARTTLS. The server MAY advertise different capabilities - after STARTTLS. - - The formal syntax for IMAP is amended as follows: - - - - -Newman Standards Track [Page 4] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - - command_any =/ "STARTTLS" - - Example: C: a001 CAPABILITY - S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED - S: a001 OK CAPABILITY completed - C: a002 STARTTLS - S: a002 OK Begin TLS negotiation now - - C: a003 CAPABILITY - S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL - S: a003 OK CAPABILITY completed - C: a004 LOGIN joe password - S: a004 OK LOGIN completed - -3.2. IMAP LOGINDISABLED capability - - The current IMAP protocol specification (RFC 2060) requires the - implementation of the LOGIN command which uses clear-text passwords. - Many sites may choose to disable this command unless encryption is - active for security reasons. An IMAP server MAY advertise that the - LOGIN command is disabled by including the LOGINDISABLED capability - in the capability response. Such a server will respond with a tagged - "NO" response to any attempt to use the LOGIN command. - - An IMAP server which implements STARTTLS MUST implement support for - the LOGINDISABLED capability on unencrypted connections. - - An IMAP client which complies with this specification MUST NOT issue - the LOGIN command if this capability is present. - - This capability is useful to prevent clients compliant with this - specification from sending an unencrypted password in an environment - subject to passive attacks. It has no impact on an environment - subject to active attacks as a man-in-the-middle attacker can remove - this capability. Therefore this does not relieve clients of the need - to follow the privacy mode recommendation in section 2.2. - - Servers advertising this capability will fail to interoperate with - many existing compliant IMAP clients and will be unable to prevent - those clients from disclosing the user's password. - -4. POP3 STARTTLS extension - - The POP3 STARTTLS extension adds the STLS command to POP3 servers. - If this is implemented, the POP3 extension mechanism [POP3EXT] MUST - also be implemented to avoid the need for client probing of multiple - commands. The capability name "STLS" indicates this command is - present and permitted in the current state. - - - -Newman Standards Track [Page 5] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - - STLS - - Arguments: none - - Restrictions: - Only permitted in AUTHORIZATION state. - - Discussion: - A TLS negotiation begins immediately after the CRLF at the - end of the +OK response from the server. A -ERR response - MAY result if a security layer is already active. Once a - client issues a STLS command, it MUST NOT issue further - commands until a server response is seen and the TLS - negotiation is complete. - - The STLS command is only permitted in AUTHORIZATION state - and the server remains in AUTHORIZATION state, even if - client credentials are supplied during the TLS negotiation. - The AUTH command [POP-AUTH] with the EXTERNAL mechanism - [SASL] MAY be used to authenticate once TLS client - credentials are successfully exchanged, but servers - supporting the STLS command are not required to support the - EXTERNAL mechanism. - - Once TLS has been started, the client MUST discard cached - information about server capabilities and SHOULD re-issue - the CAPA command. This is necessary to protect against - man-in-the-middle attacks which alter the capabilities list - prior to STLS. The server MAY advertise different - capabilities after STLS. - - Possible Responses: - +OK -ERR - - Examples: - C: STLS - S: +OK Begin TLS negotiation - - ... - C: STLS - S: -ERR Command not permitted when TLS active - - - - - - - - - - -Newman Standards Track [Page 6] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - -5. ACAP STARTTLS extension - - When the TLS extension is present in ACAP, "STARTTLS" is listed as a - capability in the ACAP greeting. No arguments to this capability are - defined at this time. This extension adds a single command, - "STARTTLS" to the ACAP protocol which is used to begin a TLS - negotiation. - -5.1. STARTTLS Command - - Arguments: none - - Responses: no specific responses for this command - - Result: OK - begin TLS negotiation - BAD - command unknown or arguments invalid - - A TLS negotiation begins immediately after the CRLF at the end of - the tagged OK response from the server. Once a client issues a - STARTTLS command, it MUST NOT issue further commands until a - server response is seen and the TLS negotiation is complete. - - The STARTTLS command is only valid in non-authenticated state. - The server remains in non-authenticated state, even if client - credentials are supplied during the TLS negotiation. The SASL - [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS - client credentials are successfully exchanged, but servers - supporting the STARTTLS command are not required to support the - EXTERNAL mechanism. - - After the TLS layer is established, the server MUST re-issue an - untagged ACAP greeting. This is necessary to protect against - man-in-the-middle attacks which alter the capabilities list prior - to STARTTLS. The client MUST discard cached capability - information and replace it with the information from the new ACAP - greeting. The server MAY advertise different capabilities after - STARTTLS. - - The formal syntax for ACAP is amended as follows: - - command_any =/ "STARTTLS" - - Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) - C: a002 STARTTLS - S: a002 OK "Begin TLS negotiation now" - - S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") - - - - -Newman Standards Track [Page 7] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - -6. PLAIN SASL mechanism - - Clear-text passwords are simple, interoperate with almost all - existing operating system authentication databases, and are useful - for a smooth transition to a more secure password-based - authentication mechanism. The drawback is that they are unacceptable - for use over an unencrypted network connection. - - This defines the "PLAIN" SASL mechanism for use with ACAP and other - protocols with no clear-text login command. The PLAIN SASL mechanism - MUST NOT be advertised or used unless a strong encryption layer (such - as the provided by TLS) is active or backwards compatibility dictates - otherwise. - - The mechanism consists of a single message from the client to the - server. The client sends the authorization identity (identity to - login as), followed by a US-ASCII NUL character, followed by the - authentication identity (identity whose password will be used), - followed by a US-ASCII NUL character, followed by the clear-text - password. The client may leave the authorization identity empty to - indicate that it is the same as the authentication identity. - - The server will verify the authentication identity and password with - the system authentication database and verify that the authentication - credentials permit the client to login as the authorization identity. - If both steps succeed, the user is logged in. - - The server MAY also use the password to initialize any new - authentication database, such as one suitable for CRAM-MD5 - [CRAM-MD5]. - - Non-US-ASCII characters are permitted as long as they are represented - in UTF-8 [UTF-8]. Use of non-visible characters or characters which - a user may be unable to enter on some keyboards is discouraged. - - The formal grammar for the client message using Augmented BNF [ABNF] - follows. - - message = [authorize-id] NUL authenticate-id NUL password - authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets - authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets - password = 1*UTF8-SAFE ; MUST accept up to 255 octets - NUL = %x00 - UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / - UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 - UTF8-1 = %x80-BF - UTF8-2 = %xC0-DF UTF8-1 - UTF8-3 = %xE0-EF 2UTF8-1 - - - -Newman Standards Track [Page 8] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - - UTF8-4 = %xF0-F7 3UTF8-1 - UTF8-5 = %xF8-FB 4UTF8-1 - UTF8-6 = %xFC-FD 5UTF8-1 - - Here is an example of how this might be used to initialize a CRAM-MD5 - authentication database for ACAP: - - Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) - C: a001 AUTHENTICATE "CRAM-MD5" - S: + "<1896.697170952@postoffice.reston.mci.net>" - C: "tim b913a602c7eda7a495b4e6e7334d3890" - S: a001 NO (TRANSITION-NEEDED) - "Please change your password, or use TLS to login" - C: a002 STARTTLS - S: a002 OK "Begin TLS negotiation now" - - S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") - C: a003 AUTHENTICATE "PLAIN" {21+} - C: timtanstaaftanstaaf - S: a003 OK CRAM-MD5 password initialized - - Note: In this example, represents a single ASCII NUL octet. - -7. imaps and pop3s ports - - Separate "imaps" and "pop3s" ports were registered for use with SSL. - Use of these ports is discouraged in favor of the STARTTLS or STLS - commands. - - A number of problems have been observed with separate ports for - "secure" variants of protocols. This is an attempt to enumerate some - of those problems. - - - Separate ports lead to a separate URL scheme which intrudes into - the user interface in inappropriate ways. For example, many web - pages use language like "click here if your browser supports SSL." - This is a decision the browser is often more capable of making than - the user. - - - Separate ports imply a model of either "secure" or "not secure." - This can be misleading in a number of ways. First, the "secure" - port may not in fact be acceptably secure as an export-crippled - cipher suite might be in use. This can mislead users into a false - sense of security. Second, the normal port might in fact be - secured by using a SASL mechanism which includes a security layer. - Thus the separate port distinction makes the complex topic of - security policy even more confusing. One common result of this - confusion is that firewall administrators are often misled into - - - -Newman Standards Track [Page 9] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - - permitting the "secure" port and blocking the standard port. This - could be a poor choice given the common use of SSL with a 40-bit - key encryption layer and plain-text password authentication is less - secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. - - - Use of separate ports for SSL has caused clients to implement only - two security policies: use SSL or don't use SSL. The desirable - security policy "use TLS when available" would be cumbersome with - the separate port model, but is simple with STARTTLS. - - - Port numbers are a limited resource. While they are not yet in - short supply, it is unwise to set a precedent that could double (or - worse) the speed of their consumption. - - -8. IANA Considerations - - This constitutes registration of the "STARTTLS" and "LOGINDISABLED" - IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP]. - - The registration for the POP3 "STLS" capability follows: - - CAPA tag: STLS - Arguments: none - Added commands: STLS - Standard commands affected: May enable USER/PASS as a side-effect. - CAPA command SHOULD be re-issued after successful completion. - Announced states/Valid states: AUTHORIZATION state only. - Specification reference: this memo - - The registration for the ACAP "STARTTLS" capability follows: - - Capability name: STARTTLS - Capability keyword: STARTTLS - Capability arguments: none - Published Specification(s): this memo - Person and email address for further information: - see author's address section below - - The registration for the PLAIN SASL mechanism follows: - - SASL mechanism name: PLAIN - Security Considerations: See section 9 of this memo - Published specification: this memo - Person & email address to contact for further information: - see author's address section below - Intended usage: COMMON - Author/Change controller: see author's address section below - - - -Newman Standards Track [Page 10] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - -9. Security Considerations - - TLS only provides protection for data sent over a network connection. - Messages transferred over IMAP or POP3 are still available to server - administrators and usually subject to eavesdropping, tampering and - forgery when transmitted through SMTP or NNTP. TLS is no substitute - for an end-to-end message security mechanism using MIME security - multiparts [MIME-SEC]. - - A man-in-the-middle attacker can remove STARTTLS from the capability - list or generate a failure response to the STARTTLS command. In - order to detect such an attack, clients SHOULD warn the user when - session privacy is not active and/or be configurable to refuse to - proceed without an acceptable level of security. - - A man-in-the-middle attacker can always cause a down-negotiation to - the weakest authentication mechanism or cipher suite available. For - this reason, implementations SHOULD be configurable to refuse weak - mechanisms or cipher suites. - - Any protocol interactions prior to the TLS handshake are performed in - the clear and can be modified by a man-in-the-middle attacker. For - this reason, clients MUST discard cached information about server - capabilities advertised prior to the start of the TLS handshake. - - Clients are encouraged to clearly indicate when the level of - encryption active is known to be vulnerable to attack using modern - hardware (such as encryption keys with 56 bits of entropy or less). - - The LOGINDISABLED IMAP capability (discussed in section 3.2) only - reduces the potential for passive attacks, it provides no protection - against active attacks. The responsibility remains with the client - to avoid sending a password over a vulnerable channel. - - The PLAIN mechanism relies on the TLS encryption layer for security. - When used without TLS, it is vulnerable to a common network - eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used - unless a suitable TLS encryption layer is active or backwards - compatibility dictates otherwise. - - When the PLAIN mechanism is used, the server gains the ability to - impersonate the user to all services with the same password - regardless of any encryption provided by TLS or other network privacy - mechanisms. While many other authentication mechanisms have similar - weaknesses, stronger SASL mechanisms such as Kerberos address this - issue. Clients are encouraged to have an operational mode where all - mechanisms which are likely to reveal the user's password to the - server are disabled. - - - -Newman Standards Track [Page 11] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - - The security considerations for TLS apply to STARTTLS and the - security considerations for SASL apply to the PLAIN mechanism. - Additional security requirements are discussed in section 2. - -10. References - - [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [ACAP] Newman, C. and J. Myers, "ACAP -- Application - Configuration Access Protocol", RFC 2244, November 1997. - - [AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", - RFC 1704, October 1994. - - [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP - AUTHorize Extension for Simple Challenge/Response", RFC - 2195, September 1997. - - [IMAP] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, December 1996. - - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed, - "Security Multiparts for MIME: Multipart/Signed and - Multipart/Encrypted", RFC 1847, October 1995. - - [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", - STD 53, RFC 1939, May 1996. - - [POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension - Mechanism", RFC 2449, November 1998. - - [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, - December 1994. - - [SASL] Myers, J., "Simple Authentication and Security Layer - (SASL)", RFC 2222, October 1997. - - [SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over - TLS", RFC 2487, January 1999. - - [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", - RFC 2246, January 1999. - - - - - -Newman Standards Track [Page 12] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - - [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", RFC 2279, January 1998. - - -11. Author's Address - - Chris Newman - Innosoft International, Inc. - 1050 Lakes Drive - West Covina, CA 91790 USA - - EMail: chris.newman@innosoft.com - - -A. Appendix -- Compliance Checklist - - An implementation is not compliant if it fails to satisfy one or more - of the MUST requirements for the protocols it implements. An - implementation that satisfies all the MUST and all the SHOULD - requirements for its protocols is said to be "unconditionally - compliant"; one that satisfies all the MUST requirements but not all - the SHOULD requirements for its protocols is said to be - "conditionally compliant". - - Rules Section - ----- ------- - Mandatory-to-implement Cipher Suite 2.1 - SHOULD have mode where encryption required 2.2 - server SHOULD have mode where TLS not required 2.2 - MUST be configurable to refuse all clear-text login - commands or mechanisms 2.3 - server SHOULD be configurable to refuse clear-text - login commands on entire server and on per-user basis 2.3 - client MUST check server identity 2.4 - client MUST use hostname used to open connection 2.4 - client MUST NOT use hostname from insecure remote lookup 2.4 - client SHOULD support subjectAltName of dNSName type 2.4 - client SHOULD ask for confirmation or terminate on fail 2.4 - MUST check result of STARTTLS for acceptable privacy 2.5 - client MUST NOT issue commands after STARTTLS - until server response and negotiation done 3.1,4,5.1 - client MUST discard cached information 3.1,4,5.1,9 - client SHOULD re-issue CAPABILITY/CAPA command 3.1,4 - IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2 - IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2 - POP server MUST implement POP3 extensions 4 - ACAP server MUST re-issue ACAP greeting 5.1 - - - - -Newman Standards Track [Page 13] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - - client SHOULD warn when session privacy not active and/or - refuse to proceed without acceptable security level 9 - SHOULD be configurable to refuse weak mechanisms or - cipher suites 9 - - The PLAIN mechanism is an optional part of this specification. - However if it is implemented the following rules apply: - - Rules Section - ----- ------- - MUST NOT use PLAIN unless strong encryption active - or backwards compatibility dictates otherwise 6,9 - MUST use UTF-8 encoding for characters in PLAIN 6 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Newman Standards Track [Page 14] - -RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Newman Standards Track [Page 15] - diff --git a/server/src/site/resources/rfclist/imap4/rfc2683.txt b/server/src/site/resources/rfclist/imap4/rfc2683.txt deleted file mode 100644 index d92e3405651..00000000000 --- a/server/src/site/resources/rfclist/imap4/rfc2683.txt +++ /dev/null @@ -1,1291 +0,0 @@ - - - - - - -Network Working Group B. Leiba -Request for Comments: 2683 IBM T.J. Watson Research Center -Category: Informational September 1999 - - - IMAP4 Implementation Recommendations - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -1. Abstract - - The IMAP4 specification [RFC-2060] describes a rich protocol for use - in building clients and servers for storage, retrieval, and - manipulation of electronic mail. Because the protocol is so rich and - has so many implementation choices, there are often trade-offs that - must be made and issues that must be considered when designing such - clients and servers. This document attempts to outline these issues - and to make recommendations in order to make the end products as - interoperable as possible. - -2. Conventions used in this document - - In examples, "C:" indicates lines sent by a client that is connected - to a server. "S:" indicates lines sent by the server to the client. - - The words "must", "must not", "should", "should not", and "may" are - used with specific meaning in this document; since their meaning is - somewhat different from that specified in RFC 2119, we do not put - them in all caps here. Their meaning is as follows: - - must -- This word means that the action described is necessary - to ensure interoperability. The recommendation should - not be ignored. - must not -- This phrase means that the action described will be - almost certain to hurt interoperability. The - recommendation should not be ignored. - - - - - - - -Leiba Informational [Page 1] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - should -- This word means that the action described is strongly - recommended and will enhance interoperability or - usability. The recommendation should not be ignored - without careful consideration. - should not -- This phrase means that the action described is strongly - recommended against, and might hurt interoperability or - usability. The recommendation should not be ignored - without careful consideration. - may -- This word means that the action described is an - acceptable implementation choice. No specific - recommendation is implied; this word is used to point - out a choice that might not be obvious, or to let - implementors know what choices have been made by - existing implementations. - -3. Interoperability Issues and Recommendations - -3.1. Accessibility - - This section describes the issues related to access to servers and - server resources. Concerns here include data sharing and maintenance - of client/server connections. - -3.1.1. Multiple Accesses of the Same Mailbox - - One strong point of IMAP4 is that, unlike POP3, it allows for - multiple simultaneous access to a single mailbox. A user can, thus, - read mail from a client at home while the client in the office is - still connected; or the help desk staff can all work out of the same - inbox, all seeing the same pool of questions. An important point - about this capability, though is that NO SERVER IS GUARANTEED TO - SUPPORT THIS. If you are selecting an IMAP server and this facility - is important to you, be sure that the server you choose to install, - in the configuration you choose to use, supports it. - - If you are designing a client, you must not assume that you can - access the same mailbox more than once at a time. That means - - 1. you must handle gracefully the failure of a SELECT command if the - server refuses the second SELECT, - 2. you must handle reasonably the severing of your connection (see - "Severed Connections", below) if the server chooses to allow the - second SELECT by forcing the first off, - 3. you must avoid making multiple connections to the same mailbox in - your own client (for load balancing or other such reasons), and - 4. you must avoid using the STATUS command on a mailbox that you have - selected (with some server implementations the STATUS command has - the same problems with multiple access as do the SELECT and - - - -Leiba Informational [Page 2] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - EXAMINE commands). - - A further note about STATUS: The STATUS command is sometimes used to - check a non-selected mailbox for new mail. This mechanism must not - be used to check for new mail in the selected mailbox; section 5.2 of - [RFC-2060] specifically forbids this in its last paragraph. Further, - since STATUS takes a mailbox name it is an independent operation, not - operating on the selected mailbox. Because of this, the information - it returns is not necessarily in synchronization with the selected - mailbox state. - -3.1.2. Severed Connections - - The client/server connection may be severed for one of three reasons: - the client severs the connection, the server severs the connection, - or the connection is severed by outside forces beyond the control of - the client and the server (a telephone line drops, for example). - Clients and servers must both deal with these situations. - - When the client wants to sever a connection, it's usually because it - has finished the work it needed to do on that connection. The client - should send a LOGOUT command, wait for the tagged response, and then - close the socket. But note that, while this is what's intended in - the protocol design, there isn't universal agreement here. Some - contend that sending the LOGOUT and waiting for the two responses - (untagged BYE and tagged OK) is wasteful and unnecessary, and that - the client can simply close the socket. The server should interpret - the closed socket as a log out by the client. The counterargument is - that it's useful from the standpoint of cleanup, problem - determination, and the like, to have an explicit client log out, - because otherwise there is no way for the server to tell the - difference between "closed socket because of log out" and "closed - socket because communication was disrupted". If there is a - client/server interaction problem, a client which routinely - terminates a session by breaking the connection without a LOGOUT will - make it much more difficult to determine the problem. - - Because of this disagreement, server designers must be aware that - some clients might close the socket without sending a LOGOUT. In any - case, whether or not a LOGOUT was sent, the server should not - implicitly expunge any messages from the selected mailbox. If a - client wants the server to do so, it must send a CLOSE or EXPUNGE - command explicitly. - - When the server wants to sever a connection it's usually due to an - inactivity timeout or is because a situation has arisen that has - changed the state of the mail store in a way that the server can not - communicate to the client. The server should send an untagged BYE - - - -Leiba Informational [Page 3] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - response to the client and then close the socket. Sending an - untagged BYE response before severing allows the server to send a - human-readable explanation of the problem to the client, which the - client may then log, display to the user, or both (see section 7.1.5 - of [RFC-2060]). - - Regarding inactivity timeouts, there is some controversy. Unlike - POP, for which the design is for a client to connect, retrieve mail, - and log out, IMAP's design encourages long-lived (and mostly - inactive) client/server sessions. As the number of users grows, this - can use up a lot of server resources, especially with clients that - are designed to maintain sessions for mailboxes that the user has - finished accessing. To alleviate this, a server may implement an - inactivity timeout, unilaterally closing a session (after first - sending an untagged BYE, as noted above). Some server operators have - reported dramatic improvements in server performance after doing - this. As specified in [RFC-2060], if such a timeout is done it must - not be until at least 30 minutes of inactivity. The reason for this - specification is to prevent clients from sending commands (such as - NOOP) to the server at frequent intervals simply to avert a too-early - timeout. If the client knows that the server may not time out the - session for at least 30 minutes, then the client need not poll at - intervals more frequent than, say, 25 minutes. - -3.2. Scaling - - IMAP4 has many features that allow for scalability, as mail stores - become larger and more numerous. Large numbers of users, mailboxes, - and messages, and very large messages require thought to handle - efficiently. This document will not address the administrative - issues involved in large numbers of users, but we will look at the - other items. - -3.2.1. Flood Control - - There are three situations when a client can make a request that will - result in a very large response - too large for the client reasonably - to deal with: there are a great many mailboxes available, there are a - great many messages in the selected mailbox, or there is a very large - message part. The danger here is that the end user will be stuck - waiting while the server sends (and the client processes) an enormous - response. In all of these cases there are things a client can do to - reduce that danger. - - There is also the case where a client can flood a server, by sending - an arbitratily long command. We'll discuss that issue, too, in this - section. - - - - -Leiba Informational [Page 4] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - -3.2.1.1. Listing Mailboxes - - Some servers present Usenet newsgroups to IMAP users. Newsgroups, - and other such hierarchical mailbox structures, can be very numerous - but may have only a few entries at the top level of hierarchy. Also, - some servers are built against mail stores that can, unbeknownst to - the server, have circular hierarchies - that is, it's possible for - "a/b/c/d" to resolve to the same file structure as "a", which would - then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy - will never end. The LIST response in this case will be unlimited. - - Clients that will have trouble with this are those that use - - C: 001 LIST "" * - - to determine the mailbox list. Because of this, clients should not - use an unqualified "*" that way in the LIST command. A safer - approach is to list each level of hierarchy individually, allowing - the user to traverse the tree one limb at a time, thus: - - C: 001 LIST "" % - S: * LIST () "/" Banana - S: * LIST ...etc... - S: 001 OK done - - and then - - C: 002 LIST "" Banana/% - S: * LIST () "/" Banana/Apple - S: * LIST ...etc... - S: 002 OK done - - Using this technique the client's user interface can give the user - full flexibility without choking on the voluminous reply to "LIST *". - - Of course, it is still possible that the reply to - - C: 005 LIST "" alt.fan.celebrity.% - - may be thousands of entries long, and there is, unfortunately, - nothing the client can do to protect itself from that. This has not - yet been a notable problem. - - Servers that may export circular hierarchies (any server that - directly presents a UNIX file system, for instance) should limit the - hierarchy depth to prevent unlimited LIST responses. A suggested - depth limit is 20 hierarchy levels. - - - - -Leiba Informational [Page 5] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - -3.2.1.2. Fetching the List of Messages - - When a client selects a mailbox, it is given a count, in the untagged - EXISTS response, of the messages in the mailbox. This number can be - very large. In such a case it might be unwise to use - - C: 004 FETCH 1:* ALL - - to populate the user's view of the mailbox. One good method to avoid - problems with this is to batch the requests, thus: - - C: 004 FETCH 1:50 ALL - S: * 1 FETCH ...etc... - S: 004 OK done - C: 005 FETCH 51:100 ALL - S: * 51 FETCH ...etc... - S: 005 OK done - C: 006 FETCH 101:150 ALL - ...etc... - - Using this method, another command, such as "FETCH 6 BODY[1]" can be - inserted as necessary, and the client will not have its access to the - server blocked by a storm of FETCH replies. (Such a method could be - reversed to fetch the LAST 50 messages first, then the 50 prior to - that, and so on.) - - As a smart extension of this, a well designed client, prepared for - very large mailboxes, will not automatically fetch data for all - messages AT ALL. Rather, the client will populate the user's view - only as the user sees it, possibly pre-fetching selected information, - and only fetching other information as the user scrolls to it. For - example, to select only those messages beginning with the first - unseen one: - - C: 003 SELECT INBOX - S: * 10000 EXISTS - S: * 80 RECENT - S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) - S: * OK [UIDVALIDITY 824708485] UID validity status - S: * OK [UNSEEN 9921] First unseen message - S: 003 OK [READ-WRITE] SELECT completed - C: 004 FETCH 9921:* ALL - ... etc... - - If the server does not return an OK [UNSEEN] response, the client may - use SEARCH UNSEEN to obtain that value. - - - - - -Leiba Informational [Page 6] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - This mechanism is good as a default presentation method, but only - works well if the default message order is acceptable. A client may - want to present various sort orders to the user (by subject, by date - sent, by sender, and so on) and in that case (lacking a SORT - extension on the server side) the client WILL have to retrieve all - message descriptors. A client that provides this service should not - do it by default and should inform the user of the costs of choosing - this option for large mailboxes. - -3.2.1.3. Fetching a Large Body Part - - The issue here is similar to the one for a list of messages. In the - BODYSTRUCTURE response the client knows the size, in bytes, of the - body part it plans to fetch. Suppose this is a 70 MB video clip. The - client can use partial fetches to retrieve the body part in pieces, - avoiding the problem of an uninterruptible 70 MB literal coming back - from the server: - - C: 022 FETCH 3 BODY[1]<0.20000> - S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000} - S: ...data...) - S: 022 OK done - C: 023 FETCH 3 BODY[1]<20001.20000> - S: * 3 FETCH (BODY[1]<20001> {20000} - S: ...data...) - S: 023 OK done - C: 024 FETCH 3 BODY[1]<40001.20000> - ...etc... - -3.2.1.4. BODYSTRUCTURE vs. Entire Messages - - Because FETCH BODYSTRUCTURE is necessary in order to determine the - number of body parts, and, thus, whether a message has "attachments", - clients often use FETCH FULL as their normal method of populating the - user's view of a mailbox. The benefit is that the client can display - a paperclip icon or some such indication along with the normal - message summary. However, this comes at a significant cost with some - server configurations. The parsing needed to generate the FETCH - BODYSTRUCTURE response may be time-consuming compared with that - needed for FETCH ENVELOPE. The client developer should consider this - issue when deciding whether the ability to add a paperclip icon is - worth the tradeoff in performance, especially with large mailboxes. - - Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[] - (or the equivalent FETCH RFC822) to retrieve the entire message. - They then do the MIME parsing in the client. This may give the - client slightly more flexibility in some areas (access, for instance, - to header fields that aren't returned in the BODYSTRUCTURE and - - - -Leiba Informational [Page 7] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - ENVELOPE responses), but it can cause severe performance problems by - forcing the transfer of all body parts when the user might only want - to see some of them - a user logged on by modem and reading a small - text message with a large ZIP file attached may prefer to read the - text only and save the ZIP file for later. Therefore, a client - should not normally retrieve entire messages and should retrieve - message body parts selectively. - -3.2.1.5. Long Command Lines - - A client can wind up building a very long command line in an effort to - try to be efficient about requesting information from a server. This - can typically happen when a client builds a message set from selected - messages and doesn't recognise that contiguous blocks of messages may - be group in a range. Suppose a user selects all 10,000 messages in a - large mailbox and then unselects message 287. The client could build - that message set as "1:286,288:10000", but a client that doesn't - handle that might try to enumerate each message individually and build - "1,2,3,4, [and so on] ,9999,10000". Adding that to the fetch command - results in a command line that's almost 49,000 octets long, and, - clearly, one can construct a command line that's even longer. - - A client should limit the length of the command lines it generates to - approximately 1000 octets (including all quoted strings but not - including literals). If the client is unable to group things into - ranges so that the command line is within that length, it should - split the request into multiple commands. The client should use - literals instead of long quoted strings, in order to keep the command - length down. - - For its part, a server should allow for a command line of at least - 8000 octets. This provides plenty of leeway for accepting reasonable - length commands from clients. The server should send a BAD response - to a command that does not end within the server's maximum accepted - command length. - -3.2.2. Subscriptions - - The client isn't the only entity that can get flooded: the end user, - too, may need some flood control. The IMAP4 protocol provides such - control in the form of subscriptions. Most servers support the - SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to - narrow down a large list of available mailboxes by subscribing to the - ones that they usually want to see. Clients, with this in mind, - should give the user a way to see only subscribed mailboxes. A - client that never uses the LSUB command takes a significant usability - feature away from the user. Of course, the client would not want to - hide the LIST command completely; the user needs to have a way to - - - -Leiba Informational [Page 8] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - choose between LIST and LSUB. The usual way to do this is to provide - a setting like "show which mailboxes?: [] all [] subscribed only". - -3.2.3. Searching - - IMAP SEARCH commands can become particularly troublesome (that is, - slow) on mailboxes containing a large number of messages. So let's - put a few things in perspective in that regard. - - The flag searches should be fast. The flag searches (ALL, [UN]SEEN, - [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT) - are known to be used by clients for the client's own use (for - instance, some clients use "SEARCH UNSEEN" to find unseen mail and - "SEARCH DELETED" to warn the user before expunging messages). - - Other searches, particularly the text searches (HEADER, TEXT, BODY) - are initiated by the user, rather than by the client itself, and - somewhat slower performance can be tolerated, since the user is aware - that the search is being done (and is probably aware that it might be - time-consuming). A smart server might use dynamic indexing to speed - commonly used text searches. - - The client may allow other commands to be sent to the server while a - SEARCH is in progress, but at the time of this writing there is - little or no server support for parallel processing of multiple - commands in the same session (and see "Multiple Accesses of the Same - Mailbox" above for a description of the dangers of trying to work - around this by doing your SEARCH in another session). - - Another word about text searches: some servers, built on database - back-ends with indexed search capabilities, may return search results - that do not match the IMAP spec's "case-insensitive substring" - requirements. While these servers are in violation of the protocol, - there is little harm in the violation as long as the search results - are used only in response to a user's request. Still, developers of - such servers should be aware that they ARE violating the protocol, - should think carefully about that behaviour, and must be certain that - their servers respond accurately to the flag searches for the reasons - outlined above. - - In addition, servers should support CHARSET UTF-8 [UTF-8] in - searches. - - - - - - - - - -Leiba Informational [Page 9] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - -3.3 Avoiding Invalid Requests - - IMAP4 provides ways for a server to tell a client in advance what is - and isn't permitted in some circumstances. Clients should use these - features to avoid sending requests that a well designed client would - know to be invalid. This section explains this in more detail. - -3.3.1. The CAPABILITY Command - - All IMAP4 clients should use the CAPABILITY command to determine what - version of IMAP and what optional features a server supports. The - client should not send IMAP4rev1 commands and arguments to a server - that does not advertize IMAP4rev1 in its CAPABILITY response. - Similarly, the client should not send IMAP4 commands that no longer - exist in IMAP4rev1 to a server that does not advertize IMAP4 in its - CAPABILITY response. An IMAP4rev1 server is NOT required to support - obsolete IMAP4 or IMAP2bis commands (though some do; do not let this - fact lull you into thinking that it's valid to send such commands to - an IMAP4rev1 server). - - A client should not send commands to probe for the existance of - certain extensions. All standard and standards-track extensions - include CAPABILITY tokens indicating their presense. All private and - experimental extensions should do the same, and clients that take - advantage of them should use the CAPABILITY response to determine - whether they may be used or not. - -3.3.2. Don't Do What the Server Says You Can't - - In many cases, the server, in response to a command, will tell the - client something about what can and can't be done with a particular - mailbox. The client should pay attention to this information and - should not try to do things that it's been told it can't do. - - Examples: - - * Do not try to SELECT a mailbox that has the \Noselect flag set. - * Do not try to CREATE a sub-mailbox in a mailbox that has the - \Noinferiors flag set. - * Do not respond to a failing COPY or APPEND command by trying to - CREATE the target mailbox if the server does not respond with a - [TRYCREATE] response code. - * Do not try to expunge a mailbox that has been selected with the - [READ-ONLY] response code. - - - - - - - -Leiba Informational [Page 10] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - -3.4. Miscellaneous Protocol Considerations - - We describe here a number of important protocol-related issues, the - misunderstanding of which has caused significant interoperability - problems in IMAP4 implementations. One general item is that every - implementer should be certain to take note of and to understand - section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec - [RFC-2060]. - -3.4.1. Well Formed Protocol - - We cannot stress enough the importance of adhering strictly to the - protocol grammar. The specification of the protocol is quite rigid; - do not assume that you can insert blank space for "readability" if - none is called for. Keep in mind that there are parsers out there - that will crash if there are protocol errors. There are clients that - will report every parser burp to the user. And in any case, - information that cannot be parsed is information that is lost. Be - careful in your protocol generation. And see "A Word About Testing", - below. - - In particular, note that the string in the INTERNALDATE response is - NOT an RFC-822 date string - that is, it is not in the same format as - the first string in the ENVELOPE response. Since most clients will, - in fact, accept an RFC-822 date string in the INTERNALDATE response, - it's easy to miss this in your interoperability testing. But it will - cause a problem with some client, so be sure to generate the correct - string for this field. - -3.4.2. Special Characters - - Certain characters, currently the double-quote and the backslash, may - not be sent as-is inside a quoted string. These characters must be - preceded by the escape character if they are in a quoted string, or - else the string must be sent as a literal. Both clients and servers - must handle this, both on output (they must send these characters - properly) and on input (they must be able to receive escaped - characters in quoted strings). Example: - - C: 001 LIST "" % - S: * LIST () "" INBOX - S: * LIST () "\\" TEST - S: * LIST () "\\" {12} - S: "My" mailbox - S: 001 OK done - C: 002 LIST "" "\"My\" mailbox\\%" - S: * LIST () "\\" {17} - S: "My" mailbox\Junk - - - -Leiba Informational [Page 11] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - S: 002 OK done - - Note that in the example the server sent the hierarchy delimiter as - an escaped character in the quoted string and sent the mailbox name - containing imbedded double-quotes as a literal. The client used only - quoted strings, escaping both the backslash and the double-quote - characters. - - The CR and LF characters may be sent ONLY in literals; they are not - allowed, even if escaped, inside quoted strings. - - And while we're talking about special characters: the IMAP spec, in - the section titled "Mailbox International Naming Convention", - describes how to encode mailbox names in modified UTF-7 [UTF-7 and - RFC-2060]. Implementations must adhere to this in order to be - interoperable in the international market, and servers should - validate mailbox names sent by client and reject names that do not - conform. - - As to special characters in userids and passwords: clients must not - restrict what a user may type in for a userid or a password. The - formal grammar specifies that these are "astrings", and an astring - can be a literal. A literal, in turn can contain any 8-bit - character, and clients must allow users to enter all 8-bit characters - here, and must pass them, unchanged, to the server (being careful to - send them as literals when necessary). In particular, some server - configurations use "@" in user names, and some clients do not allow - that character to be entered; this creates a severe interoperability - problem. - -3.4.3. UIDs and UIDVALIDITY - - Servers that support existing back-end mail stores often have no good - place to save UIDs for messages. Often the existing mail store will - not have the concept of UIDs in the sense that IMAP has: strictly - increasing, never re-issued, 32-bit integers. Some servers solve - this by storing the UIDs in a place that's accessible to end users, - allowing for the possibility that the users will delete them. Others - solve it by re-assigning UIDs every time a mailbox is selected. - - The server should maintain UIDs permanently for all messages if it - can. If that's not possible, the server must change the UIDVALIDITY - value for the mailbox whenever any of the UIDs may have become - invalid. Clients must recognize that the UIDVALIDITY has changed and - must respond to that condition by throwing away any information that - they have saved about UIDs in that mailbox. There have been many - problems in this area when clients have failed to do this; in the - worst case it will result in loss of mail when a client deletes the - - - -Leiba Informational [Page 12] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - wrong piece of mail by using a stale UID. - - It seems to be a common misunderstanding that "the UIDVALIDITY and - the UID, taken together, form a 64-bit identifier that uniquely - identifies a message on a server". This is absolutely NOT TRUE. - There is no assurance that the UIDVALIDITY values of two mailboxes be - different, so the UIDVALIDITY in no way identifies a mailbox. The - ONLY purpose of UIDVALIDITY is, as its name indicates, to give the - client a way to check the validity of the UIDs it has cached. While - it is a valid implementation choice to put these values together to - make a 64-bit identifier for the message, the important concept here - is that UIDs are not unique between mailboxes; they are only unique - WITHIN a given mailbox. - - Some server implementations have attempted to make UIDs unique across - the entire server. This is inadvisable, in that it limits the life - of UIDs unnecessarily. The UID is a 32-bit number and will run out - in reasonably finite time if it's global across the server. If you - assign UIDs sequentially in one mailbox, you will not have to start - re-using them until you have had, at one time or another, 2**32 - different messages in that mailbox. In the global case, you will - have to reuse them once you have had, at one time or another, 2**32 - different messages in the entire mail store. Suppose your server has - around 8000 users registered (2**13). That gives an average of 2**19 - UIDs per user. Suppose each user gets 32 messages (2**5) per day. - That gives you 2**14 days (16000+ days = about 45 years) before you - run out. That may seem like enough, but multiply the usage just a - little (a lot of spam, a lot of mailing list subscriptions, more - users) and you limit yourself too much. - - What's worse is that if you have to wrap the UIDs, and, thus, you - have to change UIDVALIDITY and invalidate the UIDs in the mailbox, - you have to do it for EVERY mailbox in the system, since they all - share the same UID pool. If you assign UIDs per mailbox and you have - a problem, you only have to kill the UIDs for that one mailbox. - - Under extreme circumstances (and this is extreme, indeed), the server - may have to invalidate UIDs while a mailbox is in use by a client - - that is, the UIDs that the client knows about in its active mailbox - are no longer valid. In that case, the server must immediately - change the UIDVALIDITY and must communicate this to the client. The - server may do this by sending an unsolicited UIDVALIDITY message, in - the same form as in response to the SELECT command. Clients must be - prepared to handle such a message and the possibly coincident failure - of the command in process. For example: - - - - - - -Leiba Informational [Page 13] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - C: 032 UID STORE 382 +Flags.silent \Deleted - S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value! - S: 032 NO UID command rejected because UIDVALIDITY changed! - C: ...invalidates local information and re-fetches... - C: 033 FETCH 1:* UID - ...etc... - - At the time of the writing of this document, the only server known to - do this does so only under the following condition: the client - selects INBOX, but there is not yet a physical INBOX file created. - Nonetheless, the SELECT succeeds, exporting an empty INBOX with a - temporary UIDVALIDITY of 1. While the INBOX remains selected, mail - is delivered to the user, which creates the real INBOX file and - assigns a permanent UIDVALIDITY (that is likely not to be 1). The - server reports the change of UIDVALIDITY, but as there were no - messages before, so no UIDs have actually changed, all the client - must do is accept the change in UIDVALIDITY. - - Alternatively, a server may force the client to re-select the - mailbox, at which time it will obtain a new UIDVALIDITY value. To do - this, the server closes this client session (see "Severed - Connections" above) and the client then reconnects and gets back in - synch. Clients must be prepared for either of these behaviours. - - We do not know of, nor do we anticipate the future existance of, a - server that changes UIDVALIDITY while there are existing messages, - but clients must be prepared to handle this eventuality. - -3.4.4. FETCH Responses - - When a client asks for certain information in a FETCH command, the - server may return the requested information in any order, not - necessarily in the order that it was requested. Further, the server - may return the information in separate FETCH responses and may also - return information that was not explicitly requested (to reflect to - the client changes in the state of the subject message). Some - examples: - - C: 001 FETCH 1 UID FLAGS INTERNALDATE - S: * 5 FETCH (FLAGS (\Deleted)) - S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345) - S: 001 OK done - - (In this case, the responses are in a different order. Also, the - server returned a flag update for message 5, which wasn't part of the - client's request.) - - - - - -Leiba Informational [Page 14] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - C: 002 FETCH 2 UID FLAGS INTERNALDATE - S: * 2 FETCH (INTERNALDATE "...") - S: * 2 FETCH (UID 399) - S: * 2 FETCH (FLAGS ()) - S: 002 OK done - - (In this case, the responses are in a different order and were - returned in separate responses.) - - C: 003 FETCH 2 BODY[1] - S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14} - S: Hello world! - S: ) - S: 003 OK done - - (In this case, the FLAGS response was added by the server, since - fetching the body part caused the server to set the \Seen flag.) - - Because of this characteristic a client must be ready to receive any - FETCH response at any time and should use that information to update - its local information about the message to which the FETCH response - refers. A client must not assume that any FETCH responses will come - in any particular order, or even that any will come at all. If after - receiving the tagged response for a FETCH command the client finds - that it did not get all of the information requested, the client - should send a NOOP command to the server to ensure that the server - has an opportunity to send any pending EXPUNGE responses to the - client (see [RFC-2180]). - -3.4.5. RFC822.SIZE - - Some back-end mail stores keep the mail in a canonical form, rather - than retaining the original MIME format of the messages. This means - that the server must reassemble the message to produce a MIME stream - when a client does a fetch such as RFC822 or BODY[], requesting the - entire message. It also may mean that the server has no convenient - way to know the RFC822.SIZE of the message. Often, such a server - will actually have to build the MIME stream to compute the size, only - to throw the stream away and report the size to the client. - - When this is the case, some servers have chosen to estimate the size, - rather than to compute it precisely. Such an estimate allows the - client to display an approximate size to the user and to use the - estimate in flood control considerations (q.v.), but requires that - the client not use the size for things such as allocation of buffers, - because those buffers might then be too small to hold the actual MIME - stream. Instead, a client should use the size that's returned in the - literal when you fetch the data. - - - -Leiba Informational [Page 15] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - The protocol requires that the RFC822.SIZE value returned by the - server be EXACT. Estimating the size is a protocol violation, and - server designers must be aware that, despite the performance savings - they might realize in using an estimate, this practice will cause - some clients to fail in various ways. If possible, the server should - compute the RFC822.SIZE for a particular message once, and then save - it for later retrieval. If that's not possible, the server must - compute the value exactly every time. Incorrect estimates do cause - severe interoperability problems with some clients. - -3.4.6. Expunged Messages - - If the server allows multiple connections to the same mailbox, it is - often possible for messages to be expunged in one client unbeknownst - to another client. Since the server is not allowed to tell the - client about these expunged messages in response to a FETCH command, - the server may have to deal with the issue of how to return - information about an expunged message. There was extensive - discussion about this issue, and the results of that discussion are - summarized in [RFC-2180]. See that reference for a detailed - explanation and for recommendations. - -3.4.7. The Namespace Issue - - Namespaces are a very muddy area in IMAP4 implementation right now - (see [NAMESPACE] for a proposal to clear the water a bit). Until the - issue is resolved, the important thing for client developers to - understand is that some servers provide access through IMAP to more - than just the user's personal mailboxes, and, in fact, the user's - personal mailboxes may be "hidden" somewhere in the user's default - hierarchy. The client, therefore, should provide a setting wherein - the user can specify a prefix to be used when accessing mailboxes. If - the user's mailboxes are all in "~/mail/", for instance, then the - user can put that string in the prefix. The client would then put - the prefix in front of any name pattern in the LIST and LSUB - commands: - - C: 001 LIST "" ~/mail/% - - (See also "Reference Names in the LIST Command" below.) - -3.4.8. Creating Special-Use Mailboxes - - It may seem at first that this is part of the namespace issue; it is - not, and is only indirectly related to it. A number of clients like - to create special-use mailboxes with particular names. Most - commonly, clients with a "trash folder" model of message deletion - want to create a mailbox with the name "Trash" or "Deleted". Some - - - -Leiba Informational [Page 16] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a - "Sent Mail" mailbox. And so on. There are two major - interoperability problems with this practice: - - 1. different clients may use different names for mailboxes with - similar functions (such as "Trash" and "Deleted"), or may manage - the same mailboxes in different ways, causing problems if a user - switches between clients and - 2. there is no guarantee that the server will allow the creation of - the desired mailbox. - - The client developer is, therefore, well advised to consider - carefully the creation of any special-use mailboxes on the server, - and, further, the client must not require such mailbox creation - - that is, if you do decide to do this, you must handle gracefully the - failure of the CREATE command and behave reasonably when your - special-use mailboxes do not exist and can not be created. - - In addition, the client developer should provide a convenient way for - the user to select the names for any special-use mailboxes, allowing - the user to make these names the same in all clients used and to put - them where the user wants them. - -3.4.9. Reference Names in the LIST Command - - Many implementers of both clients and servers are confused by the - "reference name" on the LIST command. The reference name is intended - to be used in much the way a "cd" (change directory) command is used - on Unix, PC DOS, Windows, and OS/2 systems. That is, the mailbox - name is interpreted in much the same way as a file of that name would - be found if one had done a "cd" command into the directory specified - by the reference name. For example, in Unix we have the following: - - > cd /u/jones/junk - > vi banana [file is "/u/jones/junk/banana"] - > vi stuff/banana [file is "/u/jones/junk/stuff/banana"] - > vi /etc/hosts [file is "/etc/hosts"] - - In the past, there have been several interoperability problems with - this. First, while some IMAP servers are built on Unix or PC file - systems, many others are not, and the file system semantics do not - make sense in those configurations. Second, while some IMAP servers - expose the underlying file system to the clients, others allow access - only to the user's personal mailboxes, or to some other limited set - of files, making such file-system-like semantics less meaningful. - Third, because the IMAP spec leaves the interpretation of the - reference name as "implementation-dependent", in the past the various - server implementations handled it in vastly differing ways. - - - -Leiba Informational [Page 17] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - The following recommendations are the result of significant - operational experience, and are intended to maximize - interoperability. - - Server implementations must implement the reference argument in a way - that matches the intended "change directory" operation as closely as - possible. As a minimum implementation, the reference argument may be - prepended to the mailbox name (while suppressing double delimiters; - see the next paragraph). Even servers that do not provide a way to - break out of the current hierarchy (see "breakout facility" below) - must provide a reasonable implementation of the reference argument, - as described here, so that they will interoperate with clients that - use it. - - Server implementations that prepend the reference argument to the - mailbox name should insert a hierarchy delimiter between them, and - must not insert a second if one is already present: - - C: A001 LIST ABC DEF - S: * LIST () "/" ABC/DEF <=== should do this - S: A001 OK done - - C: A002 LIST ABC/ /DEF - S: * LIST () "/" ABC//DEF <=== must not do this - S: A002 OK done - - On clients, the reference argument is chiefly used to implement a - "breakout facility", wherein the user may directly access a mailbox - outside the "current directory" hierarchy. Client implementations - should have an operational mode that does not use the reference - argument. This is to interoperate with older servers that did not - implement the reference argument properly. While it's a good idea to - give the user access to a breakout facility, clients that do not - intend to do so should not use the reference argument at all. - - Client implementations should always place a trailing hierarchy - delimiter on the reference argument. This is because some servers - prepend the reference argument to the mailbox name without inserting - a hierarchy delimiter, while others do insert a hierarchy delimiter - if one is not already present. A client that puts the delimiter in - will work with both varieties of server. - - Client implementations that implement a breakout facility should - allow the user to choose whether or not to use a leading hierarchy - delimiter on the mailbox argument. This is because the handling of a - leading mailbox hierarchy delimiter also varies from server to - server, and even between different mailstores on the same server. In - some cases, a leading hierarchy delimiter means "discard the - - - -Leiba Informational [Page 18] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - reference argument" (implementing the intended breakout facility), - thus: - - C: A001 LIST ABC/ /DEF - S: * LIST () "/" /DEF - S: A001 OK done - - In other cases, however, the two are catenated and the extra - hierarchy delimiter is discarded, thus: - - C: A001 LIST ABC/ /DEF - S: * LIST () "/" ABC/DEF - S: A001 OK done - - Client implementations must not assume that the server supports a - breakout facility, but may provide a way for the user to use one if - it is available. Any breakout facility should be exported to the - user interface. Note that there may be other "breakout" characters - besides the hierarchy delimiter (for instance, UNIX filesystem - servers are likely to use a leading "~" as well), and that their - interpretation is server-dependent. - -3.4.10. Mailbox Hierarchy Delimiters - - The server's selection of what to use as a mailbox hierarchy - delimiter is a difficult one, involving several issues: What - characters do users expect to see? What characters can they enter - for a hierarchy delimiter if it is desired (or required) that the - user enter it? What character can be used for the hierarchy - delimiter, noting that the chosen character can not otherwise be used - in the mailbox name? - - Because some interfaces show users the hierarchy delimiters or allow - users to enter qualified mailbox names containing them, server - implementations should use delimiter characters that users generally - expect to see as name separators. The most common characters used - for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows - file names), and "." (as in news groups). There is little to choose - among these apart from what users may expect or what is dictated by - the underlying file system, if any. One consideration about using - "\" is that it's also a special character in the IMAP protocol. While - the use of other hierarchy delimiter characters is permissible, A - DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the - server is intended for special purposes only. Implementers might be - thinking about using characters such as "-", "_", ";", "&", "#", "@", - and "!", but they should be aware of the surprise to the user as well - as of the effect on URLs and other external specifications (since - some of these characters have special meanings there). Also, a - - - -Leiba Informational [Page 19] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - server that uses "\" (and clients of such a server) must remember to - escape that character in quoted strings or to send literals instead. - Literals are recommended over escaped characters in quoted strings in - order to maintain compatibility with older IMAP versions that did not - allow escaped characters in quoted strings (but check the grammar to - see where literals are allowed): - - C: 001 LIST "" {13} - S: + send literal - C: this\%\%\%\h* - S: * LIST () "\\" {27} - S: this\is\a\mailbox\hierarchy - S: 001 OK LIST complete - - In any case, a server should not use normal alpha-numeric characters - (such as "X" or "0") as delimiters; a user would be very surprised to - find that "EXPENDITURES" actually represented a two-level hierarchy. - And a server should not use characters that are non-printable or - difficult or impossible to enter on a standard US keyboard. Control - characters, box-drawing characters, and characters from non-US - alphabets fit into this category. Their use presents - interoperability problems that are best avoided. - - The UTF-7 encoding of mailbox names also raises questions about what - to do with the hierarchy delimiters in encoded names: do we encode - each hierarchy level and separate them with delimiters, or do we - encode the fully qualified name, delimiters and all? The answer for - IMAP is the former: encode each hierarchy level separately, and - insert delimiters between. This makes it particularly important not - to use as a hierarchy delimiter a character that might cause - confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding. - - To repeat: a server should use "/", "\", or "." as its hierarchy - delimiter. The use of any other character is likely to cause - problems and is STRONGLY DISCOURAGED. - -3.4.11. ALERT Response Codes - - The protocol spec is very clear on the matter of what to do with - ALERT response codes, and yet there are many clients that violate it - so it needs to be said anyway: "The human-readable text contains a - special alert that must be presented to the user in a fashion that - calls the user's attention to the message." That should be clear - enough, but I'll repeat it here: Clients must present ALERT text - clearly to the user. - - - - - - -Leiba Informational [Page 20] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - -3.4.12. Deleting Mailboxes - - The protocol does not guarantee that a client may delete a mailbox - that is not empty, though on some servers it is permissible and is, - in fact, much faster than the alternative or deleting all the - messages from the client. If the client chooses to try to take - advantage of this possibility it must be prepared to use the other - method in the even that the more convenient one fails. Further, a - client should not try to delete the mailbox that it has selected, but - should first close that mailbox; some servers do not permit the - deletion of the selected mailbox. - - That said, a server should permit the deletion of a non-empty - mailbox; there's little reason to pass this work on to the client. - Moreover, forbidding this prevents the deletion of a mailbox that for - some reason can not be opened or expunged, leading to possible - denial-of-service problems. - - Example: - - [User tells the client to delete mailbox BANANA, which is - currently selected...] - C: 008 CLOSE - S: 008 OK done - C: 009 DELETE BANANA - S: 009 NO Delete failed; mailbox is not empty. - C: 010 SELECT BANANA - S: * ... untagged SELECT responses - S: 010 OK done - C: 011 STORE 1:* +FLAGS.SILENT \DELETED - S: 011 OK done - C: 012 CLOSE - S: 012 OK done - C: 013 DELETE BANANA - S: 013 OK done - -3.5. A Word About Testing - - Since the whole point of IMAP is interoperability, and since - interoperability can not be tested in a vacuum, the final - recommendation of this treatise is, "Test against EVERYTHING." Test - your client against every server you can get an account on. Test - your server with every client you can get your hands on. Many - clients make limited test versions available on the Web for the - downloading. Many server owners will give serious client developers - guest accounts for testing. Contact them and ask. NEVER assume that - because your client works with one or two servers, or because your - server does fine with one or two clients, you will interoperate well - - - -Leiba Informational [Page 21] - -RFC 2683 IMAP4 Implementation Recommendations September 1999 - - - in general. - - In particular, in addition to everything else, be sure to test - against the reference implementations: the PINE client, the - University of Washington server, and the Cyrus server. - - See the following URLs on the web for more information here: - - IMAP Products and Sources: http://www.imap.org/products.html - IMC MailConnect: http://www.imc.org/imc-mailconnect - -4. Security Considerations - - This document describes behaviour of clients and servers that use the - IMAP4 protocol, and as such, has the same security considerations as - described in [RFC-2060]. - -5. References - - [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, December 1996. - - [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC - 2180, July 1997. - - [UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode - and ISO 10646", RFC 2044, October 1996. - - [UTF-7] Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe - Transformation Format of Unicode", RFC 2152, May 1997. - - [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in - Progress. - -6. Author's Address - - Barry Leiba - IBM T.J. Watson Research Center - 30 Saw Mill River Road - Hawthorne, NY 10532 - - Phone: 1-914-784-7941 - EMail: 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/server/src/site/resources/rfclist/ldap/rfc2251.txt b/server/src/site/resources/rfclist/ldap/rfc2251.txt deleted file mode 100644 index 88844cbf38b..00000000000 --- a/server/src/site/resources/rfclist/ldap/rfc2251.txt +++ /dev/null @@ -1,2803 +0,0 @@ - - - - - - -Network Working Group M. Wahl -Request for Comments: 2251 Critical Angle Inc. -Category: Standards Track T. Howes - Netscape Communications Corp. - S. Kille - Isode Limited - December 1997 - - - Lightweight Directory Access Protocol (v3) - -1. 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. - -IESG Note - - This document describes a directory access protocol that provides - both read and update access. Update access requires secure - authentication, but this document does not mandate implementation of - any satisfactory authentication mechanisms. - - In accordance with RFC 2026, section 4.4.1, this specification is - being approved by IESG as a Proposed Standard despite this - limitation, for the following reasons: - - a. to encourage implementation and interoperability testing of - these protocols (with or without update access) before they - are deployed, and - - b. to encourage deployment and use of these protocols in read-only - applications. (e.g. applications where LDAPv3 is used as - a query language for directories which are updated by some - secure mechanism other than LDAP), and - - c. to avoid delaying the advancement and deployment of other Internet - standards-track protocols which require the ability to query, but - not update, LDAPv3 directory servers. - - - - - -Wahl, et. al. Standards Track [Page 1] - -RFC 2251 LDAPv3 December 1997 - - - Readers are hereby warned that until mandatory authentication - mechanisms are standardized, clients and servers written according to - this specification which make use of update functionality are - UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION - IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. - - Implementors are hereby discouraged from deploying LDAPv3 clients or - servers which implement the update functionality, until a Proposed - Standard for mandatory authentication in LDAPv3 has been approved and - published as an RFC. - -Table of Contents - - 1. Status of this Memo .................................... 1 - Copyright Notice ....................................... 1 - IESG Note .............................................. 1 - 2. Abstract ............................................... 3 - 3. Models ................................................. 4 - 3.1. Protocol Model ........................................ 4 - 3.2. Data Model ............................................ 5 - 3.2.1. Attributes of Entries ............................... 5 - 3.2.2. Subschema Entries and Subentries .................... 7 - 3.3. Relationship to X.500 ................................. 8 - 3.4. Server-specific Data Requirements ..................... 8 - 4. Elements of Protocol ................................... 9 - 4.1. Common Elements ....................................... 9 - 4.1.1. Message Envelope .................................... 9 - 4.1.1.1. Message ID ........................................ 11 - 4.1.2. String Types ........................................ 11 - 4.1.3. Distinguished Name and Relative Distinguished Name .. 11 - 4.1.4. Attribute Type ...................................... 12 - 4.1.5. Attribute Description ............................... 13 - 4.1.5.1. Binary Option ..................................... 14 - 4.1.6. Attribute Value ..................................... 14 - 4.1.7. Attribute Value Assertion ........................... 15 - 4.1.8. Attribute ........................................... 15 - 4.1.9. Matching Rule Identifier ............................ 15 - 4.1.10. Result Message ..................................... 16 - 4.1.11. Referral ........................................... 18 - 4.1.12. Controls ........................................... 19 - 4.2. Bind Operation ........................................ 20 - 4.2.1. Sequencing of the Bind Request ...................... 21 - 4.2.2. Authentication and Other Security Services .......... 22 - 4.2.3. Bind Response ....................................... 23 - 4.3. Unbind Operation ...................................... 24 - 4.4. Unsolicited Notification .............................. 24 - 4.4.1. Notice of Disconnection ............................. 24 - 4.5. Search Operation ...................................... 25 - - - -Wahl, et. al. Standards Track [Page 2] - -RFC 2251 LDAPv3 December 1997 - - - 4.5.1. Search Request ...................................... 25 - 4.5.2. Search Result ....................................... 29 - 4.5.3. Continuation References in the Search Result ........ 31 - 4.5.3.1. Example ........................................... 31 - 4.6. Modify Operation ...................................... 32 - 4.7. Add Operation ......................................... 34 - 4.8. Delete Operation ...................................... 35 - 4.9. Modify DN Operation ................................... 36 - 4.10. Compare Operation .................................... 37 - 4.11. Abandon Operation .................................... 38 - 4.12. Extended Operation ................................... 38 - 5. Protocol Element Encodings and Transfer ................ 39 - 5.1. Mapping Onto BER-based Transport Services ............. 39 - 5.2. Transfer Protocols .................................... 40 - 5.2.1. Transmission Control Protocol (TCP) ................. 40 - 6. Implementation Guidelines .............................. 40 - 6.1. Server Implementations ................................ 40 - 6.2. Client Implementations ................................ 40 - 7. Security Considerations ................................ 41 - 8. Acknowledgements ....................................... 41 - 9. Bibliography ........................................... 41 - 10. Authors' Addresses ..................................... 42 - Appendix A - Complete ASN.1 Definition ..................... 44 - Full Copyright Statement ................................... 50 - -2. Abstract - - The protocol described in this document is designed to provide access - to directories supporting the X.500 models, while not incurring the - resource requirements of the X.500 Directory Access Protocol (DAP). - This protocol is specifically targeted at management applications and - browser applications that provide read/write interactive access to - directories. When used with a directory supporting the X.500 - protocols, it is intended to be a complement to the X.500 DAP. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document - are to be interpreted as described in RFC 2119 [10]. - - Key aspects of this version of LDAP are: - - - All protocol elements of LDAPv2 (RFC 1777) are supported. The - protocol is carried directly over TCP or other transport, bypassing - much of the session/presentation overhead of X.500 DAP. - - - Most protocol data elements can be encoded as ordinary strings - (e.g., Distinguished Names). - - - - -Wahl, et. al. Standards Track [Page 3] - -RFC 2251 LDAPv3 December 1997 - - - - Referrals to other servers may be returned. - - - SASL mechanisms may be used with LDAP to provide association - security services. - - - Attribute values and Distinguished Names have been - internationalized through the use of the ISO 10646 character set. - - - The protocol can be extended to support new operations, and - controls may be used to extend existing operations. - - - Schema is published in the directory for use by clients. - -3. Models - - Interest in X.500 [1] directory technologies in the Internet has led - to efforts to reduce the high cost of entry associated with use of - these technologies. This document continues the efforts to define - directory protocol alternatives, updating the LDAP [2] protocol - specification. - -3.1. Protocol Model - - The general model adopted by this protocol is one of clients - performing protocol operations against servers. In this model, a - client transmits a protocol request describing the operation to be - performed to a server. The server is then responsible for performing - the necessary operation(s) in the directory. Upon completion of the - operation(s), the server returns a response containing any results or - errors to the requesting client. - - In keeping with the goal of easing the costs associated with use of - the directory, it is an objective of this protocol to minimize the - complexity of clients so as to facilitate widespread deployment of - applications capable of using the directory. - - Note that although servers are required to return responses whenever - such responses are defined in the protocol, there is no requirement - for synchronous behavior on the part of either clients or servers. - Requests and responses for multiple operations may be exchanged - between a client and server in any order, provided the client - eventually receives a response for every request that requires one. - - In LDAP versions 1 and 2, no provision was made for protocol servers - returning referrals to clients. However, for improved performance - and distribution this version of the protocol permits servers to - return to clients referrals to other servers. This allows servers to - offload the work of contacting other servers to progress operations. - - - -Wahl, et. al. Standards Track [Page 4] - -RFC 2251 LDAPv3 December 1997 - - - Note that the core protocol operations defined in this document can - be mapped to a strict subset of the X.500(1997) directory abstract - service, so it can be cleanly provided by the DAP. However there is - not a one-to-one mapping between LDAP protocol operations and DAP - operations: server implementations acting as a gateway to X.500 - directories may need to make multiple DAP requests. - -3.2. Data Model - - This section provides a brief introduction to the X.500 data model, - as used by LDAP. - - The LDAP protocol assumes there are one or more servers which jointly - provide access to a Directory Information Tree (DIT). The tree is - made up of entries. Entries have names: one or more attribute values - from the entry form its relative distinguished name (RDN), which MUST - be unique among all its siblings. The concatenation of the relative - distinguished names of the sequence of entries from a particular - entry to an immediate subordinate of the root of the tree forms that - entry's Distinguished Name (DN), which is unique in the tree. An - example of a Distinguished Name is - - CN=Steve Kille, O=Isode Limited, C=GB - - Some servers may hold cache or shadow copies of entries, which can be - used to answer search and comparison queries, but will return - referrals or contact other servers if modification operations are - requested. - - Servers which perform caching or shadowing MUST ensure that they do - not violate any access control constraints placed on the data by the - originating server. - - The largest collection of entries, starting at an entry that is - mastered by a particular server, and including all its subordinates - and their subordinates, down to the entries which are mastered by - different servers, is termed a naming context. The root of the DIT - is a DSA-specific Entry (DSE) and not part of any naming context: - each server has different attribute values in the root DSE. (DSA is - an X.500 term for the directory server). - -3.2.1. Attributes of Entries - - Entries consist of a set of attributes. An attribute is a type with - one or more associated values. The attribute type is identified by a - short descriptive name and an OID (object identifier). The attribute - - - - - -Wahl, et. al. Standards Track [Page 5] - -RFC 2251 LDAPv3 December 1997 - - - type governs whether there can be more than one value of an attribute - of that type in an entry, the syntax to which the values must - conform, the kinds of matching which can be performed on values of - that attribute, and other functions. - - An example of an attribute is "mail". There may be one or more values - of this attribute, they must be IA5 (ASCII) strings, and they are - case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM"). - - Schema is the collection of attribute type definitions, object class - definitions and other information which a server uses to determine - how to match a filter or attribute value assertion (in a compare - operation) against the attributes of an entry, and whether to permit - add and modify operations. The definition of schema for use with - LDAP is given in [5] and [6]. Additional schema elements may be - defined in other documents. - - Each entry MUST have an objectClass attribute. The objectClass - attribute specifies the object classes of an entry, which along with - the system and user schema determine the permitted attributes of an - entry. Values of this attribute may be modified by clients, but the - objectClass attribute cannot be removed. Servers may restrict the - modifications of this attribute to prevent the basic structural class - of the entry from being changed (e.g. one cannot change a person into - a country). When creating an entry or adding an objectClass value to - an entry, all superclasses of the named classes are implicitly added - as well if not already present, and the client must supply values for - any mandatory attributes of new superclasses. - - Some attributes, termed operational attributes, are used by servers - for administering the directory system itself. They are not returned - in search results unless explicitly requested by name. Attributes - which are not operational, such as "mail", will have their schema and - syntax constraints enforced by servers, but servers will generally - not make use of their values. - - Servers MUST NOT permit clients to add attributes to an entry unless - those attributes are permitted by the object class definitions, the - schema controlling that entry (specified in the subschema - see - below), or are operational attributes known to that server and used - for administrative purposes. Note that there is a particular - objectClass 'extensibleObject' defined in [5] which permits all user - attributes to be present in an entry. - - Entries MAY contain, among others, the following operational - attributes, defined in [5]. These attributes are maintained - automatically by the server and are not modifiable by clients: - - - - -Wahl, et. al. Standards Track [Page 6] - -RFC 2251 LDAPv3 December 1997 - - - - creatorsName: the Distinguished Name of the user who added this - entry to the directory. - - - createTimestamp: the time this entry was added to the directory. - - - modifiersName: the Distinguished Name of the user who last modified - this entry. - - - modifyTimestamp: the time this entry was last modified. - - - subschemaSubentry: the Distinguished Name of the subschema entry - (or subentry) which controls the schema for this entry. - -3.2.2. Subschema Entries and Subentries - - Subschema entries are used for administering information about the - directory schema, in particular the object classes and attribute - types supported by directory servers. A single subschema entry - contains all schema definitions used by entries in a particular part - of the directory tree. - - Servers which follow X.500(93) models SHOULD implement subschema - using the X.500 subschema mechanisms, and so these subschemas are not - ordinary entries. LDAP clients SHOULD NOT assume that servers - implement any of the other aspects of X.500 subschema. A server - which masters entries and permits clients to modify these entries - MUST implement and provide access to these subschema entries, so that - its clients may discover the attributes and object classes which are - permitted to be present. It is strongly recommended that all other - servers implement this as well. - - The following four attributes MUST be present in all subschema - entries: - - - cn: this attribute MUST be used to form the RDN of the subschema - entry. - - - objectClass: the attribute MUST have at least the values "top" and - "subschema". - - - objectClasses: each value of this attribute specifies an object - class known to the server. - - - attributeTypes: each value of this attribute specifies an attribute - type known to the server. - - These are defined in [5]. Other attributes MAY be present in - subschema entries, to reflect additional supported capabilities. - - - -Wahl, et. al. Standards Track [Page 7] - -RFC 2251 LDAPv3 December 1997 - - - These include matchingRules, matchingRuleUse, dITStructureRules, - dITContentRules, nameForms and ldapSyntaxes. - - Servers SHOULD provide the attributes createTimestamp and - modifyTimestamp in subschema entries, in order to allow clients to - maintain their caches of schema information. - - Clients MUST only retrieve attributes from a subschema entry by - requesting a base object search of the entry, where the search filter - is "(objectClass=subschema)". (This will allow LDAPv3 servers which - gateway to X.500(93) to detect that subentry information is being - requested.) - -3.3. Relationship to X.500 - - This document defines LDAP in terms of X.500 as an X.500 access - mechanism. An LDAP server MUST act in accordance with the - X.500(1993) series of ITU recommendations when providing the service. - However, it is not required that an LDAP server make use of any X.500 - protocols in providing this service, e.g. LDAP can be mapped onto any - other directory system so long as the X.500 data and service model as - used in LDAP is not violated in the LDAP interface. - -3.4. Server-specific Data Requirements - - An LDAP server MUST provide information about itself and other - information that is specific to each server. This is represented as - a group of attributes located in the root DSE (DSA-Specific Entry), - which is named with the zero-length LDAPDN. These attributes are - retrievable if a client performs a base object search of the root - with filter "(objectClass=*)", however they are subject to access - control restrictions. The root DSE MUST NOT be included if the - client performs a subtree search starting from the root. - - Servers may allow clients to modify these attributes. - - The following attributes of the root DSE are defined in section 5 of - [5]. Additional attributes may be defined in other documents. - - - namingContexts: naming contexts held in the server. Naming contexts - are defined in section 17 of X.501 [6]. - - - subschemaSubentry: subschema entries (or subentries) known by this - server. - - - altServer: alternative servers in case this one is later - unavailable. - - - - -Wahl, et. al. Standards Track [Page 8] - -RFC 2251 LDAPv3 December 1997 - - - - supportedExtension: list of supported extended operations. - - - supportedControl: list of supported controls. - - - supportedSASLMechanisms: list of supported SASL security features. - - - supportedLDAPVersion: LDAP versions implemented by the server. - - If the server does not master entries and does not know the locations - of schema information, the subschemaSubentry attribute is not present - in the root DSE. If the server masters directory entries under one - or more schema rules, there may be any number of values of the - subschemaSubentry attribute in the root DSE. - -4. Elements of Protocol - - The LDAP protocol is described using Abstract Syntax Notation 1 - (ASN.1) [3], and is typically transferred using a subset of ASN.1 - Basic Encoding Rules [11]. In order to support future extensions to - this protocol, clients and servers MUST ignore elements of SEQUENCE - encodings whose tags they do not recognize. - - Note that unlike X.500, each change to the LDAP protocol other than - through the extension mechanisms will have a different version - number. A client will indicate the version it supports as part of - the bind request, described in section 4.2. If a client has not sent - a bind, the server MUST assume that version 3 is supported in the - client (since version 2 required that the client bind first). - - Clients may determine the protocol version a server supports by - reading the supportedLDAPVersion attribute from the root DSE. Servers - which implement version 3 or later versions MUST provide this - attribute. Servers which only implement version 2 may not provide - this attribute. - -4.1. Common Elements - - This section describes the LDAPMessage envelope PDU (Protocol Data - Unit) format, as well as data type definitions which are used in the - protocol operations. - -4.1.1. Message Envelope - - For the purposes of protocol exchanges, all protocol operations are - encapsulated in a common envelope, the LDAPMessage, which is defined - as follows: - - LDAPMessage ::= SEQUENCE { - - - -Wahl, et. al. Standards Track [Page 9] - -RFC 2251 LDAPv3 December 1997 - - - messageID MessageID, - protocolOp CHOICE { - bindRequest BindRequest, - bindResponse BindResponse, - unbindRequest UnbindRequest, - searchRequest SearchRequest, - searchResEntry SearchResultEntry, - searchResDone SearchResultDone, - searchResRef SearchResultReference, - modifyRequest ModifyRequest, - modifyResponse ModifyResponse, - addRequest AddRequest, - addResponse AddResponse, - delRequest DelRequest, - delResponse DelResponse, - modDNRequest ModifyDNRequest, - modDNResponse ModifyDNResponse, - compareRequest CompareRequest, - compareResponse CompareResponse, - abandonRequest AbandonRequest, - extendedReq ExtendedRequest, - extendedResp ExtendedResponse }, - controls [0] Controls OPTIONAL } - - MessageID ::= INTEGER (0 .. maxInt) - - maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- - - The function of the LDAPMessage is to provide an envelope containing - common fields required in all protocol exchanges. At this time the - only common fields are the message ID and the controls. - - If the server receives a PDU from the client in which the LDAPMessage - SEQUENCE tag cannot be recognized, the messageID cannot be parsed, - the tag of the protocolOp is not recognized as a request, or the - encoding structures or lengths of data fields are found to be - incorrect, then the server MUST return the notice of disconnection - described in section 4.4.1, with resultCode protocolError, and - immediately close the connection. In other cases that the server - cannot parse the request received by the client, the server MUST - return an appropriate response to the request, with the resultCode - set to protocolError. - - If the client receives a PDU from the server which cannot be parsed, - the client may discard the PDU, or may abruptly close the connection. - - The ASN.1 type Controls is defined in section 4.1.12. - - - - -Wahl, et. al. Standards Track [Page 10] - -RFC 2251 LDAPv3 December 1997 - - -4.1.1.1. Message ID - - All LDAPMessage envelopes encapsulating responses contain the - messageID value of the corresponding request LDAPMessage. - - The message ID of a request MUST have a value different from the - values of any other requests outstanding in the LDAP session of which - this message is a part. - - A client MUST NOT send a second request with the same message ID as - an earlier request on the same connection if the client has not - received the final response from the earlier request. Otherwise the - behavior is undefined. Typical clients increment a counter for each - request. - - A client MUST NOT reuse the message id of an abandonRequest or of the - abandoned operation until it has received a response from the server - for another request invoked subsequent to the abandonRequest, as the - abandonRequest itself does not have a response. - -4.1.2. String Types - - The LDAPString is a notational convenience to indicate that, although - strings of LDAPString type encode as OCTET STRING types, the ISO - 10646 [13] character set (a superset of Unicode) is used, encoded - following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm - characters which are the same as ASCII (0x0000 through 0x007F) are - represented as that same ASCII character in a single byte. The other - byte values are used to form a variable-length encoding of an - arbitrary character. - - LDAPString ::= OCTET STRING - - The LDAPOID is a notational convenience to indicate that the - permitted value of this string is a (UTF-8 encoded) dotted-decimal - representation of an OBJECT IDENTIFIER. - - LDAPOID ::= OCTET STRING - - For example, - - 1.3.6.1.4.1.1466.1.2.3 - -4.1.3. Distinguished Name and Relative Distinguished Name - - An LDAPDN and a RelativeLDAPDN are respectively defined to be the - representation of a Distinguished Name and a Relative Distinguished - Name after encoding according to the specification in [4], such that - - - -Wahl, et. al. Standards Track [Page 11] - -RFC 2251 LDAPv3 December 1997 - - - ::= - - ::= - - where and are as defined in [4]. - - LDAPDN ::= LDAPString - - RelativeLDAPDN ::= LDAPString - - Only Attribute Types can be present in a relative distinguished name - component; the options of Attribute Descriptions (next section) MUST - NOT be used in specifying distinguished names. - -4.1.4. Attribute Type - - An AttributeType takes on as its value the textual string associated - with that AttributeType in its specification. - - AttributeType ::= LDAPString - - Each attribute type has a unique OBJECT IDENTIFIER which has been - assigned to it. This identifier may be written as decimal digits - with components separated by periods, e.g. "2.5.4.10". - - A specification may also assign one or more textual names for an - attribute type. These names MUST begin with a letter, and only - contain ASCII letters, digit characters and hyphens. They are case - insensitive. (These ASCII characters are identical to ISO 10646 - characters whose UTF-8 encoding is a single byte between 0x00 and - 0x7F.) - - If the server has a textual name for an attribute type, it MUST use a - textual name for attributes returned in search results. The dotted- - decimal OBJECT IDENTIFIER is only used if there is no textual name - for an attribute type. - - Attribute type textual names are non-unique, as two different - specifications (neither in standards track RFCs) may choose the same - name. - - A server which masters or shadows entries SHOULD list all the - attribute types it supports in the subschema entries, using the - attributeTypes attribute. Servers which support an open-ended set of - attributes SHOULD include at least the attributeTypes value for the - 'objectClass' attribute. Clients MAY retrieve the attributeTypes - value from subschema entries in order to obtain the OBJECT IDENTIFIER - and other information associated with attribute types. - - - -Wahl, et. al. Standards Track [Page 12] - -RFC 2251 LDAPv3 December 1997 - - - Some attribute type names which are used in this version of LDAP are - described in [5]. Servers may implement additional attribute types. - -4.1.5. Attribute Description - - An AttributeDescription is a superset of the definition of the - AttributeType. It has the same ASN.1 definition, but allows - additional options to be specified. They are also case insensitive. - - AttributeDescription ::= LDAPString - - A value of AttributeDescription is based on the following BNF: - - ::= [ ";" ] - - ::=
::= the one or two decimal integer day of the month in - the range 1 to 31. - - ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | - "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" - - ::= the two decimal integer year of the century in the - range 00 to 99. - - - - - -[Page 32] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - ::= the two decimal integer hour of the day in the - range 00 to 24. - - ::= the two decimal integer minute of the hour in the - range 00 to 59. - - ::= the two decimal integer second of the minute in the - range 00 to 59. - - ::= "UT" for Universal Time (the default) or other - time zone designator (as in [2]). - - - - ------------------------------------------------------------- - - Return Path Example - - Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA> - - Example 9 - - ------------------------------------------------------------- - - ------------------------------------------------------------- - - Time Stamp Line Example - - Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT - - Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25 - id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT - - Example 10 - - ------------------------------------------------------------- - - - - - - - - - - - - - -Postel [Page 33] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 4.2. SMTP REPLIES - - Replies to SMTP commands are devised to ensure the synchronization - of requests and actions in the process of mail transfer, and to - guarantee that the sender-SMTP always knows the state of the - receiver-SMTP. Every command must generate exactly one reply. - - The details of the command-reply sequence are made explicit in - Section 5.3 on Sequencing and Section 5.4 State Diagrams. - - An SMTP reply consists of a three digit number (transmitted as - three alphanumeric characters) followed by some text. The number - is intended for use by automata to determine what state to enter - next; the text is meant for the human user. It is intended that - the three digits contain enough encoded information that the - sender-SMTP need not examine the text and may either discard it or - pass it on to the user, as appropriate. In particular, the text - may be receiver-dependent and context dependent, so there are - likely to be varying texts for each reply code. A discussion of - the theory of reply codes is given in Appendix E. Formally, a - reply is defined to be the sequence: a three-digit code, , - one line of text, and , or a multiline reply (as defined in - Appendix E). Only the EXPN and HELP commands are expected to - result in multiline replies in normal circumstances, however - multiline replies are allowed for any command. - - - - - - - - - - - - - - - - - - - - - - - - -[Page 34] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.2.1. REPLY CODES BY FUNCTION GROUPS - - 500 Syntax error, command unrecognized - [This may include errors such as command line too long] - 501 Syntax error in parameters or arguments - 502 Command not implemented - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - [Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user] - - 220 Service ready - 221 Service closing transmission channel - 421 Service not available, - closing transmission channel - [This may be a reply to any command if the service knows it - must shut down] - - 250 Requested mail action okay, completed - 251 User not local; will forward to - 450 Requested mail action not taken: mailbox unavailable - [E.g., mailbox busy] - 550 Requested action not taken: mailbox unavailable - [E.g., mailbox not found, no access] - 451 Requested action aborted: error in processing - 551 User not local; please try - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - [E.g., mailbox syntax incorrect] - 354 Start mail input; end with . - 554 Transaction failed - - - - - - - - - - - - - -Postel [Page 35] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 4.2.2. NUMERIC ORDER LIST OF REPLY CODES - - 211 System status, or system help reply - 214 Help message - [Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user] - 220 Service ready - 221 Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to - - 354 Start mail input; end with . - - 421 Service not available, - closing transmission channel - [This may be a reply to any command if the service knows it - must shut down] - 450 Requested mail action not taken: mailbox unavailable - [E.g., mailbox busy] - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - - 500 Syntax error, command unrecognized - [This may include errors such as command line too long] - 501 Syntax error in parameters or arguments - 502 Command not implemented - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - [E.g., mailbox not found, no access] - 551 User not local; please try - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - [E.g., mailbox syntax incorrect] - 554 Transaction failed - - - - - - - - - - - - - -[Page 36] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.3. SEQUENCING OF COMMANDS AND REPLIES - - The communication between the sender and receiver is intended to - be an alternating dialogue, controlled by the sender. As such, - the sender issues a command and the receiver responds with a - reply. The sender must wait for this response before sending - further commands. - - One important reply is the connection greeting. Normally, a - receiver will send a 220 "Service ready" reply when the connection - is completed. The sender should wait for this greeting message - before sending any commands. - - Note: all the greeting type replies have the official name of - the server host as the first word following the reply code. - - For example, - - 220 USC-ISIF.ARPA Service ready - - The table below lists alternative success and failure replies for - each command. These must be strictly adhered to; a receiver may - substitute text in the replies, but the meaning and action implied - by the code numbers and by the specific command reply sequence - cannot be altered. - - COMMAND-REPLY SEQUENCES - - Each command is listed with its possible replies. The prefixes - used before the possible replies are "P" for preliminary (not - used in SMTP), "I" for intermediate, "S" for success, "F" for - failure, and "E" for error. The 421 reply (service not - available, closing transmission channel) may be given to any - command if the SMTP-receiver knows it must shut down. This - listing forms the basis for the State Diagrams in Section 4.4. - - CONNECTION ESTABLISHMENT - S: 220 - F: 421 - HELO - S: 250 - E: 500, 501, 504, 421 - MAIL - S: 250 - F: 552, 451, 452 - E: 500, 501, 421 - - - -Postel [Page 37] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - RCPT - S: 250, 251 - F: 550, 551, 552, 553, 450, 451, 452 - E: 500, 501, 503, 421 - DATA - I: 354 -> data -> S: 250 - F: 552, 554, 451, 452 - F: 451, 554 - E: 500, 501, 503, 421 - RSET - S: 250 - E: 500, 501, 504, 421 - SEND - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - SOML - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - SAML - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - VRFY - S: 250, 251 - F: 550, 551, 553 - E: 500, 501, 502, 504, 421 - EXPN - S: 250 - F: 550 - E: 500, 501, 502, 504, 421 - HELP - S: 211, 214 - E: 500, 501, 502, 504, 421 - NOOP - S: 250 - E: 500, 421 - QUIT - S: 221 - E: 500 - TURN - S: 250 - F: 502 - E: 500, 503 - - - - -[Page 38] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.4. STATE DIAGRAMS - - Following are state diagrams for a simple-minded SMTP - implementation. Only the first digit of the reply codes is used. - There is one state diagram for each group of SMTP commands. The - command groupings were determined by constructing a model for each - command and then collecting together the commands with - structurally identical models. - - For each command there are three possible outcomes: "success" - (S), "failure" (F), and "error" (E). In the state diagrams below - we use the symbol B for "begin", and the symbol W for "wait for - reply". - - First, the diagram that represents most of the SMTP commands: - - - 1,3 +---+ - ----------->| E | - | +---+ - | - +---+ cmd +---+ 2 +---+ - | B |---------->| W |---------->| S | - +---+ +---+ +---+ - | - | 4,5 +---+ - ----------->| F | - +---+ - - - This diagram models the commands: - - HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, - NOOP, QUIT, TURN. - - - - - - - - - - - - - - - -Postel [Page 39] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - A more complex diagram models the DATA command: - - - +---+ DATA +---+ 1,2 +---+ - | B |---------->| W |-------------------->| E | - +---+ +---+ ------------>+---+ - 3| |4,5 | - | | | - -------------- ----- | - | | | +---+ - | ---------- -------->| S | - | | | | +---+ - | | ------------ - | | | | - V 1,3| |2 | - +---+ data +---+ --------------->+---+ - | |---------->| W | | F | - +---+ +---+-------------------->+---+ - 4,5 - - - Note that the "data" here is a series of lines sent from the - sender to the receiver with no response expected until the last - line is sent. - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 40] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.5. DETAILS - - 4.5.1. MINIMUM IMPLEMENTATION - - In order to make SMTP workable, the following minimum - implementation is required for all receivers: - - COMMANDS -- HELO - MAIL - RCPT - DATA - RSET - NOOP - QUIT - - 4.5.2. TRANSPARENCY - - Without some provision for data transparency the character - sequence "." ends the mail text and cannot be sent - by the user. In general, users are not aware of such - "forbidden" sequences. To allow all user composed text to be - transmitted transparently the following procedures are used. - - 1. Before sending a line of mail text the sender-SMTP checks - the first character of the line. If it is a period, one - additional period is inserted at the beginning of the line. - - 2. When a line of mail text is received by the receiver-SMTP - it checks the line. If the line is composed of a single - period it is the end of mail. If the first character is a - period and there are other characters on the line, the first - character is deleted. - - The mail data may contain any of the 128 ASCII characters. All - characters are to be delivered to the recipient's mailbox - including format effectors and other control characters. If - the transmission channel provides an 8-bit byte (octets) data - stream, the 7-bit ASCII codes are transmitted right justified - in the octets with the high order bits cleared to zero. - - In some systems it may be necessary to transform the data as - it is received and stored. This may be necessary for hosts - that use a different character set than ASCII as their local - character set, or that store data in records rather than - - - - - -Postel [Page 41] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - strings. If such transforms are necessary, they must be - reversible -- especially if such transforms are applied to - mail being relayed. - - 4.5.3. SIZES - - There are several objects that have required minimum maximum - sizes. That is, every implementation must be able to receive - objects of at least these sizes, but must not send objects - larger than these sizes. - - - **************************************************** - * * - * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * - * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * - * OF THESE OBJECTS SHOULD BE USED. * - * * - **************************************************** - - user - - The maximum total length of a user name is 64 characters. - - domain - - The maximum total length of a domain name or number is 64 - characters. - - path - - The maximum total length of a reverse-path or - forward-path is 256 characters (including the punctuation - and element separators). - - command line - - The maximum total length of a command line including the - command word and the is 512 characters. - - reply line - - The maximum total length of a reply line including the - reply code and the is 512 characters. - - - - - -[Page 42] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - text line - - The maximum total length of a text line including the - is 1000 characters (but not counting the leading - dot duplicated for transparency). - - recipients buffer - - The maximum total number of recipients that must be - buffered is 100 recipients. - - - **************************************************** - * * - * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * - * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * - * OF THESE OBJECTS SHOULD BE USED. * - * * - **************************************************** - - Errors due to exceeding these limits may be reported by using - the reply codes, for example: - - 500 Line too long. - - 501 Path too long - - 552 Too many recipients. - - 552 Too much mail data. - - - - - - - - - - - - - - - - - - - -Postel [Page 43] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -APPENDIX A - - TCP Transport service - - The Transmission Control Protocol [3] is used in the ARPA - Internet, and in any network following the US DoD standards for - internetwork protocols. - - Connection Establishment - - The SMTP transmission channel is a TCP connection established - between the sender process port U and the receiver process port - L. This single full duplex connection is used as the - transmission channel. This protocol is assigned the service - port 25 (31 octal), that is L=25. - - Data Transfer - - The TCP connection supports the transmission of 8-bit bytes. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 44] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -APPENDIX B - - NCP Transport service - - The ARPANET Host-to-Host Protocol [4] (implemented by the Network - Control Program) may be used in the ARPANET. - - Connection Establishment - - The SMTP transmission channel is established via NCP between - the sender process socket U and receiver process socket L. The - Initial Connection Protocol [5] is followed resulting in a pair - of simplex connections. This pair of connections is used as - the transmission channel. This protocol is assigned the - contact socket 25 (31 octal), that is L=25. - - Data Transfer - - The NCP data connections are established in 8-bit byte mode. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 45] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -APPENDIX C - - NITS - - The Network Independent Transport Service [6] may be used. - - Connection Establishment - - The SMTP transmission channel is established via NITS between - the sender process and receiver process. The sender process - executes the CONNECT primitive, and the waiting receiver - process executes the ACCEPT primitive. - - Data Transfer - - The NITS connection supports the transmission of 8-bit bytes. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 46] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -APPENDIX D - - X.25 Transport service - - It may be possible to use the X.25 service [7] as provided by the - Public Data Networks directly, however, it is suggested that a - reliable end-to-end protocol such as TCP be used on top of X.25 - connections. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 47] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -APPENDIX E - - Theory of Reply Codes - - The three digits of the reply each have a special significance. - The first digit denotes whether the response is good, bad or - incomplete. An unsophisticated sender-SMTP will be able to - determine its next action (proceed as planned, redo, retrench, - etc.) by simply examining this first digit. A sender-SMTP that - wants to know approximately what kind of error occurred (e.g., - mail system error, command syntax error) may examine the second - digit, reserving the third digit for the finest gradation of - information. - - There are five values for the first digit of the reply code: - - 1yz Positive Preliminary reply - - The command has been accepted, but the requested action - is being held in abeyance, pending confirmation of the - information in this reply. The sender-SMTP should send - another command specifying whether to continue or abort - the action. - - [Note: SMTP does not have any commands that allow this - type of reply, and so does not have the continue or - abort commands.] - - 2yz Positive Completion reply - - The requested action has been successfully completed. A - new request may be initiated. - - 3yz Positive Intermediate reply - - The command has been accepted, but the requested action - is being held in abeyance, pending receipt of further - information. The sender-SMTP should send another command - specifying this information. This reply is used in - command sequence groups. - - 4yz Transient Negative Completion reply - - The command was not accepted and the requested action did - not occur. However, the error condition is temporary and - the action may be requested again. The sender should - - - -[Page 48] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - return to the beginning of the command sequence (if any). - It is difficult to assign a meaning to "transient" when - two different sites (receiver- and sender- SMTPs) must - agree on the interpretation. Each reply in this category - might have a different time value, but the sender-SMTP is - encouraged to try again. A rule of thumb to determine if - a reply fits into the 4yz or the 5yz category (see below) - is that replies are 4yz if they can be repeated without - any change in command form or in properties of the sender - or receiver. (E.g., the command is repeated identically - and the receiver does not put up a new implementation.) - - 5yz Permanent Negative Completion reply - - The command was not accepted and the requested action did - not occur. The sender-SMTP is discouraged from repeating - the exact request (in the same sequence). Even some - "permanent" error conditions can be corrected, so the - human user may want to direct the sender-SMTP to - reinitiate the command sequence by direct action at some - point in the future (e.g., after the spelling has been - changed, or the user has altered the account status). - - The second digit encodes responses in specific categories: - - x0z Syntax -- These replies refer to syntax errors, - syntactically correct commands that don't fit any - functional category, and unimplemented or superfluous - commands. - - x1z Information -- These are replies to requests for - information, such as status or help. - - x2z Connections -- These are replies referring to the - transmission channel. - - x3z Unspecified as yet. - - x4z Unspecified as yet. - - x5z Mail system -- These replies indicate the status of - the receiver mail system vis-a-vis the requested - transfer or other mail system action. - - The third digit gives a finer gradation of meaning in each - category specified by the second digit. The list of replies - - - -Postel [Page 49] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - illustrates this. Each reply text is recommended rather than - mandatory, and may even change according to the command with - which it is associated. On the other hand, the reply codes - must strictly follow the specifications in this section. - Receiver implementations should not invent new codes for - slightly different situations from the ones described here, but - rather adapt codes already defined. - - For example, a command such as NOOP whose successful execution - does not offer the sender-SMTP any new information will return - a 250 reply. The response is 502 when the command requests an - unimplemented non-site-specific action. A refinement of that - is the 504 reply for a command that is implemented, but that - requests an unimplemented parameter. - - The reply text may be longer than a single line; in these cases - the complete text must be marked so the sender-SMTP knows when it - can stop reading the reply. This requires a special format to - indicate a multiple line reply. - - The format for multiline replies requires that every line, - except the last, begin with the reply code, followed - immediately by a hyphen, "-" (also known as minus), followed by - text. The last line will begin with the reply code, followed - immediately by , optionally some text, and . - - For example: - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - - In many cases the sender-SMTP then simply needs to search for - the reply code followed by at the beginning of a line, and - ignore all preceding lines. In a few cases, there is important - data for the sender in the reply "text". The sender will know - these cases from the current context. - - - - - - - - - - - - -[Page 50] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -APPENDIX F - - Scenarios - - This section presents complete scenarios of several types of SMTP - sessions. - - A Typical SMTP Transaction Scenario - - This SMTP example shows mail sent by Smith at host USC-ISIF, to - Jones, Green, and Brown at host BBN-UNIX. Here we assume that - host USC-ISIF contacts host BBN-UNIX directly. The mail is - accepted for Jones and Brown. Green does not have a mailbox at - host BBN-UNIX. - - ------------------------------------------------------------- - - R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BBN-UNIX.ARPA - - S: MAIL FROM: - R: 250 OK - - S: RCPT TO: - R: 250 OK - - S: RCPT TO: - R: 550 No such user here - - S: RCPT TO: - R: 250 OK - - S: DATA - R: 354 Start mail input; end with . - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 BBN-UNIX.ARPA Service closing transmission channel - - Scenario 1 - - ------------------------------------------------------------- - - - -Postel [Page 51] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Aborted SMTP Transaction Scenario - - ------------------------------------------------------------- - - R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready - S: HELO ISI-VAXA.ARPA - R: 250 MIT-Multics.ARPA - - S: MAIL FROM: - R: 250 OK - - S: RCPT TO: - R: 250 OK - - S: RCPT TO: - R: 550 No such user here - - S: RSET - R: 250 OK - - S: QUIT - R: 221 MIT-Multics.ARPA Service closing transmission channel - - Scenario 2 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - - - - - -[Page 52] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Relayed Mail Scenario - - ------------------------------------------------------------- - - Step 1 -- Source Host to Relay Host - - R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-AI.ARPA - R: 250 USC-ISIE.ARPA - - S: MAIL FROM: - R: 250 OK - - S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with . - S: Date: 2 Nov 81 22:33:44 - S: From: John Q. Public - S: Subject: The Next Meeting of the Board - S: To: Jones@BBN-Vax.ARPA - S: - S: Bill: - S: The next meeting of the board of directors will be - S: on Tuesday. - S: John. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - - - - - - - - - - - - - - - - -Postel [Page 53] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Step 2 -- Relay Host to Destination Host - - R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIE.ARPA - R: 250 BBN-VAX.ARPA - - S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA> - R: 250 OK - - S: RCPT TO: - R: 250 OK - - S: DATA - R: 354 Start mail input; end with . - S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; - 2 Nov 81 22:40:10 UT - S: Date: 2 Nov 81 22:33:44 - S: From: John Q. Public - S: Subject: The Next Meeting of the Board - S: To: Jones@BBN-Vax.ARPA - S: - S: Bill: - S: The next meeting of the board of directors will be - S: on Tuesday. - S: John. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - Scenario 3 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - -[Page 54] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Verifying and Sending Scenario - - ------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin - - S: SEND FROM: - R: 250 OK - - S: RCPT TO: - R: 250 OK - - S: DATA - R: 354 Start mail input; end with . - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 4 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - -Postel [Page 55] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Sending and Mailing Scenarios - - First the user's name is verified, then an attempt is made to - send to the user's terminal. When that fails, the messages is - mailed to the user's mailbox. - - ------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin - - S: SEND FROM: - R: 250 OK - - S: RCPT TO: - R: 450 User not active now - - S: RSET - R: 250 OK - - S: MAIL FROM: - R: 250 OK - - S: RCPT TO: - R: 250 OK - - S: DATA - R: 354 Start mail input; end with . - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 5 - - ------------------------------------------------------------- - - - - - - -[Page 56] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Doing the preceding scenario more efficiently. - - ------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin - - S: SOML FROM: - R: 250 OK - - S: RCPT TO: - R: 250 User not active now, so will do mail. - - S: DATA - R: 354 Start mail input; end with . - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 6 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - -Postel [Page 57] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Mailing List Scenario - - First each of two mailing lists are expanded in separate sessions - with different hosts. Then the message is sent to everyone that - appeared on either list (but no duplicates) via a relay host. - - ------------------------------------------------------------- - - Step 1 -- Expanding the First List - - R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 MIT-AI.ARPA - - S: EXPN Example-People - R: 250- - R: 250-Fred Fonebone - R: 250-Xenon Y. Zither - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250- - R: 250 - - S: QUIT - R: 221 MIT-AI.ARPA Service closing transmission channel - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 58] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Step 2 -- Expanding the Second List - - R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 MIT-MC.ARPA - - S: EXPN Interested-Parties - R: 250-Al Calico - R: 250- - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250- - R: 250 - - S: QUIT - R: 221 MIT-MC.ARPA Service closing transmission channel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 59] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Step 3 -- Mailing to All via a Relay Host - - R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 USC-ISIE.ARPA - - S: MAIL FROM: - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA> - R: 250 OK - S: RCPT - TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with . - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - Scenario 7 - - ------------------------------------------------------------- - - - - - - - - - - - - -[Page 60] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Forwarding Scenarios - - ------------------------------------------------------------- - - R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready - S: HELO LBL-UNIX.ARPA - R: 250 USC-ISIF.ARPA - - S: MAIL FROM: - R: 250 OK - - S: RCPT TO: - R: 251 User not local; will forward to - - S: DATA - R: 354 Start mail input; end with . - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIF.ARPA Service closing transmission channel - - Scenario 8 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 61] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Step 1 -- Trying the Mailbox at the First Host - - R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready - S: HELO LBL-UNIX.ARPA - R: 250 USC-ISIF.ARPA - - S: MAIL FROM: - R: 250 OK - - S: RCPT TO: - R: 251 User not local; will forward to - - S: RSET - R: 250 OK - - S: QUIT - R: 221 USC-ISIF.ARPA Service closing transmission channel - - Step 2 -- Delivering the Mail at the Second Host - - R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready - S: HELO LBL-UNIX.ARPA - R: 250 USC-ISI.ARPA - - S: MAIL FROM: - R: 250 OK - - S: RCPT TO: - R: OK - - S: DATA - R: 354 Start mail input; end with . - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISI.ARPA Service closing transmission channel - - Scenario 9 - - ------------------------------------------------------------- - - - - -[Page 62] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Too Many Recipients Scenario - - ------------------------------------------------------------- - - R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BERKELEY.ARPA - - S: MAIL FROM: - R: 250 OK - - S: RCPT TO: - R: 250 OK - - S: RCPT TO: - R: 552 Recipient storage full, try again in another transaction - - S: DATA - R: 354 Start mail input; end with . - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: MAIL FROM: - R: 250 OK - - S: RCPT TO: - R: 250 OK - - S: DATA - R: 354 Start mail input; end with . - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 BERKELEY.ARPA Service closing transmission channel - - Scenario 10 - - ------------------------------------------------------------- - - Note that a real implementation must handle many recipients as - specified in Section 4.5.3. - - - -Postel [Page 63] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -GLOSSARY - - ASCII - - American Standard Code for Information Interchange [1]. - - command - - A request for a mail service action sent by the sender-SMTP to the - receiver-SMTP. - - domain - - The hierarchially structured global character string address of a - host computer in the mail system. - - end of mail data indication - - A special sequence of characters that indicates the end of the - mail data. In particular, the five characters carriage return, - line feed, period, carriage return, line feed, in that order. - - host - - A computer in the internetwork environment on which mailboxes or - SMTP processes reside. - - line - - A a sequence of ASCII characters ending with a . - - mail data - - A sequence of ASCII characters of arbitrary length, which conforms - to the standard set in the Standard for the Format of ARPA - Internet Text Messages (RFC 822 [2]). - - mailbox - - A character string (address) which identifies a user to whom mail - is to be sent. Mailbox normally consists of the host and user - specifications. The standard mailbox naming convention is defined - to be "user@domain". Additionally, the "container" in which mail - is stored. - - - - - -[Page 64] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - receiver-SMTP process - - A process which transfers mail in cooperation with a sender-SMTP - process. It waits for a connection to be established via the - transport service. It receives SMTP commands from the - sender-SMTP, sends replies, and performs the specified operations. - - reply - - A reply is an acknowledgment (positive or negative) sent from - receiver to sender via the transmission channel in response to a - command. The general form of a reply is a completion code - (including error codes) followed by a text string. The codes are - for use by programs and the text is usually intended for human - users. - - sender-SMTP process - - A process which transfers mail in cooperation with a receiver-SMTP - process. A local language may be used in the user interface - command/reply dialogue. The sender-SMTP initiates the transport - service connection. It initiates SMTP commands, receives replies, - and governs the transfer of mail. - - session - - The set of exchanges that occur while the transmission channel is - open. - - transaction - - The set of exchanges required for one message to be transmitted - for one or more recipients. - - transmission channel - - A full-duplex communication path between a sender-SMTP and a - receiver-SMTP for the exchange of commands, replies, and mail - text. - - transport service - - Any reliable stream-oriented data communication services. For - example, NCP, TCP, NITS. - - - - - -Postel [Page 65] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - user - - A human being (or a process on behalf of a human being) wishing to - obtain mail transfer service. In addition, a recipient of - computer mail. - - word - - A sequence of printing characters. - - - - The characters carriage return and line feed (in that order). - - - - The space character. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 66] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -REFERENCES - - [1] ASCII - - ASCII, "USA Code for Information Interchange", United States of - America Standards Institute, X3.4, 1968. Also in: Feinler, E. - and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for - the Defense Communications Agency by SRI International, Menlo - Park, California, Revised January 1978. - - [2] RFC 822 - - Crocker, D., "Standard for the Format of ARPA Internet Text - Messages," RFC 822, Department of Electrical Engineering, - University of Delaware, August 1982. - - [3] TCP - - Postel, J., ed., "Transmission Control Protocol - DARPA Internet - Program Protocol Specification", RFC 793, USC/Information Sciences - Institute, NTIS AD Number A111091, September 1981. Also in: - Feinler, E. and J. Postel, eds., "Internet Protocol Transition - Workbook", SRI International, Menlo Park, California, March 1982. - - [4] NCP - - McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, - January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET - Protocol Handbook", NIC 7104, for the Defense Communications - Agency by SRI International, Menlo Park, California, Revised - January 1978. - - [5] Initial Connection Protocol - - Postel, J., "Official Initial Connection Protocol", NIC 7101, - 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET - Protocol Handbook", NIC 7104, for the Defense Communications - Agency by SRI International, Menlo Park, California, Revised - January 1978. - - [6] NITS - - PSS/SG3, "A Network Independent Transport Service", Study Group 3, - The Post Office PSS Users Group, February 1980. Available from - the DCPU, National Physical Laboratory, Teddington, UK. - - - - -Postel [Page 67] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - [7] X.25 - - CCITT, "Recommendation X.25 - Interface Between Data Terminal - Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for - Terminals Operating in the Packet Mode on Public Data Networks," - CCITT Orange Book, Vol. VIII.2, International Telephone and - Telegraph Consultative Committee, Geneva, 1976. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 68] Postel - - - diff --git a/server/src/site/resources/rfclist/smtp/rfc0974.txt b/server/src/site/resources/rfclist/smtp/rfc0974.txt deleted file mode 100644 index 912ba11d3fd..00000000000 --- a/server/src/site/resources/rfclist/smtp/rfc0974.txt +++ /dev/null @@ -1,365 +0,0 @@ - -Network Working Group Craig Partridge -Request for Comments: 974 CSNET CIC BBN Laboratories Inc - January 1986 - - MAIL ROUTING AND THE DOMAIN SYSTEM - - -Status of this Memo - - This RFC presents a description of how mail systems on the Internet - are expected to route messages based on information from the domain - system described in RFCs 882, 883 and 973. Distribution of this memo - is unlimited. - -Introduction - - The purpose of this memo is to explain how mailers are to decide how - to route a message addressed to a given Internet domain name. This - involves a discussion of how mailers interpret MX RRs, which are used - for message routing. Note that this memo makes no statement about - how mailers are to deal with MB and MG RRs, which are used for - interpreting mailbox names. - - Under RFC-882 and RFC-883 certain assumptions about mail addresses - have been changed. Up to now, one could usually assume that if a - message was addressed to a mailbox, for example, at LOKI.BBN.COM, - that one could just open an SMTP connection to LOKI.BBN.COM and pass - the message along. This system broke down in certain situations, - such as for certain UUCP and CSNET hosts which were not directly - attached to the Internet, but these hosts could be handled as special - cases in configuration files (for example, most mailers were set up - to automatically forward mail addressed to a CSNET host to - CSNET-RELAY.ARPA). - - Under domains, one cannot simply open a connection to LOKI.BBN.COM, - but must instead ask the domain system where messages to LOKI.BBN.COM - are to be delivered. And the domain system may direct a mailer to - deliver messages to an entirely different host, such as SH.CS.NET. - Or, in a more complicated case, the mailer may learn that it has a - choice of routes to LOKI.BBN.COM. This memo is essentially a set of - guidelines on how mailers should behave in this more complex world. - - Readers are expected to be familiar with RFCs 882, 883, and the - updates to them (e.g., RFC-973). - - - - - - - - - -Partridge [Page 1] - - - -RFC 974 January 1986 -Mail Routing and the Domain System - - -What the Domain Servers Know - - The domain servers store information as a series of resource records - (RRs), each of which contains a particular piece of information about - a given domain name (which is usually, but not always, a host). The - simplest way to think of a RR is as a typed pair of datum, a domain - name matched with relevant data, and stored with some additional type - information to help systems determine when the RR is relevant. For - the purposes of message routing, the system stores RRs known as MX - RRs. Each MX matches a domain name with two pieces of data, a - preference value (an unsigned 16-bit integer), and the name of a - host. The preference number is used to indicate in what order the - mailer should attempt deliver to the MX hosts, with the lowest - numbered MX being the one to try first. Multiple MXs with the same - preference are permitted and have the same priority. - - In addition to mail information, the servers store certain other - types of RR's which mailers may encounter or choose to use. These - are: the canonical name (CNAME) RR, which simply states that the - domain name queried for is actually an alias for another domain name, - which is the proper, or canonical, name; and the Well Known Service - (WKS) RR, which stores information about network services (such as - SMTP) a given domain name supports. - -General Routing Guidelines - - Before delving into a detailed discussion of how mailers are expected - to do mail routing, it would seem to make sense to give a brief - overview of how this memo is approaching the problems that routing - poses. - - The first major principle is derived from the definition of the - preference field in MX records, and is intended to prevent mail - looping. If the mailer is on a host which is listed as an MX for the - destination host, the mailer may only deliver to an MX which has a - lower preference count than its own host. - - It is also possible to cause mail looping because routing information - is out of date or incomplete. Out of date information is only a - problem when domain tables are changed. The changes will not be - known to all affected hosts until their resolver caches time out. - There is no way to ensure that this will not happen short of - requiring mailers and their resolvers to always send their queries to - an authoritative server, and never use data stored in a cache. This - is an impractical solution, since eliminating resolver caching would - make mailing inordinately expensive. What is more, the out-of-date - RR problem should not happen if, when a domain table is changed, - - -Partridge [Page 2] - - - -RFC 974 January 1986 -Mail Routing and the Domain System - - - affected hosts (those in the list of MXs) have their resolver caches - flushed. In other words, given proper precautions, mail looping as a - result of domain information should be avoidable, without requiring - mailers to query authoritative servers. (The appropriate precaution - is to check with a host's administrator before adding that host to a - list of MXs). - - The incomplete data problem also requires some care when handling - domain queries. If the answer section of a query is incomplete - critical MX RRs may be left out. This may result in mail looping, or - in a message being mistakenly labelled undeliverable. As a result, - mailers may only accept responses from the domain system which have - complete answer sections. Note that this entire problem can be - avoided by only using virtual circuits for queries, but since this - situation is likely to be very rare and datagrams are the preferred - way to interact with the domain system, implementors should probably - just ensure that their mailer will repeat a query with virtual - circuits should the truncation bit ever be set. - -Determining Where to Send a Message - - The explanation of how mailers should decide how to route a message - is discussed in terms of the problem of a mailer on a host with - domain name LOCAL trying to deliver a message addressed to the domain - name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically - correct domain names. Furthermore, LOCAL is assumed to be the - official name for the host on which the mailer resides (i.e., it is - not a alias). - -Issuing a Query - - The first step for the mailer at LOCAL is to issue a query for MX RRs - for REMOTE. It is strongly urged that this step be taken every time - a mailer attempts to send the message. The hope is that changes in - the domain database will rapidly be used by mailers, and thus domain - administrators will be able to re-route in-transit messages for - defective hosts by simply changing their domain databases. - - Certain responses to the query are considered errors: - - Getting no response to the query. The domain server the mailer - queried never sends anything back. (This is distinct from an - answer which contains no answers to the query, which is not an - error). - - Getting a response in which the truncation field of the header is - - - -Partridge [Page 3] - - - -RFC 974 January 1986 -Mail Routing and the Domain System - - - set. (Recall discussion of incomplete queries above). Mailers - may not use responses of this type, and should repeat the query - using virtual circuits instead of datagrams. - - Getting a response in which the response code is non-zero. - - Mailers are expected to do something reasonable in the face of an - error. The behaviour for each type of error is not specified here, - but implementors should note that different types of errors should - probably be treated differently. For example, a response code of - "non-existent domain" should probably cause the message to be - returned to the sender as invalid, while a response code of "server - failure" should probably cause the message to be retried later. - - There is one other special case. If the response contains an answer - which is a CNAME RR, it indicates that REMOTE is actually an alias - for some other domain name. The query should be repeated with the - canonical domain name. - - If the response does not contain an error response, and does not - contain aliases, its answer section should be a (possibly zero - length) list of MX RRs for domain name REMOTE (or REMOTE's true - domain name if REMOTE was a alias). The next section describes how - this list is interpreted. - -Interpreting the List of MX RRs - - NOTE: This section only discusses how mailers choose which names to - try to deliver a message to, working from a list of RR's. It does - not discuss how the mailers actually make delivery. Where ever - delivering a message is mentioned, all that is meant is that the - mailer should do whatever it needs to do to transfer a message to a - remote site, given a domain name for that site. (For example, an - SMTP mailer will try to get an address for the domain name, which - involves another query to the domain system, and then, if it gets an - address, connect to the SMTP TCP port). The mechanics of actually - transferring the message over the network to the address associated - with a given domain name is not within the scope of this memo. - - It is possible that the list of MXs in the response to the query will - be empty. This is a special case. If the list is empty, mailers - should treat it as if it contained one RR, an MX RR with a preference - value of 0, and a host name of REMOTE. (I.e., REMOTE is its only - MX). In addition, the mailer should do no further processing on the - list, but should attempt to deliver the message to REMOTE. The idea - - - - -Partridge [Page 4] - - - -RFC 974 January 1986 -Mail Routing and the Domain System - - - here is that if a domain fails to advertise any information about a - particular name we will give it the benefit of the doubt and attempt - delivery. - - If the list is not empty, the mailer should remove irrelevant RR's - from the list according to the following steps. Note that the order - is significant. - - For each MX, a WKS query should be issued to see if the domain - name listed actually supports the mail service desired. MX RRs - which list domain names which do not support the service should be - discarded. This step is optional, but strongly encouraged. - - If the domain name LOCAL is listed as an MX RR, all MX RRs with a - preference value greater than or equal to that of LOCAL's must be - discarded. - - After removing irrelevant RRs, the list can again be empty. This is - now an error condition and can occur in several ways. The simplest - case is that the WKS queries have discovered that none of the hosts - listed supports the mail service desired. The message is thus deemed - undeliverable, though extremely persistent mail systems might want to - try a delivery to REMOTE's address (if it exists) before returning - the message. Another, more dangerous, possibility is that the domain - system believes that LOCAL is handling message for REMOTE, but the - mailer on LOCAL is not set up to handle mail for REMOTE. For - example, if the domain system lists LOCAL as the only MX for REMOTE, - LOCAL will delete all the entries in the list. But LOCAL is - presumably querying the domain system because it didn't know what to - do with a message addressed to REMOTE. Clearly something is wrong. - How a mailer chooses to handle these situations is to some extent - implementation dependent, and is thus left to the implementor's - discretion. - - If the list of MX RRs is not empty, the mailer should try to deliver - the message to the MXs in order (lowest preference value tried - first). The mailer is required to attempt delivery to the lowest - valued MX. Implementors are encouraged to write mailers so that they - try the MXs in order until one of the MXs accepts the message, or all - the MXs have been tried. A somewhat less demanding system, in which - a fixed number of MXs is tried, is also reasonable. Note that - multiple MXs may have the same preference value. In this case, all - MXs at with a given value must be tried before any of a higher value - are tried. In addition, in the special case in which there are - several MXs with the lowest preference value, all of them should be - tried before a message is deemed undeliverable. - - - -Partridge [Page 5] - - - -RFC 974 January 1986 -Mail Routing and the Domain System - - -Minor Special Issues - - There are a couple of special issues left out of the preceding - section because they complicated the discussion. They are treated - here in no particular order. - - Wildcard names, those containing the character '*' in them, may be - used for mail routing. There are likely to be servers on the network - which simply state that any mail to a domain is to be routed through - a relay. For example, at the time that this RFC is being written, all - mail to hosts in the domain IL is routed through RELAY.CS.NET. This - is done by creating a wildcard RR, which states that *.IL has an MX - of RELAY.CS.NET. This should be transparent to the mailer since the - domain servers will hide this wildcard match. (If it matches *.IL - with HUJI.IL for example, a domain server will return an RR - containing HUJI.IL, not *.IL). If by some accident a mailer receives - an RR with a wildcard domain name in its name or data section it - should discard the RR. - - Note that the algorithm to delete irrelevant RRs breaks if LOCAL has - a alias and the alias is listed in the MX records for REMOTE. (E.g. - REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This - can be avoided if aliases are never used in the data section of MX - RRs. - - Implementors should understand that the query and interpretation of - the query is only performed for REMOTE. It is not repeated for the - MX RRs listed for REMOTE. You cannot try to support more extravagant - mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an MX - for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL, - but this does not mean that UNIX.BBN.COM accepts any responsibility - for mail for .IL). - - Finally, it should be noted that this is a standard for routing on - the Internet. Mailers serving hosts which lie on multiple networks - will presumably have to make some decisions about which network to - route through. This decision making is outside the scope of this - memo, although mailers may well use the domain system to help them - decide. However, once a mailer decides to deliver a message via the - Internet it must apply these rules to route the message. - - - - - - - - - -Partridge [Page 6] - - - -RFC 974 January 1986 -Mail Routing and the Domain System - - -Examples - - To illustrate the discussion above, here are three examples of how - mailers should route messages. All examples work with the following - database: - - A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG - A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG - A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG - A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP - - B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG - B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG - B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP - - C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG - C.EXAMP - diff --git a/server/src/site/resources/rfclist/smtp/rfc1652.txt b/server/src/site/resources/rfclist/smtp/rfc1652.txt deleted file mode 100644 index 4700eb5c950..00000000000 --- a/server/src/site/resources/rfclist/smtp/rfc1652.txt +++ /dev/null @@ -1,340 +0,0 @@ - - - - - -Network Working Group J. Klensin, WG Chair -Request for Comments: 1652 MCI -Obsoletes: 1426 N. Freed, Editor -Category: Standards Track Innosoft - M. Rose - Dover Beach Consulting, Inc. - E. Stefferud - Network Management Associates, Inc. - D. Crocker - Silicon Graphics, Inc. - July 1994 - - - SMTP Service Extension for 8bit-MIMEtransport - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This memo defines an extension to the SMTP service whereby an SMTP - content body consisting of text containing octets outside of the US- - ASCII octet range (hex 00-7F) may be relayed using SMTP. - -1. Introduction - - Although SMTP is widely and robustly deployed, various extensions - have been requested by parts of the Internet community. In - particular, a significant portion of the Internet community wishes to - exchange messages in which the content body consists of a MIME - message [3] containing arbitrary octet-aligned material. This memo - uses the mechanism described in [5] to define an extension to the - SMTP service whereby such contents may be exchanged. Note that this - extension does NOT eliminate the possibility of an SMTP server - limiting line length; servers are free to implement this extension - but nevertheless set a line length limit no lower than 1000 octets. - Given that this restriction still applies, this extension does NOT - provide a means for transferring unencoded binary via SMTP. - - - - - - - - -Klensin, Freed, Rose, Stefferud & Crocker [Page 1] - -RFC 1652 SMTP 8bit-MIMEtransport July 1994 - - -2. Framework for the 8bit MIME Transport Extension - - The 8bit MIME transport extension is laid out as follows: - - (1) the name of the SMTP service extension defined here is - 8bit-MIMEtransport; - - (2) the EHLO keyword value associated with the extension is - 8BITMIME; - - (3) no parameter is used with the 8BITMIME EHLO keyword; - - (4) one optional parameter using the keyword BODY is added to - the MAIL FROM command. The value associated with this - parameter is a keyword indicating whether a 7bit message - (in strict compliance with [1]) or a MIME message (in - strict compliance with [3]) with arbitrary octet content - is being sent. The syntax of the value is as follows, - using the ABNF notation of [2]: - - body-value ::= "7BIT" / "8BITMIME" - - (5) no additional SMTP verbs are defined by this extension; - and, - - (6) the next section specifies how support for the extension - affects the behavior of a server and client SMTP. - -3. The 8bit-MIMEtransport service extension - - When a client SMTP wishes to submit (using the MAIL command) a - content body consisting of a MIME message containing arbitrary lines - of octet-aligned material, it first issues the EHLO command to the - server SMTP. If the server SMTP responds with code 250 to the EHLO - command, and the response includes the EHLO keyword value 8BITMIME, - then the server SMTP is indicating that it supports the extended MAIL - command and will accept MIME messages containing arbitrary octet- - aligned material. - - The extended MAIL command is issued by a client SMTP when it wishes - to transmit a content body consisting of a MIME message containing - arbitrary lines of octet-aligned material. The syntax for this - command is identical to the MAIL command in [1], except that a BODY - parameter must appear after the address. Only one BODY parameter may - be used in a single MAIL command. - - - - - - -Klensin, Freed, Rose, Stefferud & Crocker [Page 2] - -RFC 1652 SMTP 8bit-MIMEtransport July 1994 - - - The complete syntax of this extended command is defined in [5]. The - esmtp-keyword is BODY and the syntax for esmtp-value is given by the - syntax for body-value shown above. - - The value associated with the BODY parameter indicates whether the - content body which will be passed using the DATA command consists of - a MIME message containing some arbitrary octet-aligned material - ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT"). - - A server which supports the 8-bit MIME transport service extension - shall preserve all bits in each octet passed using the DATA command. - - Naturally, the usual SMTP data-stuffing algorithm applies so that a - content which contains the five-character sequence of - - - - or a content that begins with the three-character sequence of - - - - does not prematurely terminate the transfer of the content. Further, - it should be noted that the CR-LF pair immediately preceeding the - final dot is considered part of the content. Finally, although the - content body contains arbitrary lines of octet-aligned material, the - length of each line (number of octets between two CR-LF pairs), is - still subject to SMTP server line length restrictions (which may - allow as few as 1000 octets on a single line). This restriction means - that this extension MAY provide the necessary facilities for - transferring a MIME object with the 8BIT content-transfer-encoding, - it DOES NOT provide a means of transferring an object with the BINARY - content-transfer-encoding. - - Once a server SMTP supporting the 8bit-MIMEtransport service - extension accepts a content body containing octets with the high- - order (8th) bit set, the server SMTP must deliver or relay the - content in such a way as to preserve all bits in each octet. - - If a server SMTP does not support the 8-bit MIME transport extension - (either by not responding with code 250 to the EHLO command, or by - not including the EHLO keyword value 8BITMIME in its response), then - the client SMTP must not, under any circumstances, attempt to - transfer a content which contains characters outside the US-ASCII - octet range (hex 00-7F). - - A client SMTP has two options in this case: first, it may implement a - gateway transformation to convert the message into valid 7bit MIME, - or second, or may treat this as a permanent error and handle it in - - - -Klensin, Freed, Rose, Stefferud & Crocker [Page 3] - -RFC 1652 SMTP 8bit-MIMEtransport July 1994 - - - the usual manner for delivery failures. The specifics of the - transformation from 8bit MIME to 7bit MIME are not described by this - RFC; the conversion is nevertheless constrained in the following - ways: - - (1) it must cause no loss of information; MIME transport - encodings must be employed as needed to insure this is - the case, and - - (2) the resulting message must be valid 7bit MIME. - -4. Usage Example - - The following dialogue illustrates the use of the 8bit-MIMEtransport - service extension: - - S: - C: - S: 220 dbc.mtview.ca.us SMTP service ready - C: EHLO ymir.claremont.edu - S: 250-dbc.mtview.ca.us says hello - S: 250 8BITMIME - C: MAIL FROM: BODY=8BITMIME - S: 250 ... Sender and 8BITMIME ok - C: RCPT TO: - S: 250 ... Recipient ok - C: DATA - S: 354 Send 8BITMIME message, ending in CRLF.CRLF. - ... - C: . - S: 250 OK - C: QUIT - S: 250 Goodbye - -5. 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 [1]. - -6. Acknowledgements - - This document represents a synthesis of the ideas of many people and - reactions to the ideas and proposals of others. Randall Atkinson, - Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas - and text sufficient to be considered co-authors. Other important - suggestions, text, or encouragement came from Harald Alvestrand, Jim - Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per - - - -Klensin, Freed, Rose, Stefferud & Crocker [Page 4] - -RFC 1652 SMTP 8bit-MIMEtransport July 1994 - - - Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. - Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John - Wagner, Rayan Zachariassen, and the contributions of the entire IETF - SMTP Working Group. Of course, none of the individuals are - necessarily responsible for the combination of ideas represented - here. Indeed, in some cases, the response to a particular criticism - was to accept the problem identification but to include an entirely - different solution from the one originally proposed. - -7. References - - [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - USC/Information Sciences Institute, August 1982. - - [2] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, UDEL, August 1982. - - [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail - Extensions", RFC 1521, Bellcore, Innosoft, September 1993. - - [4] Moore, K., "Representation of Non-ASCII Text in Internet Message - Headers", RFC 1522, University of Tennessee, September 1993. - - [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, - "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach - Consulting, Inc., Network Management Associates, Inc., Silicon - Graphics, Inc., July 1994. - - [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC - 974, BBN, January 1986. - -8. Chair, Editor, and Authors' Addresses - - John Klensin, WG Chair - MCI Data Services Division - 2100 Reston Parkway, 6th floor - Reston, VA 22091 - USA - - Phone:: 1 703 715 7361 - Fax: +1 703 715 7435 - EMail: klensin@mci.net - - - - - - - - - -Klensin, Freed, Rose, Stefferud & Crocker [Page 5] - -RFC 1652 SMTP 8bit-MIMEtransport July 1994 - - - Ned Freed, Editor - Innosoft International, Inc. - 1050 East Garvey Avenue South - West Covina, CA 91790 - USA - - Phone:: +1 818 919 3600 - Fax: +1 818 919 3614 - EMail: ned@innosoft.com - - - Marshall T. Rose - Dover Beach Consulting, Inc. - 420 Whisman Court - Moutain View, CA 94043-2186 - USA - - Phone: +1 415 968 1052 - Fax: +1 415 968 2510 - EMail: mrose@dbc.mtview.ca.us - - - Einar A. Stefferud - Network Management Associates, Inc. - 17301 Drey Lane - Huntington Beach, CA, 92647-5615 - USA - - Phone: +1 714 842 3711 - Fax: +1 714 848 2091 - EMail: stef@nma.com - - - Dave Crocker - Silicon Graphics, Inc. - 2011 N. Shoreline Blvd. - P.O. Box 7311 - Mountain View, CA 94039 - USA - - Phone: +1 415 390 1804 - Fax: +1 415 962 8404 - EMail: dcrocker@sgi.com - - - - - - - - -Klensin, Freed, Rose, Stefferud & Crocker [Page 6] - - - diff --git a/server/src/site/resources/rfclist/smtp/rfc1830.txt b/server/src/site/resources/rfclist/smtp/rfc1830.txt deleted file mode 100644 index dab73522c16..00000000000 --- a/server/src/site/resources/rfclist/smtp/rfc1830.txt +++ /dev/null @@ -1,452 +0,0 @@ - - - - - -Network Working Group G. Vaudreuil -Request for Comments: 1830 Octel Network Services -Category: Experimental August 1995 - - - SMTP Service Extensions - for Transmission of Large - and Binary MIME Messages - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. This memo does not specify an Internet standard of any - kind. Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -1. Abstract - - This memo defines two extensions to the SMTP service. The first - service enables a SMTP client and server to negotiate the use of an - alternate DATA command "BDAT" for efficiently sending large MIME - messages. The second extension takes advantage of the BDAT command - to permit the negotiated sending of unencoded binary data. - -2. Introduction - - The MIME extensions to the Internet message protocol provides for the - transmission of many kinds of data which were previously unsupported - in Internet mail. Anticipating the need to more efficiently - transport the new media made possible with MIME, the SMTP protocol - has been extended to provide transport for new message types. RFC - 1426 defines one such extension for the transmission of unencoded 8 - bit MIME messages [8BIT]. This service extension permits the - receiver SMTP to declare support for 8 bit body parts and the sender - to request 8 bit transmission of a particular message. - - One expected result of the use of MIME is that the Internet mail - system will be expected to carry very large mail messages. In such - transactions, there is a need to eliminate the requirement that the - message be scanned for "CR LF . CR LF" sequences upon sending and - receiving to detect the end of message. - - Independent of the need to send large messages, Internet mail is - increasingly multi-media there is a need to avoid the overhead of - base64 and quoted-printable encoding of binary objects sent using the - MIME message format over SMTP between hosts which support binary - message processing. - - - - -Vaudreuil Experimental [Page 1] - -RFC 1830 Binary and Large Message Transport August 1995 - - - This memo uses the mechanism defined in [ESMTP] to define two - extensions to the SMTP service whereby a client ("sender-SMTP") may - declare support for the message chunking transmission mode using the - BDAT command and support for the sending of Binary messages. - -3. Framework for the Large Message Extensions - - The following service extension is hereby defined: - - 1) The name of the data chunking service extension is - "CHUNKING". - - 2) The EHLO keyword value associated with this extension is - "CHUNKING". - - 3) A new SMTP verb is defined "BDAT" as an alternative to - the "DATA" command of [RFC821]. The BDAT verb takes two - arguments. The first argument indicates the length of the - binary data packet. The second optional argument indicates - that the data packet is the last. - - bdat-cmd ::= "BDAT" SP chunk-size - [ SP end-marker ] CR LF - chunk-size ::= 1*DIGIT - end-marker ::= "LAST" - - - The CHUNKING service extension enables the use of the BDAT - alternative to the DATA command. This extension can be used for any - message, whether 7 bit, 8BITMIME or BINARYMIME. - - When a client SMTP wishes to submit (using the MAIL command) a large - message using the CHUNKING extension, it first issues the EHLO - command to the server SMTP. If the server SMTP responds with code - 250 to the EHLO command, and the response includes the EHLO keyword - value CHUNKING, then the server SMTP is indicating that it supports - the BDAT command and will accept the sending of messages in chunks. - - After all MAIL FROM and RCPT TO responses are collected and - processed, the message is sent using a series of BDAT commands. The - BDAT command takes one argument, the exact length of the data segment - in octets. The message data is sent immediately after the BDAT - command. Once the receiver-SMTP receives the specified number of - octets, it will return a 250 reply code. - - The LAST parameter on the BDAT command indicates that this is the - last chunk of message data to be sent. Any BDAT command sent after - the BDAT LAST is illegal and must be replied to with a 503 "Bad - - - -Vaudreuil Experimental [Page 2] - -RFC 1830 Binary and Large Message Transport August 1995 - - - sequence of commands" reply code. The state resulting from this error - is indeterminate. A RSET command must be sent to clear the - transaction before continuing. - - A 250 response should be sent to each BDAT data block. If a 5XX code - is sent in response to a BDAT chunk the message should be considered - failed and, the sender SMTP must not send any additional BDAT - segments. If using the ESMTP pipelining extensions [PIPE], the - sender SMTP must complete the sending of the current segment and not - send any more BDATs. When streaming, the receiver SMTP must accept - and discard additional BDAT chunks after the failed BDAT. After - receiving a 5XX error in response to a BDAT command, the resulting - state is indeterminate. A RSET command must be issued to clear the - transaction before additional commands may be sent. - - Note that an error on the receiver SMTP such as disk full or - imminent shutdown can only be reported after the BDAT segment has - been sent. It is therefore important to choose a reasonable chunk - size given the expected end to end bandwidth. - - The RSET command when issued during after the first BDAT and before - the BDAT LAST clears all segments sent during that transaction and - resets the session. - - DATA and BDAT commands cannot be used in the same transaction. If a - DATA statement is issued after a BDAT for the current transaction, a - 503 "Bad sequence of commands" must be issued. The state resulting - from this error is indeterminate. A RSET command must be sent to - clear the transaction before continuing. There is no prohibition on - using DATA and BDAT in the same session, so long as they are not - mixed in the same transaction. - - The local storage size of a message may not accurately reflect the - actual size of the message sent due to local storage conventions. In - particular, text messages sent with the BDAT command must be sent in - the canonical MIME format with lines delimited with a . It - may not be possible to convert the entire message to the canonical - format at once. Chunking provides a mechanism to convert the message - to canonical form, accurately count the bytes, and send the message a - single chunk at a time. - - Note that correct byte counting is essential. If too many bytes - are indicated by the sender SMTP, the receiver SMTP will continue - to wait for the remainder of the data or will read the subsequent - command as additional message data. In the case where a portion - of the previous command was read as data, the parser will return a - syntax error when the incomplete command is read. - - - - -Vaudreuil Experimental [Page 3] - -RFC 1830 Binary and Large Message Transport August 1995 - - - If too few bytes are indicated by the sender SMTP, the receiver - SMTP will interpret the remainder of the message data as invalid - commands. Note that the remainder of the message data may be - binary and as such lexigraphical parsers must be prepared to - receive, process, and reject lines of arbitrary octets. - -4. Framework for the Binary Service Extension - - The following service extension is hereby defined: - - 1) The name of the binary service extension is "BINARYMIME". - - 2) The EHLO keyword value associated with this extension is - "BINARYMIME". - - 3) The BINARYMIME service extension can only be used with - the "CHUNKING" service extension. - - 4) No parameter is used with the BINARYMIME keyword. - - 5) One additional parameter to the BODY keyword defined - [8BIT] for the MAIL FROM command is defined, "BINARYMIME". - The value "BINARYMIME" associated with this parameter - indicates that this message is a Binary MIME message (in - strict compliance with [MIME]) with arbitrary octet content - being sent. The revised syntax of the value is as follows, - using the ABNF notation of [RFC822]: - - body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME" - - 6) No new verbs are defined for the BINARYMIME extension. - - A sender SMTP may request that a binary MIME message be sent without - transport encoding by sending a BINARYMIME parameter with the MAIL - FROM command. When the receiver SMTP accepts a MAIL FROM command - with the BINARYMIME body type requested, it agrees to preserve all - bits in each octet passed using the BDAT command. - - BINARYMIME cannot be used with the DATA command. If a DATA command - is issued after a MAIL FROM command containing the body-value of - "BINARYMIME", a 501 response should be sent. The resulting state - from this error condition is indeterminate and the transaction should - be reset with the RSET command. - - It is important to note that when using BINARYMIME, it is - especially important to ensure that the MIME message itself is - properly formed. In particular, it is essential that text be - canonically encoded with each line properly terminated with - - - -Vaudreuil Experimental [Page 4] - -RFC 1830 Binary and Large Message Transport August 1995 - - - . Any transformation of text into non-canonical MIME to - observe local storage conventions must be reversed before sending - as BINARYMIME. The usual line-oriented shortcuts will break if - used with BINARYMIME. - - The syntax of the extended MAIL command is identical to the MAIL - command in [RFC821], except that a BODY parameter must appear after - the address. The complete syntax of this extended command is defined - in [ESMTP]. The ESMTP-keyword is BODY and the syntax for ESMTP-value - is given by the syntax for body-value in [ESMTP]. - - If a receiver SMTP does not support the BINARYMIME message format - (either by not responding with code 250 to the EHLO command, or by - rejecting the BINARYMIME parameter to the MAIL FROM command, then the - client SMTP must not, under any circumstances, send binary data using - the DATA or BDAT commands. - - If the receiver-SMTP does not support BINARYMIME and the message - content is a MIME object with a binary encoding, a client SMTP has - two options in this case: first, it may implement a gateway - transformation to convert the message into valid 7bit encoded MIME, - or second, it may treat this as a permanent error and handle it in - the usual manner for delivery failures. The specifics of the - transformation from Binary MIME to 7bit MIME are not described by - this RFC; the conversion is nevertheless constrained in the following - ways: - - o The conversion must cause no loss of information; MIME - transport encodings must be employed as needed to insure this - is the case. - - o The resulting message must be valid 7bit MIME. - - As of present there are no mechanisms for converting a binary MIME - object into a 8 bit-MIME object. Such a transformation will require - the specification of a new MIME content-transfer-encoding, the - standardization of which is discouraged by [MIME]. - - - - - - - - - - - - - - -Vaudreuil Experimental [Page 5] - -RFC 1830 Binary and Large Message Transport August 1995 - - -5. Examples - -5.1 Simple Chunking - - The following simple dialogue illustrates the use of the large - message extension to send a short psudo-RFC822 message to one - recipient using the CHUNKING extension: - - - R: - S: - R: 220 cnri.reston.va.us SMTP service ready - S: EHLO ymir.claremont.edu - R: 250-cnri.reston.va.us says hello - R: 250 CHUNKING - S: MAIL FROM: - R: 250 ... Sender ok - S: RCPT TO: - R: 250 ... Recipient ok - S: BDAT 69 LAST - S: To: Susan@random.com - S: From: Sam@random.com - S: Subject: This is a bodyless test message - R: 250 Message OK, 69 octets received - S: QUIT - R: 221 Goodbye - -5.2 Pipelining Binarymime - - The following dialogue illustrates the use of the large message - extension to send a BINARYMIME object to two recipients using the - CHUNKING and PIPELINING extensions: - - R: - S: - R: 220 cnri.reston.va.us SMTP service ready - S: EHLO ymir.claremont.edu - R: 250-cnri.reston.va.us says hello - R: 250-PIPELINING - R: 250-BINARYMIME - R: 250 CHUNKING - S: MAIL FROM: BODY=BINARYMIME - S: RCPT TO: - S: RCPT TO: - R: 250 ... Sender and BINARYMIME ok - R: 250 ... Recipient ok - R: 250 ... Recipient ok - S: BDAT 100000 - - - -Vaudreuil Experimental [Page 6] - -RFC 1830 Binary and Large Message Transport August 1995 - - - S: (First 10000 octets of canonical MIME message data) - S: BDAT 324 LAST - S: (Remaining 324 octets of canonical MIME message data) - R: 250 100000 bytes received - R: 250 Message OK, 100324 octets received - S: QUIT - R: 221 Goodbye - -6. 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 [RFC821], or otherwise - made possible by [MIME]. - -7. Acknowledgments - - This document is the result of numerous discussions in the IETF SMTP - Extensions Working Group and in particular due to the continued - advocacy of "chunking" by Neil Katin. - -8. 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, UDEL, August 1982. - - [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail - Extensions", RFC 1521, Bellcore, Innosoft, June 1992. - - [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., - Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC - 1425, United Nations University, Innosoft International, - Inc., Dover Beach Consulting, Inc., Network Management - Associates, Inc., The Branch Office, February 1993. - - [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., - Stefferud, E., and D. Crocker, "SMTP Service Extension for - 8bit-MIMEtransport" RFC 1426, United Nations University, - Innosoft International, Inc., Dover Beach Consulting, Inc., - Network Management Associates, Inc., The Branch Office, - February 1993. - - [PIPE] Freed, N., "SMTP Service Extensions for Command - Pipelining", Innosoft International, Work in Progress. - - - - -Vaudreuil Experimental [Page 7] - -RFC 1830 Binary and Large Message Transport August 1995 - - -9. Author's Address - - Gregory M. Vaudreuil - Octel Network Services - 17060 Dallas Parkway - Suite 214 - Dallas, TX 75248-1905 - - Voice/Fax: 214-733-2722 - EMail: Greg.Vaudreuil@Octel.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Vaudreuil Experimental [Page 8] - - - diff --git a/server/src/site/resources/rfclist/smtp/rfc1869.txt b/server/src/site/resources/rfclist/smtp/rfc1869.txt deleted file mode 100644 index 64e84a70424..00000000000 --- a/server/src/site/resources/rfclist/smtp/rfc1869.txt +++ /dev/null @@ -1,620 +0,0 @@ - - - - - -Network Working Group J. Klensin, WG Chair -Request For Comments: 1869 MCI -STD: 10 N. Freed, Editor -Obsoletes: 1651 Innosoft International, Inc. -Category: Standards Track M. Rose - Dover Beach Consulting, Inc. - E. Stefferud - Network Management Associates, Inc. - D. Crocker - Brandenburg Consulting - November 1995 - - - SMTP Service Extensions - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - This memo defines a framework for extending the SMTP service by - defining a means whereby a server SMTP can inform a client SMTP as to - the service extensions it supports. Extensions to the SMTP service - are registered with the IANA. This framework does not require - modification of existing SMTP clients or servers unless the features - of the service extensions are to be requested or provided. - -2. Introduction - - The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable, - effective basis for the relay function of message transfer agents. - Although a decade old, SMTP has proven remarkably resilient. - Nevertheless, the need for a number of protocol extensions has become - evident. Rather than describing these extensions as separate and - haphazard entities, this document enhances SMTP in a straightforward - fashion that provides a framework in which all future extensions can - be built in a single consistent way. - -3. Framework for SMTP Extensions - - For the purpose of service extensions to SMTP, SMTP relays a mail - object containing an envelope and a content. - - - - -Klensin, et al Standards Track [Page 1] - -RFC 1869 SMTP Service Extensions November 1995 - - - (1) The SMTP envelope is straightforward, and is sent as a - series of SMTP protocol units: it consists of an - originator address (to which error reports should be - directed); a delivery mode (e.g., deliver to recipient - mailboxes); and, one or more recipient addresses. - - (2) The SMTP content is sent in the SMTP DATA protocol unit - and has two parts: the headers and the body. The - headers form a collection of field/value pairs - structured according to RFC 822 [2], whilst the body, - if structured, is defined according to MIME [3]. The - content is textual in nature, expressed using the US - ASCII repertoire (ANSI X3.4-1986). Although extensions - (such as MIME) may relax this restriction for the - content body, the content headers are always encoded - using the US ASCII repertoire. The algorithm defined in - [4] is used to represent header values outside the US - ASCII repertoire, whilst still encoding them using the - US ASCII repertoire. - - Although SMTP is widely and robustly deployed, some parts of the - Internet community might wish to extend the SMTP service. This memo - defines a means whereby both an extended SMTP client and server may - recognize each other as such and the server can inform the client as - to the service extensions that it supports. - - It must be emphasized that any extension to the SMTP service should - not be considered lightly. SMTP's strength comes primarily from its - simplicity. Experience with many protocols has shown that: - - protocols with few options tend towards ubiquity, whilst - protocols with many options tend towards obscurity. - - This means that 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. - - Given this environment, the framework for the extensions described in - this memo consists of: - - (1) a new SMTP command (section 4) - - (2) a registry of SMTP service extensions (section 5) - - (3) additional parameters to the SMTP MAIL FROM and RCPT TO - commands (section 6). - - - - -Klensin, et al Standards Track [Page 2] - -RFC 1869 SMTP Service Extensions November 1995 - - -4. The EHLO command - - A client SMTP supporting SMTP service extensions should start an SMTP - session by issuing the EHLO command instead of the HELO command. If - the SMTP server supports the SMTP service extensions it will give a - successful response (see section 4.3), a failure response (see 4.4), - or an error response (4.5). If the SMTP server does not support any - SMTP service extensions it will generate an error response (see - section 4.5). - -4.1. Changes to STD 10, RFC 821 - - This specification is intended to extend STD 10, RFC 821 without - impacting existing services in any way. The minor changes needed are - enumerated below. - -4.1.1. First command - - RFC 821 states that the first command in an SMTP session must be the - HELO command. This requirement is hereby amended to allow a session - to start with either EHLO or HELO. - -4.1.2. Maximum command line length - - This specification extends the SMTP MAIL FROM and RCPT TO to allow - additional parameters and parameter values. It is possible that the - MAIL FROM and RCPT TO lines that result will exceed the 512 character - limit on command line length imposed by RFC 821. This limit is - hereby amended to only apply to command lines without any parameters. - Each specification that defines new MAIL FROM or RCPT TO parameters - must also specify maximum parameter value lengths for each parameter - so that implementors of some set of extensions know how much buffer - space must be allocated. The maximum command length that must be - supported by an SMTP implementation with extensions is 512 plus the - sum of all the maximum parameter lengths for all the extensions - supported. - -4.2. Command syntax - - The syntax for this command, using the ABNF notation of [2], is: - - ehlo-cmd ::= "EHLO" SP domain CR LF - - If successful, the server SMTP responds with code 250. On failure, - the server SMTP responds with code 550. On error, the server SMTP - responds with one of codes 500, 501, 502, 504, or 421. - - - - - -Klensin, et al Standards Track [Page 3] - -RFC 1869 SMTP Service Extensions November 1995 - - - This command is issued instead of the HELO command, and may be issued - at any time that a HELO command would be appropriate. That is, if - the EHLO command is issued, and a successful response is returned, - then a subsequent HELO or EHLO command will result in the server SMTP - replying with code 503. A client SMTP must not cache any information - returned if the EHLO command succeeds. That is, a client SMTP must - issue the EHLO command at the start of each SMTP session if - information about extended facilities is needed. - -4.3. Successful response - - If the server SMTP implements and is able to perform the EHLO - command, it will return code 250. This indicates that both the - server and client SMTP are in the initial state, that is, there is no - transaction in progress and all state tables and buffers are cleared. - - Normally, this response will be a multiline reply. Each line of the - response contains a keyword and, optionally, one or more parameters. - The syntax for a positive response, using the ABNF notation of [2], - is: - - ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF - / ( "250-" domain [ SP greeting ] CR LF - *( "250-" ehlo-line CR LF ) - "250" SP ehlo-line CR LF ) - - ; the usual HELO chit-chat - greeting ::= 1* - - ehlo-line ::= ehlo-keyword *( SP ehlo-param ) - - ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - - ; syntax and values depend on ehlo-keyword - ehlo-param ::= 1* - - ALPHA ::= - DIGIT ::= - - CR ::= - LF ::= - - - -Klensin, et al Standards Track [Page 4] - -RFC 1869 SMTP Service Extensions November 1995 - - - SP ::= - - 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 begun in - RFC 821. - - The IANA maintains a registry of SMTP service extensions. Associated - with each such extension is a corresponding EHLO keyword value. Each - service extension registered with the IANA must be defined in an RFC. - Such RFCs must either be on the standards-track or must define an - IESG-approved experimental protocol. The definition must include: - - (1) the textual name of the SMTP service extension; - - (2) the EHLO keyword value associated with the extension; - - (3) the syntax and possible values of parameters associated - with the EHLO keyword value; - - (4) 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); - - (5) any new parameters the extension associates with the - MAIL FROM or RCPT TO verbs; - - (6) how support for the extension affects the behavior of a - server and client SMTP; and, - - (7) the increment by which the extension is increasing the - maximum length of the commands MAIL FROM, RCPT TO, or - both, over that specified in RFC 821. - - In addition, any EHLO keyword value that starts with an upper or - lower case "X" refers to a local SMTP service extension, which is - used through bilateral, rather than standardized, agreement. Keywords - beginning with "X" may not be used in a registered service extension. - - Any 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. - - - - - - -Klensin, et al Standards Track [Page 5] - -RFC 1869 SMTP Service Extensions November 1995 - - - Additional verbs are bound by the same rules as EHLO keywords; - specifically, verbs begining with "X" are local extensions that may - not be registered or standardized and verbs not beginning with "X" - must always be registered. - -4.4. Failure response - - If for some reason the server SMTP is unable to list the service - extensions it supports, it will return code 554. - - In the case of a failure response, the client SMTP should issue - either the HELO or QUIT command. - -4.5. Error responses from extended servers - - If the server SMTP recognizes the EHLO command, but the command - argument is unacceptable, it will return code 501. - - If the server SMTP recognizes, but does not implement, the EHLO - command, it will return code 502. - - If the server SMTP determines that the SMTP service is no longer - available (e.g., due to imminent system shutdown), it will return - code 421. - - In the case of any error response, the client SMTP should issue - either the HELO or QUIT command. - -4.6. Responses from servers without extensions - - A server SMTP that conforms to RFC 821 but does not support the - extensions specified here will not recognize the EHLO command and - will consequently return code 500, as specified in RFC 821. The - server SMTP should stay in the same state after returning this code - (see section 4.1.1 of RFC 821). The client SMTP may then issue - either a HELO or a QUIT command. - -4.7. Responses from improperly implemented servers - - Some SMTP servers are known to disconnect the SMTP transmission - channel upon receipt of the EHLO command. The disconnect can occur - immediately or after sending a response. Such behavior violates - section 4.1.1 of RFC 821, which explicitly states that disconnection - should only occur after a QUIT command is issued. - - Nevertheless, in order to achieve maxmimum interoperablity it is - suggested that extended SMTP clients using EHLO be coded to check for - server connection closure after EHLO is sent, either before or after - - - -Klensin, et al Standards Track [Page 6] - -RFC 1869 SMTP Service Extensions November 1995 - - - returning a reply. If this happens the client must decide if the - operation can be successfully completed without using any SMTP - extensions. If it can a new connection can be opened and the HELO - command can be used. - - Other improperly-implemented servers will not accept a HELO command - after EHLO has been sent and rejected. In some cases, this problem - can be worked around by sending a RSET after the failure response to - EHLO, then sending the HELO. Clients that do this should be aware - that many implementations will return a failure code (e.g., 503 Bad - sequence of commands) in response to the RSET. This code can be - safely ignored. - -5. Initial IANA Registry - - The IANA's initial registry of SMTP service extensions consists of - these entries: - - Service Ext EHLO Keyword Parameters Verb Added Behavior - ------------- ------------ ---------- ---------- ------------------ - Send SEND none SEND defined in RFC 821 - Send or Mail SOML none SOML defined in RFC 821 - Send and Mail SAML none SAML defined in RFC 821 - Expand EXPN none EXPN defined in RFC 821 - Help HELP none HELP defined in RFC 821 - Turn TURN none TURN defined in RFC 821 - - which correspond to those SMTP commands which are defined as optional - in [5]. (The mandatory SMTP commands, according to [5], are HELO, - MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.) - -6. MAIL FROM and RCPT TO Parameters - - It is recognized that several of the extensions planned for SMTP will - make use of additional parameters associated with the MAIL FROM and - RCPT TO command. The syntax for these commands, again using the ABNF - notation of [2] as well as underlying definitions from [1], is: - - esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF - esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) - esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] - esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") - - ; syntax and values depend on esmtp-keyword - esmtp-value ::= 1* - C: - S: 220 dbc.mtview.ca.us SMTP service ready - C: EHLO ymir.claremont.edu - S: 250 dbc.mtview.ca.us says hello - ... - - indicates that the server SMTP implements only those - SMTP commands which are defined as mandatory in [5]. - - - - - - -Klensin, et al Standards Track [Page 8] - -RFC 1869 SMTP Service Extensions November 1995 - - - (2) In contrast, an interaction of the form: - - S: - C: - S: 220 dbc.mtview.ca.us SMTP service ready - C: EHLO ymir.claremont.edu - S: 250-dbc.mtview.ca.us says hello - S: 250-EXPN - S: 250-HELP - S: 250-8BITMIME - S: 250-XONE - S: 250 XVRB - ... - - indicates that the server SMTP also implements the SMTP - EXPN and HELP commands, one standard service extension - (8BITMIME), and two nonstandard and unregistered - service extensions (XONE and XVRB). - - (3) Finally, a server that does not support SMTP service - extensions would act as follows: - - S: - C: - S: 220 dbc.mtview.ca.us SMTP service ready - C: EHLO ymir.claremont.edu - S: 500 Command not recognized: EHLO - ... - - The 500 response indicates that the server SMTP does - not implement the extensions specified here. The - client would normally send a HELO command and proceed - as specified in RFC 821. See section 4.7 for - additional discussion. - -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 RFC-821. It does - provide an announcement of server mail capabilities via the response - to the EHLO verb. However, all information provided by announcement - of any of the initial set of service extensions defined by this RFC - can be readily deduced by selective probing of the verbs required to - transport and deliver mail. The security implications of service - extensions described in other RFCs should be dealt with in those - RFCs. - - - - -Klensin, et al Standards Track [Page 9] - -RFC 1869 SMTP Service Extensions November 1995 - - -10. Acknowledgements - - This document represents a synthesis of the ideas of many people and - reactions to the ideas and proposals of others. Randall Atkinson, - Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas - and text sufficient to be considered co-authors. Other important - suggestions, text, or encouragement came from Harald Alvestrand, Jim - Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per - Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. - Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan - Zachariassen, and the contributions of the entire IETF SMTP Working - Group. Of course, none of the individuals are necessarily responsible - for the combination of ideas represented here. Indeed, in some cases, - the response to a particular criticism was to accept the problem - identification but to include an entirely different solution from the - one originally proposed. - -11. References - - [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - USC/Information Sciences Institute, August 1982. - - [2] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, UDEL, August 1982. - - [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail - Extensions", RFC 1521, Bellcore, Innosoft, September 1993. - - [4] Moore, K., "Representation of Non-ASCII Text in Internet Message - Headers", RFC 1522, University of Tennessee, September 1993. - - [5] Braden, R., "Requirements for Internet Hosts - Application and - Support", STD 3, RFC 1123, USC/Information Sciences Institute, - October 1989. - -12. Chair, Editor, and Author Addresses - - John Klensin, WG Chair - MCI - 2100 Reston Parkway - Reston, VA 22091 - - Phone: +1 703 715-7361 - Fax: +1 703 715-7436 - EMail: klensin@mci.net - - - - - - -Klensin, et al Standards Track [Page 10] - -RFC 1869 SMTP Service Extensions November 1995 - - - Ned Freed, Editor - Innosoft International, Inc. - 1050 East Garvey Avenue South - West Covina, CA 91790 - USA - - Phone: +1 818 919 3600 - Fax: +1 818 919 3614 - EMail: ned@innosoft.com - - - Marshall T. Rose - Dover Beach Consulting, Inc. - 420 Whisman Court - Moutain View, CA 94043-2186 - USA - - Phone: +1 415 968 1052 - Fax: +1 415 968 2510 - EMail: mrose@dbc.mtview.ca.us - - - Einar A. Stefferud - Network Management Associates, Inc. - 17301 Drey Lane - Huntington Beach, CA, 92647-5615 - USA - - Phone: +1 714 842 3711 - Fax: +1 714 848 2091 - EMail: stef@nma.com - - - Dave Crocker - Brandenburg Consulting - 675 Spruce Dr. - Sunnyvale, CA 94086 USA - USA - - Phone: +1 408 246 8253 - Fax: +1 408 249 6205 - EMail: dcrocker@mordor.stanford.edu - - - - - - - - - -Klensin, et al Standards Track [Page 11] - - - diff --git a/server/src/site/resources/rfclist/smtp/rfc1870.txt b/server/src/site/resources/rfclist/smtp/rfc1870.txt deleted file mode 100644 index 30d32082009..00000000000 --- a/server/src/site/resources/rfclist/smtp/rfc1870.txt +++ /dev/null @@ -1,508 +0,0 @@ - - - - - -Network Working Group J. Klensin, WG Chair -Request For Comments: 1870 MCI -STD: 10 N. Freed, Editor -Obsoletes: 1653 Innosoft International, Inc. -Category: Standards Track K. Moore - University of Tennessee - November 1995 - - - SMTP Service Extension - for Message Size Declaration - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - This memo defines an extension to the SMTP service whereby an SMTP - client and server may interact to give the server an opportunity to - decline to accept a message (perhaps temporarily) based on the - client's estimate of the message size. - -2. Introduction - - The MIME extensions to the Internet message protocol provide for the - transmission of many kinds of data which were previously unsupported - in Internet mail. One expected result of the use of MIME is that - SMTP will be expected to carry a much wider range of message sizes - than was previously the case. This has an impact on the amount of - resources (e.g. disk space) required by a system acting as a server. - - This memo uses the mechanism defined in [5] to define extensions to - the SMTP service whereby a client ("sender-SMTP") may declare the - size of a particular message to a server ("receiver-SMTP"), after - which the server may indicate to the client that it is or is not - willing to accept the message based on the declared message size and - whereby a server ("receiver-SMTP") may declare the maximum message - size it is willing to accept to a client ("sender-SMTP"). - - - - - - - - -Klensin, et al Standards Track [Page 1] - -RFC 1870 SMTP Size Declaration November 1995 - - -3. Framework for the Size Declaration Extension - - The following service extension is therefore defined: - - (1) the name of the SMTP service extension is "Message Size - Declaration"; - - (2) the EHLO keyword value associated with this extension is "SIZE"; - - (3) one optional parameter is allowed with this EHLO keyword value, a - decimal number indicating the fixed maximum message size in bytes - that the server will accept. The syntax of the parameter is as - follows, using the augmented BNF notation of [2]: - - size-param ::= [1*DIGIT] - - A parameter value of 0 (zero) indicates that no fixed maximum - message size is in force. If the parameter is omitted no - information is conveyed about the server's fixed maximum message - size; - - (4) one optional parameter using the keyword "SIZE" is added to the - MAIL FROM command. The value associated with this parameter is a - decimal number indicating the size of the message that is to be - transmitted. The syntax of the value is as follows, using the - augmented BNF notation of [2]: - - size-value ::= 1*20DIGIT - - (5) the maximum length of a MAIL FROM command line is increased by 26 - characters by the possible addition of the SIZE keyword and - value; - - (6) no additional SMTP verbs are defined by this extension. - - The remainder of this memo specifies how support for the extension - affects the behavior of an SMTP client and server. - -4. The Message Size Declaration service extension - - An SMTP server may have a fixed upper limit on message size. Any - attempt by a client to transfer a message which is larger than this - fixed upper limit will fail. In addition, a server normally has - limited space with which to store incoming messages. Transfer of a - message may therefore also fail due to a lack of storage space, but - might succeed at a later time. - - - - - -Klensin, et al Standards Track [Page 2] - -RFC 1870 SMTP Size Declaration November 1995 - - - A client using the unextended SMTP protocol defined in [1], can only - be informed of such failures after transmitting the entire message to - the server (which discards the transferred message). If, however, - both client and server support the Message Size Declaration service - extension, such conditions may be detected before any transfer is - attempted. - - An SMTP client wishing to relay a large content may issue the EHLO - command to start an SMTP session, to determine if the server supports - any of several service extensions. If the server responds with code - 250 to the EHLO command, and the response includes the EHLO keyword - value SIZE, then the Message Size Declaration extension is supported. - - If a numeric parameter follows the SIZE keyword value of the EHLO - response, it indicates the size of the largest message that the - server is willing to accept. Any attempt by a client to transfer a - message which is larger than this limit will be rejected with a - permanent failure (552) reply code. - - A server that supports the Message Size Declaration extension will - accept the extended version of the MAIL command described below. - When supported by the server, a client may use the extended MAIL - command (instead of the MAIL command as defined in [1]) to declare an - estimate of the size of a message it wishes to transfer. The server - may then return an appropriate error code if it determines that an - attempt to transfer a message of that size would fail. - -5. Definitions - - The message size is defined as the number of octets, including CR-LF - pairs, but not the SMTP DATA command's terminating dot or doubled - quoting dots, to be transmitted by the SMTP client after receiving - reply code 354 to the DATA command. - - The fixed maximum message size is defined as the message size of the - largest message that a server is ever willing to accept. An attempt - to transfer any message larger than the fixed maximum message size - will always fail. The fixed maximum message size may be an - implementation artifact of the SMTP server, or it may be chosen by - the administrator of the server. - - The declared message size is defined as a client's estimate of the - message size for a particular message. - - - - - - - - -Klensin, et al Standards Track [Page 3] - -RFC 1870 SMTP Size Declaration November 1995 - - -6. The extended MAIL command - - The extended MAIL command is issued by a client when it wishes to - inform a server of the size of the message to be sent. The extended - MAIL command is identical to the MAIL command as defined in [1], - except that a SIZE parameter appears after the address. - - The complete syntax of this extended command is defined in [5]. The - esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by - the syntax for size-value shown above. - - The value associated with the SIZE parameter is a decimal - representation of the declared message size in octets. This number - should include the message header, body, and the CR-LF sequences - between lines, but not the SMTP DATA command's terminating dot or - doubled quoting dots. Only one SIZE parameter may be specified in a - single MAIL command. - - Ideally, the declared message size is equal to the true message size. - However, since exact computation of the message size may be - infeasable, the client may use a heuristically-derived estimate. - Such heuristics should be chosen so that the declared message size is - usually larger than the actual message size. (This has the effect of - making the counting or non-counting of SMTP DATA dots largely an - academic point.) - - NOTE: Servers MUST NOT use the SIZE parameter to determine end of - content in the DATA command. - -6.1 Server action on receipt of the extended MAIL command - - Upon receipt of an extended MAIL command containing a SIZE parameter, - a server should determine whether the declared message size exceeds - its fixed maximum message size. If the declared message size is - smaller than the fixed maximum message size, the server may also wish - to determine whether sufficient resources are available to buffer a - message of the declared message size and to maintain it in stable - storage, until the message can be delivered or relayed to each of its - recipients. - - A server may respond to the extended MAIL command with any of the - error codes defined in [1] for the MAIL command. In addition, one of - the following error codes may be returned: - - (1) If the server currently lacks sufficient resources to accept a - message of the indicated size, but may be able to accept the - message at a later time, it responds with code "452 insufficient - system storage". - - - -Klensin, et al Standards Track [Page 4] - -RFC 1870 SMTP Size Declaration November 1995 - - - (2) If the indicated size is larger than the server's fixed maximum - message size, the server responds with code "552 message size - exceeds fixed maximium message size". - - A server is permitted, but not required, to accept a message which - is, in fact, larger than declared in the extended MAIL command, such - as might occur if the client employed a size-estimation heuristic - which was inaccurate. - -6.2 Client action on receiving response to extended MAIL command - - The client, upon receiving the server's response to the extended MAIL - command, acts as follows: - - (1) If the code "452 insufficient system storage" is returned, the - client should next send either a RSET command (if it wishes to - attempt to send other messages) or a QUIT command. The client - should then repeat the attempt to send the message to the server - at a later time. - - (2) If the code "552 message exceeds fixed maximum message size" is - received, the client should immediately send either a RSET command - (if it wishes to attempt to send additional messages), or a QUIT - command. The client should then declare the message undeliverable - and return appropriate notification to the sender (if a sender - address was present in the MAIL command). - - A successful (250) reply code in response to the extended MAIL - command does not constitute an absolute guarantee that the message - transfer will succeed. SMTP clients using the extended MAIL command - must still be prepared to handle both temporary and permanent error - reply codes (including codes 452 and 552), either immediately after - issuing the DATA command, or after transfer of the message. - -6.3 Messages larger than the declared size. - - Once a server has agreed (via the extended MAIL command) to accept a - message of a particular size, it should not return a 552 reply code - after the transfer phase of the DATA command, unless the actual size - of the message transferred is greater than the declared message size. - A server may also choose to accept a message which is somewhat larger - than the declared message size. - - A client is permitted to declare a message to be smaller than its - actual size. However, in this case, a successful (250) reply code is - no assurance that the server will accept the message or has - sufficient resources to do so. The server may reject such a message - after its DATA transfer. - - - -Klensin, et al Standards Track [Page 5] - -RFC 1870 SMTP Size Declaration November 1995 - - -6.4 Per-recipient rejection based on message size. - - A server that implements this extension may return a 452 or 552 reply - code in response to a RCPT command, based on its unwillingness to - accept a message of the declared size for a particular recipient. - - (1) If a 452 code is returned, the client may requeue the message for - later delivery to the same recipient. - - (2) If a 552 code is returned, the client may not requeue the message - for later delivery to the same recipient. - -7. Minimal usage - - A "minimal" client may use this extension to simply compare its - (perhaps estimated) size of the message that it wishes to relay, with - the server's fixed maximum message size (from the parameter to the - SIZE keyword in the EHLO response), to determine whether the server - will ever accept the message. Such an implementation need not - declare message sizes via the extended MAIL command. However, - neither will it be able to discover temporary limits on message size - due to server resource limitations, nor per-recipient limitations on - message size. - - A minimal server that employs this service extension may simply use - the SIZE keyword value to inform the client of the size of the - largest message it will accept, or to inform the client that there is - no fixed limit on message size. Such a server must accept the - extended MAIL command and return a 552 reply code if the client's - declared size exceeds its fixed size limit (if any), but it need not - detect "temporary" limitations on message size. - - The numeric parameter to the EHLO SIZE keyword is optional. If the - parameter is omitted entirely it indicates that the server does not - advertise a fixed maximum message size. A server that returns the - SIZE keyword with no parameter in response to the EHLO command may - not issue a positive (250) response to an extended MAIL command - containing a SIZE specification without first checking to see if - sufficient resources are available to transfer a message of the - declared size, and to retain it in stable storage until it can be - relayed or delivered to its recipients. If possible, the server - should actually reserve sufficient storage space to transfer the - message. - - - - - - - - -Klensin, et al Standards Track [Page 6] - -RFC 1870 SMTP Size Declaration November 1995 - - -8. Example - - The following example illustrates the use of size declaration with - some permanent and temporary failures. - - S: - C: - S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992) - C: EHLO ymir.claremont.edu - S: 250-sigurd.innosoft.com - S: 250-EXPN - S: 250-HELP - S: 250 SIZE 1000000 - C: MAIL FROM: SIZE=500000 - S: 250 Address Ok. - C: RCPT TO: - S: 250 ned@innosoft.com OK; can accomodate 500000 byte message - C: RCPT TO: - S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU - C: RCPT TO: - S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU - C: DATA - S: 354 Send message, ending in CRLF.CRLF. - ... - C: . - S: 250 Some recipients OK - C: QUIT - S: 221 Goodbye - -9. Security Considerations - - The size declaration extensions described in this memo can - conceivably be used to facilitate crude service denial attacks. - Specifically, both the information contained in the SIZE parameter - and use of the extended MAIL command make it somewhat quicker and - easier to devise an efficacious service denial attack. However, - unless implementations are very weak, these extensions do not create - any vulnerability that has not always existed with SMTP. In addition, - no issues are addressed involving trusted systems and possible - release of information via the mechanisms described in this RFC. - -10. Acknowledgements - - This document was derived from an earlier Working Group work in - progess contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot - Lear, Marshall T. Rose, and Einar Stefferud provided extensive - comments in response to earlier works in progress of both this and - the previous memo. - - - -Klensin, et al Standards Track [Page 7] - -RFC 1870 SMTP Size Declaration November 1995 - - -11. References - - [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - USC/Information Sciences Institute, August 1982. - - [2] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, UDEL, August 1982. - - [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail - Extensions", RFC 1521, Bellcore, Innosoft, September 1993. - - [4] Moore, K., "Representation of Non-ASCII Text in Internet Message - Headers", RFC 1522, University of Tennessee, September 1993. - - [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, - "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft - International, Inc., Dover Beach Consulting, Inc., Network - Management Associates, Inc., Brandenburg Consulting, November - 1995. - - [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC - 974, BBN, January 1986. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Klensin, et al Standards Track [Page 8] - -RFC 1870 SMTP Size Declaration November 1995 - - -12. Chair, Editor, and Author Addresses - - John Klensin, WG Chair - MCI - 2100 Reston Parkway - Reston, VA 22091 - - Phone: +1 703 715-7361 - Fax: +1 703 715-7436 - EMail: klensin@mci.net - - - Ned Freed, Editor - Innosoft International, Inc. - 1050 East Garvey Avenue South - West Covina, CA 91790 - USA - - Phone: +1 818 919 3600 - Fax: +1 818 919 3614 - EMail: ned@innosoft.com - - - Keith Moore - Computer Science Dept. - University of Tennessee - 107 Ayres Hall - Knoxville, TN 37996-1301 - USA - - EMail: moore@cs.utk.edu - - - - - - - - - - - - - - - - - - - - -Klensin, et al Standards Track [Page 9] - - - diff --git a/server/src/site/resources/rfclist/smtp/rfc1891.txt b/server/src/site/resources/rfclist/smtp/rfc1891.txt deleted file mode 100644 index 578cb00d464..00000000000 --- a/server/src/site/resources/rfclist/smtp/rfc1891.txt +++ /dev/null @@ -1,521 +0,0 @@ - - - - - -Network Working Group K. Moore -Request for Comments: 1891 University of Tennessee -Category: Standards Track January 1996 - - - SMTP Service Extension - for Delivery Status Notifications - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - This memo defines an extension to the SMTP service, which allows an - SMTP client to specify (a) that delivery status notifications (DSNs) - should be generated under certain conditions, (b) whether such - notifications should return the contents of the message, and (c) - additional information, to be returned with a DSN, that allows the - sender to identify both the recipient(s) for which the DSN was - issued, and the transaction in which the original message was sent. - - Any questions, comments, and reports of defects or ambiguities in - this specification may be sent to the mailing list for the NOTARY - working group of the IETF, using the address - . Requests to subscribe to the mailing - list should be addressed to . - Implementors of this specification are encouraged to subscribe to the - mailing list, so that they will quickly be informed of any problems - which might hinder interoperability. - - NOTE: This document is a Proposed Standard. If and when this - protocol is submitted for Draft Standard status, any normative text - (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in - this document will be re-evaluated in light of implementation - experience, and are thus subject to change. - -2. Introduction - - The SMTP protocol [1] requires that an SMTP server provide - notification of delivery failure, if it determines that a message - cannot be delivered to one or more recipients. Traditionally, such - notification consists of an ordinary Internet mail message (format - defined by [2]), sent to the envelope sender address (the argument of - - - -Moore Standards Track [Page 1] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - the SMTP MAIL command), containing an explanation of the error and at - least the headers of the failed message. - - Experience with large mail distribution lists [3] indicates that such - messages are often insufficient to diagnose problems, or even to - determine at which host or for which recipients a problem occurred. - In addition, the lack of a standardized format for delivery - notifications in Internet mail makes it difficult to exchange such - notifications with other message handling systems. - - Such experience has demonstrated a need for a delivery status - notification service for Internet electronic mail, which: - -(a) is reliable, in the sense that any DSN request will either be - honored at the time of final delivery, or result in a response - that indicates that the request cannot be honored, - -(b) when both success and failure notifications are requested, - provides an unambiguous and nonconflicting indication of whether - delivery of a message to a recipient succeeded or failed, - -(c) is stable, in that a failed attempt to deliver a DSN should never - result in the transmission of another DSN over the network, - -(d) preserves sufficient information to allow the sender to identify - both the mail transaction and the recipient address which caused - the notification, even when mail is forwarded or gatewayed to - foreign environments, and - -(e) interfaces acceptably with non-SMTP and non-822-based mail - systems, both so that notifications returned from foreign mail - systems may be useful to Internet users, and so that the - notification requests from foreign environments may be honored. - Among the requirements implied by this goal are the ability to - request non-return-of-content, and the ability to specify whether - positive delivery notifications, negative delivery notifications, - both, or neither, should be issued. - - In an attempt to provide such a service, this memo uses the mechanism - defined in [4] to define an extension to the SMTP protocol. Using - this mechanism, an SMTP client may request that an SMTP server issue - or not issue a delivery status notification (DSN) under certain - conditions. The format of a DSN is defined in [5]. - - - - - - - - -Moore Standards Track [Page 2] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -3. Framework for the Delivery Status Notification Extension - - The following service extension is therefore defined: - -(1) The name of the SMTP service extension is "Delivery Status - Notification"; - -(2) the EHLO keyword value associated with this extension is "DSN", - the meaning of which is defined in section 4 of this memo; - -(3) no parameters are allowed with this EHLO keyword value; - -(4) two optional parameters are added to the RCPT command, and two - optional parameters are added to the MAIL command: - - An optional parameter for the RCPT command, using the - esmtp-keyword "NOTIFY", (to specify the conditions under which a - delivery status notification should be generated), is defined in - section 5.1, - - An optional parameter for the RCPT command, using the - esmtp-keyword "ORCPT", (used to convey the "original" - (sender-specified) recipient address), is defined in section 5.2, - and - - An optional parameter for the MAIL command, using the - esmtp-keyword "RET", (to request that DSNs containing an - indication of delivery failure either return the entire contents - of a message or only the message headers), is defined in section - 5.3, - - An optional parameter for the MAIL command, using the - esmtp-keyword "ENVID", (used to propagate an identifier for this - message transmission envelope, which is also known to the sender - and will, if present, be returned in any DSNs issued for this - transmission), is defined in section 5.4; - -(5) no additional SMTP verbs are defined by this extension. - - The remainder of this memo specifies how support for the extension - effects the behavior of a message transfer agent. - -4. The Delivery Status Notification service extension - - An SMTP client wishing to request a DSN for a message may issue the - EHLO command to start an SMTP session, to determine if the server - supports any of several service extensions. If the server responds - with code 250 to the EHLO command, and the response includes the EHLO - - - -Moore Standards Track [Page 3] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - keyword DSN, then the Delivery Status Notification extension (as - described in this memo) is supported. - - Ordinarily, when an SMTP server returns a positive (2xx) reply code - in response to a RCPT command, it agrees to accept responsibility for - either delivering the message to the named recipient, or sending a - notification to the sender of the message indicating that delivery - has failed. However, an extended SMTP ("ESMTP") server which - implements this service extension will accept an optional NOTIFY - parameter with the RCPT command. If present, the NOTIFY parameter - alters the conditions for generation of delivery status notifications - from the default (issue notifications only on failure) specified in - [1]. The ESMTP client may also request (via the RET parameter) - whether the entire contents of the original message should be - returned (as opposed to just the headers of that message), along with - the DSN. - - In general, an ESMTP server which implements this service extension - will propagate delivery status notification requests when relaying - mail to other SMTP-based MTAs which also support this extension, and - make a "best effort" to ensure that such requests are honored when - messages are passed into other environments. - - In order that any delivery status notifications thus generated will - be meaningful to the sender, any ESMTP server which supports this - extension will attempt to propagate the following information to any - other MTAs that are used to relay the message, for use in generating - DSNs: - -(a) for each recipient, a copy of the original recipient address, as - used by the sender of the message. - - This address need not be the same as the mailbox specified in the - RCPT command. For example, if a message was originally addressed - to A@B.C and later forwarded to A@D.E, after such forwarding has - taken place, the RCPT command will specify a mailbox of A@D.E. - However, the original recipient address remains A@B.C. - - Also, if the message originated from an environment which does not - use Internet-style user@domain addresses, and was gatewayed into - SMTP, the original recipient address will preserve the original - form of the recipient address. - -(b) for the entire SMTP transaction, an envelope identification - string, which may be used by the sender to associate any delivery - status notifications with the transaction used to send the - original message. - - - - -Moore Standards Track [Page 4] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -5. Additional parameters for RCPT and MAIL commands - - The extended RCPT and MAIL commands are issued by a client when it - wishes to request a DSN from the server, under certain conditions, - for a particular recipient. The extended RCPT and MAIL commands are - identical to the RCPT and MAIL commands defined in [1], except that - one or more of the following parameters appear after the sender or - recipient address, respectively. The general syntax for extended - SMTP commands is defined in [4]. - - NOTE: Although RFC 822 ABNF is used to describe the syntax of these - parameters, they are not, in the language of that document, - "structured field bodies". Therefore, while parentheses MAY appear - within an emstp-value, they are not recognized as comment delimiters. - - The syntax for "esmtp-value" in [4] does not allow SP, "=", control - characters, or characters outside the traditional ASCII range of 1- - 127 decimal to be transmitted in an esmtp-value. Because the ENVID - and ORCPT parameters may need to convey values outside this range, - the esmtp-values for these parameters are encoded as "xtext". - "xtext" is formally defined as follows: - - xtext = *( xchar / hexchar ) - - xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, - except for "+" and "=". - -; "hexchar"s are intended to encode octets that cannot appear -; as ASCII characters within an esmtp-value. - - hexchar = ASCII "+" immediately followed by two upper case - hexadecimal digits - -When encoding an octet sequence as xtext: - -+ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", - MAY be encoded as itself. (A CHAR in this range MAY instead be - encoded as a "hexchar", at the implementor's discretion.) - -+ ASCII CHARs that fall outside the range above must be encoded as - "hexchar". - -5.1 The NOTIFY parameter of the ESMTP RCPT command - - A RCPT command issued by a client may contain the optional esmtp- - keyword "NOTIFY", to specify the conditions under which the SMTP - server should generate DSNs for that recipient. If the NOTIFY - esmtp-keyword is used, it MUST have an associated esmtp-value, - - - -Moore Standards Track [Page 5] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - formatted according to the following rules, using the ABNF of RFC - 822: - - notify-esmtp-value = "NEVER" / 1#notify-list-element - - notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" - -Notes: - -a. Multiple notify-list-elements, separated by commas, MAY appear in a - NOTIFY parameter; however, the NEVER keyword MUST appear by itself. - -b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled - in any combination of upper and lower case letters. - -The meaning of the NOTIFY parameter values is generally as follows: - -+ A NOTIFY parameter value of "NEVER" requests that a DSN not be - returned to the sender under any conditions. - -+ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" - keywords requests that a DSN be issued on successful delivery or - delivery failure, respectively. - -+ A NOTIFY parameter value containing the keyword "DELAY" indicates the - sender's willingness to receive "delayed" DSNs. Delayed DSNs may be - issued if delivery of a message has been delayed for an unusual amount - of time (as determined by the MTA at which the message is delayed), - but the final delivery status (whether successful or failure) cannot - be determined. The absence of the DELAY keyword in a NOTIFY parameter - requests that a "delayed" DSN NOT be issued under any conditions. - - The actual rules governing interpretation of the NOTIFY parameter are - given in section 6. - - For compatibility with SMTP clients that do not use the NOTIFY - facility, the absence of a NOTIFY parameter in a RCPT command may be - interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. - -5.2 The ORCPT parameter to the ESMTP RCPT command - - The ORCPT esmtp-keyword of the RCPT command is used to specify an - "original" recipient address that corresponds to the actual recipient - to which the message is to be delivered. If the ORCPT esmtp-keyword - is used, it MUST have an associated esmtp-value, which consists of - the original recipient address, encoded according to the rules below. - The ABNF for the ORCPT parameter is: - - - - -Moore Standards Track [Page 6] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - orcpt-parameter = "ORCPT=" original-recipient-address - - original-recipient-address = addr-type ";" xtext - - addr-type = atom - - The "addr-type" portion MUST be an IANA-registered electronic mail - address-type (as defined in [5]), while the "xtext" portion contains - an encoded representation of the original recipient address using the - rules in section 5 of this document. The entire ORCPT parameter MAY - be up to 500 characters in length. - - When initially submitting a message via SMTP, if the ORCPT parameter - is used, it MUST contain the same address as the RCPT TO address - (unlike the RCPT TO address, the ORCPT parameter will be encoded as - xtext). Likewise, when a mailing list submits a message via SMTP to - be distributed to the list subscribers, if ORCPT is used, the ORCPT - parameter MUST match the new RCPT TO address of each recipient, not - the address specified by the original sender of the message.) - - The "addr-type" portion of the original-recipient-address is used to - indicate the "type" of the address which appears in the ORCPT - parameter value. However, the address associated with the ORCPT - keyword is NOT constrained to conform to the syntax rules for that - "addr-type". - - Ideally, the "xtext" portion of the original-recipient-address should - contain, in encoded form, the same sequence of characters that the - sender used to specify the recipient. However, for a message - gatewayed from an environment (such as X.400) in which a recipient - address is not a simple string of printable characters, the - representation of recipient address must be defined by a - specification for gatewaying between DSNs and that environment. - -5.3 The RET parameter of the ESMTP MAIL command - - The RET esmtp-keyword on the extended MAIL command specifies whether - or not the message should be included in any failed DSN issued for - this message transmission. If the RET esmtp-keyword is used, it MUST - have an associated esmtp-value, which is one of the following - keywords: - - FULL requests that the entire message be returned in any "failed" - delivery status notification issued for this recipient. - - HDRS requests that only the headers of the message be returned. - - - - - -Moore Standards Track [Page 7] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - The FULL and HDRS keywords may be spelled in any combination of upper - and lower case letters. - - If no RET parameter is supplied, the MTA MAY return either the - headers of the message or the entire message for any DSN containing - indication of failed deliveries. - - Note that the RET parameter only applies to DSNs that indicate - delivery failure for at least one recipient. If a DSN contains no - indications of delivery failure, only the headers of the message - should be returned. - -5.4 The ENVID parameter to the ESMTP MAIL command - - The ENVID esmtp-keyword of the SMTP MAIL command is used to specify - an "envelope identifier" to be transmitted along with the message and - included in any DSNs issued for any of the recipients named in this - SMTP transaction. The purpose of the envelope identifier is to allow - the sender of a message to identify the transaction for which the DSN - was issued. - - The ABNF for the ENVID parameter is: - - envid-parameter = "ENVID=" xtext - - The ENVID esmtp-keyword MUST have an associated esmtp-value. No - meaning is assigned by the mail system to the presence or absence of - this parameter or to any esmtp-value associated with this parameter; - the information is used only by the sender or his user agent. The - ENVID parameter MAY be up to 100 characters in length. - -5.5 Restrictions on the use of Delivery Status Notification parameters - - The RET and ENVID parameters MUST NOT appear more than once each in - any single MAIL command. If more than one of either of these - parameters appears in a MAIL command, the ESMTP server SHOULD respond - with "501 syntax error in parameters or arguments". - - The NOTIFY and ORCPT parameters MUST NOT appear more than once in any - RCPT command. If more than one of either of these parameters appears - in a RCPT command, the ESMTP server SHOULD respond with "501 syntax - error in parameters or arguments". - -6. Conformance requirements - - The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer - Agents (MTAs) when accepting, relaying, or gatewaying mail, as well - as User Agents (UAs) when submitting mail to the mail transport - - - -Moore Standards Track [Page 8] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - system. The DSN extension to SMTP may be used to allow UAs to convey - the sender's requests as to when DSNs should be issued. A UA which - claims to conform to this specification must meet certain - requirements as described below. - - Typically, a message transfer agent (MTA) which supports SMTP will - assume, at different times, both the role of a SMTP client and an - SMTP server, and may also provide local delivery, gatewaying to - foreign environments, forwarding, and mailing list expansion. An MTA - which, when acting as an SMTP server, issues the DSN keyword in - response to the EHLO command, MUST obey the rules below for a - "conforming SMTP client" when acting as a client, and a "conforming - SMTP server" when acting as a server. The term "conforming MTA" - refers to an MTA which conforms to this specification, independent of - its role of client or server. - -6.1 SMTP protocol interactions - - The following rules apply to SMTP transactions in which any of the - ENVID, NOTIFY, RET, or ORCPT keywords are used: - -(a) If an SMTP client issues a MAIL command containing a valid ENVID - parameter and associated esmtp-value and/or a valid RET parameter - and associated esmtp-value, a conforming SMTP server MUST return - the same reply-code as it would to the same MAIL command without - the ENVID and/or RET parameters. A conforming SMTP server MUST - NOT refuse a MAIL command based on the absence or presence of - valid ENVID or RET parameters, or on their associated - esmtp-values. - - However, if the associated esmtp-value is not valid (i.e. contains - illegal characters), or if there is more than one ENVID or RET - parameter in a particular MAIL command, the server MUST issue the - reply-code 501 with an appropriate message (e.g. "syntax error in - parameter"). - -(b) If an SMTP client issues a RCPT command containing any valid - NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST - return the same response as it would to the same RCPT command - without those NOTIFY and/or ORCPT parameters. A conforming SMTP - server MUST NOT refuse a RCPT command based on the presence or - absence of any of these parameters. - - However, if any of the associated esmtp-values are not valid, or - if there is more than one of any of these parameters in a - particular RCPT command, the server SHOULD issue the response "501 - syntax error in parameter". - - - - -Moore Standards Track [Page 9] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -6.2 Handling of messages received via SMTP - - This section describes how a conforming MTA should handle any - messages received via SMTP. - - NOTE: A DSN MUST NOT be returned to the sender for any message for - which the return address from the SMTP MAIL command was NULL ("<>"), - even if the sender's address is available from other sources (e.g. - the message header). However, the MTA which would otherwise issue a - DSN SHOULD inform the local postmaster of delivery failures through - some appropriate mechanism that will not itself - diff --git a/server/src/site/resources/rfclist/smtp/rfc1893.txt b/server/src/site/resources/rfclist/smtp/rfc1893.txt deleted file mode 100644 index 47454b8811a..00000000000 --- a/server/src/site/resources/rfclist/smtp/rfc1893.txt +++ /dev/null @@ -1,844 +0,0 @@ - - - - - -Network Working Group G. Vaudreuil -Request for Comments: 1893 Octel Network Services -Category: Standards Track January 1996 - - - Enhanced Mail System Status Codes - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Overview - - There currently is not a standard mechanism for the reporting of mail - system errors except for the limited set offered by SMTP and the - system specific text descriptions sent in mail messages. There is a - pressing need for a rich machine readable status code for use in - delivery status notifications [DSN]. This document proposes a new - set of status codes for this purpose. - - SMTP [SMTP] error codes have historically been used for reporting - mail system errors. Because of limitations in the SMTP code design, - these are not suitable for use in delivery status notifications. - SMTP provides about 12 useful codes for delivery reports. The - majority of the codes are protocol specific response codes such as - the 354 response to the SMTP data command. Each of the 12 useful - codes are each overloaded to indicate several error conditions each. - SMTP suffers some scars from history, most notably the unfortunate - damage to the reply code extension mechanism by uncontrolled use. - This proposal facilitates future extensibility by requiring the - client to interpret unknown error codes according to the theory of - codes while requiring servers to register new response codes. - - The SMTP theory of reply codes partitioned in the number space such a - manner that the remaining available codes will not provide the space - needed. The most critical example is the existence of only 5 - remaining codes for mail system errors. The mail system - classification includes both host and mailbox error conditions. The - remaining third digit space would be completely consumed as needed to - indicate MIME and media conversion errors and security system errors. - - A revision to the SMTP theory of reply codes to better distribute the - error conditions in the number space will necessarily be incompatible - with SMTP. Further, consumption of the remaining reply-code number - - - -Vaudreuil Standards Track [Page 1] - -RFC 1893 Mail System Status Codes January 1996 - - - space for delivery notification reporting will reduce the available - codes for new ESMTP extensions. - - The following proposal is based on the SMTP theory of reply codes. - It adopts the success, permanent error, and transient error semantics - of the first value, with a further description and classification in - the second. This proposal re-distributes the classifications to - better distribute the error conditions, such as separating mailbox - from host errors. - -2. Status Codes - - This document defines a new set of status codes to report mail system - conditions. These status codes are intended to be used for media and - language independent status reporting. They are not intended for - system specific diagnostics. - - The syntax of the new status codes is defined as: - - status-code = class "." subject "." detail - class = "2"/"4"/"5" - subject = 1*3digit - detail = 1*3digit - - White-space characters and comments are NOT allowed within a status- - code. Each numeric sub-code within the status-code MUST be expressed - without leading zero digits. - - Status codes consist of three numerical fields separated by ".". The - first sub-code indicates whether the delivery attempt was successful. - The second sub-code indicates the probable source of any delivery - anomalies, and the third sub-code indicates a precise error - condition. - - The codes space defined is intended to be extensible only by - standards track documents. Mail system specific status codes should - be mapped as close as possible to the standard status codes. Servers - should send only defined, registered status codes. System specific - errors and diagnostics should be carried by means other than status - codes. - - New subject and detail codes will be added over time. Because the - number space is large, it is not intended that published status codes - will ever be redefined or eliminated. Clients should preserve the - extensibility of the code space by reporting the general error - described in the subject sub-code when the specific detail is - unrecognized. - - - - -Vaudreuil Standards Track [Page 2] - -RFC 1893 Mail System Status Codes January 1996 - - - The class sub-code provides a broad classification of the status. - The enumerated values the class are defined as: - - 2.X.X Success - - Success specifies that the DSN is reporting a positive delivery - action. Detail sub-codes may provide notification of - transformations required for delivery. - - 4.X.X Persistent Transient Failure - - A persistent transient failure is one in which the message as - sent is valid, but some temporary event prevents the successful - sending of the message. Sending in the future may be successful. - - 5.X.X Permanent Failure - - A permanent failure is one which is not likely to be resolved by - resending the message in the current form. Some change to the - message or the destination must be made for successful delivery. - - A client must recognize and report class sub-code even where - subsequent subject sub-codes are unrecognized. - - The subject sub-code classifies the status. This value applies to - each of the three classifications. The subject sub-code, if - recognized, must be reported even if the additional detail provided - by the detail sub-code is not recognized. The enumerated values for - the subject sub-code are: - - X.0.X Other or Undefined Status - - There is no additional subject information available. - - X.1.X Addressing Status - - The address status reports on the originator or destination - address. It may include address syntax or validity. These - errors can generally be corrected by the sender and retried. - - X.2.X Mailbox Status - - Mailbox status indicates that something having to do with the - mailbox has cause this DSN. Mailbox issues are assumed to be - under the general control of the recipient. - - - - - - -Vaudreuil Standards Track [Page 3] - -RFC 1893 Mail System Status Codes January 1996 - - - X.3.X Mail System Status - - Mail system status indicates that something having to do - with the destination system has caused this DSN. System - issues are assumed to be under the general control of the - destination system administrator. - - X.4.X Network and Routing Status - - The networking or routing codes report status about the - delivery system itself. These system components include any - necessary infrastructure such as directory and routing - services. Network issues are assumed to be under the - control of the destination or intermediate system - administrator. - - X.5.X Mail Delivery Protocol Status - - The mail delivery protocol status codes report failures - involving the message delivery protocol. These failures - include the full range of problems resulting from - implementation errors or an unreliable connection. Mail - delivery protocol issues may be controlled by many parties - including the originating system, destination system, or - intermediate system administrators. - - X.6.X Message Content or Media Status - - The message content or media status codes report failures - involving the content of the message. These codes report - failures due to translation, transcoding, or otherwise - unsupported message media. Message content or media issues - are under the control of both the sender and the receiver, - both of whom must support a common set of supported - content-types. - - X.7.X Security or Policy Status - - The security or policy status codes report failures - involving policies such as per-recipient or per-host - filtering and cryptographic operations. Security and policy - status issues are assumed to be under the control of either - or both the sender and recipient. Both the sender and - recipient must permit the exchange of messages and arrange - the exchange of necessary keys and certificates for - cryptographic operations. - - - - - -Vaudreuil Standards Track [Page 4] - -RFC 1893 Mail System Status Codes January 1996 - - -3. Enumerated Status Codes - - The following section defines and describes the detail sub-code. The - detail value provides more information about the status and is - defined relative to the subject of the status. - - 3.1 Other or Undefined Status - - X.0.0 Other undefined Status - - Other undefined status is the only undefined error code. It - should be used for all errors for which only the class of the - error is known. - - 3.2 Address Status - - X.1.0 Other address status - - Something about the address specified in the message caused - this DSN. - - X.1.1 Bad destination mailbox address - - The mailbox specified in the address does not exist. For - Internet mail names, this means the address portion to the - left of the "@" sign is invalid. This code is only useful - for permanent failures. - - X.1.2 Bad destination system address - - The destination system specified in the address does not - exist or is incapable of accepting mail. For Internet mail - names, this means the address portion to the right of the - "@" is invalid for mail. This codes is only useful for - permanent failures. - - X.1.3 Bad destination mailbox address syntax - - The destination address was syntactically invalid. This can - apply to any field in the address. This code is only useful - for permanent failures. - - X.1.4 Destination mailbox address ambiguous - - The mailbox address as specified matches one or more - recipients on the destination system. This may result if a - heuristic address mapping algorithm is used to map the - specified address to a local mailbox name. - - - -Vaudreuil Standards Track [Page 5] - -RFC 1893 Mail System Status Codes January 1996 - - - X.1.5 Destination address valid - - This mailbox address as specified was valid. This status - code should be used for positive delivery reports. - - X.1.6 Destination mailbox has moved, No forwarding address - - The mailbox address provided was at one time valid, but mail - is no longer being accepted for that address. This code is - only useful for permanent failures. - - X.1.7 Bad sender's mailbox address syntax - - The sender's address was syntactically invalid. This can - apply to any field in the address. - - X.1.8 Bad sender's system address - - The sender's system specified in the address does not exist - or is incapable of accepting return mail. For domain names, - this means the address portion to the right of the "@" is - invalid for mail. - - 3.3 Mailbox Status - - X.2.0 Other or undefined mailbox status - - The mailbox exists, but something about the destination - mailbox has caused the sending of this DSN. - - X.2.1 Mailbox disabled, not accepting messages - - The mailbox exists, but is not accepting messages. This may - be a permanent error if the mailbox will never be re-enabled - or a transient error if the mailbox is only temporarily - disabled. - - X.2.2 Mailbox full - - The mailbox is full because the user has exceeded a - per-mailbox administrative quota or physical capacity. The - general semantics implies that the recipient can delete - messages to make more space available. This code should be - used as a persistent transient failure. - - - - - - - -Vaudreuil Standards Track [Page 6] - -RFC 1893 Mail System Status Codes January 1996 - - - X.2.3 Message length exceeds administrative limit - - A per-mailbox administrative message length limit has been - exceeded. This status code should be used when the - per-mailbox message length limit is less than the general - system limit. This code should be used as a permanent - failure. - - X.2.4 Mailing list expansion problem - - The mailbox is a mailing list address and the mailing list - was unable to be expanded. This code may represent a - permanent failure or a persistent transient failure. - - 3.4 Mail system status - - X.3.0 Other or undefined mail system status - - The destination system exists and normally accepts mail, but - something about the system has caused the generation of this - DSN. - - X.3.1 Mail system full - - Mail system storage has been exceeded. The general - semantics imply that the individual recipient may not be - able to delete material to make room for additional - messages. This is useful only as a persistent transient - error. - - X.3.2 System not accepting network messages - - The host on which the mailbox is resident is not accepting - messages. Examples of such conditions include an immanent - shutdown, excessive load, or system maintenance. This is - useful for both permanent and permanent transient errors. - - X.3.3 System not capable of selected features - - Selected features specified for the message are not - supported by the destination system. This can occur in - gateways when features from one domain cannot be mapped onto - the supported feature in another. - - - - - - - - -Vaudreuil Standards Track [Page 7] - -RFC 1893 Mail System Status Codes January 1996 - - - X.3.4 Message too big for system - - The message is larger than per-message size limit. This - limit may either be for physical or administrative reasons. - This is useful only as a permanent error. - - X.3.5 System incorrectly configured - - The system is not configured in a manner which will permit - it to accept this message. - - 3.5 Network and Routing Status - - X.4.0 Other or undefined network or routing status - - Something went wrong with the networking, but it is not - clear what the problem is, or the problem cannot be well - expressed with any of the other provided detail codes. - - X.4.1 No answer from host - - The outbound connection attempt was not answered, either - because the remote system was busy, or otherwise unable to - take a call. This is useful only as a persistent transient - error. - - X.4.2 Bad connection - - The outbound connection was established, but was otherwise - unable to complete the message transaction, either because - of time-out, or inadequate connection quality. This is - useful only as a persistent transient error. - - X.4.3 Directory server failure - - The network system was unable to forward the message, - because a directory server was unavailable. This is useful - only as a persistent transient error. - - The inability to connect to an Internet DNS server is one - example of the directory server failure error. - - X.4.4 Unable to route - - The mail system was unable to determine the next hop for the - message because the necessary routing information was - unavailable from the directory server. This is useful for - both permanent and persistent transient errors. - - - -Vaudreuil Standards Track [Page 8] - -RFC 1893 Mail System Status Codes January 1996 - - - A DNS lookup returning only an SOA (Start of Administration) - record for a domain name is one example of the unable to - route error. - - X.4.5 Mail system congestion - - The mail system was unable to deliver the message because - the mail system was congested. This is useful only as a - persistent transient error. - - X.4.6 Routing loop detected - - A routing loop caused the message to be forwarded too many - times, either because of incorrect routing tables or a user - forwarding loop. This is useful only as a persistent - transient error. - - X.4.7 Delivery time expired - - The message was considered too old by the rejecting system, - either because it remained on that host too long or because - the time-to-live value specified by the sender of the - message was exceeded. If possible, the code for the actual - problem found when delivery was attempted should be returned - rather than this code. This is useful only as a persistent - transient error. - - 3.6 Mail Delivery Protocol Status - - X.5.0 Other or undefined protocol status - - Something was wrong with the protocol necessary to deliver - the message to the next hop and the problem cannot be well - expressed with any of the other provided detail codes. - - X.5.1 Invalid command - - A mail transaction protocol command was issued which was - either out of sequence or unsupported. This is useful only - as a permanent error. - - X.5.2 Syntax error - - A mail transaction protocol command was issued which could - not be interpreted, either because the syntax was wrong or - the command is unrecognized. This is useful only as a - permanent error. - - - - -Vaudreuil Standards Track [Page 9] - -RFC 1893 Mail System Status Codes January 1996 - - - X.5.3 Too many recipients - - More recipients were specified for the message than could - have been delivered by the protocol. This error should - normally result in the segmentation of the message into two, - the remainder of the recipients to be delivered on a - subsequent delivery attempt. It is included in this list in - the event that such segmentation is not possible. - - X.5.4 Invalid command arguments - - A valid mail transaction protocol command was issued with - invalid arguments, either because the arguments were out of - range or represented unrecognized features. This is useful - only as a permanent error. - - X.5.5 Wrong protocol version - - A protocol version mis-match existed which could not be - automatically resolved by the communicating parties. - - 3.7 Message Content or Message Media Status - - X.6.0 Other or undefined media error - - Something about the content of a message caused it to be - considered undeliverable and the problem cannot be well - expressed with any of the other provided detail codes. - - X.6.1 Media not supported - - The media of the message is not supported by either the - delivery protocol or the next system in the forwarding path. - This is useful only as a permanent error. - - X.6.2 Conversion required and prohibited - - The content of the message must be converted before it can - be delivered and such conversion is not permitted. Such - prohibitions may be the expression of the sender in the - message itself or the policy of the sending host. - - X.6.3 Conversion required but not supported - - The message content must be converted to be forwarded but - such conversion is not possible or is not practical by a - host in the forwarding path. This condition may result when - an ESMTP gateway supports 8bit transport but is not able to - - - -Vaudreuil Standards Track [Page 10] - -RFC 1893 Mail System Status Codes January 1996 - - - downgrade the message to 7 bit as required for the next hop. - - X.6.4 Conversion with loss performed - - This is a warning sent to the sender when message delivery - was successfully but when the delivery required a conversion - in which some data was lost. This may also be a permanant - error if the sender has indicated that conversion with loss - is prohibited for the message. - - X.6.5 Conversion Failed - - A conversion was required but was unsuccessful. This may be - useful as a permanent or persistent temporary notification. - - 3.8 Security or Policy Status - - X.7.0 Other or undefined security status - - Something related to security caused the message to be - returned, and the problem cannot be well expressed with any - of the other provided detail codes. This status code may - also be used when the condition cannot be further described - because of security policies in force. - - X.7.1 Delivery not authorized, message refused - - The sender is not authorized to send to the destination. - This can be the result of per-host or per-recipient - filtering. This memo does not discuss the merits of any - such filtering, but provides a mechanism to report such. - This is useful only as a permanent error. - - X.7.2 Mailing list expansion prohibited - - The sender is not authorized to send a message to the - intended mailing list. This is useful only as a permanent - error. - - X.7.3 Security conversion required but not possible - - A conversion from one secure messaging protocol to another - was required for delivery and such conversion was not - possible. This is useful only as a permanent error. - - - - - - - -Vaudreuil Standards Track [Page 11] - -RFC 1893 Mail System Status Codes January 1996 - - - X.7.4 Security features not supported - - A message contained security features such as secure - authentication which could not be supported on the delivery - protocol. This is useful only as a permanent error. - - X.7.5 Cryptographic failure - - A transport system otherwise authorized to validate or - decrypt a message in transport was unable to do so because - necessary information such as key was not available or such - information was invalid. - - X.7.6 Cryptographic algorithm not supported - - A transport system otherwise authorized to validate or - decrypt a message was unable to do so because the necessary - algorithm was not supported. - - X.7.7 Message integrity failure - - A transport system otherwise authorized to validate a - message was unable to do so because the message was - corrupted or altered. This may be useful as a permanent, - transient persistent, or successful delivery code. - -4. References - - [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - USC/Information Sciences Institute, August 1982. - - [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for - Delivery Status Notifications", RFC 1894, University of - Tennessee, Octel Network Services, January 1996. - -5. Security Considerations - - This document describes a status code system with increased - precision. Use of these status codes may disclose additional - information about how an internal mail system is implemented beyond - that currently available. - -6. Acknowledgments - - The author wishes to offer special thanks to Harald Alvestrand, Marko - Kaittola, and Keith Moore for their extensive review and constructive - suggestions. - - - - -Vaudreuil Standards Track [Page 12] - -RFC 1893 Mail System Status Codes January 1996 - - -7. Author's Address - - Gregory M. Vaudreuil - Octel Network Services - 17060 Dallas Parkway - Suite 214 - Dallas, TX 75248-1905 - - Voice/Fax: +1-214-733-2722 - EMail: Greg.Vaudreuil@Octel.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Vaudreuil Standards Track [Page 13] - -RFC 1893 Mail System Status Codes January 1996 - - -8. Appendix - Collected Status Codes - - X.1.0 Other address status - X.1.1 Bad destination mailbox address - X.1.2 Bad destination system address - X.1.3 Bad destination mailbox address syntax - X.1.4 Destination mailbox address ambiguous - X.1.5 Destination mailbox address valid - X.1.6 Mailbox has moved - X.1.7 Bad sender's mailbox address syntax - X.1.8 Bad sender's system address - - X.2.0 Other or undefined mailbox status - X.2.1 Mailbox disabled, not accepting messages - X.2.2 Mailbox full - X.2.3 Message length exceeds administrative limit. - X.2.4 Mailing list expansion problem - - X.3.0 Other or undefined mail system status - X.3.1 Mail system full - X.3.2 System not accepting network messages - X.3.3 System not capable of selected features - X.3.4 Message too big for system - - X.4.0 Other or undefined network or routing status - X.4.1 No answer from host - X.4.2 Bad connection - X.4.3 Routing server failure - X.4.4 Unable to route - X.4.5 Network congestion - X.4.6 Routing loop detected - X.4.7 Delivery time expired - - X.5.0 Other or undefined protocol status - X.5.1 Invalid command - X.5.2 Syntax error - X.5.3 Too many recipients - X.5.4 Invalid command arguments - X.5.5 Wrong protocol version - - X.6.0 Other or undefined media error - X.6.1 Media not supported - X.6.2 Conversion required and prohibited - X.6.3 Conversion required but not supported - X.6.4 Conversion with loss performed - X.6.5 Conversion failed - - - - - -Vaudreuil Standards Track [Page 14] - -RFC 1893 Mail System Status Codes January 1996 - - - X.7.0 Other or undefined security status - X.7.1 Delivery not authorized, message refused - X.7.2 Mailing list expansion prohibited - X.7.3 Security conversion required but not possible - X.7.4 Security features not supported - X.7.5 Cryptographic failure - X.7.6 Cryptographic algorithm not supported - X.7.7 Message integrity failure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Vaudreuil Standards Track [Page 15] - - - diff --git a/server/src/site/resources/rfclist/smtp/rfc1985.txt b/server/src/site/resources/rfclist/smtp/rfc1985.txt deleted file mode 100644 index a604b425ea1..00000000000 --- a/server/src/site/resources/rfclist/smtp/rfc1985.txt +++ /dev/null @@ -1,396 +0,0 @@ - - - - - -Network Working Group J. De Winter -Request for Comments: 1985 Wildbear Consulting, Inc. -Category: Standards Track August 1996 - - - SMTP Service Extension - for Remote Message Queue Starting - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This memo defines an extension to the SMTP service whereby an SMTP - client and server may interact to give the server an opportunity to - start the processing of its queues for messages to go to a given - host. This extension is meant to be used in startup conditions as - well as for mail nodes that have transient connections to their - service providers. - -1. Introduction - - The TURN command was a valid attempt to address the problem of having - to start the processing for the mail queue on a remote machine. - However, the TURN command presents a large security loophole. As - there is no verification of the remote host name, the TURN command - could be used by a rogue system to download the mail for a site other - than itself. - - Therefore, this memo introduces the ETRN command. This command uses - the mechanism defined in [4] to define extensions to the SMTP service - whereby a client ("sender-SMTP") may request that the server - ("receiver-SMTP") start the processing of its mail queues for - messages that are waiting at the server for the client machine. If - any messages are at the server for the client, then the server should - create a new SMTP session and send the messages at that time. - - - - - - - - - - -De Winter Standards Track [Page 1] - -RFC 1985 SMTP Service Extension - ETRN August 1996 - - -2. Framework for the ETRN Extension - - The following service extension is therefore defined: - - (1) the name of the SMTP service extension is "Remote Queue - Processing Declaration"; - - (2) the EHLO keyword value associated with this extension is "ETRN", - with no associated parameters; - - (3) one additional verb, ETRN, with a single parameter that - specifies the name of the client(s) to start processing for; - - (4) no additional SMTP verbs are defined by this extension. - - The remainder of this memo specifies how support for the extension - affects the behavior of an SMTP client and server. - -3. The Remote Queue Processing Declaration service extension - - To save money, many small companies want to only maintain transient - connections to their service providers. In addition, there are some - situations where the client sites depend on their mail arriving - quickly, so forcing the queues on the server belonging to their - service provider may be more desirable than waiting for the retry - timeout to occur. - - Both of these situations could currently be fixed using the TURN - command defined in [1], if it were not for a large security loophole - in the TURN command. As it stands, the TURN command will reverse the - direction of the SMTP connection and assume that the remote host is - being honest about what its name is. The security loophole is that - there is no documented stipulation for checking the authenticity of - the remote host name, as given in the HELO or EHLO command. As such, - most SMTP and ESMTP implementations do not implement the TURN command - to avoid this security loophole. - - This has been addressed in the design of the ETRN command. This - extended turn command was written with the points in the first - paragraph in mind, yet paying attention to the problems that - currently exist with the TURN command. The security loophole is - avoided by asking the server to start a new connection aimed at the - specified client. - - In this manner, the server has a lot more certainty that it is - talking to the correct SMTP client. This mechanism can just be seen - as a more immediate version of the retry queues that appear in most - SMTP implementations. In addition, as this command will take a - - - -De Winter Standards Track [Page 2] - -RFC 1985 SMTP Service Extension - ETRN August 1996 - - - single parameter, the name of the remote host(s) to start the queues - for, the server can decide whether it wishes to respect the request - or deny it for any local administrative reasons. - -4. Definitions - - Remote queue processing means that using an SMTP or ESMTP connection, - the client may request that the server start to process parts of its - messaging queue. This processing is performed using the existing - SMTP infrastructure and will occur at some point after the processing - is initiated. - - The server host is the node that is responding to the ETRN - command. - - The client host is the node that is initiating the ETRN command. - - The remote host name is defined to be a plain-text field that - specifies a name for the remote host(s). This remote host name may - also include an alias for the specified remote host or special - commands to identify other types of queues. - -5. The extended ETRN command - - The extended ETRN command is issued by the client host when it wishes - to start the SMTP queue processing of a given server host. The - syntax of this command is as follows: - - ETRN [
-

-

-

-
-
- - -

James currently (v2.1) includes only the most basic list functionality, users can subscribe and unsubscribe, but there is no moderation of messages or subscriptions

-

To enable a list you need the following in config.xml in the root processor block and above the final mailet block -

- -<mailet match="CommandForListserv=james@localhost" - class="AvalonListservManager"> - <repositoryName>list-james</repositoryName> -</mailet> - -

that will intercept the command emails sent to -

    -
  • james-on@localhost to subscribe the sender
    • -
  • james-off@localhost to unsubscribe the sender
    • -
-

-

and-

- -<mailet match="RecipientIs=james@localhost" class="AvalonListserv"> - <membersonly> false </membersonly> - <attachmentsallowed> true </attachmentsallowed> - <replytolist> true </replytolist> - <repositoryName>list-james</repositoryName> - <subjectprefix>JamesList</subjectprefix> -</mailet> - -

Which will distribute the mail to the current subscribers

-

in addition to the above you need to have a repository configured in the users-store block(usually near the bottom of config.xml) like so (database)-

- -<repository name="list-james" - class="org.apache.james.userrepository.ListUsersJdbcRepository" - destinationURL="db://maildb/lists/list-james"> - <sqlFile>file://conf/sqlResources.xml</sqlFile> -</repository> - -

Database users will also need to ensure that they have configured a data-source named to match the destination URL

-

Using the filesystem:-

- -<repository name="list-james" - class="org.apache.james.userrepository.UsersFileRepository"> - <destination URL="file://var/lists/list-james/"/> -</repository> - -

Restart James, send a mail to james-on@localhost and you should be subscribed.

-

The repository, be it a database table or directory in the filesystem will be created automatically.

-

Database users can manipulate the users repository using SQL, and hence any application capable of running SQL queries against it.

- - - -

In some simple tests of mail relays James appears to be an open relay, properly configured it is not.

-

Because James is an email application platform it currently accepts all mail delivered to it via SMTP for processing. Only after the mail has been recieved does this processing begin.

-

This means that James accepts Spam. However the default configuration, and any sensible re-configuration has a number of anti-spam measures which will prevent the re-transmisson of spam from James. This makes it a blackhole for spam.

-

This also means that James will not verify addresses, but of course this means that valid addresses can't be harvested from James by spammers either.

- - - -

Check that you've added valid DNS servers to your James installation. Email delivery requires the use of special mail related DNS information (MX records), so James needs to explicitly be given DNS servers. Look at your config.xml file for a <dnsserver> section and add one or more DNS servers.

-

Additionally, check the RemoteAddrNotInNetwork matcher under<processor name="transport">. By default it looks like this:

- -<mailet match="RemoteAddrNotInNetwork=127.0.0.1" class="ToProcessor"> - <processor> spam </processor> -</mailet> - -

because most mail programs will use the external IP address (as opposed to 127.0.0.1) when processing mail, you need to add your internal network and/or your static IP address to this list. You may also use a DNS domain name in this list. The resulting entry would look something like this:

- -<mailet match="RemoteAddrNotInNetwork=127.0.0.1,192.168.1.*" - class="ToProcessor"> - <processor> spam </processor> -</mailet> - -

This tells the processor that anything not in this address list should go to the spam processor.

-

Please note that if you wish to configure James to allow users to send email from any domain or IP address you will need to disable this matcher. In this situation you must use SMTP AUTH to ensure that your server does not act as an open relay. For more on open relays, please see the Open Relay Database.

- - - -

You need to do one of two things: -

    -
  1. Update your domain's DNS entries so there are MX records that point to the machine that is running James. Note that it is illegal for MX records to point to IP addresses. You need to point MX records to a valid CNAME or A name entry, and then map that eventually to an IP address.
    2. -
  2. You could alternatively give people an email address with IP addresses. Most people will think it's a very strange email address, but hello@[192.168.0.1] is a valid email address. Note that you need to wrap the IP address in brackets.
    3. -
-

- - - -

First step is to look in the log directory at the mailet.log file. Look for entries that include the text "RemoteDelivery". This should provide some high-level debug information of James' attempt to delivery mail remotely.

-

If you want to delve into the code, look at the RemoteDelivery mailet. You may also want to review the mail repository source code for the repository type you are using (file, db, etc...).

- - - -

IMAP development had been stalled, but has recently attracted new activity. IMAP support is scheduled for inclusion in James v3. In the meantime, there is experimental code in the repository. If you are interested in working on or trying the IMAP prototype code, join the james-dev mailing list and let us know.

- - - -

James v2.1 includes a new mailet for database users, JDBCVirtualUserTable, that mimics some of the sendmail capabilities of the same name.

-

JDBCVirtualUserTable does not provide any administation tools. -You'll have to create and maintain the database table yourself. The -standard configuration is as follows:

- -CREATE TABLE VirtualUserTable -( - user varchar(64) NOT NULL default '', - domain varchar(255) NOT NULL default '', - target_address varchar(255) NOT NULL default '', - PRIMARY KEY (user,domain) -); - -

The standard query used with VirtualUserTable is:

- -select VirtualUserTable.target_address from VirtualUserTable, VirtualUserTable as VUTDomains -where (VirtualUserTable.user like ? or VirtualUserTable.user like "\%") -and (VirtualUserTable.domain like ? -or (VirtualUserTable.domain like "\%" and VUTDomains.domain like ?)) -order by concat(VirtualUserTable.user,'@',VirtualUserTable.domain) desc limit 1 - -

For a given [user, domain, domain] used with the query, this will -match as follows (in precedence order): -

    -
  1. user@domain - explicit mapping for user@domain
    2. -
  2. user@% - catchall mapping for user anywhere
    3. -
  3. %@domain - catchall mapping for anyone at domain
    4. -
  4. null - no valid mapping
    5. -
-

-

A sample mailet looks like:

- -<mailet match="All" class="JDBCVirtualUserTable"> - <table>db://maildb/VirtualUserTable</table> -</mailet> - -

More generalized viirtual hosting is something the developers are still discussing. One issue is that POP3 does not support virtual hosting in that it does not have a command to indicate what domain the user is in. What this means is the mail server needs to support a 'mapping' or 'translation' convention, e.g., 'user1@domaina.com' gets a username 'domaina.user1'. This allows the mail server to have a single username namespace. We have seen a few good proposals put forward, but nothing that seemed the clear solution, as ideally we could have this part solve the next issue.

-

Beyond that, James needs to refine virtual hosting for mailet processing. With the current user model, the mailet API has a Mail.getUser() method that no longer would be useable as a reliable indicator of whether they were in the local username namespace. To date we are unclear of the best way to bring this translation into the mailet processing. Similarly, it would be nice to support different mailet processing based on the domain, although this is somewhat feasible using the limited processing flow offered with a HostIs matcher.

-

Virtual hosting is one of the most requested features, and additional work is scheduled for the 3.0 release.

- - - -

We are largely reliant on what Avalon is doing in terms of classloading, but here are a few tips and suggestions: -

- Eventually we hope to support mailet reloading and a special lib and classes directory within the james directory that custom mailets can load from, but for now these are hopefully some useful tips.

- - - -

-

    -
  1. Rename the previous james directory into a james.old
    2. -
  2. Run phoenix to let the new james.sar be deployed.
    3. -
  3. Edit the newly deployed config.xml to reflect your customizations from the previous config.xml.
    4. -
  4. If using JDBC, see necessary table changes. -
    5. -
  5. Replace the var directory by the previous var directory. This will copy over user accounts, inboxes, spools, and whatever else.
    6. -
  6. Restart James.
    7. -
-

- - - -

The version of Avalon Phoenix distributed with James v2.1 and later includes a wrapper that lets you run James as a service. An alternative strategy is to install the JavaService from Alexandia Software.

- - - -

Check the JavaMail docs. Per the API, when you call MimeMessage.setContent(blah), you have to call saveChanges() to apply your changes. James tries to automatically call this method so you don't have to, but in certain cases you'll still have to call saveChanges().

- - - -

The following information is based on James 2.0a3, but the - upcoming 2.1 version should be similar.

-

NNTP and other underlying services are called "blocks" in the - Avalon Phoenix terminology. Blocks are specified in the - assembly.xml file which is located in the apps/james/SAR-INF directory (2.1) - or apps/james/conf directory (2.0a3). Note: this file is created - during the first startup of James.

-

There are dependencies between the blocks, which you can read from - the file. For example the SMTP Server block depends on the - users-store block, so if you want SMTP then you cannot remove the - users-store block even if you only want to relay messages.

-

To remove the NNTP Server comment out the following blocks: - NNTP server, NNTP Authentication Service, NNTP repository. - To remove the POP3 Server comment out the POP3 Server block.

-

If you remove a block it wont't be loaded next time you restart - James. You must also remove all sections related to the removed - blocks from the James configuration file - config.xml - otherwise - you will get error messages, saying that there is no corresponding - block.

- - - -

Read the "Contributors How To" here -

- - - -

Read the "sendmail How To" here -

- - - -

I am using Microsoft's SQL Type 4 JDBC Driver, why do I get the following exception?
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Can't start manual transaction mode because there are cloned connections.

-

This seems to be a problem with the Microsoft Type 4 JDBC Driver and concurrent statements/transactions/resultsets on the same database conntection.

-

To solve this you need to add ;SelectMethod=cursor to the end of your dburl string. Your dburl string would then look something like this
<dburl>jdbc:microsoft:sqlserver://dbserver.host.name:1433;SelectMethod=cursor</dburl>

-

NOTE: some people have complained about performance when using this option, the alternative is a 3rd party JDBC driver but these are often not free.

- - - -

When a user tries to send a large message that is close to but not quite at the max message limit the send fails and an exception similar to the following appears in the log:

-

Sent: 451 Error processing message:
- Exception spooling message: Exception caught while storing mail Container:
- java.lang.IllegalArgumentException: Packet is larger than max_allowed_packet
- from server configuration of 4193280 bytes;
- nested exception is:
- java.lang.RuntimeException: Exception caught while storing mail
- Container: java.lang.IllegalArgumentException: Packet is larger than
- max_allowed_packet from server configuration of 4193280 bytes
-

-

Because of how the JDBC driver is written, a 25% - factor is necessary between the maximum message size and the max_packet_size - to prevent the driver from throwing an exception. So if you want a 4MB - maximum message size, you need a 5MB max_packet size. Or a 4MB - max_packet_size allows only a 3.2MB max message. -

- - - -

First of all read this: ASF Source Code. -
Now go to http://subversion.tigris.org/ and download a subversion client. -
James subversion repository is at http://svn.apache.org/repos/asf/james/server. Commiters use "https". -
You may want to search the web, our dev and user mail archives or our wiki for more information.

- -
- - diff --git a/server/src/site/xdoc/archive/announcement_2_1.xml b/server/src/site/xdoc/archive/announcement_2_1.xml deleted file mode 100755 index 9c94d0384bb..00000000000 --- a/server/src/site/xdoc/archive/announcement_2_1.xml +++ /dev/null @@ -1,57 +0,0 @@ - - - - - James 2.1 - Release Announcement - - -
-

The Java Apache Mail Enterprise Server (a.k.a. Apache James) Project is happy to announce the release -of version 2.1 of the Apache James server.

- -

James is a 100% pure Java Mail and News server designed to be a complete and portable enterprise -mail engine solution. James supports currently available IETF protocols, including SMTP and POP3 -(NNTP is experimental in v2.1, and it and IMAP are targeted for full functionality in v3). James -is able to store user and message data either in a file-system or a JDBC-compatible database, -allowing fast, reliable, even real-time replicated storage.

- -

James provides a powerful, flexible mail application engine through support for the Apache Mailet -API. With its Mailet pipeline architecture, James can be used not only to provide standard e-mail -services, but also to implement custom e-mail applications.

- -

The James mail server is deployed in production environments and has proven itself to be a robust -and high performance mail solution. Tests indicate that version 2.1 is able to maintain a constant -mail throughput rate of thousands of messages/minute for continuous periods.

- -

The James Community is also happy to announce the beginning of the design phase for James version -3.0. Features tentatively slated for that version include enhancements to nearly every area of -functionality, including full IMAP support, improved mailing list capabilities, and the next revision -of the Mailet API. This is expected to be an exciting time in James development. We are actively -looking for eager, capable developers to contribute to James. If you're interesting in contributing -to the James project, please subscribe to the James developer mailing list.

- -

Information about James can be found at the James web site -at http://james.apache.org/. Users interested in subscribing to the James -user and -developer mailings lists should send emails -to server-user-subscribe@james.apache.org and server-dev-subscribe@james.apache.org, respectively

-
- - diff --git a/server/src/site/xdoc/archive/architecture_v1_2.xml b/server/src/site/xdoc/archive/architecture_v1_2.xml deleted file mode 100644 index 42e1bbf1f1f..00000000000 --- a/server/src/site/xdoc/archive/architecture_v1_2.xml +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - James 1.2 - Architecture - - - -
- -

- JAMES is a multi-protocol message processing and storage engine. JAMES - currently consists of: -

-
    -
  • two mail prototcol servers (SMTP and POP3),
    • -
  • a remote administration server,
    • -
  • a mail processing engine that supports the Mailet API
    • -
  • file-system message storage and a message storage interface to RDBMS's
    • -
  • file-system user record storage and an experimental interface to LDAP directories
    • -
  • beta support for TLS (SSL) for POP3 and remote administration
    • -
-

- JAMES is built on top of Avalon, the Java Apache Server Framework. - Versions 1.1 and 1.2 of James use a slightly older version of Avalon, - specifically the avalon-james-1-1b1 branch. We intend to - migrate to the new Avalon in the near future. -

- -
- - - diff --git a/server/src/site/xdoc/archive/architecture_v2_0.xml b/server/src/site/xdoc/archive/architecture_v2_0.xml deleted file mode 100644 index a47c631ef61..00000000000 --- a/server/src/site/xdoc/archive/architecture_v2_0.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - Notes for developers - Serge Knystautas - - - - -
- -

- James is a multi-protocol message processing and storage engine. James - currently consists of: -

    -
  • two mail prototcol servers (SMTP and POP3),
    • -
  • a remote administration server,
    • -
  • an NNTP server,
    • -
  • a mail processing engine that supports the Mailet API
    • -
  • file-system message storage and a message storage interface to RDBMS's
    • -
  • file-system user record storage and an experimental interface to LDAP directories
    • -
  • support for TLS (SSL) for POP3 and remote administration
    • -
  • support for SMTP auth
    • -
-

- -

- James is built on top of Avalon, the Java Apache Server Framework. - Versions 2.0 of James use a date-snapshot of Avalon code as of November 2001. - The lib directory includes date-stamped jars of the various Avalon libraries. - We intend to stay current with new versions of Avalon as they are released.

- -
- - - diff --git a/server/src/site/xdoc/archive/configuration_v2_0.xml b/server/src/site/xdoc/archive/configuration_v2_0.xml deleted file mode 100644 index 7020fabc809..00000000000 --- a/server/src/site/xdoc/archive/configuration_v2_0.xml +++ /dev/null @@ -1,716 +0,0 @@ - - - - - - Configuration - Serge Knystautas - - - - -
- -

-

-

This document explains the JAMES.conf.xml file for James 2.0 -
JAMES 2.0 uses a date-stamped version of Avalon from late September 2001. - The lib directory includes jars with date-stamped names for the Avalon libraries. -
-

-
-

- -
- -
- -

- These tag elements control the JAMES spooling and identification - settings. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<name>default valuemeaning
postmaster Postmaster@localhost Is the source of error replies and the email users will mail to for any problem. You - should change this to an address that can receive incoming messages.
helloName attribute autodetect=TRUE and value of 'myMailServer' The name by which James will identify itself in SMTP and POP3 - greetings. If autodetect is TRUE James will attempt to detect - automatically the name, failing which it will use 'localhost'. If - autodetect is not TRUE, James will use the specified name or - 'localhost' if none is specified. Look in jamesinfo.log for - lines like "[...] Local host is: [servername] and [...] Hello Name is: [machine name]"
servernames/servername attribute autodetect=TRUE and last value of 'localhost' A list of host names James will consider as local. Any user [user]@[servername] - will be considered to be local. If autodetect is TRUE James will attempt to detect - automatically the name and use any names specified. Look in jamesinfo.log for a line like "[...] Handling mail for:: [domain/host]"
spoolRepository file://var/mail/spool/ This is the path where incoming messages are stored before beeing processed.
inboxRepository file://var/mail/localinbox/ This is the root for local users inbox. Each user will have a personal folder - [inboxRepository]/[user]
spoolmanagerthreads 5 This is the number of thread that work polling mails from the spool and take care - of processing them.
- - - -

- These tag elements affect the SMTP listener (for incoming messages). -

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
<name>default valuemeaning
port 25 The port we are listening to.
bind N.A. Specific IP addresses that you wish to bind this service to.
smtphandler N.A. Parent for all SMTPHandler configuations.
connectiontimeout 120000 If nothing is received from an open connection for more than {timeout] mills - the connection is closed.
- - - -

- These tag elements affect the POP3 server (for message retrieval) -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<name>default valuemeaning
port 110 The port we are listening to.
bind N.A. Specific IP addresses that you wish to bind this service to.
useTLS false Whether you wish to require/use TLS (SSL) on this port.
pop3handler N.A. Parent for all POP3Handler configuations.
connectiontimeout 120000 If nothing is received from an open connection for more than {timeout] mills - the connection is closed.
- - - -

- These tag elements affect the configuration of the list of local users. -

- - - - - - - - - - - -
<name>default valuemeaning
repository file://var/users/ The path where local mail account informations are stored.
- - - -

- These tag elements affect the remote manager, a telnet based utility - to manage the User Manager. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<name>default valuemeaning
port 4555 The port we are listening to.
bind N.A. Specific IP addresses that you wish to bind this service to.
useTLS false Whether you wish to require/use TLS (SSL) on this port.
administrator_accounts N.A. The parent of <account>
account login="root" password="root" A list of root account to administer JAMES.
connectiontimeout 120000 If nothing is received from an open connection for more than {timeout] mills
- - - -

- These tag elements affect SMTP remote delivery, specifically, DNS - lookup functionality. -

- - - - - - - - - - - - - - - - - - - - - - - - - - -
<name>default valuemeaning
dnsServer/servers/server N.A. This is a list of DNS to resolve external address.
authoritative false Whether to require authoritative (non-cached) DNS records. Should always be false - unless you understand the implications.
repository file://var/mail/delayed/ This is a temp repository path shared with the name of "TMP_REPOSITORY". - It is used by the RemoteDelivery Mailet to store mail for futher delivery. - (Note: this is not very elegant and will probally change soon)
mailets rootpath="org.apache.james.transport.mailets." This is the parent node for all mailet configurations. The rootpath specify - where mailet repository is. (Note: need to plug more than one repository)
- -
- -
-

- This is James sitemap. It defines how each incoming mail will be - processed. Incoming mails begins their process at the first mailet in the - pipe. Each step is described by a <servet> tag with some attributes: - <mailet match="[matchClass]=[matchParameters]" - class="[mailetClass]">. - The Matcher class split the mail into two Collections: one with all recipients - matching conditions and the other with all recipient not matching. All information - in the mail except recipients cloned so the message that both matching and not matching - are identical (again except recipients). The matching recipients and mail will be passed to - the specified mailet for processing. After processing both mails, the - untouched not-matching mail and the processed matching mail, each go to next step in - the processor. Some mailets will indicate the mail should be consumed and no continue processing. - The Null mailet for example will simply consume any incoming mail as will the RemoteDelivery - since after delivery the mail needs no more processing. -

- - -

- The Matcher interface defines how match class should work. Their work is - to split a Vector of recipients into two: the ones matching a specified - condition and all others. - Currently implemented matchers: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
class nameparameteractionexample
All none match all recipients. match="All"
HasAttachment none match all recipients if the message has an attachment (if content type is multipart/mixed). match="All"
HostIs comma separated list of hosts names match all recipients belonging to one of the specified hosts match="HostIs=myHost.mydom.org,yourHost"
HostIsLocal none check recipients's hosts against the list of host names set in configuration for localhost - (see <servername>). match="HostIsLocal"
InSpammerBlacklist DNS zone with blacklist match all recipients if mail received from an IP address on the blacklist. match="InSpammerBlacklist=blackholes.mail-abuse.org"
IsSingleRecipient none match mail if only has 1 recipient. match="IsSingleRecipient"
NESSpamCheck none match all recipients if mail matches various spam detection rules. match="NESSpamCheck"
RecipientIs comma separated list of recipients match all recipients defined in condition. match="RecipientIs=root@localhost,admin@localhost"
RecipientIsLocal none match recipient which host is local (see HostIsLocal) and that are recognized by the - Users Manager to be local accounts. match="RecipientIsLocal"
RelayLimit Maximum number of hops. match all recipients if the message has more than the specified number of SMTP hops. - Important to prevent race conditions in SMTP delivery. - match="RelayLimit=30"
RemoteAddrInNetwork comma separated list of network addresses match all recipients if the message was received from an IP address that matches the - comma separated list. Wildcards are supposed, e.g., 192.168.0.* is a valid option. - match="RemoteAddrInNetwork=127.0.0.1,192.168.*"
RemoteAddrNotInNetwork comma separated list of network addresses match all recipients if the message was not received from an IP address that matches - the comma separated list. Wildcards are supposed, e.g., 192.168.0.* is a valid option. - match="RemoteAddrNotInNetwork=127.0.0.1,192.168.*"
SenderInFakeDomain none match recipients who's domain name portion of their email address is invalid. Queries - for A, CNAME, and MX record entries. match="SenderInFakeDomain"
SenderIs comma separated list of address. match all recipients if sender is in the condition string, else match none. match="SenderIs=badBay@badhost"
SizeGreaterThan number of bytes. supports 'k' and 'm' suffixes. match all recipients if message is larger than the given number of bytes, kilobytes, or megabytes. match="SizeGreaterThan=1m"
SubjectIs comma separated list of address. match all recipients if the subject is equal to the condition string, else match none. match="SubjectIs=REMOVE"
SubjectStartsWith comma separated list of address. match all recipients if the subject starts with the condition string, else match none. match="SubjectStartsWith: [ADV]"
UserIs comma separated list of accounts match all recipients defined in condition regardless of host. match="UserIs=root,admin"
-

- Some examples: -
- - <mailet match="RecipientIsLocal" - class="LocalDelivery"> -
-
- - <mailet match="UserIs=root" - class="Forward"> -
-
- - <mailet match="SenderIs=badBoy@myhost,badGirl@yourhost" - class="Null"> -
-

- - - -

- Mailet are classes that process a message. They are - passed a Mail object on which they can perform any kind of task. - Clever use of mailets allow you to write an email-based application. - Simple mailets provide basic mail functionality like mail forwarding, - mailing list, "I'm on vacation" message, mail logging etc. As simply as - these mailet, you can write and deploy your own mailet to perform any kind of task. -
- Here you are some of the mailets bundled with James along with their configuration: -
-

- Null -
- Consume any incoming mail. No configuration needed. -
- <mailet match="SenderIs=badBoy@badhost" class="Null"> - </mailet> -
-
- debug.Identity -
- Leave any incoming mail untouched. A debug mailet - (not really useful). - No configuration needed. -
- <mailet match="All" class="Identity"> - </mailet>
-
- Forward -
-
- Replace the recipient list with recipient specified in - configurations.
-
- <mailet match="RecipientIs=root@localhost" - class="Forward">
-
-
- <forwardto> green@blue.org </forwardto> - <forwardto> red@yellow.com </forwardto> -
-
- </mailet> -
- - ToProcessor -
- Sends the incoming mail object to a new processor pipeline. - root and error are special processors that - should always be defined. -
- <mailet match="RecipientIsLocal" class="ToProcessor"> -
-
- <processor> localdelivery </processor> -
- </mailet> -
- - ServerTime -
- Replies to the sender with a short message with the current time. - No configuration needed. -
- <mailet match="RecipientIs=time@localhost" class="ServerTime"> -
- </mailet> -
- - ToRepository -
- Stores mails in the specified MailRepository. Useful for mail logging - etc. If the passThrough parameter is false the mail will be consumed, if true - it will be returned untouched to the pipe. -
- <mailet match="RecipientIs=root@localhost" - class="ToRepository"> -
-
-
- <repositoryPath> file://var/mail/logAdmin - </repositoryPath> -
-
- <passThrough> true </passThrough> (default false) -
-
- </mailet> -
- - LocalDelivery -
- Store mail in the local inbox, one folder for each user. -
- <mailet match="RecipientIsLocal" class="LocalDelivery"> -
- </mailet> -
- - RemoteDelivery - - Relays mails to remote hosts. "delayTime" is the time in mills the - mailet will wait before retrying sending a mail which fail at first time. "maxRetries" - is the number of retries before sending back to sender the mail.
- <mailet match="!RecipientIsLocal" class="RemoteDelivery"> -
-
-
- <delayTime> 21600000 </delayTime> -
-
- <maxRetries> 5 </maxRetries> -
-
- -

</mailet>

- - Redirect -
A mailet providing configurable redirection services

- This mailet can produce listserver, forward and notify behaviour, with the - original message intact, attached, appended or left out altogether.

- This built in functionality is controlled by the configuration as laid out - below.
-
-

However it is also designed to be easily subclassed to make authoring redirection - mailets simple.

- By extending it and overriding one or more of its methods new behaviour can - be quickly created without the author having to address any other issue than - the relevant one. For more information see the javadocs

-

The configuration parameters are:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
paramdesc
<recipients>A comma delimited list of email addresses for recipients of this message, - it will use the "to" list if not specified. These addresses - will only appear in the To: header if no "to" list is supplied.
<to>A comma delimited list of addresses to appear in the To: header, the - email will only be delivered to these addresses if they are in the recipients - list.
-
- The recipients list will be used if this is not supplied
<sender>A single email address to appear in the From: header
-
- It can include constants "sender" and "postmaster"
<message>A text message to be the body of the email. Can be omitted.
<inline> -

One of the following items:

-
    -
  • unaltered The original message is the new - message, for forwarding/aliasing
    • -
  • heads The - headers of the original message are appended to the message
    • -
  • body The - body of the original is appended to the new message
    • -
  • all Both - headers and body are appended
    • -
  • none Neither - body nor headers are appended
    • -
-
<attachment> -

One of the following items:

-
    -
  • heads The headers of the original - are attached as text
    • -
  • body The body of the original - is attached as text
    • -
  • all Both - headers and body are attached as a single text file
    • -
  • none Nothing is attached
    • -
  • message The original message is attached as type message/rfc822, - this means that it can, in many cases, be opened, resent, fw'd, replied - to etc by email client software.
    • -
-
<passThrough>TRUE or FALSE, if true the original message continues in the mailet - processor after this mailet is finished. False causes the original to - be stopped.
<attachError>TRUE or FALSE, if true any error message available to the mailet is - appended to the message body (except in the case of inline == unaltered)
<replyto>A single email address to appear in the Rely-To: header, can also be - "sender" or "postmaster", this header is not set if - this is omited.
<prefix>An optional subject prefix prepended to the original message subject, - for example..
-
- Undeliverable mail:
<static> -

TRUE or FALSE, if this is true it hints to the mailet that none of - the parameters are set dynamically, and therefore they can be set once - in the init method.

- False tells the mailet to call all the "getters" for every - mail processed.

-

This defaults to false.

- It should be TRUE in all cases, except where one of the getter methods - has been overriden to provide dynamic values, such as a listserve which - might override getRecipients() to get a list from a users repository.

-
- -
-

Example, creates a distribution list:

-

<mailet match="RecipientIs=test@localhost" class="Redirect">

- <recipients>x@localhost, y@localhost, z@localhost</recipients>

- <to>list@localhost</to>

- <sender>owner@localhost</sender>

- <message>sent on from James</message>

- <inline>unaltered</inline>

- <passThrough>FALSE</passThrough>

- <replyto>postmaster</replyto>

- <prefix>[test mailing]</prefix>

- <static>TRUE</static>

- <passThrough>FALSE</passThrough>

- </mailet>

-

- -
- -

and this sends a spam notification to the postmaster

with the original message - attached as a message, and a subject prefix:

-

<mailet match="All" class="Redirect">

- <recipients>x@localhost</recipients>

- <sender>postmaster</sender>

- <message>Message marked as spam:

- </message>

- <inline>heads</inline>

- <attachment>message</attachment>

- <passThrough>FALSE</passThrough>

- <attachError>TRUE</attachError>

- <replyto>postmaster</replyto>

- <prefix>[spam notification]</prefix>

- <static>TRUE</static>

- <passThrough>FALSE</passThrough>

- </mailet>

-
- -
- - - diff --git a/server/src/site/xdoc/archive/document_archive.xml b/server/src/site/xdoc/archive/document_archive.xml deleted file mode 100644 index 7fa00ab636a..00000000000 --- a/server/src/site/xdoc/archive/document_archive.xml +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - James Document Archive - Table of Contents - - - -
- -

The Java Apache Mail Enterprise Server (a.k.a. Apache James) is a -100% pure Java SMTP and POP3 Mail server and NNTP News server designed -to be a complete and portable enterprise mail engine solution. James -is based on currently available open protocols.

- -

The documentation for obsolete versions of James is preserved here -for users who still have need of it. The James project urges all -users to upgrade to the current Release Build of James.

- - -

-

-

- -
- - diff --git a/server/src/site/xdoc/archive/install.xml b/server/src/site/xdoc/archive/install.xml deleted file mode 100644 index 0aeddbf1170..00000000000 --- a/server/src/site/xdoc/archive/install.xml +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - Installation -Serge Knystautas -
-

If you have downloaded a binary distribution, you do not need to build James. - Proceed directory to Step 1.

-

To compile James from the source code you need Ant. - This is a Java-tailored, XML-configured, extensible build or make system. We - are currently using Ant 1.4, which is included in the source distribution.

-

If you have downloaded a daily snapshot, you need to build a distribution. - James includes Ant to compile and package its distribution. Extract the snapshot - to your favorite directory, cd to that directory and run the build by calling "build" - or "./build.sh" which will create an unpacked binary distribution - in the dist directory, but no archives.

-

This "./dist" directory is the distribution directory used in Step 1 and beyond. - You may either cd to ./dist, or you may copy and rename the dist directory to your - installation directory.

-

If you prefer you can run build with the "dist" task "build dist" - (or "./build.sh dist"). This will create the distribution in the "./dist" - directory as well as create .tgz and .zip copies of this directory, however it may - require other resources to build the documentation.

-

Warning! Any changes you've made in the 'dist' directory - will be lost after a recompilation. If you are making changes to the conf.xml - or other files, we recommend you backup and then change the copies in src to - avoid losing work.

-
-

Download distibution. Extract or copy all the files in the archive or dist - directory intto your installation directory.

-
- -
-

- Read the short and snappy documentation at docs/index.html for a proper - overview of configuring the system. -

-

- Summary (for impatient people) -

- -

M$ users should just run /bin/run.bat. Unix users will find run.sh under the - same directory. A JVM must be present and its location specified in the JAVA_HOME - environment variable. Set this on windows at the command prompt with something - similar to "set JAVA_HOME=\jdk1.3\bin" on *nix with JAVA_HOME=/jdk1.3/

-

Running [run* --help] will provide a simple command line help.

-

- Most UNIX systems require superuser privileges to open sockets below 1024, - which includes the IANA-standard SMTP (on port 25) and POP3 (on port 110). - These default ports can be changed in the conf.xml file. (Obviously, you - would then need to reconfigure your clients. This may not be an option if - you want to receive mail from external mailservers.) -

- -

The Avalon framework will unpack the necessary configuration files you will - need to start the server. Wait until it is running, stop it again (ctrl-c), and - edit the configuration (thereafter *nix users can run the server in the background - using ./run.sh &). For basic use, you only need to set two items in the - JAMES.conf.xml file: a root password for the remote administration facility - and the IP address of a DNS server. Once you have edited the configuration files, - press 'Enter' on the terminal where Avalon is waiting.

-
- -
-

- Once started you'll see a message saying Avalon is running. This means that - Avalon has loaded JAMES and every other needed Block (see /logs/avalon.log) - and is now waiting for a socket request. - Since at the beginning James is empty, it will not have any local users - registered. - To register a local user open a telnet session with localhost on port 4555, - log in as root ("root[enter] <password-you-set-in-conf.xml>[enter]") and - type "help" for a list of available commands in the "JAMES remote - administrator tool". It is really a basic set but should allow you to test - installation. -

-

- Once you have some local users registered, try sending mail to one of them - @localhost with SMTP (port 25) (assuming you have not changed the default - server names in the conf.xml file). You'll see the mail appear under - ../var/mail/localinbox/[user]. - Try now to retrieve that mail using POP3 (port 110). - Trace out JAMES actions in /logs/*info.log. - Actions that will be taken by JAMES on incoming mail are configured in - the mailet pipe line (/conf/JAMES.conf.xml). Look at it if you want to - understand what's happening. -

-

- Good luck :) -

-
- - - diff --git a/server/src/site/xdoc/archive/usingJDBC_v2.0.xml b/server/src/site/xdoc/archive/usingJDBC_v2.0.xml deleted file mode 100644 index 541c85f3bea..00000000000 --- a/server/src/site/xdoc/archive/usingJDBC_v2.0.xml +++ /dev/null @@ -1,174 +0,0 @@ - - - - - - Using JDBC - Charles Benett - - - - -
- -

- This document explains how to enable JAMES 2.0 to use database storage via JDBC. Based on ReadMe notes by Darrell DeBoer and ??. -

-
- -
- -

Main Goals. -

    -
  • use Avalon and Cornerstone DataSource components for connection serving and pooling (done)
    • -
  • Remove hard-coded SQL statements from UsersJdbcRepository (done)
    • -
  • 'SqlResources.java' - detect db product from jdbc connection and select appropriate SQL statements from SQL definition file for specific product (done)
    • -
  • Simpler to create database-backed UserRepository implementations for different User implementations (done)
    • -
  • Simplify UserRepository specification in config - make it URL:// based, like MailRepository. (done)
    • -
  • Consolidate existing UserRepository implementations - refactor out common functionality (TODO)
    • -
  • Have UserStore serve up repository implementations based on: storage, User implementation, and location. (TODO)
    • -
-

-

Other Goals (reuse development in JdbcMailRepository): -

    -
  • use Avalon and Cornerstone DataSource components in JdbcMailRepository (done)
    • -
  • Use SqlResources.java to provide db-specific SQL to JdbcMailRepository (done)
    • -
  • Automatic table generation for JdbcMailRepository (done)
    • -
  • Get rid of the separate database .properties files. (done)
    • -
-

- -
- -
- -

- The main configuration is setting up the "database-connections" section of the -config file. There's an example there using MySql - I haven't yet tested on -other databases (although the SQL statements haven't changed much, so I -imagine it will still work on other platforms). -

-

-The only config properties you should need to set are: -

    -
  • <driver> Class name of database driver to use </driver>
    • -
  • <dburl> the jdbc connection string for your database </dburl>
    • -
  • <user> database user </user>
    • -
  • <password> database password </password>
    • -
-

-
- -
-

-

    -
  • Telnet to the remote manager: "telnet localhost 4555".
    • -
  • Do some user management - type "help" for options.
    • -
  • type "use list-james", to switch to the repository for this list.
    • -
  • list the users
    • -
  • send an email to "james-on@localhost"
    • -
  • list the users again
    • -
-(note: some user management commands fail for repositories other than "LocalUsers"). -

- -
- -
-

-Mail repositories are now configured primarily by their "destinationURL" -property. This has the format "db://datasource/table[/repository]". Other -config such as the "sqlFile" (where to find sqlResources.xml, and the "filestore" -for mixed storage, can also be included, or can be left to defaults (see below). -

-

-Each repository registered in the MailStore can now take a "config" section, -which is the default configuration used by the MailStore when creating a repository -of that class. This allows us to have a configurable JDBCMailRepository, without -needing to specify config everywhere it's used. I've set up the SPOOL repository -to use mixed storage (a filestore in addition to the database), but the MAIL -repository to use pure db storage. -

-

-The new config has been tested with "inbox" and "spool" repositories, but it's not -yet tested with the "error", "spam" and "outgoing" repositories. -

-

-The statements in the SqlResources.xml file have been tested on MySQL and M$SQL. -Only M$ has the optimised "getMessageSize" SQL, but this is optional. -

-

-You no longer have to manually create the tables required - this is automatic. -Create Table statements are included for M$SQL and MySQL; we'll need to add others -for other db products. -

- -
- -
-

-I've added an "AbstractJdbcUsersRepository", which takes care of most of the work -of a JdbcUsersRepository, making it pretty easy to add new ones. The abstract -implementation doesn't have knowledge of User implementations, this is restricted to -overridden methods in concrete UsersRepository implementations. -

-

-The AbstractJdbcUsersRepository obtains SQL statements via an "SqlResources" object, -which reads an sql definition file, finds the appropriate <sqlDefs> element, and -provides the sql strings contained. In addition, the SqlResources class handles -2 other things: -

    -
  • - a) Parameter replacement in SQL (eg replace all occurances of ${table} within - an sql statement with the parameter value for "table". Currently, all - parameters are taken from the configuration <sqlParameters> element. It - is also possible to define parameters (defaults, if you like) within the - sql definition file itself (a <parameters> element).
    • -
  • b) Examines the Jdbc Connection to determine what database product is being - used. SQL statements specific to a db product (eg mysql) can then be used - automatically. (Detection is done by regexp matches on - Connection.getMetaData.getDatabaseProductName())
    • -
-I've added 3 concrete subclasses of AbstractJdbcUserRepository: for DefaultUser, -DefaultJamesUser, and "ListUser" (which for now is nothing more than a name). These -give an example of how little work there is to implement a new repository. The -ListUsersJdbcRepository can store multiple lists of names in a single table. -

-

-I've made a simple modification to "RemoteManagerHandler", to allow testing. The -"use [userRepositoryName]" command will switch the Remote manager to manage the -named repository. This isn't really intended for production, makes for easier testing. -The "james-config.xml" included in the proposal sets up 4 JDBC repositories: -

    -
  • "localUsers" - a JamesUsersJdbcRepository.
    • -
  • "list-james" - a ListUsersJdbcRepository, used by the ListServ mailet.
    • -
  • "list-test" - another ListUsersJdbcRepositor, for testing.
    • -
  • "default-users" - a DefaultUsersJdbcRepository, for testing.
    • -
-

-

-Note that in order for the Avalon DataSource components to work, I've included -an upgraded "avalon-excalibur.jar" in the proposal. - -

- -
- - diff --git a/server/src/site/xdoc/archive/usingLDAP_v1_2.xml b/server/src/site/xdoc/archive/usingLDAP_v1_2.xml deleted file mode 100644 index 6f57bf2f933..00000000000 --- a/server/src/site/xdoc/archive/usingLDAP_v1_2.xml +++ /dev/null @@ -1,185 +0,0 @@ - - - - - - Using LDAP - Charles Benett - - - - -
- -

- This document explains how to enable JAMES to use an LDAP directory as a - Users Repository. -

-
- -
- -

- We have tried to make the LDAP implementation of UsersRepository as - flexible a possible, recognising that each installation will have a unique - directory schema. -
We assume that all users that a James Mailserver will handle fall - within one single-rooted tree. The root of this tree, ie the lowest node - in the directory which is an ancestor for all users served by this - mailserver and the mailserver, is called the LDAPRoot. (See diagram) -
-
It is entirely possible that an organization may have more than one - mail server. Consequently, the fact that a user is in the Directory does - not imply that this mailserver should handle mail for them. -
-
This implementation of UsersRepository creates one node (object) for - each set of mail users. The set called 'LocalUsers' is the set of users - whose mail is handled by this server. Other sets include any mail-lists - handled by the server. Each member of a set is recorded as an attribute - of these objects. These nodes are child nodes of the mailserver. -
-
The mailserver will accept mail for local delivery if the user part of - the email address matches a member of LocalUsers and if the domain/host - part of the email address matches the first servername . - (Set servernames autodetect to false and enter the domain served as the - first servername, e.g. apache.org). -
-
For POP3 authentication, the mailserver first finds the user entry in - the directory, underLDAPRoot, whose attribute, specified as - MailAttribute in conf, matches user@domain. The mailserver authenticates - the POP3 user if it can bind to the directory as that user entry with - the offered password. -
-
- This implementation does not set passwords in the directory. Use a dummy - password when invoking adduser in RemoteManger. -
-
- If ManageGroupAttribute is set to TRUE (as it is by default), then the - RemoteManger will add/remove the full DN of the email group to/from the - user entry. This facilty allows users to ask the directory what is my - mailserver and what email lists am I subscribed to? -
- -

- - - - - - - - - - - - - - - - - - - - - -
Root of Directory -
Example: dc=org
-
May not be referenced in conf.xml
-
|
-
|
-
-------------------------------------------------------------------------------------------------
| -
Subtree not served by James
-
e.g.: dc=w3c, dc=org
- 		| -
Subtree served by James
-
e.g.: dc=apache, dc=org
-
"LDAPRoot"
-
|
- 		| -
Subtree not served by James
-
e.g.: dc=xml, dc=org
-
- - - - - - - - - - - - - - - - -
----------------------------------------------------
| -
This mailserver
-
cn=mailserver.apache.org
-
|
-
---------------
- 		| -
A user
-
cn=King Arthur
-
memberOfGroup=
-
cn=LocalUsers etc
- 		| -
A user
-
cn=Morgan LeFay
- 		| -
Another mailserver
-
cn=oldmail.apache.org
-
- - - - - -
| -
LocalUsers
-
member=Arthur
- 		| -
list-james
-
member=Arthur
-
-
-
-
- -
- -

- Six entries in JAMES.conf.xml must be set for this to work: -

    -
  • change usersManager - type to ldap.
    • -
  • Set the ldapServer element to point to the correct host and port
    • -
  • Set LDAPRoot and ThsServerRDN.
    • -
  • Set the direcory FDN and password that should be used to write to the directory.
    • -
  • Unless all your users have email addresses of the form, name@the-machine-running-James, set servernames-autodetect to false and apecify the your email domain as the first servername.
    • -
-

- -
- - - diff --git a/server/src/site/xdoc/archive/usingTLS_v1_2.xml b/server/src/site/xdoc/archive/usingTLS_v1_2.xml deleted file mode 100644 index 0e6c13053fc..00000000000 --- a/server/src/site/xdoc/archive/usingTLS_v1_2.xml +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - Using TLS - Charles Benett - - - - -
- -

- This document explains how to enable JAMES 1.2.1 to use Transport Layer - Security (TLS) (ie SSL). -

-
- -
- -

- Obtain JSSE source from java.sun.com. Follow their installation directions. - We assume that you install JSSE as a standard extension, with a static - provider definition. (See notes with JSSE distribution) -

-

- Note that the US export restrictions still apply to JSSE - (at version 1.0.2), so while both the international and domestic versions - offer the same level of crypto, the international version does not take - alternative providers. -

- -
- -
- -

- Using JAMES with TLS. You need to do three things over and above the - normal operation of James: -

    -
  • In Avalon.conf.xml, uncomment the TLS listener defintion.
    • -
  • In JAMES.conf.xml, uncomment the <useTLS>TRUE</useTLS> element - for the service you want to use TLS. It is currently available for - remote manager and POP3. (If using POP3 over TLS, it is probably best - to change port to 995, which is the IANA designated POP3S port).
    • -
  • Ensure that avalonTestKeys is in the conf directory. You may need - to manually extract this from the Avalon.jar (with: jar xvf Avalon.jar - conf/avalonTestKeys). Note that this is a self-signed certificate for - test purposes only. You can specify a different server certificate in - the Avalon.conf.xml file.
    • -
-

-

- Start James -

-
- -
-

- (Positive Test) Use an SSL client to open a socket to the appropriate port. - I used openssl from www.openssl.org to test this. - E.g. openssl s_client -connect localhost:4555. You should see the normal - remote manager or POP3 server greeting and have normal operation. -
- - If, using openssl s_client, you get a connection refused/ error no - 111, just try again. This probably means you got to the port before it - was ready. -
-

-

- (Negative Test) telnet to port 4555 (ie without SSL). This should hang the - telnet client. It should also lock port 4555 until the connection times out, - I think. -

-
- - - diff --git a/server/src/site/xdoc/design_objectives.xml b/server/src/site/xdoc/design_objectives.xml deleted file mode 100644 index a373e108d46..00000000000 --- a/server/src/site/xdoc/design_objectives.xml +++ /dev/null @@ -1,122 +0,0 @@ - - - - - Design Objectives - James Project Web Team - - -
- - -

These are some of the currently implemented features:

-

- - Complete portability - Apache James is be a 100% pure Java application - based on the Java 2 platform and the JavaMail 1.3 API. -

-

- - Protocol abstraction - Unlike other mail engines, protocols are seen only - like "communication languages" ruling comunications between clients and - the server. Apache James is not be tied to any particular protocol but - follow an abstracted server design (like JavaMail did on the - client side)

-

- - Complete solution - the mail system is able to handle both mail - transport and storage in a single server application. Apache James - works alone without the need for any other server or solution.

-

- - Mailet support - Apache James supports the Apache Mailet API. A Mailet - is a discrete piece of mail-processing logic which is incorporated into - a Mailet-compliant mail-server's processing. This easy-to-write, - easy-to-use pattern allows developers to build powerful customized mail - systems. Examples of the services a Mailet might provide include: a - mail-to-fax or mail-to-phone transformer, a filter, a language translator, a mailing - list manager, etc. Several Mailets are included in the JAMES - distribution (see documentation).

-

- - Resource abstraction - Like protocols, resources are abstracted and, - accessed through defined interfaces (JavaMail for transport, JDBC for - spool storage or user accounts in RDBMS's, Apache Mailet API). The server is - highly modular and reuse solutions from other projects.

-

- - Secure and multi-threaded design - Based on the technology developed - for the Apache JServ servlet engine, Apache James has a careful, - security-oriented, full multi-threaded design, to allow performance, - scalability and mission-critical use.

-

Anything else you may want if you help us write it :-)

- - -

It is the existence of published "open" standards which -allows independant teams to develop interoperable software. -
James attempts to support a number of these standards most of which are -IETF RFC's and in the areas covered by these standards the published standard -is our requirements document. -
This sometimes leads to confusion where behaviour is not -the subject of a relevant standard, or conflict where common -(de-facto) behaviour is actually at odds with a supported standard. -
We believe that it is our responsibility to adhere to the published standard. -If we allow our implementation to deviate it means that we are tacitly encouraging -the situation whereby interoperability is no longer guarenteed by standards -compliance alone, but also requires access to undocumented and possibly -even commercially licenced technology. There is no easy route for a -newcomer to aquire these secrets, and interoperabilty -becomes something only available to the elite. -

-

The James policy for issues of non-compliance tries to tread the fine line -between a pragmatic acceptance of other people's misinterpretation of the -RFC's and an evangelical defence of open standards as the key to freedom of interoperation. -

-

-In practice this policy is that certain well argued of cases of -non-compliance which can be *safely* worked around, will be tolerated by -James. -

-

-In cases (like jira issue JAMES-344 ) where variance from a published standard is -required it is desirable that this functionality is disabled in James by default, -it must be prominently and clearly documented that this causes James -to violate the relevant standard, and should be enabled by explicit -configuration, making its use a conscious decision of the user rather -than an decision taken by the James team. -

-

-In cases where the required behaviour is not within the scope of any standard which -James claims to support (such as behaviour which is a de-facto standard or -an internet draft RFC but not yet subject of a standards track RFC) it is -acceptable to implement the behaviour so long as it is adequately -documented (for instance by refrence to an internet draft or -other public document) and users can be clear about what to expect from James. -

- -
- - diff --git a/server/src/site/xdoc/index.xml b/server/src/site/xdoc/index.xml deleted file mode 100644 index fc3b5e8693b..00000000000 --- a/server/src/site/xdoc/index.xml +++ /dev/null @@ -1,131 +0,0 @@ - - - - - Overview - James Project Web Team - - -
-

The Apache Java Enterprise Mail Server (a.k.a. Apache James) is a 100% pure Java SMTP and POP3 Mail server and NNTP News server. We have designed James to be a complete and portable enterprise mail engine solution based on currently available open protocols.

-

James is also a mail application platform. We have developed a Java API to let you write Java code to process emails that we call the mailet API. A mailet can generate an automatic reply, update a database, prevent spam, build a message archive, or whatever you can imagine. A matcher determines whether your mailet should process an email in the server. The James project hosts the Mailet API, and James provides an implementation of this mail application platform API.

-

James is based upon the Apache Avalon application framework, formerly a product of the Apache Avalon project (see "news" below).

-

James requires Java 1.4 (For further information you may want to search the web, our dev and user mail archives or our wiki).

-
-
-

- Latest and Stable: James v2.2.0 -
-James v2.2.0 is the current release, and the latest in the James v2 series. -Both binary and source distributions are available.

-

James v2.2.0 is a major update to the James platform, with many new features, functional improvements, and bug fixes. -See the Change Log for a detailed list of changes. All -users are urged to upgrade to v2.2.0 as soon as possible.

-

Any bugs found in James are dealt with promptly. Please provide feedback on the james-user and james-dev mailing lists.

-

- Get your hands on the latest versions.. -
We put significant milestones, and potential release candidates in the download area. -
Whilst the quality of these versions cannot be guaranteed they may contain important bug fixes and cool new features.
-

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ItemStatusSinceFirst released
SMTP serverStable1.00.95
Mailet EngineStable1.20.95
FileSystem mailboxes/spoolStable1.21.0
RDBMS mailboxes/spoolStable1.21.2
POP3 serverStable1.11.0
RDBMS - UsersStable1.2.11.2.1
LDAP Support - UsersExperimental1.21.2
TLS Support - POP3Experimental1.21.2
Remote ManagerStable1.01.0
TLS Support - Remote ManagerStable1.21.2
NNTP serverExperimental1.21.2
FetchPOPDeprecated2.32.1
-
- - diff --git a/server/src/site/xdoc/rfclist.xml b/server/src/site/xdoc/rfclist.xml deleted file mode 100644 index f7c2af12841..00000000000 --- a/server/src/site/xdoc/rfclist.xml +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - James - RFC Directory - - - -
-

This document contains a list of and links to RFCs relevant to James.

- -RFC 822: Mail Message Format
-RFC 1123: Requirements for Internet Hosts -- Application and Support (updated by RFC 2821)
-RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
-RFC 2822: Internet Message Format
- - -RFC 821: SMTP Protocol
-RFC 974: Mail Routing and the Domain System
-RFC 1652: SMTP Service Extension for 8bit-MIMEtransport (elective, but widely adopted)
-RFC 1830: SMTP Service Extensions for Transmission of Large and Binary MIME Messages (experimental, but cool idea)
-RFC 1869: SMTP Service Extensions
-RFC 1870: SMTP Service Extension for Message Size Declaration
-RFC 1891: SMTP Service Extension for Delivery Status Notifications (elective)
-RFC 1893: Enhanced Mail System Status Codes (experimental)
-RFC 1985: SMTP Service Extension for Remote Message Queue Starting (elective)
-RFC 2034: SMTP Service Extension for Returning Enhanced Error Codes (elective)
-RFC 2142: Mailbox Names For Common Services, Roles And Functions
-RFC 2197: SMTP Service Extension for Command Pipelining (elective)
-RFC 2554: SMTP Service Extension for Authentication
-RFC 2821: Simple Mail Transfer Protocol (obsoletes RFC 821)
- - -RFC 1725: POP3 Protocol
-RFC 1734: POP3 AUTHentication command
-RFC 1939: POP3 Protocol (obsoletes RFC 1725)
- - - -RFC 1731: IMAP4 Authentication Mechanisms
-RFC 2060: IMAP Version 4rev1
-RFC 2086: IMAP4 ACL extension
-RFC 2087: IMAP4 QUOTA extension
-RFC 2088: IMAP4 non-synchronizing literals
-RFC 2177: IMAP4 IDLE command
-RFC 2180: IMAP4 Multi-accessed Mailbox Practice
-RFC 2192: IMAP URL Scheme
-RFC 2193: IMAP4 Mailbox Referrals
-RFC 2195: IMAP/POP AUTHorize Extension for Simple Challenge/Response
-RFC 2221: IMAP4 Login Referrals
-RFC 2342: IMAP4 Namespace (elective)
-RFC 2359: IMAP4 UIDPLUS extension (elective)
-RFC 2595: Using TLS with IMAP, POP and ACAP
-RFC 2683: IMAP4 Implementation Recommendations
- - -RFC 977 : NNTP Protocol
-RFC 1036: Format of News Messages
-RFC 2980: Common NNTP Extensions
-NNTP Working Group
- - -RFC 3377 : Lightweight Directory Access Protocol (v3): Technical Specification
-RFC 2251 : Lightweight Directory Access Protocol (v3)
-RFC 2252 : Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
-RFC 2253 : Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
-RFC 2254 : The String Representation of LDAP Search Filters
-RFC 2255 : The LDAP URL Format
-RFC 2256 : A Summary of the X.500(96) User Schema for use with LDAPv3
-RFC 2829 : Authentication Methods for LDAP
-RFC 2830 : Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
- -
- - diff --git a/server/src/site/xdoc/todo.xml b/server/src/site/xdoc/todo.xml deleted file mode 100644 index 8c249fd8c5b..00000000000 --- a/server/src/site/xdoc/todo.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - TODO - Serge Knystautas - Charles Benett - Peter M. Goldstein - - - - -
-

This is a living document that will give new and existing volunteers some areas where we need help. As always, any help is appreciated, be it documentation, code, suggestions, or feedback. -Last Updated July 2006.

-
- -
-

Determine a way to support multiple domains.

-

Revisit UserRepository. The interface must support multiple authentication types per user, -aliasing (both local and non-local), as well as per-user quotas. It may be desirable to be able -to associate attributes with users in the repository.

-

Revisit the MailRepository interface and associated implementations. Special consideration is -necessary to support IMAP Search functionality. It should be possible to associate attributes -with mail messages stored in the repository.

-

Revisit the SpoolRepository implementations and do away with the current exception-generating -two-phase message retrieval.

-

Define a simple mechaism for addressing repositories in a uniform way.

-

Add support for mbox mail file repository.

-

Add support for the maildir file repository.

-

Add support for DRAC login/relay authorization. This feature records the IP addresses and times of -POP3 logins. SMTP connections from these same IP addresses are considered authenticated if they occur -within a fixed period of the POP3 authentication.

-

Develop repository migration tools so that users of the old repositories can easily migrate to newer repositories.

-
- -
-

Add support for the 8BITMIME extension.

-

Expand the SMTP server so it supports a variety of SASL authentication mechanisms.

-

Complete support for delivery service notification (RFC 1891).

-

Discuss optional support for VRFY and EXPN.

-
- -
-

Get IMAP server to alpha standard (i.e. basic interoperation with e-mail clients).

-

Add #news namespace to IMAP system

-
- -
-

Give admins the option to enforce one access at a time to a POP3 mailbox.

-
- -
-

Refactor NNTP code base.

-

Tie in the NNTP Repository with POP/SMTP/IMAP repository structure.

-
- -
-

Write a list server implementation with functionality comparable to ezmlm. This would include -the capability to handle multiple lists of 100,000+ members, double opt-in subscription mechanisms, -and a full suite of mail-driven commands.

-
-
-

Discuss and agree future architecture in the light of Avalon's demise. Modify codebase to implement architecture design.

-
- -
-

Discuss and design the next revision of the Mailet API.

-
- -
-

Improve the debugging output, including a) catching that DNS servers are not correct (at least have DNS log channel record DNS server usage)

-
-
-

Add support for better mailet router/processing (maybe like RequestDispatcher) - Use Stage/Pipeline pattern

-

Add support for deployable message processing apps using Camelot pattern

-
- -
-

Rewrite RemoteManager to be an exposed object that can be controlled via RMI or what have you, and have the remote manager telnet interface make appropriate calls to this interface.

-

Take advantage of Phoenix JMX capabilities to enable more complete measurement of James behavior.

-

Add support in the RemoteManager to manage repositories. This includes listing what's in a repository, viewing individual messages, deleting messages, copying messages, and moving messages.

-

Add needed functions to RemoteManager, Including Stop and ReConfigure (?), Reinject mail (this should just be copying/moving messages...), Store RemoteManger password securely.

-
- -
-

Document instructions on configuring logging in James.

-
- - - diff --git a/src/site/resources/css/site.css b/src/site/resources/css/site.css deleted file mode 100644 index b9279090553..00000000000 --- a/src/site/resources/css/site.css +++ /dev/null @@ -1,13 +0,0 @@ -#apacheconbox { - margin: 20px 0px 0px 20px; - padding: 10px; - border: 1px solid #ccc; - background-color: white; - background-image: url(../images/button-top.gif); - background-repeat: repeat-x; -} -#apacheconspacer { - float: right; - margin: 0px 0px 10px 10px; - background-color: white; -} diff --git a/src/site/resources/download.cgi b/src/site/resources/download.cgi deleted file mode 100644 index 06a42f2012b..00000000000 --- a/src/site/resources/download.cgi +++ /dev/null @@ -1,6 +0,0 @@ -#!/bin/sh -# Wrapper script around mirrors.cgi script -# (we must change to that directory in order for python to pick up the -# python includes correctly) -cd /www/www.apache.org/dyn/mirrors -/www/www.apache.org/dyn/mirrors/mirrors.cgi $* diff --git a/src/site/resources/favicon.ico b/src/site/resources/favicon.ico deleted file mode 100644 index f0c22ad9bf0c7db2eaa899c41405a27f6b2281d5..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 3638 zcmeH}i(k$6AIG1kbLmu4%-AiL%zd_Do6Y7r6Xw1wl|qE5SSl7%8Ix9RvNUrkYS|Ez zp)ytzN^UFZcGRg;o$gXeNayz<9#h)m@%sbzemq|1d|vO@`}6sJzn|~-`+j{vf*z)( zJdUMu=qpA&d$#ajln^9x{RMqg@+d7qBt?voJpOy`N2k-_XQt*i<#6WynaAosWsstr5rqX5Z~G5tWor4tKxIk>0QFB zM>1Q@j<9-cE{9Yl?30I)U^s=MtOk;js;H@YK=jEfHeA1nyM7$@eYAKiEyhJLp1(Ty z;_-4mmT^~z-Eo7mvO+@qig4A-;z!w5GIDF#uW;v*finlf%UQ1I&+@SvyezadHa4)u z(1N8y^Vuvr&oVO&c3nzw=%!+(yf>STP7$iV2fs~U@$Iz&&MVgtd!z!_4w)1bG!UYH z41ehvwku{3vZ0IvhJM_?_mGpo7m&OU(Ke$8?br52zQw+`KB8fV(*T#vop54O8M(V z72m%SM^08U(?a4fH#aBl_fW>_O&}yahZ1!iJKfZrFipj+?_~~!77`udg_qtH;T;~F zQh0MsxqyV;lj)&njAvjr9+&>cW=fZ4$=@Tiy+Yb@pP4Fs7e84dZn8<7?YahA{R&ojWpVuHEWT5W zV8x5+q#AAHa>rRXy_d(lekH8$eu2Cj#Y8Iiuxl~q`vo7K$ zi@N7<;tvfDor{^>tAP9tmiRgsvgo`DBjhyRZ6rH88>^97>`~bBt9&={M%!30K9?Kn z+k7p&ck*{fSS86MARqwi85(SkXEJweDT$|cVLiBt9bP#M&@*MmzBAY^Ea&>QvjjTl zV{<8=goHA}uI7@IrWO9!$g)wHq?|uVV4#|U+jT6F6p4LVfK@^ku?i24EBweYUBwTw z1Hy|2;wA4x@I@6#@dw#qu!c|N-6=JmK!EUeyUw@pm8J2U(N12HC`mVPBIZ~*U&*YA z|2>R3rUfJzco8a(!_3T#WD^h07=FVpSrqQBD$0t=*xzvuw&@xccTq7>+6Aq_EbI)c zQR*wOmz3Zt(eSk_g`ea{ITx>Gu6ZT)z4EZSlFdBhQVuEivce|^$Ir5P@Sur1wf6`T z-kp(lku#@?*mFb0@*dgTuBqg@(PUgCDr|-nQ>MLxx~huBvV7|6YYCSfWUizftGL_E5sVI>w>XE4IBw-lPg| z2#GxU79on%X@ zz$YDsir(}u;ko+*iRTR8e^I&qXV3m2Lwkrm*IrzIz4SHxcTddtwmlK9&kfg(STwmq z{EZVi?Nmr!4{x>@v~KWuD|!DDHP01DzH(F@o_Q?V@|}(czBBWDPTzXLUt3rao$+R@ z!-N%6#Z|VB;&aK`jn?ai#dN-?(oAcu36}Rwy~-l?w)EDWZog@U|K3)=XK>EH{B(uX z^3doxea=;HZmVy<+Td?dyKYkO=sDLue(#00`;)ohq$(=X`j?pHKP&wm7YiF`6|-Nw zIw0zFtf6C)@pkC85i|khmE!OV;-#3s)B+Vr?i&$)T_%QkG-+~*1?r2Doyq3ovmca#OnI+ z@`t%+SDms@grE-)jzJ@P zw^|$0FFT#y8_{clZKQwrr6PBqw(__jFFn&vpI)44p>dp^+D0Ypt?$)`kC)Ag^l#1% zaL#KhPg(!U4>uKEBQ2U;>ZbqHRz>pmmC*4ob(bv6!#;^mRJ5M5jv-y3Z4cPm5-OrYC4bUsoeOH4+4T=pml9(aqr9B$jMMBG4kM87)e@ Ubv|M>F;ge1bt0t`R41tJf5W(}rvLx| diff --git a/src/site/resources/images/asf-logo-reduced.gif b/src/site/resources/images/asf-logo-reduced.gif deleted file mode 100644 index 93cc102077a940966a0bf6d77e74ac273a10ef8f..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6636 zcmW-jdpy&NB^`k5({Ud=*EWJLJM77(p_7Ubjo^?L{6ozBTG zrT8~-uT3`YA6z(iU(uWv#wdC?*LrZ+m}~LRdiKU&$f@Oy^oJ`=i6+hgRAVF_PDwp- ztgxs!1ZD4l68M_KW_UVk-#Q!$Pa@K2Br166_?3pnI2h|A-a0BAXQR5&A?Fpb?Gb8 z2*k5oCs=r^?5ey-sZ^AxYup^lC`5wE?{)1hj19^$$^{?dW+pEpj_VrXL%+<@Wf;^t zJCdiUvs(#-G^G|kfoFntz873~ctb_>t(@D#$7q=4Jv#>J`Qv=$b>~!(=u%)Bm4nQx4G0uy}~g_xl^(YUhBvak#5 zgOuvw;WT+BuH_Fe^Qfh^cx6`2s#Q)p=qizh0B=u>WgT3-Um`*}GI*J|%p$EpRN<4Y zGf~z{=<@Z%ciE4S^38-`SDls-3H17pfQxW&*i~EFS~THa;&q8l$;Vfpq4`<-XV(d$ z`-SexHAn1eerw`+&nuVTz17YrVcMN=n%6b~Pk7R#fQs2Gpwl_l;)!9Zix3)AS!c&C zQ34C)+gAHfADmZ#J!@ouF>Xj{z_YVB18pQxGV z#8&ZYQIjf}4+ukXt98XP)EbGFTjdXCr7XQ<39V`EX@7dX7sgi%K^WawfM#Gv=)Aa1 z+o?NS!01`I1iDVjJKI}zgx$&^C5Ef~EU7JH?OH!a+{=QV@_zU`-5PH*I zPuRv#n3aaLEiBR7@r{SVvX-}mUhuV3xb?k!BFIAH>qbPzbWFRFgIRYuh*K-nKBmlY zXo!mHbNn_F82LJk8Y(6HVBaJGfDmIP$=s!3^Huul_S2gBtEE}_T2@5k_$OT|Hfb(5 z)X<#6D%iKo^EXxX4F^7^85Vz6sG)}#XEvtZDoScZ&v0xHPB;j%ar+w*l2aoKKDo2- zb9>!cbUD@Cqd08ehtuEgl-E^3le=d;7%p1%H-?USDXO&=Ns#x}Gv34#dLGHj^Mbev){8$exY)@D8txn4_GgU^Q#nGSmQLy^q-T1(e6TLYS zkyodfAaB@J5Bc38m*mNB>VrC0Ux|ebUq~Fex!-O z_3SLrfr{Ra$gx{pd(y!YKvCLGkH;%6{CVnQ{;UW?4*=tq1vDz`SEy-1yIj(V2R)ZFCY__!(Zs!f z`rl=^e16E7%Pt1a*QGNC=$-{`qOzJAu$vUT+P&2n>8pCwFvLX7zj^SYb`8p=S+0`E z$XYnM2{X2F1lL-FD1N}lfYe#DT)AY*L<*-3n_K(QvY5+XtlTfjs_Xqib0@!ESbnk! zSA5ArtJN=qF`{-hEnA~6zDFo%d=8mF^^sHw%D{yEh@{rPMqBF5>hB{?M8h{}t@d0a z$TBh@8x%i2xYqf->Z_kO?ik9N@?Tnd1s`-Sm~BEsL0u8q&B1GhLXeauby8lte(=TH z=AV&6s2Bxw4Bv}#m_ApmU%KiQkf8nY=}IGzQPzj<_?tbT?S^q>@387$GCgoZ>{a?} zs*!BKHygc@UGbJ=GHbM@>qZ!K2AH8?ChBt!Rc8lW$zk7VEIyd*pHZ< zE$>3tEVKs2MMV7_y;EJ&`Ixn`WSsRp6bJd9jN0ez7 z|Ma|Lc!>!cW3KHdjTYX+6Ie1ce`!;(oJVsG#TcaQP4A00xHl)OMsj5M5|l7eC(3az zDJOcF{El8dJ#Rzx_qnmF*i5mBua?=I@#wMvrXgR?ichil(W`n;21chubB`0YX{t^$lR@)6e zzxHWowXNRH^1Qj<$tzEf&Y^`bdfs&ERfbPdDZ3B53tO443vu5as^NZ_IwXJfQLrGe z*svE7@rd$rX)~s^qXx&9l&pV0F0Lg#>vRaEt0D{^yK6JYuX|TyX#+v*D)2mcq;*Cp zfmg+{`z{X8I**n$^E#AvnZc#GzrRAukx7ov5b^QQouH>j)7lqpVBE5P^}wWc9VJMF zl|RDZCikc^4kDE8%0ixL8a>;T0`GN{#v6|OnR?@tEUXAkxLJ7eVdS$v?N0>>6O+H` z^2{Fo2$O4$vb6y!ta9)n;7$uEBjvIC)aTjix?Ev&58b zTHCwd`4prf7n;f;4aFhXHwe2DD!6nD&voHBVW_e^kk z4BA-^s7S#3%MdJ4#z`=;Gr>L_NJXrykOQM%3PUrC{5VkM211p-l*eeZE_gIfIC*wHsp5pD4ONn{s>gfc~b%Z~YZ zfnp?qAD#z;w}Pl!;NNdN^7{Ah$UuBd#BGr$q;yX1IYErS2Le0Dx zqKPdB6#2#+aF1s2nU>;y3GRIxtU@)ZW|^FpfQ~=ZZp%^@YPfu9&Thx@P=y`kq&RXQ zrP!}nk8sM64X>6!PGY$JGH6aPF_geaVX2e20;v#Fg(T&7r%qiezhli!WB6VLkCZ*B zG&`?pe<1&KTg6Y!%9gm&{(-Dz0m4ZN2hm-2e=EFq8EYj6+(TS9F#>*%LhWhDO$Eqg(i@Bw z)ysu*&R-5ba{&B^X%ph=;~Ze6V^@UXC;oaVAh3nK4e=SJ+})Q!mhX`!p&LC@;->&y z*%W2taFQ)dn8M%$JL=tRX3)qPH=>dPFsJGwCA2L|HJ%mKj z+y{JohjEIwLdk)ki%L3nlF_un1W|C)_?oXdHHJxWEt5OSuAY78a@UvZQv>#fngy#D zda$eabAW`YbKVk=e-xVk`<#M<0C`~Vq#5R;JN!<{#bsQ{XJ#H_~xNkfws>)tk=Nd2=DuVh(`? zKbj9|62X&jT2m5yRsj^6*w}MyONIWHK+*)q!^jL_U2(Mwdv&9cwJ)Nvvpa7o8k)iy zo$y3h|0JtOk~^bd8{WmujPMc%sHVchB03^Sb~uD=9ux_+r#L6jz0P(=Y$!X|c){Km z?fLK}si+@jkFBv!Q@K0>0$w#6{ub%)YMSm>%~9uFy#et(ya<}gRQ2;ElN`gOWOB)M z?>DekR{i9Jsx8$4$*0#w)Bf5RkUxJ!K+o^z4rbhv;V_6(p-7uz?>a# zDmQ!+XacocAKJy4EE*aJ5_O zOl7@}o4eoGZTmg|$@UZeg7>|qstB=;z~yyP7^X&>6Iul9wdDbqR!|(HgI(~y4bEgj z%tqp_C+GnG6Eu5vYZwFarm%kO0S`>W{wXs4Bc*Kx9v*U#|E11@P&c^;w33o+rS3mX zZ^{t6E||fFhT*& z$DjcTq$Y2;o9%Wf9FZevyFIOXQdsN9MYJA58+<3}B-N#2cE!;z5WI==7sz?xMoOhz zCcFEp2Joy;%Tm{v(b4hj?*Q^*NLZjte-Cvs+}BwF*3RDM+ZvgK2YRtLoAP1um6~CC zw@>rEM)H;)OM3k2JaP$*d$h-ya-e6dr-4L468u-H8afR_e5*9CiF(K(Cm9J@isrWu;W$PP1TA^Q5f6Fvm^0E!e%5G?i3bKu z{Y_bc)_ET~Je&J>&|Ppxty-gD7^mFzg)*;3yK$m!uh89nW?=u;;J(Ukj}X{@$o$uk z$D||T{CMs~RQp&nti<#1&O(x{p7CHf|PgnQpY-@>Nvror76~GP}JT(kgx;Nb}5NhSZnAlLKawpPv{}C;)2hij} z-VORkhG$HWlVpA6+QO`}!i1jeMpnIN(Qw3S+*Ou5@BOsu;ShlNeakxDSlH5X@`wsZ-B=B^}t8EVN2WpeWtGP7&oYjaRX;8E)O+J)+0Eg`%&btht7o@_=5B zG}L1PyFKiFGCjmEgcCDdUcVCjw?p#*6+*WFo_@ZNNb6~LvrE2P1Ru4##STL3u4F3L z*$=Vae1mATs5Qf%z+bemF7Xbf3~@o!*q#q%6(KZ*3pVUEz8tvgS;Lvcg@LO8O#eXH zq>p^m_Q3Yl@-yi5M)=KD;6NHM`7vBn)9`{|U3AEtE=_e1P?$VMP7CLdHrY4?p-KJt z?4I-SV<|g?s@V3;aUsaKmh-9j@-TT;R2b6YKEmiZGJXW%GmD56}7a!qg*ZT093>v zRz?yK$i^kR0fx>=K=sg4p)3658SV*r>97F6DgYB65WZigcl|(D>z%LO=H`Mnn`wZ$ z17R)!YJR$CP66?+0Ra!Q>N@l%0q;r2xtIPhwW?=e^`9!vZwV17-} z`v&|Lxi`;X*yrlGVH2dVIefugw~g0%h=SUIP?B$j31DUvBdWX!RR_#(g^grxEaBNF zPBtudN<)iV+FZ!d+5hg+5J&Kc{8OETWxW%AhS&-JAzgnD!y2*9@s(5EO^-9pGAbx= zg#EdZxG!MeuOgDwu1+Avr1pU-1JvD&F&{S%|h`1jKPE8AZ9k@JRFi0v2K#muJ(ewI`fD=fye1%bs?&BeGF zZ;Kf*o`hYW^tpt?tq$ty>AH5Dulshs%z~6tiW1;GG`f9=Ly2Rh*sacZBEQUkRMCso zF(ECs$v<#4B+Ci`W8DE(IH(va?>eRhd&*Ws)cPcdW>57a3zdK*%pb*f<;JNtKI0 z-OK4Xju4k0B=B+2Gi?d-6YhU0Hg-u4T3_eoi!hE{=_4w2X!!hhR9UR3Z*bVfO^dB@ z%PGwF+v0V23+}E!LbhW#s?0(LXH?3&zWt$Tk-C=x5J4Uxye3j?S>N?L*6t@Ap4dt zcM)kz>l6V3L(wORWE4ZuXZU>MMajkfSMTVD^jZMsMn!gIo{f6w>v(K0>sOvxzEw=a zrNq05F^F4qmE!-zC(QGQ`ALI5Ao<%CXooIt<-mU(5n<_HaS8j zDuLZSYT+|{!Wh1VGuH~Ji%q}YTBR-VL>(y61_$YZ82tG5K;VJrr`+k+V ifk3o@FNQYto?ua@#Ta7 diff --git a/src/site/resources/images/james-project-logo.gif b/src/site/resources/images/james-project-logo.gif deleted file mode 100644 index 715a9bf970849d7564a7c4ac46f6512d6e2d8bbd..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7227 zcmWldc{J3E1I54Fm>G;2``E_V*OmMZ?MPVgzsp_gB9UnA&z+p~Kl7iG{Gvt6|9<|nAzEG<(XiQWWs^wr6n*(Q-*!i| z_G`0D^y1>@-9|4#oMYiaRv-}au`y08B()Kyp4*xC8-2s`2H_xA1d z%KE=QfBtN2YAn4}+}_sqYIg3$Kz}FiF#rJnWooP;{}})<{=fXc6CftyRWh87l`r(w zMD~Z;RPr05UH|gA`MNoF@N41|0XKfHN!g3Jw#4DE2Y(COH>^tK#IN*JkF3h2SQ2rv zc0@^{Y|<`boQ^D!75}g_r@+tkGkP>>q#n%k1PGist$Taf^BBjU9QcAKrm5JY_e6* zWt$~qMB73=d9y(4teu1V(SEZDLoucB3<`znn5W#R%qd}mwT7ZRyvAKs*XY4?`RIV! zEshOt@L7G;hSQsw0E%E7SfyX+=ia}ct&14B-Zhr1NoTjvugYlBUJfB=9YXgkIW=|LrTpezp=(vH=JcTaOl zs|`omJF`JKV2C2Ek}e5pTizI0-s<5n%F9vqy`^9fav~`c_nVi>%tx?$860YPS0)~( z5IrYEtJiGn?3Ue~*j?av*Db;D?+*aNoWnL9WO7+AR(25|rYXLttiFYjo@R9Wxng$@ zXeo9w;7~c9qI!&iF#y9PNm&=|e@|MExLc`mL;zyF%;@%crex-PoWkP+665`WU1?Vy zae09XJFDNF-ypxFN{OcfAdaxi%`!aqddykvTQu#^N!^DSAcibSKQ4x1r*)<5=4O1j zd`XULha;`W^T4gkls>%G>q{&x|4j#g(7l#xA3ez>Z*0Z1E~e>7`$W!vQZedlrAqE{ z<#d5tRC%_z>4eK(R%+IC&$N99EbAq-Y2H-q&_-QJ{khDmz3!kY2f}G2W$WX%P8$r0 zcV^$|LaR&CU!9G7erigJgbd_I95&Ql;0A5nvWwlEpA&+ijtag=7z@FEoJZu3G?bZ# zLOJ%b@5xRK<;!@drqi;^myQ#}ZK6)>)_kljMuR~%MQb9ba&aieAwXP`%`l3d_HqoW zqj0)%rDv;ea21{XxX+*y6Dq0576$DWrrD7X6rZJVyC8*)sQ_rd&%_AHfYT-%IMp2E z0b2x9bU|@vO7}wrd!9X3Eg>-j$F^CgFSP~xMY8Ds8D?tGXt z3Y>{NwvP}Q%6Fls@($s+%-uv8(0D9V<>feLI|Be8X)ugTahiQ9Jji2`ZHF>xBbFoD z_VacCu4d~~^)ps~(yzQSwhh4l$mORZ;vU<74MW!i{~(INjMBThuZ<}f1rJI-x8NQL z^`SFN_SZv=Rf5PAZBC$=;-C2nyH4Vu?JJk=DlvjW9=5kUBowNHzX|9cGM&?HNA@N6 z$Uot~gp~Wpk(b^`C9SyIH9y)|b5ks|G(-RPLli57>7vo;4)OeVfycW=FO-Pdt;DIsVl)x?PzA|wZ|3ZsA7RE?bE}>9a zW?dQ8&mIFqI4IYy7+;fSjtU0!)_%{t<{*$-lE8ecrc^|xCWnEE$lj~(CJwP-RSXqy z`vT%a7*Gx6x%ExELA)ygm>!mZEUtU^%<0@D9VG`Wf+h3WucXgv6Ew5+dl!5)0QJ|R zrGlNjX)uvs$Kdk{wgPApo`=xJHBiz#Td7C_thRk5=lmC2#Enwjt@?@5RPy#=AfY#Y zc>if;)C;~g)pC4C&k1~Ex7JfLr$ggQ1zW5^ygvup--l0g?<( zn&W!_y*Zloj(xNL`*c3bQggPX9&aIE)@D`I@-`-Re`t`g)cku@2hVdwke*cwop zhYT{DfeV`j|EOW#q_@2WOKfP`2yxz7PeC?!FrRsaf-Quep2=U{M*SLg#VRqvp=e6; zs^|b3qak@6oY}0Ww$$)kQwUrDX}wtC9IVc6|y8S0$}`l1x-4UDYY>aA;rzr3W=mPig-_BZWJ{kTCKZ7H~!J-N+@Rg zhD_Vbs}pHt8yXCHTUKtSn3Pt$?(<)vmOhna!du9x56|bo7C%_fT-K{GnZ;-m0qEG{ zpH_?9EqAd7Nc~2cveOEgTVK~IL%bnOG%Fo;?aI7F$g!uvWGx~~i!9x6YvRz8e&{c= zS0V4OnEZ0GE*sirjt0jHTFw5b@KB_8v3Kem(f&Dduv`$JWTND3S7PiZ`s6Zge*nG1b6@#l*QwK@6(c@Z-n!oA*_;2w;{zlUxF^1k*{f~X~9(FkACLqYjYf>8* zAj3aAr8VUB&s(oh+2>zjN4)Jreu~|uv13T|)wuq+p}5OTyYpBf?{7>nD^1!~^D)9} z-jw;CGNp4b?bDAOQ;s4?#)!I=KHfqhK*fcsZpU5mN!n!<+}1+Ms7{$`ZTk66oMVBL zk-El}gri-dPm+;vE8EFftFG(G{7~I&#VIGkw-<4z7YXTdejJ0KLte|@&~1V&S$+KX z0ky*chUS%Q4{IdT;IQ6f-r=$brLVHq`C&FWH|4#l`o2(Pqv1O-?PA_kt?R1Yhg-tk zya)L7f^_+5=~ZXpZ<(6mGZ#{$vDVxZvX}>}*NkixGQE$%mi$!ob}FpJP_pfhEAhU) zTJp!ZnG%970CW&SUkS zuAC$nYE)kkawf=0gw95=#Q4EO$w`NZtpv$JE@aAw6FY$vd#N5a1dm#gD8~nC;YF*1 z2D2uc`HY@)^V}|%gk_7J3Xt+ANRgl*OTauBkxiv)k1|0k9-0M;YcAPO>7+L~X!r)Y zg)Jk@Sj5xf%=cN(_Bf~eP6*1HxsM)>(~ojyXB;m)Geu6HS z)cp$~eSS0xIBvm%cLY-X8v-I6u)ob&>LWZ86(N4_5KshJQZO%h@;f>K z-6c@&K!B??Bae+sW8l7VTnz-E!6nG!fVSZnawr(N-ph0#hhMNlcChn0ypa{LDA8Uv z^X`?TzDk2_P7ShWOKw3;S9j0k1Keuf3m;@J8Aq1*% zAr%5(8kjg318oy#<&VSL2nBu$f!lbn#RsT;Go(iV{Z?QlD)jsv(9Koz2j%?Sp|&ph zsS!|}&hBQw9EwH{&%BAD_R1Q1*UoMl-_C81jdMESC=5N-huofn&%`Iccoo-8O!{^A zqHzc7;_SHtg!2oq^ms5$n+oaC(Ni(F4`!eQ2PV+BZsJ3c-LMuP1ce763gltA+k&mA zCxm3ip&PwUDgX!z04*UzpuqP1peY41rh`%fU&uf~lu5_z;sav+4gttz6^dk%A3m}O zR3`w+WLpbIfI!VIsW041$b;tc?1Z6|!+v5!RHi|G`0Ba2%oMg#=|uy;k)2@?hcZhD zi7GMOBnWp(6Oa2Y^^5;sWHN>W?jQh1*8mqQV4-Bc4Fy63;buZm3jiGqAaPp4j1?eo zhRO|K3$KJtR486EgGfpJCNNVW8`Ss1+nKPYAROkh7496=lm^V0fbDmGgkSn+1q$`o zawC`6Q&y1Z7ccq6|CiSLnv{)5!p-A2X~;N3h1ADE$$+FDOA;c?%q6KIrtuqLeCi zLU~gXo&6Pni}m1=z6)A{WE(yZ%qkS?fb6`;4!Hr2%*Y|{ytaj;4;Cl|%kZX!i)-Sj zmEI^mkvo)@oHqt`goxLd;G~(+o0;ly{?a4>))rO)21rCMU?#*U7MrmtRUzxpGfTBv?0JVJ%BXt3K@|q1Py`wY*lO)cB6(VZk|8oMaI21| z@=>T(JD&`3aovFAk%+r9ieL}#f|9^Woea%b6>Z`GsYdOhm2eyK*?a*|X8>EV&334C zWCJC82zlGtp3>HpH*yjES7#6KJAO6Q*m3faZK$vF@GqrHVh@gmby>GB)Yb_JMg;7X ztxlpJTOpyy?=Gm`v?D8`TK+zU>WwD-fQsv3|KHe7LMqf`C?Pqsz#q21}TMtt~7;I`UrO)h(oy{;v01yG;p}LT4>2K@TNxtoVX_P5wDtliP8B z7d`yvHq_eZj@5y-r99O4m3;4kr-o1OvH1Y)8a9guNK?vHB?@A$vPTR%Ih}x9NN1vR zZ)Q!W#zUJ^)8Ot2aKMN6q!_n_&@NJ;Xyo%7Dw%S^-8$--=V9vYW&_A>_E1`Wck$`I zo%wy=W1qTGp6)kde*28%Ha|T`zoTfJPi)U*OOIfI!6;9XEjD; z57m@TAbd$$cjXkqD@RBr2n$qWlQU zlltV^qv7mOt+StBbgWmdjRJDHfH74k>Z?@D`Fco*H7ei!aVwJYR-%dU+FGSuf_IGi zZ*uQdNbL5pUljbdQuPb}!V+9aTTm65=qeM4a3$Acq7jdAQ&)R&W<-?0V7 zmPZyOKE6SVk_Y*xbFsz8P*;v2b;>A(yKi?fp45MaPkllz8;sr#=}(fu)<2qvWrCx$ z@fjz8K}n=1YTjN5YY_m{amZV4fnrgFz^Ut*(D%$ zjhU$2b2+s8Sj0>FvX|Kp-^Dxh?_*YEB|JGzjP_=~^E^AzWhCBk=HurKXzQM7HoaB6 zX!d3j+RqsFi|DjtL)(1uJ7)lC`c;^U&K3+H0^eCg@`P@}>nrL;XJ@Dl3hDr;A0j1N zPS>%{&NqoIcZDyO!JA&e}7KGHRj_}Njp+- z(xT*bLLBdb@1*=HuU#|&8F5VWE9N2%=EA4s)F$L~3vZ|cs8??h`LK81`zCgOe(c0; z>kLL|JfE)#n>|%N6Z+^<_p!MP=ew8p=@`*I#r<*2<9>S05dTM5^^a=05-+)~A8MIZ z=?D{?={(@s;EUoaDNMa@@tXH`d%v6g)w>=L!b^DXYMYAajP~E4jYYJpO=*00A;VT%}3 z)R^1X*rNO6nNDSOFPBd*(>VD@cfQwrt{2p@;<}W-QF(n23`B{; z_fK74c=SNGlKnBw_${7ZuH67{63La>-s>{PSq)2w)u9*fS+|MCj zv6FkqNyopwUHA~Y5Zkt5IpNA&V%q-vyZ+KQE>PZoRZ&1lQu!9Uslp?2s?HlpDHpG# zNuF~b#1jA=27E#1ErtM4D8J(T-JG&br)|Slt5nsP=^I2$s-U*jYV}34@TcMIK6Z%< z<4xIO_x1BlJ2}IO_{F)uxSr=`l{s}U*LuF7Bz=rJJ~qIOofvo0)L-+fDTxS=|cpK?y4 z3ED{a(4w2X{Jp~?`QCSPLEg!jm;4Qh@GGS$2Xs@!clwY>TQXB}T`dDh1d`=WqRBxs zJy$8&7%y=%W8IS&330BNuDY+d<^Bwghb%UevYogSBctwYLoq35ZgzFFv~xD|Wgl|Y zJ+L#~)hi`5RCf!(SiviF^;%t1%j4SNIXYfLQ7)Qs+IOU{wZXt-)!D)fJuCzYn$V_3v`rj2ac zIgKf<>V%|ksBRBsT*v0hYdN$vENd2KN>gZCf~mKZ^gK1aw%Ce(Zc;6d_){^|y%122 zS3555F~8aAw3715C{tP%klbaNTz&V!_ZMzBkiO&|KD@R*PJTnWkJ}pTKVP9v;R<~7e)0=~ynjExoujyqIseY+A zF?MIIb|9aLw%o+!vE)n+M=-$@I#2`WG3fg@wnWl)V0ICrUnq{22w=LnF)PDTcFEXH z!KS?md>b;!10|-Hjj_^VujwpQiIA7p7@B^<^<4Dc#Vpl}ZJ(H?jn|>n==fkMsT=Q? z>NDZ{2QKCk{H-)#$WzEF%>cYmlZ^c4mNvcC>rQq@KrlQe?ANx{&>Mfs`O*Nd9U}0qQhZtPF~p-8<}ppS+{KR$;-AT z2?51%zNNEOev8&Y)oHQcgR9)7)`B=`y|1xRf6iV#Rb1tGb*?1p`Q*vs;)%6|yeC7< zn~=D}yFwQq?`k%mOrtJ#%(qM}K3IBwSf*=URnwg*s;c(TFD_^PCdL zmcsF!wO0Y1OqlZG=#Sy8-==@Ou*Dx+9&s^!yFBK;|5$W)BisJxD?hzQ#|zVGVJ#2H41jm5+f7=(PS-jwIkwq*^Kiu^rUy*Bsxv3a{f$Dl6^c0b}#ADTXxRawATq6 zNj5|XOcb$+?(9Xl*Mn-o=`CmBZ|a$N&@LoyM7@)~_gzXIk;vKi)DG=mfx-GFa2%ONrx-#U&LD z>UCL7UdEv%_Y4x%+ZJuZgzODRVPZ+YM=JX1mwh@H(%U}jl#|7GS9aKfNlQ+ Deg8ll diff --git a/src/site/resources/robots.txt b/src/site/resources/robots.txt deleted file mode 100644 index da97f40a611..00000000000 --- a/src/site/resources/robots.txt +++ /dev/null @@ -1,5 +0,0 @@ -# /robots.txt file for http://james.apache.org - -User-agent: * -Disallow: /CVS -Disallow: /images diff --git a/src/site/site.xml b/src/site/site.xml deleted file mode 100644 index 08407856b26..00000000000 --- a/src/site/site.xml +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - James Project - images/james-project-logo.gif - http://james.apache.org/index.html - - - - The Apache Software Foundation - images/asf-logo-reduced.gif - http://www.apache.org/index.html - - - - org.apache.james - maven-skin - 1.1-SNAPSHOT - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/src/site/xdoc/code-standards.xml b/src/site/xdoc/code-standards.xml deleted file mode 100644 index c1343f7258e..00000000000 --- a/src/site/xdoc/code-standards.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Coding Standards - Serge Knystautas - - - - -
- -

- Submissions to the James project must follow the coding conventions - outlined in this document. James developers - are asked to follow coding conventions already present in the code. - (For example, if the existing code has the bracket on - the same line as the if statement, then all subsequent code - should also follow that convention.) Anything not - explicitly mentioned in this document should adhere to the - official - Sun - Java Coding Conventions. -

- -

- Developers who commit code that does not follow - the coding conventions outlined in this document will be - responsible for fixing their own code. -

- -

-1. Spaces between parentheses are optional. The preference is to exclude -extra spaces. Both of these conventions are acceptable: -

- -

- -

- -

-2. Four spaces. NO tabs. Period. The James -mailing list receives cvs commit messages that are almost impossible -to read if tabs are used. -

- -

-In Emacs-speak, this translates to the following command: - -(setq-default tab-width 4 indent-tabs-mode nil) -

- -

-3. Use Unix linefeeds for all .java source code files. Only platform-specific -files (e.g. .bat files for Windows) should contain non-Unix linefeeds. -

- -

-4. Javadoc must exist on all methods. Contributing -a missing javadoc for any method, class, variable, etc., will be GREATLY -appreciated as this will help to improve the James project. -

- -

-5. The Jakarta Apache/James License MUST be placed -at the top of every file. -

- -
- - - diff --git a/src/site/xdoc/contribute.xml b/src/site/xdoc/contribute.xml deleted file mode 100644 index c3af9292fa1..00000000000 --- a/src/site/xdoc/contribute.xml +++ /dev/null @@ -1,112 +0,0 @@ - - - - - Contributors How To - Danny Angus - - -
-

- Anyone can contribute
- That's right, we always want to hear from people with contributions to the code, - the documentation, the website, and bug reports.
- The rest of this document outlines the way to go about these to maximum effect.
-

-

- If you are new to this you may be interested in some of these resources.
- A good, full, summary of links to guidelines
- Subscribe to the relevant mailing lists (link on the left).
- Craig R. McClanahan's advice how to get involved
- How Jakarta projects run
-

- -
- -
-

- Patches should be submitted to the developers mailing list.
- Always use diff -u to generate patches, so we can apply them using 'patch'.
- Make sure you are patching the latest cvs (the HEAD). - (You might want to try 'cvs diff -u -w -b -rHEAD' against the checked out module where - you have implemented the patch.
-
Make sure the patch only contains what is intended, your checkout could be outdated.
- Make your patch from the jakarta-james directory and make sure it conforms - to the code standards, otherwise it may be ignored. It is OK to make a single patch covering several - files, but please only one issue at a time.
- Prefix the mail subject with [PATCH]
- Briefly outline the reason for your patch, - the solution your patch implements, why a patch is - needed and why your code will solve the problem. Note any bug numbers your patch addresses.
- Submit the patch as an attachment to the mail, this - mail should preferably be in either BASE64 or QuotedPrintable format, to prevent line wrapping.
-

- -

- The reason for these rules is so that commiters can easily see what you are trying to achieve, - it is their resonsibility to manage the code and review submissions, - if you make it easy for them to see what you are doing your patch is more likely to - be commited quickly (or at all).
-

-
- -
-

- Like the principles for patch submission, mark your mail [PATCH] and ensure - your submission conforms to the code standards. Provide a Brief outline of - your intentions, as above, so that your code can be reviewed easily, and a - note of any relevant bug numbers.
- New files must contain a reference to the Apache licence, copy the header from an existing file.
- It also helps if you send your files in an archive (tar, zip) which preserves directories, make it from the jakarta-james directory so we can un-tar your files into the right place. -

-
- -
-

- Many improvements come as a direct result of bug - reports, and contributed fixes, often by the same person. It is sometimes said that Apache - projects evolve because users become so fed-up waiting for bugs to be addressed that they - fix them themselves. :)
- If you report a bug, here we'd appreciate it if you could send a mail to the users or developers - mailing lists, so that we can discuss it with you, bugzilla isn't a great way for mediating - communication.
- If you want to fix a bug, please contribute your changes according to the guidelines above, - in the Code Patches section. It is much simpler to deal with submissions if they all come - through the same channel. If you still really want to attach patches to bug submissions, please do send us a mail tagged [PATCH] too, so that we notice your patch. -

-
- -
-

- While we are glad to accept contributions to documentation - from anyone, in almost any format, because its much better than none, please consider these - guidelines to help us to assimilate your contribution.
- To edit an existing document try to edit the xml version in src/xdocs (check it out from cvs) - and if you can, submit a patch as for Code Patches.
- If you want to contribute new files please try to use the simple xml format we use.
- If this means nothing to you please try to contribute HTML or plain text documents without - any styling, so that we can get at the words and easily convert them into our xml format.
- If all this seems like unnecessary nonsense, send us whatever you like, we'd still be - happy to receive good documentation. -

-
- - - diff --git a/src/site/xdoc/download.xml b/src/site/xdoc/download.xml deleted file mode 100644 index 36aa4f34163..00000000000 --- a/src/site/xdoc/download.xml +++ /dev/null @@ -1,159 +0,0 @@ - - - - - Apache James Mail Server Project - Download - - -
- -

Use the links below to download the Apache James Mail Server from one of -our mirrors. You must verify the -integrity of the downloaded files using signatures downloaded from -our main distribution directory.

- -

Only current recommended releases are available on the main -distribution site and its mirrors. Older releases are available from -the archive download -site.

- -
- -

[if-any logo] -[end] -The currently selected mirror is [preferred]. If you encounter a -problem with this mirror, please select another mirror. If all -mirrors are failing, there are backup mirrors (at the end of -the mirrors list) that should be available.

- -
-Other mirrors: - -
- -

You may also consult the complete -list of mirrors.

- -
- -
- -

This release has many enhancements and bug fixes over the previous -release. See the Change Log -for a detailed list of changes. Some of the earlier defects could -turn a James mail server into an Open Relay. All users of James are urged to upgrade to James v2.2.0 as soon as -possible.

- - - -
- -
- -

It is essential that you verify the integrity of the downloaded -files using the PGP or MD5 signatures.

- -

The PGP signatures can be verified using PGP or GPG. First -download the KEYS -as well as the asc signature file for the particular -distribution. Make sure you get these files from the main distribution -directory, rather than from a mirror. Then verify the signatures -using

- -

-% pgpk -a KEYS
-% pgpv james-version.tar.gz.asc
- -or
- -% pgp -ka KEYS
-% pgp james-version.tar.gz.asc
- -or
- -% gpg --import KEYS
-% gpg --verify james-version.tar.gz.asc -

- -
- -
- -

The software listed above represents the latest Release Build -available from the Apache James Project. From time to time, we also -make available Test Builds. These Test Builds are periodic -snapshots during development. Generally, these are considered -stable snapshots, but they have not undergone as much testing as a -Release Build, nor have they been voted upon for release by the -developer community. These are simply convenient test builds. -Sometimes the purpose for a Test Build could be soliciting feedback on -a specific change. Test Builds are announced on the General mailing -list (general@james.apache.org).

- -Latest Test Build - -
- -
- - diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml deleted file mode 100644 index d0ddcd4139f..00000000000 --- a/src/site/xdoc/index.xml +++ /dev/null @@ -1,46 +0,0 @@ - - - - Overview - JAMES Project Web Team - - -
-

The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

-

JAMES is organized into subprojects with JAMES Server and the Mailet API as their core.

-

Apache JAMEs is a project of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.

-

The ASF maintains other Java projects which may also be of interest. These are detailed on the ASF Projects page.

-

We recommended that users of JAMES products subscribe to the JAMES users mailing list.

-
-
-
-
- - ApacheCon US 2006 -
- -

JAMES Server 2.3.0 RC3 Released

-

James PMC is proud to announce the availability of the third, and hopefully last, release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

-

New development roadmaps are being discussed right now, so stay tuned for 2.3.0 final and for the following news. - Sep/2006

-

JAMES Products website revamped

-

We just finished a major update of james products to be able to publish each product specific site under this new website structure - Aug/2006

-

JAMES Server 2.3.0 on the way

-

After a long time of development we have released the first release candidate of JAMES Server 2.3.0. After a period of user testing version 2.3.0 will be released. - Jul/2006

-

New project JAMES jSPF

-

JAMES PMC is happy to announce that we are working on a Java implementation of the SPF specification. The first betas are already available for download. - Jul/2006

- - -

JAMES PMC react to the closure of Apache Avalon.

-

JAMES PMC would like to reassure all of our users that JAMES Server is alive and well. All of the James team have kept abreast of the Avalon developments culminating in the closure of the Avalon project and dispersal of its codebase. We are are keen to stress that this has little impact on our ability to support and develop Server in both the short and long terms.
Over the coming months we will be finalising and publishing a road map for JAMES Server which will address all of the specific concerns raised by Avalon's closure, but rest assured JAMES Server' future is safe, and we have enthusiasm and plans aplenty.
In the meantime we would like to extend our best wishes to all our friends from Avalon, here's luck with your future projects guys!
If you are at all concerned please subscribe to the server-user mailing list and raise your points there. - 05/Jan/2005

- -

JAMES product sources have moved to "Subversion"

-

Subversion is a version control system like CVS, but it has advantages over CVS for Apache Software Foundation (ASF) projects.
In common with all other ASF projects we have reviewed our use of CVS and migrated our code to Subversion.
-Have a look at this FAQ for further details. - 05/Jan/2005

-

- -

- - diff --git a/src/site/xdoc/license.xml b/src/site/xdoc/license.xml deleted file mode 100644 index 06475cf8c68..00000000000 --- a/src/site/xdoc/license.xml +++ /dev/null @@ -1,208 +0,0 @@ - - - - - - Apache Software License - Serge Knystautas - - - -
-

- James is released under the Apache Software License - listed below: -

- - - -
- -
-

- dnsjava is distributed with James, a copy of the licence is contained in the distribution -

-
- - - - diff --git a/src/site/xdoc/mail.xml b/src/site/xdoc/mail.xml deleted file mode 100644 index 5919d820f48..00000000000 --- a/src/site/xdoc/mail.xml +++ /dev/null @@ -1,249 +0,0 @@ - - - - - Mailing lists - James Project Web Team - - -
-

This is a living -document that provides details of mailing lists and guidelines for their -use for the Apache James project.
Please read the whole document -and find a list of available mailinglists at the bottom of the -page.
Last Updated June 2006.

-
-
-

A mailing list is an electronic discussion forum -that anyone can subscribe to. When someone sends an email message to the -mailing list, a copy of that message is broadcast to everyone who is -subscribed to that mailing list. Mailing lists provide a simple and -effective communication mechanism for discussion and decision making. -

-

The Apache Software Foundation has well established reasons for -using email and not other types of forum.
We are -not interested in hearing proposals to use NNTP (news -groups) or web forums or any other medium.
You may use a mail-news -gateway, gmail or anything else you like but email is, and will remain, -the official medium.

-

With potentially thousands of subscribers, -there is a common etiquette that you should observe. Please keep on -reading.

-

- Respect the mailing list type -

-

-

    -
  • "User" lists are lists where you can send questions -and comments about configuration, setup, usage and other "user" types of -questions.
    • -
  • "Developer" lists are lists where you can send -questions, comments and contributions about the project's software -source code and general "development" types of questions.
    • -
-

-

Some questions are appropriate for posting on both the -"user" and the "developer" lists. In this case, pick one and only one. -Do not cross post.

-

Asking a configuration question on the -developers list is frowned upon because developers' time is as precious -as yours. By contacting them directly instead of the users list you are -abusing resources. It is unlikely that you will get a quicker answer -this way, those developers who have time to devote to providing support -are also subscribed to the users list. If you contact individuals -directly, or post your user issues to the developer list you may get no -answer at all.

-

- Join the lists that are appropriate for -your discussion. -
Please make sure that you are joining -the list that is appropriate for the topic that you would like to -discuss. The general list is for discussions about the management and -direction of the James project, not for "general support".

-

- Ask smart questions. -
- -Every volunteer project obtains its strength from the people involved in -it. You are welcome to join any of our mailing lists. You can choose to -lurk, or actively participate; it's up to you. The level of community -responsiveness to specific questions is generally directly proportional -to the amount of effort you spend formulating your question. Eric -Raymond and Rick Moen have even written an essay entitled "Asking -Smart Questions" precisely on this topic. Although somewhat -militant, it is definitely worth reading.
- Note: Please do -NOT send your Java problems to the two authors. They welcome feedback on -the FAQ's contents, but are simply not a Java help resource. Follow the -essay's advice and choose -your forum carefully.

-

- Keep your email short and to -the point. -
If your email is more than about a page of -text, chances are that it won't get read by very many people. It is much -better to try to pack a lot of informative information (see above about -asking smart questions) into as small of an email as possible. If you -are replying to a previous email only quote the parts that you are -replying to and to remove the unnecessary bits. This makes it easier for -people to follow a thread as well as making the email archives easier to -search and read.

-

- Do your best to ensure that you are -not sending HTML or "Stylelized" email to the list. -
If -you are using Outlook or Outlook Express or Eudora, chances are that you -are sending HTML email by default. There is usually a setting that will -allow you to send "Plain Text" email. If you are using Microsoft -products to send email, there are several bugs in the software that -prevent you from turning off the sending of HTML email. Please read this -page as well...

-

- Watch -where you are sending email. -
The majority of our mailing -lists have set the Reply-To to go back to the list. That means that when -you Reply to a message, it will go to the list and not to the original -author directly. The reason is because it helps facilitate discussion on -the list for everyone to benefit from. Be careful of this as sometimes -you may intend to reply to a message directly to someone instead of the -entire list. The appropriate contents of the Reply-To header is an -age-old debate that should not be brought up on the mailing lists. You -can examine opposing points of view condemning our -convention and -condoning it. Bringing this up for debate on a mailing list will add -nothing new and is considered off-topic. -

-

- Do not -cross post messages. -
In other words, pick one mailing -list and send your messages to that mailing list only. Do not send your -messages to multiple mailing lists. The reason is that people may be -subscribed to one list and not to the other. Therefore, some people will -only see part of the conversation.

-
-
-

There are several sites on the net that archive and -provide searching for our mailing lists in HTML readable format. If a -list is not there, then feel free to take initiative and submit it for -us via jakarta-general mailing list. -

-

-

-

-
-
-

- Now that you have -read the guidelines above please subscribe to our lists and join our -community.

- -

- Low -Traffic - Subscribe - Unsubscribe - Guidelines - -Archive -

-

This is the list where users of the Apache James -(Server) meet and discuss issues. Developers are also expected to be -subscribed to this list to offer support to users of Apache James -(Server).

- - -

- Low Traffic - Subscribe - Unsubscribe - Guidelines - -Archive -

-

This is the list where participating developers of -the the Apache James Project meet and discuss issues, code -changes/additions, etc. Subscribers to this list get notices of each and -every code change, build results, testing notices, etc. Do not send -mail to this list with usage questions or configuration problems -- -that's what server-user@james is for.

- - -

- Very Low Traffic - Subscribe - Unsubscribe - Guidelines - -Archive -

-

This is the list where participating developers of -the the Apache James project discuss changes/additions to the James -websites etc. Subscribers to this list get notifications of every commit -of the website reaourcesDo not send mail to this list with James -software problems -- that's what server-user@james is for.

- - -

- Low -Traffic - Subscribe - Unsubscribe - Guidelines - -

-

This is the list for general discussions -relating to the running of the project, it is the public list of the -James project management comittee (PMC) and is a public list open to -all. Do not send mail to this list with James software problems --- that's what server-user@james is for.

- -
- - diff --git a/src/site/xdoc/weare.xml b/src/site/xdoc/weare.xml deleted file mode 100644 index eab3e15ad63..00000000000 --- a/src/site/xdoc/weare.xml +++ /dev/null @@ -1,172 +0,0 @@ - - - - - Who We Are - James Project Web Team - - -
-

Special thanks go to the following people for their contributions to this project. We also appreciate documentation, feedback, and bug reports. This is a living document that describes the key contributors to James. Last Updated July 2006.

-
-
-

- Serge Knystautas (sergek at lokitech.com) (SK) -
Serge was the original donator of the James code, which has since been massively improved by people smarter than him. He tries to answer questions on the listserv and make code contributions when he does get a rare bit of free time.

-

- Harmeet Bedi (harmeet at kodemuse.com) (HB) -

-

- Danny Angus (danny at apache.org) (DA) -
Danny is a member of the Apache Software Foundation and married father of two by night, and by day works as lead technical consultant for the Student Loans Company ltd. -

-

- Noel J. Bergman (noel at devtech.com) (NjB) -

-

- Vincenzo Gianferrari Pini (vincenzo.gianferraripini at praxis.it) [VGP] -

-

- Soeren Hilmer (sh at widetrail.dk) [SH] -

-

- Steve Brewin (sbrewin at synsys.com) [SB] -

-

- Jason Webb (jw at inovem.com) [JW] -

-

- Stefano Bagnara (apache at bago.org) [SB2] -

-

- Norman Maurer (nm at byteaction.de) [NM] -

-

- Bernd Fondermann (bf_jak at brainlounge.de) [BF] -

- -
-
-

Many people have had a hand in James' success over the years, here we'd like to give credit to those who have made a difference and to those who have left.

-

- Alan D. Cabrera (list at toolazydogs.com) [ADC] -

-

- Darrell DeBoer (DD) -

-

- Stephen J. McConnell (mcconnell at apache.org) (SJM) -

-

- Peter M. Goldstein (farsight at alum.mit.edu) (PG) -

-

- Pete Donald (PD) -

-

- Charles Benett (charles at benett1.demon.co.uk) (CB) -

-

- Federico Barbieri, (scoobie at systemy.it) (FB) -

-

- Stuart Roebuck, stuart.roebuck at adolos.co.uk (SR) -

-

- Ivan Seskar, iseskar at upsideweb.com (IS) -

-

- Prasanna Uppaladadium, prasanna at vayusphere.com (PU) -

-

- Gabriel Bucher, gabriel.bucher at razor.ch (GB) -

-

- Matthew Pangaro, mattp at lokitech.com (MP) -

-

- Jason Borden, jborden at javasense.com (JB) -

-

- Randy Stanard (rstanard at lokitech.com) (RS) -
Contributed the James logo.

-

- Samuel Sadek (Samuel.Sadek at kpmg.co.uk) (SS) -

-

- Stephan Schiessling (s at rapi.com) (SS2) -

-

- Eung-ju Park (colus at apache.org) (EP) -

-

- Paul Hammant (Paul_Hammant at yahoo.com) (PH) -

-

- Jeff Keyser (JKeyser at telocity.com) (JK) -

-

- Andrei Ivanov (myfam at surfeu.fi) (AI) -

-

- Brad Walker (bwalker at studentadvantage.com) (BW) -

-

- Christian Buchegger (christian.buchegger at planet-interkom.de) (CB2) -

-

- Shilpa Dalmia (shilpa at postx.com) (SD) -

-

- Steve Short (sshort at postx.com) (SS3) -

-

- Aaron Knauf (aknauf at xtra.co.nz) (AK) -

-

- Serge "Sergei" Sozonoff (serge at globalbeach.com) (SS4) -

-

- Kai Londenberg (kai.londenberg at my-vwclub.de) [KL] -

-

- Mark Imel (james at imelshire.com) [MI] -

-

- Kevin Schmidt (ktschmidt at earthlink.net) [KS] -

-

- Hontvari Jozsef (hontvari2 at solware.com) [HJ] -

-

- Cesar Bonadio (bonadio at picture.com.br) [CB3] -

-

- Marco Tedone (mtedone at jemos.org) [MT] -

-

- Tim Stephenson (tim at thestephensons.me.uk) [TS] -

-

- Richard O. Hammer (rohammer at earthlink.net) [ROH] -

-
- - From a29ff315ed4fe35a1a15ced428cdbf17f611414f Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 30 Sep 2006 17:21:53 +0000 Subject: [PATCH 003/541] Reorganizing project folder to include trunk/tags/branches structure. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@451621 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 56 ++++ .../src/main/resources/css/maven-theme.css | 257 ++++++++++++++++++ .../main/resources/images/button-bottom.gif | Bin 0 -> 590 bytes .../src/main/resources/images/button-top.gif | Bin 0 -> 392 bytes .../src/main/resources/images/collapsed.gif | Bin 0 -> 53 bytes .../src/main/resources/images/expanded.gif | Bin 0 -> 52 bytes .../src/main/resources/images/external.png | Bin 0 -> 230 bytes .../src/main/resources/images/h2feather.gif | Bin 0 -> 360 bytes maven-skin/src/main/resources/images/h4.jpg | Bin 0 -> 360 bytes .../main/resources/images/icon_error_sml.gif | Bin 0 -> 1010 bytes .../main/resources/images/icon_info_sml.gif | Bin 0 -> 606 bytes .../resources/images/icon_success_sml.gif | Bin 0 -> 990 bytes .../resources/images/icon_warning_sml.gif | Bin 0 -> 576 bytes .../src/main/resources/images/newwindow.png | Bin 0 -> 220 bytes maven-skin/src/main/resources/images/void.gif | Bin 0 -> 50 bytes 15 files changed, 313 insertions(+) create mode 100644 maven-skin/pom.xml create mode 100644 maven-skin/src/main/resources/css/maven-theme.css create mode 100644 maven-skin/src/main/resources/images/button-bottom.gif create mode 100644 maven-skin/src/main/resources/images/button-top.gif create mode 100644 maven-skin/src/main/resources/images/collapsed.gif create mode 100644 maven-skin/src/main/resources/images/expanded.gif create mode 100644 maven-skin/src/main/resources/images/external.png create mode 100644 maven-skin/src/main/resources/images/h2feather.gif create mode 100644 maven-skin/src/main/resources/images/h4.jpg create mode 100644 maven-skin/src/main/resources/images/icon_error_sml.gif create mode 100644 maven-skin/src/main/resources/images/icon_info_sml.gif create mode 100644 maven-skin/src/main/resources/images/icon_success_sml.gif create mode 100644 maven-skin/src/main/resources/images/icon_warning_sml.gif create mode 100644 maven-skin/src/main/resources/images/newwindow.png create mode 100644 maven-skin/src/main/resources/images/void.gif diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml new file mode 100644 index 00000000000..ce9707112f0 --- /dev/null +++ b/maven-skin/pom.xml @@ -0,0 +1,56 @@ + + + 4.0.0 + org.apache.james + maven-skin + 1.1-SNAPSHOT + JAMES Skin + Apache JAMES Official Maven2 Site Skin + + + + + apache.snapshots + Apache Development Snapshot Repository + scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository + + + maven-skin-website + scp://minotaur.apache.org/www/james.apache.org/maven-skin + + + + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/maven-skin + scm:svn:https://svn.apache.org/repos/asf/james/project/maven-skin + http://svn.apache.org/viewvc/james/project/maven-skin + + + \ No newline at end of file diff --git a/maven-skin/src/main/resources/css/maven-theme.css b/maven-skin/src/main/resources/css/maven-theme.css new file mode 100644 index 00000000000..19ac0cbae3c --- /dev/null +++ b/maven-skin/src/main/resources/css/maven-theme.css @@ -0,0 +1,257 @@ +/* + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +*/ + +#apacheconbox { + margin: 20px 0px 0px 20px; + padding: 10px; + border: 1px solid #ccc; + background-color: white; + background-image: url(../images/button-top.gif); + background-repeat: repeat-x; +} +#apacheconspacer { + float: right; + margin: 0px 0px 10px 10px; + background-color: white; +} +#poweredBy { + display: none; +} +.xleft { + float: right; +} +.xright { + float: left; +} +#bannerLeft img { + margin-left: 20px; +} +#bannerRight img { + padding: 0px; + border: 0px; + margin-top: 20px; + margin-right: 20px; + margin-bottom: 0px; +} +body { + padding: 0px 0px 10px 0px; +} +body, td, select, input, li{ + font-family: Verdana, Helvetica, Arial, sans-serif; + font-size: 13px; +} +code{ + font-family: Courier, monospace; + font-size: 13px; +} +a { + text-decoration: none; +} +a:link { + color:#36a; +} +a:visited { + color:#47a; +} +a:active, a:hover { + color:#69c; +} +#legend li.externalLink { + background: url(../images/external.png) left top no-repeat; + padding-left: 18px; +} +a.externalLink, a.externalLink:link, a.externalLink:visited, a.externalLink:active, a.externalLink:hover { + background: url(../images/external.png) right center no-repeat; + padding-right: 18px; +} +#legend li.newWindow { + background: url(../images/newwindow.png) left top no-repeat; + padding-left: 18px; +} +a.newWindow, a.newWindow:link, a.newWindow:visited, a.newWindow:active, a.newWindow:hover { + background: url(../images/newwindow.png) right center no-repeat; + padding-right: 18px; +} +.section { +margin-left: 10px; +} +.section p, .section table { +margin-left: 10px; +} +h2 { + color: #904040; + background-color: white; + border: 0px; + border-bottom: 2px solid #525D76; + padding: 0px; + padding-left: 20px; + vertical-align: bottom; + font-weight:900; + font-size: large; + background: url(../images/h2feather.gif) left center no-repeat; + margin-bottom: 15px; +} +h3 { + border: thin solid #828DA6; + padding-bottom: 0px; + color: #525D76; + background-color: white; + padding: 2px 2px 2px 2px; + border: 0px; + font-weight: bold; + font-size: 15px; + margin-top: 5px; + margin-bottom: 13px; + border-bottom: 1px dotted #525D76; +} +h4 { + padding: 2px 2px 2px 2px; + border: 0px; + background: url(../images/h4.jpg) 0% 70% no-repeat; + color: black; + margin-top: 5px; + padding-left: 12px; + background-color: #fff; + font-weight: bold; + font-size: small; + margin-left: 10px; +} +h5 { + padding: 2px px 2px 2px; + border: 0px; + border-bottom: 0px; + color: black; + background-color: #fff; + font-weight: bold; + font-size: small; +} +p { + line-height: 1.3em; + font-size: small; +} +#breadcrumbs { + background: url(../images/button-top.gif) left top repeat; + border-top: 0px solid #525D76; + border-bottom: 1px solid #ccc; /* #525D76;*/ + border-top: 1px solid #ccc; + padding-top: 3px; + padding-bottom: 3px; + background-color: #eeeeee; + font-size: small; +} +#breadcrumbs a { + font-weight: bold; +} +#bodyColumn { +} +#leftColumn { + margin: 0px; + margin-top: -1px; + border: 0px; + padding: 0px; + padding-left: 20px; + background: none; +} +#leftColumn ul { + font-size: 15px; + padding-top: 4px; + padding-bottom: 10px; +} +#leftColumn li { + padding-left: 10px; + padding-bottom: 3px; +} +#navcolumn { + border: 1px solid #ccc; /* #525D76;i*/ + background: url(../images/button-bottom.gif) left bottom no-repeat; + padding: 15px; + border-top: 0px solid white; + background-color: white; +} +#navcolumn h5 { + font-size: 12px; + border-bottom: 1px solid #eee; + padding-top: 3px; + padding-bottom: 2px; + margin-right: 10px; + color: #000; +} +table.bodyTable { + padding-right: 20px; +} +table.bodyTable th { + color: black; + background-color: #bbb; + text-align: left; + font-weight: bold; + border-top: 1px solid #ccc; + border-bottom: 1px solid #ccc; + background-image: url(../images/button-top.gif); +} +#footer { + border-top: 1px solid #ccc; + margin-top: 30px; + padding: 10px; + background-image: url(../images/button-top.gif); +} +table.bodyTable th, table.bodyTable td { + padding: 2px; + font-size: 1em; +} +table.bodyTable tr.a { + background-color: #fff; +} +table.bodyTable tr.a td { + border-bottom: 1px solid #eee; +} +table.bodyTable tr.b { + background-color: #fff; +} +table.bodyTable tr.b td { + border-bottom: 1px solid #ddd; +} +.source { + border: 1px solid #525D76; +} +dl { + padding: 4px 4px 4px 6px; + border: 1px solid #aaa; + background-color: #ffc; +} +dt { + color: #900; +} +#organizationLogo img, #projectLogo img, #projectLogo span{ + margin: 8px; +} +#banner img { + padding: 10px; +} +.errormark, .warningmark, .donemark, .infomark { + background: url(../images/icon_error_sml.gif) no-repeat; +} +.warningmark { + background-image: url(../images/icon_warning_sml.gif); +} +.donemark { + background-image: url(../images/icon_success_sml.gif); +} +.infomark { + background-image: url(../images/icon_info_sml.gif); +} diff --git a/maven-skin/src/main/resources/images/button-bottom.gif b/maven-skin/src/main/resources/images/button-bottom.gif new file mode 100644 index 0000000000000000000000000000000000000000..4c992992537acd3ae629ee046c446d68dad05deb GIT binary patch literal 590 zcmV-U0M)j$~<`D4?!v>%MR- z&vb3yc&_h!@BhG{a7Zi~kI1BQ$!t2G(CBkOty-_xtai)odcWYXcuX#v&*-#z&2GEj z@VIs;jK6uCK7Mva__cwzs&sx}68TzQ4f1!o$SH#>dFX%FE2n&d<=%($mz{*4NnC z+S}aSzzyKx;^XAy=I7|?>g(+7?(gvN^7Hid_5}F(`uqI-{{H|23LHqVpuvL(6DnND zu%W|;5F<*QNU@^Dix~GM*vPS?$B!WYLy8oJq5$&6_xL z>fGtkfzO{ng9;r=w5ZXeNRujE%CxD|r%fOt?uiw9b0}CEZxUk{Fh!ZPb%($`R$B-jSo=my2 z<;$2e^HspPv**vCLyI0wy0q!js8g$6&APSg*RW&Do=v;9?c2C>>)y@#bAjK$g9{%{ zytwh>$dfBy&b+zv=g^}|pH98H_3PNPYv0bjyZ7(H7l)+46zyJRL1}IKEy*TU5yZ@lqjAUt^XsWJk>%MUO zB6Mxvc&_h!@BhG{5LhT0kI1BQ$!t2G(5Q48U0AQ!tai)odcWYXcuW>6&gisy&2GEj z@VIs;jK6uCK7J2eY)bwzs&sy1Tr+zQ4f1zX8O>#>dFX%FE2n&d<=%($E9d*4NnC z+S}aS-rwNi;^W}}=I7|?>g(+7?(gvN^7Hia4EOl?`uqI-{{H|23LHqVpuvL(6DnND zu%W|;5F<*QNU@^Dix@L%+{m$`$B!UALy8oJq5$&6_xL m>fFh*r_Y~2g9;r=w5ZXeNRujE%CxD|r%#h)yUTnvm1Iv_qshJlI4r7uBZ*YkPFU8d4p4Aua}2?(?R literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/expanded.gif b/maven-skin/src/main/resources/images/expanded.gif new file mode 100644 index 0000000000000000000000000000000000000000..0fef3d89e0df1f8bc49a0cd827f2607c7d7fd2f0 GIT binary patch literal 52 xcmZ?wbhEHbWM^P!XkdT>#h)yUTnvm1Iv_qshJlH@g}+fUi&t{amUB!D)&R0C2fzRT literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/external.png b/maven-skin/src/main/resources/images/external.png new file mode 100644 index 0000000000000000000000000000000000000000..3f999fc88b360074e41f38c3b4bc06ccb3bb7cf8 GIT binary patch literal 230 zcmeAS@N?(olHy`uVBq!ia0vp^+(699!3-oX?^2ToQY`6?zK#qG>ra@ocD)4hB}-f* zN`mv#O3D+9QW+dm@{>{(JaZG%Q-e|yQz{EjrrH1%@dWsUxR#cd{{R1fCIbVIy!atN z8e~{WkY6y6%iy53@(Yk3;OXKRQgJIOfsI*BO@UFsfhWLBc>*(#PB?Jn2*(o!76E4F z2oaVU3``tH+Kgs0GI5+@Tg}d)z%jd%F@?{8!SRZ5b1yT80-FZIMn)zc2Ca66y`pzY R*nws*Vde$l!dH+G>WG0AkX9 zkw^kO#R5~f0aWVd+rdU|kr+Si_VM}o_L~4i{{R1E0Y;4gL(m&pmH<-GRdQ4VNXrIK zG6p+K1xfSs^r&!}(M4+c|NmbFUeHl(I7LJBadO19Z?}R=@%Qb_ zUw+eqhx6az`t$SLbC2rg!|?j`%n?`h`T2zbUHbd|`u_XaJz1}qOsSPq;ibOfx3Eta zLjV8&A^8LV00000EC2ui01p5Z000JsK#Ak_D;keQ$Ij$IIwdNdtL8+?R*)8|YNQ-2 zmP~p<114LCg84U{-IRaz?G&UR! zDO+4I4H_B@0~A~@GzlCwAS{CoA{{h6WH2YD69{BK2CO~+a%4OoBm@DsKLG>;#6=#+ GK>$0AHKMBk literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/h4.jpg b/maven-skin/src/main/resources/images/h4.jpg new file mode 100644 index 0000000000000000000000000000000000000000..859f82f381a2c18f9768c9360ef25fcfa644bd8d GIT binary patch literal 360 zcmex=;a)Bf!ASz{JdmkYQwEW?*3z5*7r?ih_KO3P6U53StNg{=db*12l$7kXewy zp5f~3U3Y#L@2O4RYA;f5TH-V*;+uWii;P;?DJQfU_VT=Vx@&v)rhf(#|KH>S0HGN@ A3jhEB literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/icon_error_sml.gif b/maven-skin/src/main/resources/images/icon_error_sml.gif new file mode 100644 index 0000000000000000000000000000000000000000..61132ef2b01806f6122c31d173c98e01e499b9a0 GIT binary patch literal 1010 zcmZ?wbhEHbJMCn#OVEqF*oew~oaAu*+mN;-=y?VHT3tIe$XQqrDo-uB_a z!$aaK`z6))OKGn34?nwc^SuifkIL#EmDgV_qjg-#8v*0u4q4%1moUw{LZ54UeCgzNF^jX`uv-XK+9g@yFrG9?@ z!9&5&Tgk*j(b!GF&{N4I-Owl3GNQ;Kslp@APSw&&&ux9d>WxL~{EYoKm2KHvv3+ax zZUYB?Ae*8JnchZheXeEaa>@87?_fB*jV>(`erUx0B6j@wa!KnN)QWMO1rn9HC8 zQU}Tt3>@bftT|;oHYhlHH8T8tc{qL2LBC1&wnQeg^-S05<#H=J%;q~&KX!$OXH$lP zifQJ#9>L8|xhAVRHT-xPa*}7JK>(A*!AmL!CQC~j>707p+C5b#ib-SZ5@wfn#-0y8 zor_pb3M^%mkXhlduwjw4dk@RWhYZ<*tSUAV9x3eYyi#^d39lH{872xT#>g14FgCZb z+Lvv}DClhGVU*`8y(Qe}(9I>Lw<6->0~Q`zX3oMH2272dBARI`0wDzxS_G8b_H+a` TZ#n2*^y*Bf^Krq04Gh)*dSnrT literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/icon_info_sml.gif b/maven-skin/src/main/resources/images/icon_info_sml.gif new file mode 100644 index 0000000000000000000000000000000000000000..c6cb9ad7ce438a798426703e86a7ffc197d51dbb GIT binary patch literal 606 zcmZ?wbhEHb!Rj)7jHhhdgsOUdoQoueZi?7 z>>gViTe&E#V48n=mrru5S3;v}WQB8hiDz7$TU2Fg8RZkU)J)l4H+4sO@7jjxJ4?G(<~7c1nYFul=C0P+d#d`@bj{yi z-npcE!T#Qb2PP~z)H;3B%r(bntUlH>Y2~CvyV|C%UbyM>vTf&9?!2&e&!siHFV0_c zVB`KP8}?n^dg$7Yqc`@PxOMQ%-NWbZ9Xfk=)1K2OFF!hV;r{6>kIr6ua^~ve%eS9j zy7lbD`I|4_et!J??bq+WzI^-n`RfmdkOIfh!pgqYwSCK`t~@$#!^!1aj_y2mzyI{@?vuB79>2N$==JkApPs$`_~ygc*YCf)diVLp z{pXKfy#M&+`?nvze*gIk#Q*;N0|qHLXbBUFKUo+V7>XElKuSSz!oa?}p{S|3rL`#` zEj=M8CWV#D$GthOu#hRgfH^NPHz`Z6or!6tudIJkhF|)EqL_SUmH;#E=*;vU)ut4d z*}1MJ+3|6yK5|W*0YQlwY}}E_93D;*P3)($(!#iHyj&dYc$?gAB*f@)n?~7Mn)5Ze zB*b!gs&gB@F*e|Da`5(ac688Lp~TGAEh5PBlHo`4aV}w%hy?;49h(#+>`NXTD0Bjy;4ci{C-1K14rU#4Xoa9{m6qopA9n0cn|!>ecYkij zwyX=!4*mH3EoqLqSGiVbyFqxD(bS8XSDu{6U1jZO70Ic@{~t&7=B^ zBD)NOoAkU&Gy^LQJ5PtV?u{&65}4ZUmfYbweP{LTy^YnAGv=AGa7*6wj}%~b0?7r5!@qH7P%p1*$L z@#{ODxoUwG+WsY)zWExj-aqxpQS(e!bx&6L`u)?tfB$~}{{8*?cVO&*V`-G2NeC$Z zWMO1r=w{FXnGVVm3>>=|#5rX=HY{-DP?VFNPL-%m%>B+*~5-k^-+4*MLFr;tQ0}^rlS-^!^Q`Mx1hrB$jwn&hk~Xk=#Nl+_9Nu|Y$D G!5RQ;-6)O# literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/icon_warning_sml.gif b/maven-skin/src/main/resources/images/icon_warning_sml.gif new file mode 100644 index 0000000000000000000000000000000000000000..873bbb52cb9768103c27fbb9a9bac16ac615fce5 GIT binary patch literal 576 zcmZ?wbhEHbB!Sy%bj7w z8LP{2I!WYbmF&-Ixi?j6tD|K1XR2M#l>Aw*aXL%wXS3nYW}{zi=4WzsU5r%E6qx+# za{AThd85YVOsT`KDUrWsBtGknIa3>Sy(4;AS@f^Dxt>-=XPXm#FD(1Lr2hBv=9?3X zZS^!XrNw@)>eiN((2|w-y>{aB1+99DGMA?}+UTggT+(Z*rf8+5x~aWVOGcurtl;&U zIa)H3I&#vwvQjJBn`YHj9iKlB7`)(M#!e{yWMO1rC}Yq8NrU2qfqia6SyOXMYa1sM zM_a34eqyRfcQbQJY;^IYGTuzaxglKLqNQEA}OiQec+sQ#rUUjLqg_MpsPmY43 zsgmVV8EHK$eV-B~6*UcAW2+w%1e4o&9#aAczLGF}PmMg|6J0Ey4q A)Bpeg literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/newwindow.png b/maven-skin/src/main/resources/images/newwindow.png new file mode 100644 index 0000000000000000000000000000000000000000..6287f72bd08a870908e7361d98c35ee0d6dcbc82 GIT binary patch literal 220 zcmeAS@N?(olHy`uVBq!ia0vp^+(699!3-oX?^2ToQY`6?zK#qG>ra@ocD)4hB}-f* zN`mv#O3D+9QW+dm@{>{(JaZG%Q-e|yQz{EjrrH1%@dWsUxR#cd&SYTt4+aeuCvSob zD+%%o1`04ZXs!GLj7%Iec?BF2%&y2ZFfeUwWbk2P5nvW+xWT~4#-PT{uyM;F);OSv44$rjF6*2U FngH~|K)3(^ literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/void.gif b/maven-skin/src/main/resources/images/void.gif new file mode 100644 index 0000000000000000000000000000000000000000..e3a7d8c469d83eef8aed3cc26266438752d536ec GIT binary patch literal 50 zcmZ?wbhEHbWMp7unE0RJ|Ns9C3=9Vj8~~DvKUo+V7?>DzfNY>Fh|Ltj$Y9L{09+#q AWdHyG literal 0 HcmV?d00001 From 81a389255ea57efe5119324eaa1b58474ede6aa0 Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 30 Sep 2006 17:22:50 +0000 Subject: [PATCH 004/541] Reorganizing project folder to include trunk/tags/branches structure. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@451622 13f79535-47bb-0310-9956-ffa450edef68 --- server/2.2.0/pom.xml | 52 + .../resources/images/asf-logo-reduced.gif | Bin 0 -> 6636 bytes .../resources/images/james-server-logo.gif | Bin 0 -> 6944 bytes server/2.2.0/src/site/site.xml | 53 + server/2.2.0/src/site/xdoc/adding_users.xml | 58 + .../src/site/xdoc/build_instructions.xml | 79 + server/2.2.0/src/site/xdoc/changelog.xml | 446 ++ server/2.2.0/src/site/xdoc/custom_mailet.xml | 117 + server/2.2.0/src/site/xdoc/custom_matcher.xml | 128 + .../2.2.0/src/site/xdoc/dns_configuration.xml | 59 + .../src/site/xdoc/fetchmail_configuration.xml | 967 +++ .../src/site/xdoc/fetchpop_configuration.xml | 105 + server/2.2.0/src/site/xdoc/index.xml | 104 + .../site/xdoc/installation_instructions.xml | 110 + .../src/site/xdoc/james_and_sendmail.xml | 124 + server/2.2.0/src/site/xdoc/mailet_api.xml | 51 + server/2.2.0/src/site/xdoc/mailing_lists.xml | 115 + .../src/site/xdoc/nntp_configuration.xml | 98 + .../src/site/xdoc/pop3_configuration.xml | 74 + .../2.2.0/src/site/xdoc/provided_mailets.xml | 253 + .../2.2.0/src/site/xdoc/provided_matchers.xml | 186 + .../site/xdoc/remotemanager_configuration.xml | 78 + server/2.2.0/src/site/xdoc/repositories.xml | 86 + .../site/xdoc/serverwide_configuration.xml | 100 + server/2.2.0/src/site/xdoc/smtp_auth.xml | 70 + .../src/site/xdoc/smtp_configuration.xml | 85 + server/2.2.0/src/site/xdoc/spoolmanager.xml | 85 + .../site/xdoc/spoolmanager_configuration.xml | 99 + server/2.2.0/src/site/xdoc/summary.xml | 116 + server/2.2.0/src/site/xdoc/usingTLS.xml | 89 + server/2.2.0/src/site/xdoc/using_database.xml | 143 + server/pom.xml | 94 + server/src/site/resources/css/site.css | 31 + .../resources/images/asf-logo-reduced.gif | Bin 0 -> 6636 bytes .../resources/images/james-server-logo.gif | Bin 0 -> 6944 bytes .../images/james_config_load_balance.png | Bin 0 -> 3645 bytes .../images/james_config_secondary.png | Bin 0 -> 5758 bytes .../images/james_config_smart_host.png | Bin 0 -> 3266 bytes .../site/resources/rfclist/basic/rfc0822.txt | 2902 +++++++++ .../site/resources/rfclist/basic/rfc1123.txt | 5781 +++++++++++++++++ .../site/resources/rfclist/basic/rfc2045.txt | 1740 +++++ .../site/resources/rfclist/basic/rfc2046.txt | 2468 +++++++ .../site/resources/rfclist/basic/rfc2822.txt | 2858 ++++++++ .../site/resources/rfclist/imap4/rfc1731.txt | 340 + .../site/resources/rfclist/imap4/rfc2060.txt | 4596 +++++++++++++ .../site/resources/rfclist/imap4/rfc2086.txt | 452 ++ .../site/resources/rfclist/imap4/rfc2087.txt | 284 + .../site/resources/rfclist/imap4/rfc2088.txt | 116 + .../site/resources/rfclist/imap4/rfc2177.txt | 228 + .../site/resources/rfclist/imap4/rfc2180.txt | 787 +++ .../site/resources/rfclist/imap4/rfc2192.txt | 900 +++ .../site/resources/rfclist/imap4/rfc2193.txt | 508 ++ .../site/resources/rfclist/imap4/rfc2195.txt | 284 + .../site/resources/rfclist/imap4/rfc2221.txt | 284 + .../site/resources/rfclist/imap4/rfc2342.txt | 564 ++ .../site/resources/rfclist/imap4/rfc2359.txt | 340 + .../site/resources/rfclist/imap4/rfc2595.txt | 843 +++ .../site/resources/rfclist/imap4/rfc2683.txt | 1291 ++++ .../site/resources/rfclist/ldap/rfc2251.txt | 2803 ++++++++ .../site/resources/rfclist/ldap/rfc2252.txt | 1388 ++++ .../site/resources/rfclist/ldap/rfc2253.txt | 470 ++ .../site/resources/rfclist/ldap/rfc2254.txt | 451 ++ .../site/resources/rfclist/ldap/rfc2255.txt | 423 ++ .../site/resources/rfclist/ldap/rfc2256.txt | 1137 ++++ .../site/resources/rfclist/ldap/rfc2829.txt | 865 +++ .../site/resources/rfclist/ldap/rfc2830.txt | 419 ++ .../site/resources/rfclist/ldap/rfc3377.txt | 339 + .../nntp/draft-ietf-nntpext-base-13.txt | 3270 ++++++++++ .../site/resources/rfclist/nntp/rfc0977.txt | 1540 +++++ .../site/resources/rfclist/nntp/rfc1036.txt | 1068 +++ .../site/resources/rfclist/nntp/rfc2980.txt | 1516 +++++ .../site/resources/rfclist/pop3/rfc1725.txt | 1012 +++ .../site/resources/rfclist/pop3/rfc1734.txt | 284 + .../site/resources/rfclist/pop3/rfc1939.txt | 1290 ++++ .../site/resources/rfclist/smtp/rfc0821.txt | 4051 ++++++++++++ .../site/resources/rfclist/smtp/rfc0974.txt | 365 ++ .../site/resources/rfclist/smtp/rfc1652.txt | 340 + .../site/resources/rfclist/smtp/rfc1830.txt | 452 ++ .../site/resources/rfclist/smtp/rfc1869.txt | 620 ++ .../site/resources/rfclist/smtp/rfc1870.txt | 508 ++ .../site/resources/rfclist/smtp/rfc1891.txt | 521 ++ .../site/resources/rfclist/smtp/rfc1893.txt | 844 +++ .../site/resources/rfclist/smtp/rfc1985.txt | 396 ++ .../site/resources/rfclist/smtp/rfc2034.txt | 340 + .../site/resources/rfclist/smtp/rfc2142.txt | 338 + .../site/resources/rfclist/smtp/rfc2197.txt | 452 ++ .../site/resources/rfclist/smtp/rfc2554.txt | 620 ++ .../site/resources/rfclist/smtp/rfc2821.txt | 4426 +++++++++++++ server/src/site/site.xml | 57 + server/src/site/xdoc/FAQ.xml | 318 + .../site/xdoc/archive/announcement_2_1.xml | 57 + .../site/xdoc/archive/architecture_v1_2.xml | 51 + .../site/xdoc/archive/architecture_v2_0.xml | 55 + .../site/xdoc/archive/configuration_v2_0.xml | 716 ++ .../site/xdoc/archive/document_archive.xml | 54 + server/src/site/xdoc/archive/install.xml | 113 + .../src/site/xdoc/archive/usingJDBC_v2.0.xml | 174 + .../src/site/xdoc/archive/usingLDAP_v1_2.xml | 185 + .../src/site/xdoc/archive/usingTLS_v1_2.xml | 96 + server/src/site/xdoc/design_objectives.xml | 122 + server/src/site/xdoc/index.xml | 131 + server/src/site/xdoc/rfclist.xml | 93 + server/src/site/xdoc/todo.xml | 109 + 103 files changed, 66700 insertions(+) create mode 100644 server/2.2.0/pom.xml create mode 100644 server/2.2.0/src/site/resources/images/asf-logo-reduced.gif create mode 100644 server/2.2.0/src/site/resources/images/james-server-logo.gif create mode 100644 server/2.2.0/src/site/site.xml create mode 100644 server/2.2.0/src/site/xdoc/adding_users.xml create mode 100644 server/2.2.0/src/site/xdoc/build_instructions.xml create mode 100644 server/2.2.0/src/site/xdoc/changelog.xml create mode 100644 server/2.2.0/src/site/xdoc/custom_mailet.xml create mode 100644 server/2.2.0/src/site/xdoc/custom_matcher.xml create mode 100755 server/2.2.0/src/site/xdoc/dns_configuration.xml create mode 100755 server/2.2.0/src/site/xdoc/fetchmail_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/fetchpop_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/index.xml create mode 100644 server/2.2.0/src/site/xdoc/installation_instructions.xml create mode 100644 server/2.2.0/src/site/xdoc/james_and_sendmail.xml create mode 100644 server/2.2.0/src/site/xdoc/mailet_api.xml create mode 100644 server/2.2.0/src/site/xdoc/mailing_lists.xml create mode 100644 server/2.2.0/src/site/xdoc/nntp_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/pop3_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/provided_mailets.xml create mode 100644 server/2.2.0/src/site/xdoc/provided_matchers.xml create mode 100644 server/2.2.0/src/site/xdoc/remotemanager_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/repositories.xml create mode 100644 server/2.2.0/src/site/xdoc/serverwide_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/smtp_auth.xml create mode 100644 server/2.2.0/src/site/xdoc/smtp_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/spoolmanager.xml create mode 100644 server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml create mode 100644 server/2.2.0/src/site/xdoc/summary.xml create mode 100644 server/2.2.0/src/site/xdoc/usingTLS.xml create mode 100644 server/2.2.0/src/site/xdoc/using_database.xml create mode 100644 server/pom.xml create mode 100644 server/src/site/resources/css/site.css create mode 100644 server/src/site/resources/images/asf-logo-reduced.gif create mode 100644 server/src/site/resources/images/james-server-logo.gif create mode 100644 server/src/site/resources/images/james_config_load_balance.png create mode 100644 server/src/site/resources/images/james_config_secondary.png create mode 100644 server/src/site/resources/images/james_config_smart_host.png create mode 100644 server/src/site/resources/rfclist/basic/rfc0822.txt create mode 100644 server/src/site/resources/rfclist/basic/rfc1123.txt create mode 100644 server/src/site/resources/rfclist/basic/rfc2045.txt create mode 100644 server/src/site/resources/rfclist/basic/rfc2046.txt create mode 100644 server/src/site/resources/rfclist/basic/rfc2822.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc1731.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2060.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2086.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2087.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2088.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2177.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2180.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2192.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2193.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2195.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2221.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2342.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2359.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2595.txt create mode 100644 server/src/site/resources/rfclist/imap4/rfc2683.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2251.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2252.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2253.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2254.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2255.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2256.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2829.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc2830.txt create mode 100644 server/src/site/resources/rfclist/ldap/rfc3377.txt create mode 100644 server/src/site/resources/rfclist/nntp/draft-ietf-nntpext-base-13.txt create mode 100644 server/src/site/resources/rfclist/nntp/rfc0977.txt create mode 100644 server/src/site/resources/rfclist/nntp/rfc1036.txt create mode 100644 server/src/site/resources/rfclist/nntp/rfc2980.txt create mode 100644 server/src/site/resources/rfclist/pop3/rfc1725.txt create mode 100644 server/src/site/resources/rfclist/pop3/rfc1734.txt create mode 100644 server/src/site/resources/rfclist/pop3/rfc1939.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc0821.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc0974.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1652.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1830.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1869.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1870.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1891.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1893.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc1985.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc2034.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc2142.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc2197.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc2554.txt create mode 100644 server/src/site/resources/rfclist/smtp/rfc2821.txt create mode 100644 server/src/site/site.xml create mode 100644 server/src/site/xdoc/FAQ.xml create mode 100755 server/src/site/xdoc/archive/announcement_2_1.xml create mode 100644 server/src/site/xdoc/archive/architecture_v1_2.xml create mode 100644 server/src/site/xdoc/archive/architecture_v2_0.xml create mode 100644 server/src/site/xdoc/archive/configuration_v2_0.xml create mode 100644 server/src/site/xdoc/archive/document_archive.xml create mode 100644 server/src/site/xdoc/archive/install.xml create mode 100644 server/src/site/xdoc/archive/usingJDBC_v2.0.xml create mode 100644 server/src/site/xdoc/archive/usingLDAP_v1_2.xml create mode 100644 server/src/site/xdoc/archive/usingTLS_v1_2.xml create mode 100644 server/src/site/xdoc/design_objectives.xml create mode 100644 server/src/site/xdoc/index.xml create mode 100644 server/src/site/xdoc/rfclist.xml create mode 100644 server/src/site/xdoc/todo.xml diff --git a/server/2.2.0/pom.xml b/server/2.2.0/pom.xml new file mode 100644 index 00000000000..1055c16207b --- /dev/null +++ b/server/2.2.0/pom.xml @@ -0,0 +1,52 @@ + + + + 4.0.0 + org.apache.james + james-server-site-2-2-0 + JAMES Server 2.2.0 Documentation + 1.0-SNAPSHOT + + Apache JAMES Server 2.2.0 Documentation + + pom + + org.apache.james + james-server-root + 1.0-SNAPSHOT + + http://james.apache.org/server/2.2.0/ + 2006 + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/server/2.2.0 + scm:svn:https://svn.apache.org/repos/asf/james/project/server/2.2.0 + http://svn.apache.org/viewvc/james/project/server/2.2.0 + + + + + + james-server-website + scp://minotaur.apache.org/www/james.apache.org/server/2.2.0/ + + + \ No newline at end of file diff --git a/server/2.2.0/src/site/resources/images/asf-logo-reduced.gif b/server/2.2.0/src/site/resources/images/asf-logo-reduced.gif new file mode 100644 index 0000000000000000000000000000000000000000..93cc102077a940966a0bf6d77e74ac273a10ef8f GIT binary patch literal 6636 zcmW-jdpy&NB^`k5({Ud=*EWJLJM77(p_7Ubjo^?L{6ozBTG zrT8~-uT3`YA6z(iU(uWv#wdC?*LrZ+m}~LRdiKU&$f@Oy^oJ`=i6+hgRAVF_PDwp- ztgxs!1ZD4l68M_KW_UVk-#Q!$Pa@K2Br166_?3pnI2h|A-a0BAXQR5&A?Fpb?Gb8 z2*k5oCs=r^?5ey-sZ^AxYup^lC`5wE?{)1hj19^$$^{?dW+pEpj_VrXL%+<@Wf;^t zJCdiUvs(#-G^G|kfoFntz873~ctb_>t(@D#$7q=4Jv#>J`Qv=$b>~!(=u%)Bm4nQx4G0uy}~g_xl^(YUhBvak#5 zgOuvw;WT+BuH_Fe^Qfh^cx6`2s#Q)p=qizh0B=u>WgT3-Um`*}GI*J|%p$EpRN<4Y zGf~z{=<@Z%ciE4S^38-`SDls-3H17pfQxW&*i~EFS~THa;&q8l$;Vfpq4`<-XV(d$ z`-SexHAn1eerw`+&nuVTz17YrVcMN=n%6b~Pk7R#fQs2Gpwl_l;)!9Zix3)AS!c&C zQ34C)+gAHfADmZ#J!@ouF>Xj{z_YVB18pQxGV z#8&ZYQIjf}4+ukXt98XP)EbGFTjdXCr7XQ<39V`EX@7dX7sgi%K^WawfM#Gv=)Aa1 z+o?NS!01`I1iDVjJKI}zgx$&^C5Ef~EU7JH?OH!a+{=QV@_zU`-5PH*I zPuRv#n3aaLEiBR7@r{SVvX-}mUhuV3xb?k!BFIAH>qbPzbWFRFgIRYuh*K-nKBmlY zXo!mHbNn_F82LJk8Y(6HVBaJGfDmIP$=s!3^Huul_S2gBtEE}_T2@5k_$OT|Hfb(5 z)X<#6D%iKo^EXxX4F^7^85Vz6sG)}#XEvtZDoScZ&v0xHPB;j%ar+w*l2aoKKDo2- zb9>!cbUD@Cqd08ehtuEgl-E^3le=d;7%p1%H-?USDXO&=Ns#x}Gv34#dLGHj^Mbev){8$exY)@D8txn4_GgU^Q#nGSmQLy^q-T1(e6TLYS zkyodfAaB@J5Bc38m*mNB>VrC0Ux|ebUq~Fex!-O z_3SLrfr{Ra$gx{pd(y!YKvCLGkH;%6{CVnQ{;UW?4*=tq1vDz`SEy-1yIj(V2R)ZFCY__!(Zs!f z`rl=^e16E7%Pt1a*QGNC=$-{`qOzJAu$vUT+P&2n>8pCwFvLX7zj^SYb`8p=S+0`E z$XYnM2{X2F1lL-FD1N}lfYe#DT)AY*L<*-3n_K(QvY5+XtlTfjs_Xqib0@!ESbnk! zSA5ArtJN=qF`{-hEnA~6zDFo%d=8mF^^sHw%D{yEh@{rPMqBF5>hB{?M8h{}t@d0a z$TBh@8x%i2xYqf->Z_kO?ik9N@?Tnd1s`-Sm~BEsL0u8q&B1GhLXeauby8lte(=TH z=AV&6s2Bxw4Bv}#m_ApmU%KiQkf8nY=}IGzQPzj<_?tbT?S^q>@387$GCgoZ>{a?} zs*!BKHygc@UGbJ=GHbM@>qZ!K2AH8?ChBt!Rc8lW$zk7VEIyd*pHZ< zE$>3tEVKs2MMV7_y;EJ&`Ixn`WSsRp6bJd9jN0ez7 z|Ma|Lc!>!cW3KHdjTYX+6Ie1ce`!;(oJVsG#TcaQP4A00xHl)OMsj5M5|l7eC(3az zDJOcF{El8dJ#Rzx_qnmF*i5mBua?=I@#wMvrXgR?ichil(W`n;21chubB`0YX{t^$lR@)6e zzxHWowXNRH^1Qj<$tzEf&Y^`bdfs&ERfbPdDZ3B53tO443vu5as^NZ_IwXJfQLrGe z*svE7@rd$rX)~s^qXx&9l&pV0F0Lg#>vRaEt0D{^yK6JYuX|TyX#+v*D)2mcq;*Cp zfmg+{`z{X8I**n$^E#AvnZc#GzrRAukx7ov5b^QQouH>j)7lqpVBE5P^}wWc9VJMF zl|RDZCikc^4kDE8%0ixL8a>;T0`GN{#v6|OnR?@tEUXAkxLJ7eVdS$v?N0>>6O+H` z^2{Fo2$O4$vb6y!ta9)n;7$uEBjvIC)aTjix?Ev&58b zTHCwd`4prf7n;f;4aFhXHwe2DD!6nD&voHBVW_e^kk z4BA-^s7S#3%MdJ4#z`=;Gr>L_NJXrykOQM%3PUrC{5VkM211p-l*eeZE_gIfIC*wHsp5pD4ONn{s>gfc~b%Z~YZ zfnp?qAD#z;w}Pl!;NNdN^7{Ah$UuBd#BGr$q;yX1IYErS2Le0Dx zqKPdB6#2#+aF1s2nU>;y3GRIxtU@)ZW|^FpfQ~=ZZp%^@YPfu9&Thx@P=y`kq&RXQ zrP!}nk8sM64X>6!PGY$JGH6aPF_geaVX2e20;v#Fg(T&7r%qiezhli!WB6VLkCZ*B zG&`?pe<1&KTg6Y!%9gm&{(-Dz0m4ZN2hm-2e=EFq8EYj6+(TS9F#>*%LhWhDO$Eqg(i@Bw z)ysu*&R-5ba{&B^X%ph=;~Ze6V^@UXC;oaVAh3nK4e=SJ+})Q!mhX`!p&LC@;->&y z*%W2taFQ)dn8M%$JL=tRX3)qPH=>dPFsJGwCA2L|HJ%mKj z+y{JohjEIwLdk)ki%L3nlF_un1W|C)_?oXdHHJxWEt5OSuAY78a@UvZQv>#fngy#D zda$eabAW`YbKVk=e-xVk`<#M<0C`~Vq#5R;JN!<{#bsQ{XJ#H_~xNkfws>)tk=Nd2=DuVh(`? zKbj9|62X&jT2m5yRsj^6*w}MyONIWHK+*)q!^jL_U2(Mwdv&9cwJ)Nvvpa7o8k)iy zo$y3h|0JtOk~^bd8{WmujPMc%sHVchB03^Sb~uD=9ux_+r#L6jz0P(=Y$!X|c){Km z?fLK}si+@jkFBv!Q@K0>0$w#6{ub%)YMSm>%~9uFy#et(ya<}gRQ2;ElN`gOWOB)M z?>DekR{i9Jsx8$4$*0#w)Bf5RkUxJ!K+o^z4rbhv;V_6(p-7uz?>a# zDmQ!+XacocAKJy4EE*aJ5_O zOl7@}o4eoGZTmg|$@UZeg7>|qstB=;z~yyP7^X&>6Iul9wdDbqR!|(HgI(~y4bEgj z%tqp_C+GnG6Eu5vYZwFarm%kO0S`>W{wXs4Bc*Kx9v*U#|E11@P&c^;w33o+rS3mX zZ^{t6E||fFhT*& z$DjcTq$Y2;o9%Wf9FZevyFIOXQdsN9MYJA58+<3}B-N#2cE!;z5WI==7sz?xMoOhz zCcFEp2Joy;%Tm{v(b4hj?*Q^*NLZjte-Cvs+}BwF*3RDM+ZvgK2YRtLoAP1um6~CC zw@>rEM)H;)OM3k2JaP$*d$h-ya-e6dr-4L468u-H8afR_e5*9CiF(K(Cm9J@isrWu;W$PP1TA^Q5f6Fvm^0E!e%5G?i3bKu z{Y_bc)_ET~Je&J>&|Ppxty-gD7^mFzg)*;3yK$m!uh89nW?=u;;J(Ukj}X{@$o$uk z$D||T{CMs~RQp&nti<#1&O(x{p7CHf|PgnQpY-@>Nvror76~GP}JT(kgx;Nb}5NhSZnAlLKawpPv{}C;)2hij} z-VORkhG$HWlVpA6+QO`}!i1jeMpnIN(Qw3S+*Ou5@BOsu;ShlNeakxDSlH5X@`wsZ-B=B^}t8EVN2WpeWtGP7&oYjaRX;8E)O+J)+0Eg`%&btht7o@_=5B zG}L1PyFKiFGCjmEgcCDdUcVCjw?p#*6+*WFo_@ZNNb6~LvrE2P1Ru4##STL3u4F3L z*$=Vae1mATs5Qf%z+bemF7Xbf3~@o!*q#q%6(KZ*3pVUEz8tvgS;Lvcg@LO8O#eXH zq>p^m_Q3Yl@-yi5M)=KD;6NHM`7vBn)9`{|U3AEtE=_e1P?$VMP7CLdHrY4?p-KJt z?4I-SV<|g?s@V3;aUsaKmh-9j@-TT;R2b6YKEmiZGJXW%GmD56}7a!qg*ZT093>v zRz?yK$i^kR0fx>=K=sg4p)3658SV*r>97F6DgYB65WZigcl|(D>z%LO=H`Mnn`wZ$ z17R)!YJR$CP66?+0Ra!Q>N@l%0q;r2xtIPhwW?=e^`9!vZwV17-} z`v&|Lxi`;X*yrlGVH2dVIefugw~g0%h=SUIP?B$j31DUvBdWX!RR_#(g^grxEaBNF zPBtudN<)iV+FZ!d+5hg+5J&Kc{8OETWxW%AhS&-JAzgnD!y2*9@s(5EO^-9pGAbx= zg#EdZxG!MeuOgDwu1+Avr1pU-1JvD&F&{S%|h`1jKPE8AZ9k@JRFi0v2K#muJ(ewI`fD=fye1%bs?&BeGF zZ;Kf*o`hYW^tpt?tq$ty>AH5Dulshs%z~6tiW1;GG`f9=Ly2Rh*sacZBEQUkRMCso zF(ECs$v<#4B+Ci`W8DE(IH(va?>eRhd&*Ws)cPcdW>57a3zdK*%pb*f<;JNtKI0 z-OK4Xju4k0B=B+2Gi?d-6YhU0Hg-u4T3_eoi!hE{=_4w2X!!hhR9UR3Z*bVfO^dB@ z%PGwF+v0V23+}E!LbhW#s?0(LXH?3&zWt$Tk-C=x5J4Uxye3j?S>N?L*6t@Ap4dt zcM)kz>l6V3L(wORWE4ZuXZU>MMajkfSMTVD^jZMsMn!gIo{f6w>v(K0>sOvxzEw=a zrNq05F^F4qmE!-zC(QGQ`ALI5Ao<%CXooIt<-mU(5n<_HaS8j zDuLZSYT+|{!Wh1VGuH~Ji%q}YTBR-VL>(y61_$YZ82tG5K;VJrr`+k+V ifk3o@FNQYto?ua@#Ta7 literal 0 HcmV?d00001 diff --git a/server/2.2.0/src/site/resources/images/james-server-logo.gif b/server/2.2.0/src/site/resources/images/james-server-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..f69394f6bbee48b5b336395a573aa484fe1e05dc GIT binary patch literal 6944 zcmWkxc|6mPAO3tk+w8E-%ze)>cNs;Y_%OH9=^LqY!p6C5~|M5J|u1;GmLv_J0U;+RJRY#^L#+n)$-(9#+ zy+3^Y&w6}p-1uGlNG0VswXXG*g(dO&`uZY+!B`s}&P~lsA(7YD*FJoB|F25w^6WKb zd99Ji1M9yA*2H4*>UwK-`ufKY$$R6)OMgGF{}C@Oj%r!KTWpd%yu_b>F5GSvul+J5 z$1bgZUlp%brx6yve_35y`8z8-Zejk+!>YIX>X*MCYpScS+S~8<3O^L~&+P1r)wRDr zmzS?JTswcZq@(55)cg67fyaFQLjVB&)6`r={zm}7`2X<#On`)#ewY`pk%{&wQXk&ai<(K@^JgErzM-gvFd(D2gsijs=b ziMEO;C26XnVoXu-*%Ie`l$z;QS$$kQDm^wWBN5NZqe>T^t8ZvLgwn$q7@*N7GLmgk zu~(Y)JCx4or#3z6f9w~Zg}&Wpt}hwSxqn5!CQqriZ{XjTublPuskUt!+R#L*o}z_P z;&|qLNlE?h!j;v>v^N^EZLP$E7yv=fB#PjHYWmSGDbF=6w+h)%@Qfr7;U7IGq-VzC zw?v8dHt~{0bazl|Q_ts(QPtv-d=>$nLa{GH)O|YjbxCX=|IOqT1b3uF_vyGWVtPcsvaZ(clg4kUw_ryM zS{`6SG-Dx~#(|H$N`FO)PXh^x6j*8t_ncT!lPy9a@Hn0zDDl%yRJWu;m_((a?4$BC z1X~)1j?ml&r-9qw#tcX;JuAvJw1^Wzi9k759T;KLfMg|E$`kBQxuViDel4LrICBB3 zxKTBES!@g>{UR3El;n!=GEJRfR(aM+8jZhk6AmS^| zx9&s}NrH-FZXS~rk~(3&Fm`BOzM>}SxS=x^RD=-(&COhG!lt(zITQ6lE(9kj|rZKWx!)+CkEM9DSotW zAL%$wc2hPg;;VehRV}d{QR4PZV}fcllaH5roMV6GSzil)z18Mxbf?t+_G3e*wSP<*?VC1r68u=L)VR173Y%55{^Mit~opR}< zqn*Rw8IV0rP|d2ZzgDXrNjb>r$8NtC87F%}{tu(sa+s1jZu)eaAwfW_ooM}QxQE@a zlgNb~$z;1XqhVgA{i@m`!AA6^$eoLIvauuwXABhh0DW}}5E%>f?L&Z+Ckvxz2J-KOohq*THAPi3)8RUok zqZ35y58bbFwEeY1`Xz#-M9>qEAm>d#ec?(AYYfWBHnm zy~Zk)<5B?2Y&Ou=uBrYEMr}5no%Zu7)nK`$s8YOthXYN|M_FiDk!tbsByc1~oUTr* zNYl&?wc20Dg={!l(g}iIz4y#q2Hhr&_~^F#+etCCORUU{Whv-zL_h^_iiFL8TU zxG3-nQDosv^?`SLH3NaZFk$0yV%sZXbZ; z(*HJtq28i2bxL%2)Y;%AWf&kN*B@wIJHOs(vGKLb5XHH|LB@!i4s2cIv?r%hGJ9Rr zgg|Y#}$n)kX?dhIZVTN=oTa2CJt21Lp!wbFCB|ciprB-HZ zwi^B!3~XhE;nhVfRR?l0{|}XVexPiXMvV$~$rMB7wZw$z;Y1n}VVV8n-I4Z3=X2l! zxyZfiHTKspeyNJKPC*eaPXoG3%sO|!3~Sj`XZ3mDYGBwDBKz*MI;UfK+bF&#9D1r8maluh^IZ(XHL_sf(BxSx1z@J1reMKfis;a9&Ejp;TBG z3lLC_-0tC!|M6|kpC8$|f%gV{@;r-96DmRpRiDiQQIH`d`_r!rt=gr4g?~2o)Q6V; z8SML5P=czAD~*&fGK7MT)&zbEJR8JglS%vKz6r%8Iy#gf4el*Tkb48EOMV3m-@!k+ zMxOO{uvkJ$FvQ}U7Vo4oL3B_mH6jk`u*?kTe z?vCGXD&Z>Pf$6l@dQa}2@6NB2QD1Y=t(!qdI)xHnsvfW&zkC0LN2(@9`mLM@s4+k2 zsu4+H8|1a!8a^lySXWXH<}{8 zz?t(y%J{`g`r!BBU6_saWwcKLl5>+DJL06{Mk3}OOp)b^GPSm_03-|}HCEh}&JF+f zjy`#x_f4|*l6+K!!okrW#d>|pFalUd_f1O=Y3U|Mu-|_>ex?7ja zq7DQ;f>EF4z9wt_@zN7LpLSf?LPlQxl-lu2V$C;!{GO!aD8YS>ImkXqnA2oTQvk$E zMy<;E2lv-^UxyOxzEt@1#Iym~~groMgMq*${F1wcp$Y2azZMePl?F*vUlcr!Oc9fe1PmrBY5mk@+FZ zEh4V?y}E9Pn~G2916IDpRkd^@Ch#KFgBx~@kFp;v4g-pNcbEU1$>&7twM{IfsN25- zgLUVs&SMJ;&B;1V>3aiTVw#pgX^YdV+M-laO&%W|0Dzc-T!hh&r*xth%PrPZhNiKh zBo-J@5K<&c(sW;xltU&5V!0mo;LTyXvcn=zePl4_KMah$BopT*1|P6LWbj1|o4S@r z3aQIwywtDzU!vzU9+Ep_-)bcD2T%C3{_VBH%P#4;Z4rW{zW+R(aA(LP-qs+@6t+ih z^4N;DGSxo1k(VI;E<(30#I}>lE}8}6^ccpe0zLTz3nCPT%W&RJLj0CE&i&wE zDnOWRP1`(;2>F08l|SB%+DB)k*)!rr{Ydu@DUPB9Q@=Fxgfz>Q6l*`EO&zjRB=<%u zNdw-T!IbKahN!>LimVt=5M?5Ql&L$+OPqq1fC+~kDt)`ZS~y!$O!mKnDgyUZ}FJ!_**y8jd8NhC)h)`Fev@x*LGyQyo)>2e*s;%q+ht`7rg9(YKRMo zCjmMzM269wKIqqE5XVJGQJ@WsqC>rit#W|dHI}w8FT@*hyb>~j0a>iqb_SqA@*>h8 z6Izk{Dx}Sa6XTp8Hv(ypJu(e$U_^M8A~Li+gX4z7Xea= zCMO{T542`^TG1dRBg#w!s&GLwZHOQ|e)L3{3Jl53KrTv9>lCEJ0mEC^ik#D5xI3hI zU_Ml)!$&|AXu<**if0tbrGgX$hGDW@P)x}JOlUf^*GGRJS8UV^@~4#Uh|Z~MN7f!d zqL>#$bIy4(IKBHzCrS~QIfOzuTbUU}5d!Z_^|Xb+(d!_Mhj9A`k%9%yVCX4S&U+1* zF_K6?S;}=#V3}v;dfBv8DT9={oh@%gg3N@#cnl=Xhf=U*p$=+4qybG9Km>~V$Y&9Z zs3zBZU0qb+FNcfSNMnqn_>Muvihhuc_3RKY4o)(zEu{@kwH=Nu@JPW|Z` ziKs({sJw6tik76K9H*x#c_0VS;wefC^j=3JsI<$Pzd(I1q#j*Og5?SX?3wv9nX3@v zf`ToNZO8>CWSODC)KdRruYCEIA#hH6*+Qpb07_d-X6MQ z4+HNE5I2|&I~Fm|7miyo;cgbB>9>7S7qLviEaXDtN*7eP0KM&uwy2uK<4jdH%=$NN zosnINhWNY!Uy^k<>OgQAPe!?RC#TR$$r{(eOMhR<)klr<2`#^>l?C-bnj2Lp;H3+o zktn~+EZbx5xCv#WEff557bUq>&l2ri@pfd5|zu%0C{)I zC&Qy0!mbg4t4JPbBp|6Iq#ief8PO?cT#&aU(g;b-JAw4b!-}`!kb$2NVwnh3zm?~A zPmP4ZdP^*JT$*}f(eOjImqQ!)b`=U}hPLDaW*p4q!Bq8VZbPnae6+4wG&CUr5^0S# zo|IG9!GaP*vGrZ$=(}Yqe(9`+wZmn7qk)b38j@}()xlQp0iJxv%}#8Eq;-8)?!99H z^$sZ90V*=;MRNvxar-@tq3BSGGWV(0<%YqQjYF4M9i-7^$n_?|Vn)ucC7+80-EYcB zj@K?_<~QeJU-+pzWd_OH-Flk?r~<934ysi*QJ9M->72r+zNkYtk*f#KrCFT(^eHm< z=Dn*JO%}g-#EM2t1$P8QZJ?1f7-vivMDvw~;KUdAAR;5NN8fc6(F&^l2~#|xXB9`0G_*(nHd zV%>BR^>5jRdUWj}p5I))kAUYxwr&7E74kQ2eYaTMWU%#&AtF$@Wa}z|{0CynU`9D% z6Z9&J>!fGCNl3=Eu~LkgktY2QM%|9Mxfm3ad6(WEO1iLLt%HXOpRCN1=-nlHATkPS z4fk02jaZ!?X0V219N{y=4<&S{cwvKh5YQ7*l;HDyW3?uvj7!GI8P4%d7w<%lV#e>7 zng|EeaqUqb266D_=|wsIHVm&Ht(yf>d0_nP(5c+Io1zj1=YfAmME6AE!H8jJPLF48 zp^G3A|F&iR!lH0!A?OCa3z-FzO;Y+VgtI=x2d5&`cLT^Oz3FO&LD(#Yj0HTW}^woeLb% zgM82Avf7&)*0A~w@rgbM;i#~8=C8hKNcGmPN_LGTWW}aBhJuU0jjgDGT{6@ zZ{c)F5AvEynVOXqo8SyV6_*XWL9{40>VoD;Ez7#=}pJP?K>+N)SI z%BOr6cU~^(^m-pW=D8cvJAyG-S1^7l7rv2-V=lys(8YhcG(;Flf#f!}^G~~N-z!u5 zeSq^t4dTYmk2{zE`U%p(`QatMnv#_Ho4>t+XR_rJXUFnKpQXH0HTr~Nj=yLC%8%@$ zruc?Oy?2(kI7FP?{hBlcUp{TQQH^%{-Q6y#Bfe~mWE+f^bNnA_zfjtCgdo&2_oYY&L$%SJ{!Xd2Jero?$zjZyNxkPXj`5urL7bl$tq zhuS-%r*2zMlV}%~xQN#tn@i2q|0R4)cwp)3qfeZ6!XKlmOT9LyM+zo%0`OnB*Iko9@$XyZ`=s_Y_A5M{a^y}f1fxHCbUep{ zVvq!G;eSla2SCAyI%N@O-nufD^r{@w3*H#;US=_-mOYTJ$j45ii0+q>_d`6wFN%Bw z+@}N->l^ZYT$}fU7*0rqKVcy(G73S1+PT>>AVR|Y{9|VS)-|lnDENm1#7#=omHWu>n zW;BK|i4+z|lw2y-3Lzomtr*`|zMsPRsxqVlY>wc}%oJrE7@DdUvWkjFv@G^GIRsc7 z2|=1WF+CIw-F@8*(If|7j?=`27W;(y8vC!s$6Av2wI8;ht(s5%Ja*TxV(?qp>ii@LwpigzE-dgfw_;neJY(XQzRBfmcQv7e_FKPAQWE0nt zhj?9Q^~koqVe{}A6lk}>#X(UXL>Xa`4m`z0JG3KGHIdI0i|o3xim4vbeu+9gYT)X$ zxxka&mk&rJ3ur5dkW!pff(yfw-hbwH(ELo`MWp+=`>xO1*hXcI!L7dE*Z+@h(ZmN4vY|J_Bzna@DkqjBlpQhQnl$6SfCZ zQQ9XA@15C%g*I&7R@F9#IX=Y#1=5@}!fcbzlT z@ibPZ7OGwIfsT&Q4h<&Og$@{$MSdU9zuuXqk3ZHNYK@}&28!ra@It0?!n9pRW9jFO zkE!?1=Vd9sY=4ufmf-ROQxP%~+hPn7yajgPJ6an3!JiDIEb(Vern4r2<$=}DcsAy4 zIW{^?qDhxCHLpQ9x74S(Dq!Ze#G}h)ZH(WFOGH*_RPi%Y?zvj9o@Mn zIOfX&H(h#(rt7%Nn90o8W}j2}I7Pf_-ty`+Nc0o3u^XqEr=>jn<}ze#is!O43ly1I zs3(;rHZ;TL^e6{KcAZLlI<-V+*&%gk%bPq@>A4p=<6$Lb(W}JryNr{v7p8LI@beAA z^Ma$DcTc)qN?WoFuc(F{axgmjxB!%eC + + James Server + images/james-server-logo.gif + http://james.apache.org/server/ + + + The Apache Software Foundation + images/asf-logo-reduced.gif + http://www.apache.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/server/2.2.0/src/site/xdoc/adding_users.xml b/server/2.2.0/src/site/xdoc/adding_users.xml new file mode 100644 index 00000000000..e063dcf480e --- /dev/null +++ b/server/2.2.0/src/site/xdoc/adding_users.xml @@ -0,0 +1,58 @@ + + + + + + James 2.1 - Adding Users + + + +
+

User accounts are shared across services. A common user repository is shared across James +services. That is, once you've created a POP3 mail account and set a password, that same +account is available for authenticated SMTP and NNTP.

+ +

In James, user accounts are created throught the RemoteManager. So, after installation is complete, the first step to adding users +is to configure the RemoteManager. More information on RemoteManager configuration can be found +here. You will need to have configured at least one administrator account and +ensured that the RemoteManager is enabled.

+

Also, you need to make sure that your user repository configuration is correct before adding any users. If +you change your user repository type (i.e. file to database) or the configuration of your user repository +(i.e. the file or database URL) after you have added users, you may lose your user data. Please change these +values with care.

+

After you've done this, restart James to ensure that any changes you've made in the configuration are incorporated into +the running system. You are now ready to create user accounts.

+ +

Once James is up and listening, adding a user is simple:

+1. Telnet to the host and port on which the RemoteManager is listening. For command-line telnet clients +this is generally done by typing "telnet <host> <pass>" where <host> is the James +hostname and <port> is the RemoteManager port specified in the James config.xml.

+2. You will be prompted for your administrator userid and password. Enter the values you specified +in the James config.xml.

+3. After logging in, type "adduser <user> <password>" where <user> is the user name +and <password> is the password of the account you wish to create. Please note that the user name +should NOT be a complete email address. Rather, all email addresses of the form <user>@<domain> +(where <domain> is any of the values specified in the <servernames> block) will be delivered to +this account by default. Mailet configuration can change this default behavior.

+4. Repeat step 3 for all user accounts you wish to create. +

That's it. Your user accounts are now created and can be used by all James services.

+
+ + diff --git a/server/2.2.0/src/site/xdoc/build_instructions.xml b/server/2.2.0/src/site/xdoc/build_instructions.xml new file mode 100644 index 00000000000..b6ff76db084 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/build_instructions.xml @@ -0,0 +1,79 @@ + + + + + + James 2.1 - Building James + + +

This step is not necessary to use the standard out of the box version of James. A +pre-built binary version of James is available from the James download directory. But +if you wish to customize the James source code, it will be necessary for you to build the +distribution yourself. +

+
+

There are two ways to get the James source code.

+

1. Download the source distribution - the source is available from the +James release mirrors. +Simply choose the version of James you'd like to download, and pick the source distribution appropriate for your platform. +

+

2. Get the source code using CVS - this method gives you access to the cutting edge code +base. Instructions on how to use CVS to get the James source code (the jakarta-james distribution) +can be found here. +

+
+
+

To run the build you need two third-party tools.

+

1. Java Development Kit - You must have a JDK of Java version 1.3 or higher installed to build the +James distribution. The exact JDKs available depend on the platform. A JDK must be downloaded and +installed before the build can run.

+

2. Ant - This is a Java-tailored, XML-configured, extensible build or make system. The James +source tree includes Ant v1.5. You can get the latest version of Ant +here. Since Ant is currently included in the source +distribution, it is not necessary to download it separately.

+
+
+

In the top level directory of the source distribution James includes two helper scripts for running +the build. The script build.bat should be used on Windows systems, while build.sh is appropriate for +Unix systems. Each script takes an optional set of arguments that tell the script exactly what to build.

+

To use these scripts, simple set the environment variable JAVA_HOME to the base directory of the +JDK. Then run the build script, optionally with any of the following command line arguments: +

    +
  • clean - deletes the build directory, making the system ready for a clean build.
    • +
  • compile - compiles the source code.
    • +
  • dist - generates all the James distributions, packed.
    • +
  • dist-lite - generates all the James distributions, unpacked. This is the default argument.
    • +
  • javadocs - builds the James javadocs.
    • +
  • usage - prints out the usage instructions for the script.
    • +
  • website - builds the entirety of the James website.
    • +
  • xdocs - creates the documentaion for James.
    • +
+

+

All build products are output in the dist subdirectory of the James source distribution directory. There +is also a build subdirectory of the James source distribution directory that is created during the build process. Both +of these directories will be deleted if you run build with the clean argument.

+

Warning! Any changes you've made in the 'dist' directory +will be lost after a recompilation. If you are making changes to the config.xml +or other files, we recommend you backup and then change the copies in src to +avoid losing work.

+
+ + + diff --git a/server/2.2.0/src/site/xdoc/changelog.xml b/server/2.2.0/src/site/xdoc/changelog.xml new file mode 100644 index 00000000000..d9841e13ebd --- /dev/null +++ b/server/2.2.0/src/site/xdoc/changelog.xml @@ -0,0 +1,446 @@ + + + + + + ChangeLog + James Project Web Team + + + + +

This is a document that records what was done between releases. As always, thank you to everyone who contributed code, documentation, bug reports, and feedback. +

+
+

Released 15 June 2004

+

+Below are some highlights of features and changes already available: +

    +
  • mbox support
    • +
  • Mail attributes
    • +
  • JavaMail 1.3.1
    • +
  • dnsjava 1.6.2, includes auto-discover DNS servers
    • +
  • FetchMAIL, deprecating FetchPop
    • +
  • Quotas
    • +
  • Extensive message redirect system
    • +
  • Improved network address handling
    • +
  • Multiple remote delivery gateway servers
    • +
  • Many performance improvements
    • +
  • Many new matchers and mailets
    • +
  • Many bug fixes
    • +
  • And much more!
    • +
+

+

Details

+ + +
    +
  • [JAMES-9] - JamesSpoolManager doesn't shutdown gracefully
    • +
  • [JAMES-62] - Spooler loops and add message many times
    • +
  • [JAMES-72] - SMTP Handler DATA buffering issue
    • +
  • [JAMES-96] - Mailet container should not trap exceptions in init()
    • +
  • [JAMES-109] - run.bat created wrong temp dir
    • +
  • [JAMES-128] - Fix problem when invalid domain name is passed to NetMatcher
    • +
  • [JAMES-133] - NullPointerException at org.apache.james.mailrepository.AvalonMailRepository.store
    • +
  • [JAMES-135] - NPE on nonexistant mailing-list repository
    • +
  • [JAMES-142] - RemoteDelivery only tries one of multiple A record entries.
    • +
  • [JAMES-144] - POP3Handler breaks with message numbers out of bounds
    • +
  • [JAMES-147] - Update libraries
    • +
  • [JAMES-150] - NullPointer Exception when mail does not contain any Received: headers
    • +
  • [JAMES-151] - connectionLimit on services ignored
    • +
  • [JAMES-152] - When a Received header is invalid mail may be created with a null remote address and host name
    • +
  • [JAMES-153] - Looping MessageException causes system stall
    • +
  • [JAMES-156] - AbstractStorageQuota matcher subclasses never match when recipient alias is used
    • +
  • [JAMES-157] - AbstractQuotaMatcher subclasses should not match when reverse path is NULL
    • +
  • [JAMES-163] - RemoteManager buffering issues
    • +
  • [JAMES-167] - Remote delivery counting retries wrong
    • +
  • [JAMES-170] - Postmaster address should be case insensitive
    • +
  • [JAMES-176] - MySQL query not using index for string comparison
    • +
  • [JAMES-178] - MailAddress can spit OutOfBoundsException
    • +
  • [JAMES-182] - Fix the TMPDIR path under windows/cygwin use of script
    • +
  • [JAMES-187] - Bug with DNS entries with 0 TTL
    • +
  • [JAMES-189] - Remote delivery sometimes not trying all MX records
    • +
  • [JAMES-191] - HasAttachment has false positives and negatives
    • +
  • [JAMES-192] - MSSQL mail table create bug
    • +
  • [JAMES-193] - MailetConfig does not implement getInitParameterNames()
    • +
  • [JAMES-194] - DNS occassional null pointer
    • +
  • [JAMES-199] - Bounce not using null sender
    • +
  • [JAMES-200] - MailetConfig throws exception for empty getInitAttribute
    • +
  • [JAMES-202] - Proper POP3 response to QUIT
    • +
  • [JAMES-203] - File protocol URL with JDK 1.4.2
    • +
  • [JAMES-207] - Exception handling when fetching message, stranding connection
    • +
  • [JAMES-208] - Regex code is not thread-safe
    • +
  • [JAMES-215] - Javadoc corrections in mailet API
    • +
  • [JAMES-230] - File stream repository may strand resource
    • +
  • [JAMES-233] - SMTP AUTH PLAIN doesn't work
    • +
  • [JAMES-236] - java.lang.NullPointerException iterating over SMTP hosts
    • +
  • [JAMES-238] - Missing Date: header with CommandListserv
    • +
  • [JAMES-239] - CommandListserv corrupts Subject: header
    • +
  • [JAMES-240] - LinearProcessor.verifyMailAddresses should catch java.lang.ArrayStoreException
    • +
  • [JAMES-243] - FromRepository does not reset mail state
    • +
  • [JAMES-247] - James Does Not Work With Oracle DB For Spool Repository
    • +
  • [JAMES-249] - getSMTPHostAddresses doesn't resolve when MX RHS is CNAME
    • +
  • [JAMES-251] - ClassCastException
    • +
  • [JAMES-253] - deadlock in mordred connection pool
    • +
  • [JAMES-255] - SMTPHandler logs exceptions that abort the connection only at DEBUG level
    • +
  • [JAMES-261] - Text error in config.xml
    • +
  • [JAMES-262] - Invalid link in james-fetchmail.xml
    • +
  • [JAMES-265] - org.xbill.DNS.Address not resolving addresses in some configurations
    • +
  • [JAMES-267] - NullPointerException in Fetchmail when there are no From: or Sender: headers
    • +
  • [JAMES-268] - Spooler.accept(...) can leave locked messages and leak memory
    • +
  • [JAMES-269] - AvalonMailRepository emits spurious "so we're deleting it... good riddance" messages due to synchronization
    • +
  • [JAMES-271] - can't resolve when MX record direct an ip
    • +
  • [JAMES-276] - The url for the ENTITY declarations in config.xml should be just "../conf/file-name"
    • +
  • [JAMES-278] - Remove references to Jakarta where no longer accurate
    • +
  • [JAMES-280] - DNSServer does not cleanup DNS cache cleaner thread.
    • +
  • [JAMES-281] - Return-Path twice in header
    • +
  • [JAMES-282] - Partial message may be delivered if client disconnects
    • +
  • [JAMES-294] - Database Pool becomes exhausted after a short time when heavily polled
    • +
+ + +
    +
  • [JAMES-99] - RFC1894 format notification
    • +
  • [JAMES-161] - Quota framework
    • +
  • [JAMES-162] - Partial send support
    • +
  • [JAMES-169] - Network-based authorization for SMTP AUTH
    • +
  • [JAMES-171] - Improve support for character encoded subjects in mailing lists
    • +
  • [JAMES-172] - New thread pool implementation
    • +
  • [JAMES-173] - Control number of rows returned in JDBCSpoolRepository
    • +
  • [JAMES-174] - Improve performance on message size
    • +
  • [JAMES-177] - DNS settings autodiscovery
    • +
  • [JAMES-179] - Reduce memory footprint of sql resouces
    • +
  • [JAMES-180] - Faster listing usernames
    • +
  • [JAMES-181] - Better CRLF handling in protocols
    • +
  • [JAMES-183] - Overhauled Redirect mailet
    • +
  • [JAMES-184] - New network matcher classes
    • +
  • [JAMES-188] - Improved error handling in processors
    • +
  • [JAMES-198] - New listserv code.
    • +
  • [JAMES-204] - Upgrade to JavaMail 1.3.1
    • +
  • [JAMES-205] - New database connection pooler
    • +
  • [JAMES-210] - Upgrade to dnsjava 1.4.0
    • +
  • [JAMES-212] - Batch delete from mail repository
    • +
  • [JAMES-214] - Better PID handling
    • +
  • [JAMES-217] - Upgrade to dnsjava 1.4.1
    • +
  • [JAMES-218] - showalias and showforwarding commands
    • +
  • [JAMES-221] - SenderInFakeDomain network setting
    • +
  • [JAMES-222] - Make file mail repository sort FIFO
    • +
  • [JAMES-225] - Upgrade to dnsjava 1.4.2
    • +
  • [JAMES-226] - Simplify connection tracking
    • +
  • [JAMES-227] - Upgrade to dnsjava 1.4.3
    • +
  • [JAMES-228] - Upgrade to DBCP 1.1
    • +
  • [JAMES-232] - JMX exposes more server information
    • +
  • [JAMES-234] - Improved bounce from RemoteDelivery
    • +
  • [JAMES-283] - James should use default backLog value when creating a ServerSocket
    • +
+ + + + + +
    +
  • [JAMES-149] - Add soft-fail to unresolved received from domains
    • +
  • [JAMES-190] - Apache license 2.0
    • +
  • [JAMES-213] - Mail repository throw MessagingException instead of RuntimeException
    • +
  • [JAMES-223] - Remove stack traces to console
    • +
  • [JAMES-252] - Upgrade to dnsjava 1.6.2
    • +
  • [JAMES-277] - Generate mailet.jar as separate from core james.jar
    • +
+ +
+ +
+

Released 12 May 2003

+
    +
  • [NjB] (code) Fixed stream handling in MimeMessageWrapper to address a JavaMail issue introduced in v2.1.2
    • +
  • [NjB] (code) Fixes to AddFooter for text/html parts
    • +
  • [MI,PG,NjB] (code) Fixes to AddFooter for MimeMultipart messages
    • +
  • [NjB] (code) Changed ExtraDotOutputStream to enforce RFC 2821 #2.3.7
    • +
  • [NjB] (code) Corrected allowable characters for localpart of address
    • +
  • [NjB] (update) Removed generated files from source distributions
    • +
  • [PG] (code) Corrrected handling of NNTP messages to avoid character encoding issues
    • +
  • [NjB] (code) James.getId bug - courtesy of Sid Stuart
    • +
  • [KS} (code) Added NNTP linecounting support
    • +
  • [KS} (code) Fixed NNTP authentication
    • +
  • [HJ] (code) Fixed bug 18726 (optional socket factory to specify outgoing bind address)
    • +
  • [NjB] (code) Fixed bug 19418 (changed notify/wait code in spooler)
    • +
  • [NjB] (code) Fixed bug 18307 (NotifySender headers)
    • +
  • [NjB] (code) Fixed bug with non-InternetAddress addresses - courtesy of Steen Jansdal
    • +
  • [NjB] (code) Fixed bug in NotifySender with complex MIME messages
    • +
  • [SK, NjB] (code) Added Delivered-To header in LocalDelivery
    • +
  • [NjB] (code) Fixed Bug 15428 - check for valid user before attempting removal
    • +
+
+ +
+

Released 21 February 2003

+
    +
  • [NjB] (code) Fixed handling of permanent/temporary errors in RemoteDelivery
    • +
  • [NjB] (code) Fixed bug where connect error could cause outgoing mail to be discarded.
    • +
  • [PG] (code) Fixed the bounce() method to add the original message as a message MIME type with an attachment disposition.
    • +
+
+ +
+

Released 11 February 2003

+
    +
  • [KL] (code) SMTP AUTH compatibility change
    • +
  • [NjB] (code) Changed MimeMessageWrapper to use the raw stream when possible
    • +
  • [NjB] (code) Fixed synchronization bug in AvalonMailRepository
    • +
  • [NjB] (update) Updated Avalon LogKit
    • +
  • [NjB] (code) Infinite loops are interruptable
    • +
  • [HB, NjB] (code) Fixed NNTP crossposting
    • +
  • [NjB] (code) Fixed synchronizaion bug in file repository
    • +
  • [NjB] (code) Enabled log rotation
    • +
  • [NjB] (doc) Fixed broken links
    • +
  • [DA, NjB] (update) Updated JavaMail and JAF
    • +
  • [NjB] (code) Updated sqlResources.xml for PostgreSQL with patch from simon
    • +
  • [NjB] (code) Reorder primary key for JDBCMailRepository to optimize queries using just the repository name.
    • +
  • [PG,HB] (code) NNTP dot stuffing fix
    • +
  • [PG] (code) NNTP OVER/XOVER fix
    • +
  • [NjB] (code) Experimental RegexMatcher classes
    • +
+
+ +
+

Released 29 December 2002

+
    +
  • (AK) (doc) Added LDAP RFCs.
    • +
  • (PG) (code) Fixed platform-specific performance issue with the POP3 server delivery.
    • +
  • (PG) (code) Fixed bug where RemoteDelivery did not iterate through all MX records on connect failure.
    • +
  • (PG) (update) Updated James to use the Avalon Framework version 4.1.3.
    • +
  • (PG) (update) Updated James to use Avalon Phoenix version 4.0.1.
    • +
  • (PG) (doc) Added extensive commenting - specifically Javadoced the vast majority of methods.
    • +
  • (PG,AI) (code) Added a James specific abstract Service implementation. Unified configuration, logging, as well as enabling the use of thread pools and socket types on a per service basis.
    • +
  • (NjB) (code) Corrected JDBCMailRepository to obey stated contract.
    • +
  • (NjB,PG) (code) Adjusted service handlers to flush socket output streams to ensure prompt client interactions.
    • +
  • (PG) (code) Adjusted the NNTP server so that it better conforms to the NNTP specification (see bug #13564 for details).
    • +
  • (PG) (code) Corrected a typo that had been disabling NNTP using SSL functionality.
    • +
  • (PG) (code) Corrected an architectural flaw in the NNTP server implemenation that disabled NNTP authentication.
    • +
  • (NjB) (code) Fixed a bug in the GenericListserv subject normalization. Neatened the code to make later modifications easier.
    • +
  • (BW) (code) Fixed a bug in the RemoteDelivery mailet that caused the mailet to unnecessarily split the recipient list when using a gateway.
    • +
  • (NjB,PG) (code) Added object pooling for service handlers to substantially improve performance.
    • +
  • (AI,PG) (code) Added a new Watchdog interface to effectively support connection timeouts. An implementation of the interface was added that uses a second thread per connection to ensure timeouts.
    • +
  • (NjB,PG) (code) Resolved a memory leak in the source - a list of files to be deleted was being maintained that was unnecessary. The file to be deleted is now deleted immediately after it is no longer needed.
    • +
  • (PG) (code) Changed the code to ensure that all thread pool threads are returned to the thread pool in a non-interrupted state.
    • +
  • (PG) (code) Centralized the file/directory lookup code inside James and fixed it so that it handled absolute URLs properly.
    • +
  • (AI,PG) (code) Added a more substantial connection manager. This connection manager allows us to limit the maximum number of client connections per server socket. It also allows us to set the socket timeout for client sockets explicitly.
    • +
  • (DA,PG) (code) Added enabled/disabled switch to main server components.
    • +
  • (DA) (code) Added new FetchPOP functionality, to allow James to consolidate mail from a number of POP3 servers in a single server.
    • +
  • (DA) (doc) Added documentation to demonstrate how to configure James as a universal sendmail relay.
    • +
  • (NjB) (code) Made subject prefix bracketing in GenericListserv configurable.
    • +
  • (NjB) (code) Added the HasHeader matcher.
    • +
  • (NjB) (code) Added the JDBCVirtualUserTable mailet.
    • +
  • (NjB) (code) Enhanced the RemoteAddrInNetwork and RemoteAddrNotInNetwork to accept domain names.
    • +
  • (PG) (update) Fixed the log configuration so that AM and PM entries are properly distinguishable by default.
    • +
  • (NjB) (code) Added a configurable debug parameter to several mailets to allow a more granular control of debug logging.
    • +
  • (NjB) (code) Added the Habeas warrant mailet and matcher.
    • +
  • (NjB,PG) (update) Changed the server configuration to default log at INFO level. Adjusted logging statements so that they are log level appropriate.
    • +
  • (PG) (code) Fixed a critical bug in the dbfile implementation. Fixed repository implementation so that db repositories do not behave as dbfile repositories.
    • +
  • (NjB) (code) Fixed MimeMessageWrapper so that mail headers are properly updated when headers are set on the wrapper.
    • +
  • (PG) (code) Added UNSETFORWARDING functionality to the RemoteManager.
    • +
  • (PG) (code) Closed an open relay hole involving an empty Sender header.
    • +
  • (PG) (code) Fixed Oracle specific bug that limited us to messages of 4K or less in the repository.
    • +
  • (SS,NjB,PG) (code) Ensured that a number of database and I/O resources are properly closed under all conditions.
    • +
  • (NjB) (code) Changed default column sizes for JDBC repositories to be RFC compliant.
    • +
  • (NjB) (code) Fixed exception handling in JdbcDataSource when getConnection() fails.
    • +
  • (PG) (code) Fixed NotifySender/NotifyPostmaster to be more robust against ill-formed headers in the email being forwarded.
    • +
  • (SD,SS3) (code) Made a substantial performance enhancement to the LinearProcessor such that mail changes are not persisted to the store until necessary. Also reduced synchronization scope.
    • +
  • (PG) (code) Converted String concatenation to the use of StringBuffers throughout the code base.
    • +
  • (PG) (code) Fixed date formatting to be thread safe.
    • +
  • (NjB) (code) Fixed InSpammerBlacklist
    • +
  • (PH) (update) Upgrade James to the Avalon 4.0/4.1 actual releases.
    • +
  • (NjB,SK) (update) Fixed MailImpl.duplicate to include remote addr, remote host, and last updated fields.
    • +
  • (CB2) (update) Fixed NNTP server bug where the NEXT command was not being properly dispatched and handled.
    • +
  • (SK) (update) Cleaned up error handling in LocalDelivery.
    • +
  • (SS2) (code) Changed the default configuration so that log files are appending by default.
    • +
  • (SS2) (update) Reported the lack of in.close in MimeMessageSource.getSize(), which was causing stranded file handles, especially during large POP3 sessions.
    • +
  • (AI) (update) Matcher config implementation object now properly set with matcher name.
    • +
+
+
+

Released 20 April 2002

+
    +
  • (DA) (update) Fixed POP3 message size bug that prevented retrieval
    • +
  • (SK) (code) FileRepository should no longer produce 0-byte files. It checks that the source is different than the target, or confirm it is in memory before saving to disk.
    • +
  • (SK) (update) Removed check that connection is not closed before returning it. The pooler is already confirming the connection was open before putting it in the pool, so this was a big unnecessary performance drain.
    • +
  • (SK) (update) Fixed the delay in the JDBC mail spool repository as it wasn't rechecking correctly after it emptied the spool.
    • +
  • (SS2) (code) Added dot-stuffing in POP3 message delivery to fix problems with Netscape and other mail clients and to comply with RFC.
    • +
  • (JK) (code) Fixed bounce method to use the Return-Path header if there is one.
    • +
  • (SK) (update) Improved handling of delivery error messages when the remote server returns a specific 5XY complaint.
    • +
  • (SK) (code) Better diagnosing of temporary vs. permanent delivery exceptions, most notably "Could not connect to host.." is a temporary exception.
    • +
  • (SK) (code) Remote SMTP delivery now sets the remote hostname using the servername configuration setting (uses the first one).
    • +
  • (SK) (update) Have it cleanly (not print stack trace) if the remote manager handler has io/socket exceptions.
    • +
  • (SK) (update) Support in "IsSenderInFakeDomain" to handle null senders properly (was producing a false positive in this case).
    • +
  • (PH) (update) Added releaseConnection method to BaseConnectionHandler as per Paul H's bug report.
    • +
  • (SK) (update) Reordered 250 SMTP responses to fix Mac client issue per Giles Chanot's bug report.
    • +
+
+ +
+

Released 1 December 2001

+
    +
  • (*) (update) Moved to Avalon snapshot of November 2001
    • +
  • (DA) (update) Fixed POP3 message size bug that prevented retrieval
    • +
  • (SK) (code) Added Mordred database connection pooling. It is the marriage of Town's db pooling code and Excalibur's configuration.
    • +
  • (SK) (update) Changed MailImpl.getSize() to getMessageSize() and from int to long.
    • +
  • (SK) (docs) Small updates to documentation
    • +
  • (SK) (code) Added JDBCListserv, straight JDBC implementation of old TownListserv that extends GenericListserv
    • +
  • (SK) (update) Patched bug in GenericListserv for when subject was null
    • +
  • (SK) (update) Got mailets/matchers to load from something besides james.bar
    • +
  • (SK) (code) Added scheduler notification during SMTP DATA reception and POP3 RETR sending so the connection handler doesn't time out connection while data is being transfered.
    • +
  • (SK) (code) Support <gatewayPort> setting on RemoteDelivery to send all messages to a non-port 25 SMTP server. Only makes sense when <gateway> is also set.
    • +
  • (EP) (update) Used getAsBooleanValue in various configuration methods to make code more readable.
    • +
  • (SS) (update) Added support for Oracle database for mail and spool JDBC repositories.
    • +
+
+ +
+

Released 26 October 2001

+
    +
  • (CB,*) (update) Moved to Avalon snapshot of 9-25-2001.
    • +
  • (HB) (code) Added NNTP service.
    • +
  • (SK) (update) Greatly improved multi-threading support for repositories and SMTP reception.
    • +
  • (JB) (code) SMTP AUTH support
    • +
  • (SK) (update) Support null senders, i.e., MAIL RCPT: <>.
    • +
  • (DD,SK) (update) Converted Town mail and user repositories to straight JDBC ones, using Excalibur connection pooling and configurable SQL statements per DB.
    • +
  • (SK) (update) Messages are no longer loaded until absolutely necessary.
    • +
  • (GB) (update) Fixed exception being thrown on MailAddress parsing.
    • +
  • (CB) (update) Rebuilt CVS tree after hack and moved src to src/java.
    • +
  • (DA) (code) New extensible, flexible Redirect mailet that handles notifications and forwarding.
    • +
  • (SK) (code) JDBC Alias mailet.
    • +
  • (various) (docs) Added a whole bunch of related RFCs to the webdocs.
    • +
  • (DA) (update) Add date to bounced emails.
    • +
  • (HB) (update) Updated DNS library and started process to move it to Avalon service.
    • +
  • (various) (update) More checks to fix "stuck file" problem in Avalon mail repository.
    • +
  • (MP) (code) Limit the size of a message on reception (rather than waiting until processors).
    • +
  • (SK) (update) Fixed dot-stuffing in SMTP reception/delivery.
    • +
  • (SK) (update) Improved how Return-Path and Received headers are generated during SMTP reception.
    • +
  • (SK) (update) More efficient remote delivery code, better error messages, and gateway parameter to route all messages to a single target.
    • +
  • (DA) (update) Fixed timezone bug in RFC822DateFormat
    • +
  • (MP) (update) Patch to support username@[yyy.yyy.yyy.yyy] addresses
    • +
  • (GB) (update) Patch to fix size calculation from headers
    • +
  • (RS) (image) Contributed James logo
    • +
  • (SK) (update) Changed MailetException to extend MessagingException, and Mailet.init() throws MailetException.
    • +
+
+ +
+

Released 13 December 2000

+
    +
  • (SK,SR,CB) (update) Fix for "stuck file" problem in Avalon mail repository.
    • +
  • (SK) (design) Made usernames case insensitive on MailAddress
    • +
  • (SK) (code) Complete rewrite of processor code to send through Mail object through matchers and mailets. Design might be less efficient but easier to understand and more flexible for later improvements to API. Also no longer "loses" IP address and error message information when Mail object go from one processor/state to the next (ToProcessor changed as well now that processor works).
    • +
  • (SK) (update) Updated to JavaMail 1.2
    • +
  • (SK) (update) Changed instantiation of recipients on a Mail object to a Set (HashSet) whenever possible in preparation for the API having this change.
    • +
  • (IS) (code) Added UsersTownRepository to let you maintain user lists in a database
    • +
  • (SR) (update) In POP3 handler, properly includes headers in calculating size of messages.
    • +
  • (SK) (update) Removed "synchronized" attribute on many methods in town and file spool repositories. Should significantly boost performance and multithreaded capabilities.
    • +
  • (SK) (code) Optimization of town mail repository, introduction of JamesMimeMessageInputStream and the James MimeMessage. Should significantly reduce the number of unnecessary parses or saves on MimeMessages in server.
    • +
  • (SR) (update) Properly calculates hashCode for MailAddress so duplicates do not exist in Hashmaps
    • +
  • (SR) (update) Hardcoded serialVerUID on MailAddress and MailImpl to that of James 1.2 release so future releases can continue to use mail stored in earlier releases.
    • +
  • (IS) (update) Added ability on NotifySender and NotifyPostmaster to attach informative notice.
    • +
  • (SK) (update) GenericListservManager now requires existsAddress() which it uses to prevent someone already on the list from subscribing or someone not on the list from removing themselves.
    • +
  • (SK) (update) Changed User repository for file to *always* end the destination with a File.separator. Otherwise if people mixed usage of this, it would crash the repositories with confusing error messages. Child repositories were already properly created with a terminating File.separator.
    • +
  • (SK) (code) New matcher: IsSingleRecipient
    • +
  • (SK) (code) Added spam blacklist checking for 3 spam blacklists that make this available in a simple DNS lookup check. All free services through mail-abuse.org. Added to default configuration in config.xml
    • +
  • (PU) (code) Added first testing program. This would recreate file stuck problem. Would be good to build collection of testing utilities in this new package.
    • +
  • (SK) (docs) Documented what all the jars are in the lib directory (what they're called, where they're from)
    • +
+
+ +
+

Released 16 October 2000

+
    +
  • (SK) (design) Abstracted mailet API to be Avalon (implementation) independent
    • +
  • (CB) (code) Abstracted mail repository in JAMES/Avalon to allow more varied implementations.
    • +
  • (SK) (code) Database implementations of mail repositories
    • +
  • (SK) (code) Changed remote delivery to use an outgoing spool with a specified number of delivery threads
    • +
  • (CB) (code) Experimental implementation of LDAP user manager
    • +
  • (SK) (update) Reworked mailets and matchers to fit new API and added many more classes
    • +
  • (CB, SK) (update) Fixed some bugs in POP3 server
    • +
  • (CB) (update) Added full TLS support in POP3 (POP3S)
    • +
  • (SK) (update) Fixed sorting of MX records so it attempts delivery in correct order
    • +
  • (SK) (update) Changed remote manager to not allow a login if an admin account's password is empty, + and sets the root account's password empty by default (so you have to set one... prevents someone + from knowing the password to your system out of the box)
    • +
+
+
+

Release 27 July 2000

+
    +
  • (??) (code) Unknown changes
    • +
  • (SK) (code) Made DNS functionality a separate block
    • +
+
+ +
+

Released 26 February 2000

+
    +
  • (SK, FB) (code) Added DNS stuff to remote delivery.
    • +
  • (FB) (code) Add some autodetect support for easier configuration.
    • +
  • (FB) (code) Add support for Mailet.
    • +
  • (FB) (update) Add Mailet interface draft.
    • +
+
+ +
+

Released early 2000

+
    +
  • (FB) (update) Split the SMTP Server in a protocol handler and a MailServer available to + all Avalon blocks.
    • +
  • (FB) (update) Tune MessageContainer class.
    • +
+
+ +
+

Unknown release date

+
    +
  • (FB) (update) Based on much code from Serge Knystautas first implementation of JAMES on + top of the Avalon framework.
    • +
+
+ +
+

Check out our Who We Are page to see who to thank.

+
+ + + diff --git a/server/2.2.0/src/site/xdoc/custom_mailet.xml b/server/2.2.0/src/site/xdoc/custom_mailet.xml new file mode 100644 index 00000000000..3a9dab66755 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/custom_mailet.xml @@ -0,0 +1,117 @@ + + + + + + James 2.1 - Writing a Custom Mailet + + + +
+

Implementing a custom mailet is generally a simple task, most of whose complexity +lies in coding the actual work to be done by the mailet. This is largely due to the +simplicity of the Mailet interface and the fact that a GenericMailet class is provided +as part of the Mailet package.

+

In this discussion we will assume that any mailet being implemented is a subclass of +GenericMailet. The GenericMailet class serves to abstract away of the configuration and +logging details. While it provides a noop implementation of the init() and destroy() methods, +these can be easily overridden to provide useful functionality.

+

In general, the only four methods that you should need to implement are init(), destroy(), +getMailetInfo(), and service(Mail). And only the last is required in all cases.

+ +

As described in the SpoolManager configuration +section, mailets are configured with a set of String (name, value) pairs. These values are +passed into the Mailet upon initialization (although the details of this process are hidden by +the GenericMailet implementation). GenericMailet provides access to this configuration +information through use of the getInitParameter(String) method. Passing in the name of the +requested configuration value will yield the value if set, and null otherwise. Configuration +values are available inside the init(), destroy(), and service(Mail) methods.

+ + +

There is a simple logging mechanism provided by the Mailet API. It does not support +logging levels, so any log filtering will have to be implemented in the Mailet code. +Logging is done by calling one of the two logging methods on GenericMailet - log(String) +or log(String,Throwable). Logging is available inside the init(), destroy(), and service(Mail) +methods.

+

The value of getMailetInfo() for the Mailet is prepended to the log entries for that +Mailet. So it may be desirable for you to override this method so you can distinguish mailet +log entries by Mailet.

+ + +

As part of the Mailet lifecycle, a Mailet is guaranteed to be initialized immediately after +being instantiated. This happens once and only once for each Mailet instance. The +Initialization phase is where configuration parsing and per-Mailet resource creation generally +take place. Depending on your Mailet, it may or may not be necessary to do any initialization +of the mailet. Initialization logic is implemented by overriding the init() method of +GenericMailet.

+ + +

The bulk of the Mailet logic is expected to be invoked from the service(Mail) method. This +method is invoked each time a mail message is to be processed by the mailet. The message is +passed in as an instance of the Mail interface, which is part of the Mailet API.

+

The Mail interface is essentially a light wrapper around JavaMail's MimeMessage class with a +few important differences. See the Javadoc for the interface for a description of the additional +methods available on this wrapper.

+ + +

As part of the Mailet lifecycle, a Mailet is guaranteed to be destroyed when the container +cleans up the Mailet. This happens once and only once for each Mailet instance. The +Destruction phase is where per-Mailet resource release generally takes place. Depending +on your Mailet, it may or may not be necessary to do any destruction +of the mailet. Destruction logic is implemented by overriding the destroy() method of +GenericMailet.

+ +
+
+

Once a Mailet has been successfully implemented there are only a couple of +additional steps necessary to actually deploy the Mailet.

+ +

+The Mailet must be added to James' classpath so that the Mailet can be loaded by James. There +are two ways to add a custom Mailet to the classpath so that James will be able to load the +Mailet. These are: +

+

+1. Download the source distribution, add a jar file containing the custom files to the lib +directory of the unpacked source distribution, and build a new .sar file by following the +directions here. This new .sar file will now +include your custom classes. +

+

+or +

+

+2. Place a jar file containing the custom class files in the lib subdirectory of the James +installation. It will also be necessary to unpack the JavaMail and James jar files from +the provided .sar file and add them to this directory. +

+ + +

Configuration of the processor chain is discussed +elsewhere in this documentation. The +details of configuring mailet deployment is discussed at length. Here we will only comment +that it is important to add the appropriate mailet package for your custom mailet to the +<mailetpackages> list and that the name of your mailet should not conflict with any of +the mailets described here. +

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/custom_matcher.xml b/server/2.2.0/src/site/xdoc/custom_matcher.xml new file mode 100644 index 00000000000..b590166b76b --- /dev/null +++ b/server/2.2.0/src/site/xdoc/custom_matcher.xml @@ -0,0 +1,128 @@ + + + + + + James 2.1 - Writing a Custom Matcher + + + +
+

Implementing a custom matcher is generally a simple task, most of whose complexity +lies in coding the actual work to be done by the matcher. This is largely due to the +simplicity of the Matcher interface and the fact that a couple of abstract Matcher template +classes are provided in the Mailet package. These two classes, GenericMatcher and +GenericRecipientMatcher, greatly simplfy the task of Matcher authoring.

+

As discussed elsewhere in this manual, the Matcher interface does not simply match +or not match a particular message. Rather, it returns some subset of the original message +recipients as a result of the match(Mail) method. This leads to the two different abstract +Matcher implementations.

+

The first, GenericMatcher, is intended for matchers where recipient evaluation is not +necessary. Basically, you should subclass this implementation if your matcher is going to +return all or none of the recipients.

+

When subclassing this class, there are four methods that potentially need to be +overridden. These are getMatcherInfo(), init(), match(Mail), and destroy(). More on these +anon.

+

The second implementation, GenericRecipientMatcher, is intended for those matchers where +each recipient is evaluated individually. It is a subclass of GenericMatcher, and inherits +most of its behavior from that class. The only major difference is that subclasses are +expected to override matchRecipient(MailAddress) rather than match(Mail).

+ +

Matchers are passed a single String as part of their configuration. Interpretation of this +list is left entirely to the body of the Matcher. This String value is available in +the body of the Matcher through use of the getCondition() method of the +GenericMatcher class. This method returns the String value passed to the Matcher, and returns +null if no value is set. The method getCondition() is available inside the init(), destroy(), match(Mail), +and matchRecipient(MailAddress) methods.

+ + +

There is a simple logging mechanism provided by the Mailet API. It does not support +logging levels, so any log filtering will have to be implemented in the Matcher code. +Logging is done by calling one of the two logging methods on GenericMatcher/GenericRecipientMatcher - log(String) +or log(String,Throwable). Logging is available inside the init(), destroy(), match(Mail), +and matchRecipient(MailAddress) methods.

+

The value of getMatcherInfo() for the Matcher is prepended to the log entries for that +Matcher. So it may be desirable for you to override this method so you can distinguish Matcher +log entries by Matcher.

+ + +

As part of the Matcher lifecycle, a Matcher is guaranteed to be initialized immediately after +being instantiated. This happens once and only once for each Matcher instance. The +Initialization phase is where configuration parsing and per-Matcher resource creation generally +take place. Depending on your Matcher, it may or may not be necessary to do any initialization +of the Matcher. Initialization logic is implemented by overriding the init() method of +GenericMatcher/GenericRecipientMatcher.

+ + +

It is the matching phase where the Matcher's work is done. The exact form of this phase largely +depends on which Matcher superclass is subclassed.

+

If GenericMatcher is being subclassed, it is the match(Mail) that is implemented. As described +above, this method returns a Collection of MailAddresses that is a subset of the original +recipients for the Mail object.

+

If it is a purely recipient-filtering Matcher, then the GenericRecipientMatcher should be +subclassed. In this case, developers must provide an implementation of the +matchRecipient(MailAddress) method. This method returns true if the recipient matches, +and false otherwise.

+ + +

As part of the Matcher lifecycle, a Matcher is guaranteed to be destroyed when the container +cleans up the Matcher. This happens once and only once for each Matcher instance. The +Destruction phase is where per-Matcher resource release generally takes place. Depending +on your Matcher, it may or may not be necessary to do any destruction +of the Matcher. Destruction logic is implemented by overriding the destroy() method of +GenericMatcher/GenericRecipientMatcher.

+ +
+
+

Once a Matcher has been successfully implemented there are only a couple of +additional steps necessary to actually deploy the Matcher.

+ +

+The Matcher must be added to James' classpath so that the Matcher can be loaded by James. There +are two ways to add a custom Matcher to the classpath so that James will be able to load the +Matcher. These are: +

+

+1. Download the source distribution, add a jar file containing the custom files to the lib +directory of the unpacked source distribution, and build a new .sar file by following the +directions here. This new .sar file will now +include your custom classes. +

+

+or +

+

+2. Place a jar file containing the custom class files in the lib subdirectory of the James +installation. It will also be necessary to unpack the JavaMail and James jar files from +the provided .sar file and add them to this directory. +

+ + +

Configuration of the processor chain is discussed +elsewhere in this documentation. The +details of configuring matcher deployment is discussed at length. Here we will only comment +that it is important to add the appropriate matcher package for your custom matcher to the +<matcherpackages> list and that the name of your matcher should not conflict with any of +the matchers described here. +

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/dns_configuration.xml b/server/2.2.0/src/site/xdoc/dns_configuration.xml new file mode 100755 index 00000000000..2405840f245 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/dns_configuration.xml @@ -0,0 +1,59 @@ + + + + + + James 2.1 - Configuring DNS Services + + + +
+ + +

DNS Transport services are controlled by a configuration block in +the config.xml. This block affects SMTP remote delivery.

+ +

The dnsserver tag defines the boundaries of the configuration +block. It encloses all the relevant configuration for the DNS server. +The behavior of the DNS service is controlled by the attributes and +children of this tag.

+ +

The standard children of the dnsserver tag are:

+
    +
  • servers - This is a list of DNS Servers to be used by James and are +specified by one, or more server elements, which are child elements. +Each server element is the IP address of a single DNS server. + +<servers> + <server>127.0.0.1</server> + <server>166.181.194.205</server> +</servers> + +
    • + +
  • authoritative - (true/false)This tag specifies whether or not +to require authoritative (non-cached) DNS records; to only accept DNS responses that are +authoritative for the domain. It is primarily useful in an intranet/extranet environment. +

    This should always be false unless you understand the implications.

    +
    • +
+
+ + diff --git a/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml b/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml new file mode 100755 index 00000000000..512e7de1b52 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml @@ -0,0 +1,967 @@ + + + + + James 2.2 - fetchmail Configurartion + + + +
+

fetchmail acts as a gateway between an external message store such as an IMAP +or POP3 server and James. Mail is fetched from the external message store and +injected into the James input spool.

+ +

fetchmail is useful when delivery via standard SMTP is not an option, as a +means of consolidating mail delivered to several external accounts into a single +James account, or to apply the mail processing capabilities of James to mail +stored in an external message store.

+ +

fetchmail has several configuration options that control the fetching and +filtering of mail injected into the James input spool. Once there, James' +flexible mail processing engine can be used to further process the mail, just as +if it had been delivered via standard SMTP.

+ +

+How fetchmail Works
+fetchmail Configuration Parameters
+fetchmail Examples
+fetchmail Caveats +

+
+ +
+

Mail is delivered by periodically running fetch tasks that read messages from +an external message store and injects them into the James input spool. Fetch +tasks run concurrently.

+ +

A set of filters applies to each fetch task. Each filter provides the ability +to reject a message that matches the filter criteria. Rejected messages are not +injected into the James input spool; they are either marked as seen or deleted. +When a filter is configured to accept a message that matches its criteria, +messages are marked with a MailAttribute. This MailAttribute can be detected +within the James matcher/mailet chain, allowing further processing as +required.

+ +

Each fetch task is associated with a single host server. Accounts are defined +to the fetch task for each mailbox on the server from which mail is to be +fetched. Accounts run consecutively.

+ +

Optionally, the fetch task can be configured with an <alllocal> Account that +generates an Account entry for each user defined in the James user repository. +This removes the requirement to manually add or remove Account entries to the +fetchmail configuration each time a James user is added or removed. Currently +this is only useful if the server supports virtual mailboxes that allow the same +password to apply to all users within a domain.

+ +

Accounts can be configured to deliver all mail for an Account to a specified +recipient or to deduce the intended recipient from the mail headers.

+ +

Accounts are normally configured to deliver all mail for an Account to a +specified recipient, ignoring the recipient in the mail headers. This works well +in the majority of cases where a mailbox is guaranteed to contain mail for a sole +mailbox recipient.

+ +

Accounts are configured to deduce the intended recipient from the mail headers +when a mailbox contains mail for several users, typically all users in a domain. +Used alone, this is not foolproof as there are circumstances when a single unique +recipient cannot be deduced from the mail headers alone. Used in conjunction with +an appropriately configured <alllocal> account, it is always possible to deduce +the intended recipient when the recipient is a James user.

+
+ +
+

The fetchmail configuration parameters are part of the James configuration, +whose base file is config.xml. For clarity and flexibility, the +fetchmail configuration parameters are stored in the file +james-fetchmail.xml, which is referenced within +config.xml.

+ +

The configuration parameters are described below.

+ + +

The configuration block delimited by the fetchmail tag +controls fetchmail.

+ +

The tag has these attributes: +

+
enabled
+
A boolean. If "true", the fetch tasks will be run periodically. If "false", +no fetch tasks will be run. The default is "false".
+
+

+ +

The tag has these child tags (minimum cardinality, maximum cardinality): +

+

+ +

+ +<fetchmail enabled="true"> +... +</fetchmail> + +

+ + + +

The fetch tag defines a fetch task to be run +periodically. Fetch tasks run concurrently.

+ +

The tag has these attributes: +

+
name
+
A string uniquely identifying the fetch task.
+
+

+ +

The tag has these child tags (minimum cardinality, maximum cardinality): +

+

+ +

+ +<fetch name="mydomain.com"> +... +</fetch> + +

+ + + +

The accounts tag declares the accounts from which mail will +be fetched by the fetch task. Accounts run concurrently.

+ +

The tag has these child tags (minimum cardinality, maximum cardinality): +

+

+ +

+ +<accounts> +... +</accounts> + +

+ + + +

The blacklist tag declares a list of recipient addresses +for whom mail will be rejected and what happens to the rejected mail.

+ +

The tag value is a tab, comma or space delimited list of recipient +addresses, eg: wibble@mydomain.com, flobble@mydomain.com.

+ +

The tag has these attributes: +

+
reject
+
A boolean. If "true", mail for recipients in the blacklist will +not be injected into the James input spool. If "false", mail for +recipients in the blacklist will be injected into the James input spool with the +Mail Attribute org.apache.james.fetchmail.isBlacklistedRecipient +added to the mail.
+
leaveonserver
+
A boolean. If "true", mail for recipients in the blacklist will be +left on the server. If "false", mail for recipients in the blacklist +will be marked for deletion.
+
markseen
+
A boolean. If "true", mail for recipients in the blacklist will be +marked as seen on the server. If "false", mail for recipients in the blacklist +will not be marked as seen.
+
+

+ +

+ +<blacklist + reject="true" + leaveonserver="true" + markseen="true"> +wibble@mydomain.com, flobble@mydomain.com +</blacklist> + +

+ + + +

The defaultdomain tag declares the domain name to be +appended to the From: header of a mail that has a valid user part +but is missing the domain part.

+ +

If not specified, the default behaviour is to append the canonical host name +of the James server.

+ +

The tag value is the name of the server to append. The name must be a server +declared in the servernames tag of the James +block in the configuration or the name localhost.

+ +

+ +<defaultdomain> + mydomain.com +</defaultdomain> + +

+ + + +

The fetchall tag declares if all mail should be fetched from +the server, or just unseen mail.

+ +

The tag value is a boolean. If true, all mail is fetched. If false, only +unseen mail is fetched.

+ +

+ +<fetchall>false</fetchall> + +

+ + + +

The fetched tag declares what will happen to mail on the +external server that is successfully injected into the James input spool.

+ +

The tag has these attributes: +

+
leaveonserver
+
A boolean. If "true", mail injected into the James input spool +will be left on the server. If "false", mail injected into the James +input spool will be marked for deletion.
+
markseen
+
A boolean. If "true", mail injected into the James input spool +will be marked as seen on the server. If "false", mail injected into +the James input spool will not be marked as seen.
+
+

+ +

+ +<fetched leaveonserver="true" markseen="true"/> + +

+ + + +

The host tag declares the IP address of the external +server from which mail is fetched.

+ +

The tag value is the DNS name or IP address literal of the external +server.

+ +

+ +<host>pop3.server.com</host> + +

+ + + +

The interval tag declares the period between invocations of +the fetch tasks. If a fetch task is still active from a previous invocation +when the period expires, the new invocation is skipped over.

+ +

The tag value is an integer representing the number of milliseconds to elapse +between invocations of the fetch tasks.

+ +

+ +<interval>60000</interval> + +

+ + + +

The javaMailFolderName tag declares the name of the root +folder on the external server from which mail is fetched.

+ +

The tag value is the cAsE-sEnSiTiVe name of the root folder on the external +server from which mail is fetched. For POP3 servers this is always +INBOX.

+ +

+ +<javaMailFolderName>INBOX</javaMailFolderName> + +

+ + + +

The javaMailProperties tag declares the properties to be +applied to the JavaMail Session used by the fetch task. These override the +properties answered by System.getProperties(). Many JavaMail +properties are specific to the JavaMail Provider selected by the +javaMailProviderName tag.

+ +

Relying on the default values selected by the Provider can be +inappropriate. For instance, the default connection and I/O timeout +values of infinite for the default IMAP and POP3 Providers is rarely what is +required. Consult the documentation of the Provider for details and options.

+ +

Documentation for the default Provider for IMAP is located + +here.

+ +

Documentation for the default Provider for POP3 is located + +here.

+ +

Details of how to change a Provider are located + +here.

+ +

The tag has these child tags (minimum cardinality, maximum cardinality): +

+

+ +

+ +<javaMailProperties> +... +</javaMailProperties> + +

+ + + +

The javaMailProviderName tag selects the JavaMail protocol +Provider used to interact with the external server.

+ +

The tag value is the name of a JavaMail supported protocol, such as +pop3 or imap. The name is used to select the default +Provider for the protocol.

+ +

+ +<javaMailProviderName>pop3</javaMailProviderName> + +

+ + + +

The maxmessagesize tag declares the maximum permitted message +size for messages injected into the James input spool and what happens to fetched +messages that exceed this size.

+

The tag has these attributes: +

+
limit
+
An integer. The maximum message size expressed in Kilobytes. If 0, there is +no limit.
+
reject
+
A boolean. If "true", mail whose message size exceeds the maximum +permitted size will not be injected into the James input spool. If +"false", mail whose message size exceeds the maximum permitted size will +have its contents removed, an explanatory error message and the Mail Attribute +org.apache.james.fetchmail.isMaxMessageSizeExceeded added prior to +injection into the James input spool, (see below for the location of an example).
+
leaveonserver
+
A boolean. If "true", mail whose message size exceeds the maximum +permitted size will be left on the server. If "false", mail whose message +size exceeds the maximum permitted size will be marked for deletion.
+
markseen
+
A boolean. If "true", mail whose message size exceeds the maximum +permitted size will be marked as seen on the server. If "false", +mail whose message size exceeds the maximum permitted size will not be marked as +seen.
+
+

+ +

+ +<maxmessagesize + limit="4096" + reject="false" + leaveonserver="false" + markseen="false"/> + +

+ +

An example configuration using James mailet processing to bounce fetched +messages that exceed the maximum permitted size can be found in the file +$PHOENIX_HOME/apps/james/conf/samples/fetchmail/maxMessageSize.xml. +

+ + + +

The recipientnotfound tag declares what happens to mail for +which a sole intended recipient cannot be found when attempting to determine +the recipient from the mail headers.

+ +

In configurations with more than one account per fetch task, processing of +matched mail can be deferred to the next run of the fetch task. This gives +other accounts that may be able to determine a sole intended recipient an +opportunity to do so before recipientnotfound processing is invoked.

+ +

The tag has these attributes: +

+
defer
+
A boolean. If "true", mail for which a sole intended recipient +cannot be determined is left unprocessed until the next run of the fetch task. +If "false", mail for which a sole intended recipient cannot be +determined is processed immediately.
+
reject
+
A boolean. If "true", mail for which a sole intended recipient +cannot be determined will not be injected into the James input spool. If +"false", mail for which a sole intended recipient cannot be +determined will be injected into the James input spool using the recipient +attribute of the current account and with the Mail Attribute +org.apache.james.fetchmail.isRecipientNotFound added to the +mail.
+
leaveonserver
+
A boolean. If "true", mail for which a sole intended recipient +cannot be determined will be left on the server. If "false", mail for +which a sole intended recipient cannot be determined will be marked for +deletion.
+
markseen
+
A boolean. If "true", mail for which a sole intended recipient +cannot be determined will be marked as seen on the server. If "false", +mail for which a sole intended recipient cannot be determined will not be marked +as seen.
+
+

+ +

+ +<recipientnotfound + defer="true" + reject="true" + leaveonserver="true" + markseen="true"/> + +

+ + + +

The recursesubfolders tag declares if mail should be fetched +from sub-folders of the root folder, or just the root folder.

+ +

The tag value is a boolean. If true, mail is fetched from the root folder and +its subfolders. If false, mail is fetched from just the root folder.

+ +

+ +<recursesubfolders>false</recursesubfolders> + +

+ + + +

The remoteReceivedHeader tag declares the zero based +index of the RFC2822 compliant RECEIVED header used to determine the address and +host name of the remote MTA that sent a fetched message and what happens to +messages when the specified header is invalid.

+ +

Typically, the first (index = 0) RECEIVED header is for the local MTA that +delivered the message to the message store and the second (index = 1) RECEIVED +header is for the remote MTA that delivered the message to the local MTA. When +this configuration applies, the remoteReceivedHeaderIndex should +be set to 1. +

+ +

To verify the correct setting, examine the RECEIVED headers for messages +delivered to the configured message store and locate the first one containing a +remote domain in the'from' field. Remembering that zero based indexing is used, +if this the second header, use an index of 1, if this is the third header, use an +index of 2, and so forth.

+ +

Matchers such as InSpammerBlacklist use the remote address and/or remote host +name to identify illegitimate remote MTAs. If you do not use such matchers, the +remoteReceivedHeaderIndex tag may be omitted or the default +index value of -1 can be specified. This causes the remote address to be set to +127.0.0.1 and the remote host name to be set to +localhost. Matchers almost always considered these values to be +legitimate.

+ +

The tag has these attributes: +

+
index
+
An integer whose meaning is described above. +
+
reject
+
A boolean. If "true", mail whose specified recieved header is invalid +will not be injected into the James input spool. If "false", mail whose +specified recieved header is invalid will be injected into the James input spool with +the Mail Attribute org.apache.james.fetchmail.isInvalidReceivedHeader +added to the mail, the remote address set to 127.0.0.1 and the remote +host name set to localhost. +
+
leaveonserver
+
A boolean. If "true", mail whose specified recieved header is invalid +will be left on the server. If "false", mail whose specified recieved header +is invalid will be marked for deletion.
+
markseen
+
A boolean. If "true", mail whose specified recieved header is invalid +will be marked as seen on the server. If "false", mail whose specified +recieved header is invalid will not be marked as seen.
+
+

+ +

+ +<remoteReceivedHeader + index="1" + reject="true" + leaveonserver="true" + markseen="true"/> + +

+ +

An example configuration using James mailet processing to notify the postmaster +of fetched messages that contain an invalid Received header can be found in the file +$PHOENIX_HOME/apps/james/conf/samples/fetchmail/remoteReceivedHeader.xml. +

+ + + +

The remoterecipient tag declares what happens to mail for +which the domain part of the recipient is remote. A domain is remote if it is +not a server declared in the servernames tag of the +James block in the configuration.

+ +

The tag has these attributes: +

+
reject
+
A boolean. If "true", mail for remote recipients will not be +injected into the James input spool. If "false", mail for remote +recipients will be injected into the James input spool with the Mail Attribute +org.apache.james.fetchmail.isRemoteRecipient added to the mail. +
+
leaveonserver
+
A boolean. If "true", mail for remote recipients will be left on +the server. If "false", mail for remote recipients will be marked for +deletion.
+
markseen
+
A boolean. If "true", mail for remote recipients will be marked as +seen on the server. If "false", mail for remote recipients will not be +marked as seen.
+
+

+ +

+ +<remoterecipient + reject="true" + leaveonserver="true" + markseen="true"/> + +

+ + + +

The undeliverable tag declares what happens to mail that +cannot be delivered.

+ +

The tag has these attributes: +

+
leaveonserver
+
A boolean. If "true", mail that cannot be delivered will be left +on the server. If "false", mail that cannot be delivered will be +marked for deletion.
+
markseen
+
A boolean. If "true", mail for that cannot be delivered will be +marked as seen on the server. If "false", mail that cannot be +delivered will not be marked as seen.
+
+

+ +

+ +<undeliverable + leaveonserver="true" + markseen="true"/> + +

+ + + +

The userundefined tag declares what happens to mail for +which the recipient is not defined as a James user.

+ +

The tag has these attributes: +

+
reject
+
A boolean. If "true", mail for recipients who are not defined as +James users will not be injected into the James input spool. If +"false", mail for recipients who are not defined as James users will +be injected into the James input spool with the Mail Attribute +org.apache.james.fetchmail.isUserUndefined added to the mail. +
+
leaveonserver
+
A boolean. If "true", mail for recipients who are not defined as +James users will be left on the server. If "false", mail for +recipients who are not defined as James users will be marked for deletion.
+
markseen
+
A boolean. If "true", mail for recipients who are not defined as +James users will be marked as seen on the server. If "false", mail +for recipients who are not defined as James users will not be marked as seen. +
+
+

+ +

+ +<userundefined + reject="true" + leaveonserver="true" + markseen="true"/> + +

+ + + +

The account tag declares an account on the external server +from which mail should be fetched.

+ +

The tag has these attributes: +

+
user
+
The string to be passed as the user when connecting to the external server. +
+
password
+
The string to be passed as the password when connecting to the external +server.
+
recipient
+
The recipient to whom messages will be delivered when the intended recipient +cannot be determined or when the intended recipient is to be ignored.
+
ignorercpt-header
+
A boolean. If "true", mail is always delivered to the recipient +declared in the recipient attribute above. If +"false", the intended recipient is determined from the mail headers or +the process declared by the recipientnotfound tag. +
+
+

+ +

+ +<account + user="myaccount" + password="mypassword" + recipient="user@localhost" + ignorercpt-header="true"/> + +

+ + + +

The alllocal tag declares the parameters to be applied to +dynamic accounts. The set of dynamic accounts is refreshed each time the fetch +task runs by combining the alllocal tag attributes with each of +the currently defined James users to create an account for every James user.

+ +

The tag has these attributes: +

+
userprefix
+
The string to be added before the James user when constructing the string +passed as the user when connecting to the external server. +
+
usersuffix
+
The string to be added after the James user when constructing the string +passed as the user when connecting to the external server. +
+
password
+
The string to be passed as the password when connecting to the external +server.
+
recipientprefix
+
The string to be added before the James user when constructing the recipient +to whom messages will be delivered when the intended recipient cannot be +determined or when the intended recipient is to be ignored.
+
recipientsuffix
+
The string to be added after the James user when constructing the recipient +to whom messages will be delivered when the intended recipient cannot be +determined or when the intended recipient is to be ignored.
+
ignorercpt-header
+
A boolean. If "true", mail is always delivered to the recipient +constructed from the recipientprefix and +recipientsuffix attributes above and the James user. If +"false", the intended recipient is determined from the mail headers or +the process declared by the recipientnotfound tag. +
+
+

+ +

+ +<alllocal + userprefix="" + usersuffix="@external.domain.com" + password="mypassword" + recipientprefix="" + recipientsuffix="@mydomain.com" + ignorercpt-header="true"/> + +

+ + + +

The property tag declares a name/value pair.

+ +

The tag has these attributes: +

+
name
+
The name of the property. +
+
value
+
The value of the property.
+
+

+ +

+ +<property + name="mail.pop3.connectiontimeout" + value="180000"/> + +

+ + +
+ +
+

Full sources to the examples discussed below can be found in the directory +$PHOENIX_HOME/apps/james/conf/samples/fetchmail.

+ + +

When all mail for an account is to be delivered to a single user, +configure each account to ignore the recipient in the mail headers and deliver +to the specified recipient. The accounts block looks like +this:

+ +

+ +<accounts> + <account + user="user1@external.domain.com" + password="password1" + recipient="user1@localhost" + ignorercpt-header="true"/> + + <account + user="user2@external.domain.com" + password="password2" + recipient="user2@localhost" + ignorercpt-header="true"/> + + <account + user="user3@external.domain.com" + password="password3" + recipient="user3@localhost" + ignorercpt-header="true"/> +</accounts> + +

+ + + +

When an account contains mail to be delivered to many users, configure each +account to determine the recipient from the mail headers and deliver to that +user. The accounts block looks like this:

+ +

+ +<accounts> + <account + user="global@external.domain.com" + password="password" + recipient="fetchmail@localhost" + ignorercpt-header="false"/> +</accounts> + +

+ +

The recipientnotfound tag is used to declare what happens +when the recipient cannot be determined from the mail headers. In the example +below, mail is injected into the spool using the recipient declared in the +account tag:

+ +

+ +<recipientnotfound + defer="false" + reject="false" + leaveonserver="false" + markseen="false"/> + +

+ + + +

When an external server supports virtual mailboxes, fetchmail's dynamic +account facility can be used. This greatly simplifies user configuration as +the fetchmail accounts for users are automatically synchronized with those +defined in the James user repository. This guarantees that mail for all local +users will be fetched and delivered.

+ +

Currently, there is a limitation that all virtual accounts and the global +account must share the same password.

+ +

The alllocal tag declares the parameters for the dynamic +accounts. The accounts block below will deliver mail for +user1@external.domain.com to user1@localhost, +user2@external.domain.com to user2@localhost, +userZ@external.domain.com to userZ@localhost etc.:

+ +

+ +<accounts> + <alllocal + userprefix="" + usersuffix="@external.domain.com" + password="mypassword" + recipientprefix="" + recipientsuffix="@localhost" + ignorercpt-header="true"/> +</accounts> + +

+ + + +

The +One Account, One User - Dynamic +example guarantees delivery of mail for all local users, but leaves other mail +on the external server unprocessed. The +One Account, Many Users example +processes all mail on the external server, but cannot guarantee delivery to the +intended recipient. By combining the two, it is possible to guarantee the +delivery of mail for all local users and process all mail.

+ +

In the snippet below, the alllocal tag declares dynamic +accounts for all local users and the account tag configures an +account to fetch all mail.

+ +

The recipientnotfound tag rejects mail for which a recipient +cannot be determined. By the time this processing is activated, the dynamic +accounts will have processed mail for all local users, so the mail can +only be mail for non-local users or newly arrived mail for local users. It is +not possible to know which, but we want to leave mail for local users to be +dealt with by the dynamic accounts. The next time the dynamic accounts run any +newly arrived mail for local users will be processed. The remainder will be for +non-local users and can now be safely dealt with.

+ +

The <recipientnotfound defer="true" attribute +enables deferal of the processing of messages for which the recipient cannot be +determined to the next iteration of the fetch task, and is used here. The +relevant tags are:

+ +

+ +<accounts> + <alllocal + userprefix="" + usersuffix="@external.domain.com" + password="mypassword" + recipientprefix="" + recipientsuffix="@localhost" + ignorercpt-header="true"/> + + <account + user="global@external.domain.com" + password="password" + recipient="fetchmail@localhost" + ignorercpt-header="false"/> +</accounts> + +<recipientnotfound + defer="true" + reject="true" + leaveonserver="true" + markseen="true"/> + +

+ + +
+ +
+

These are some things to be aware of when using fetchmail: +

    +
  • As noted in the +One Account, One User - Dynamic +example, all virtual accounts and the global account must share the same +password. A future version might associate each James user to a set of account +credentials. +
    • + +
  • When using dynamic accounts, an account is generated and an attempt made to +fetch mail for all James users defined to James even if there is no such mailbox +on the server. This is inefficient but not fatal. The solution is the same as +described above. +
    • + +
  • When using dynamic accounts, as described in the +One Account, Many Users - Dynamic +example, the user name used to fetch the mail for all accounts must not be +defined as a James user. If it is, a dynamic account will be generated for it +and fetch all the mail before the account declared to process mail for all users +has an opportunity to run! +
    • + +
  • The now deprecated fetchPOP interacted with the FetchedFrom +matcher to detect mail injected by fetchPOP. This will not work with fetchmail. +Compared to fetchPOP, there are far fewer occasions when mail injected by +fetchmail requires special processing. When it does, use the HasMailAttribute +matcher to match the attribute named +org.apache.james.fetchmail.taskName to detect all mail injected by +fetchmail. To detect mail injected by a specific fetch task, use one of the +HasMailAttributeWithValue matchers to match on the attribute name and the +attribute value. The attribute value is the name of the fetch task that +injected the mail. +
    • + +
  • The POP3 protocol does not enforce support of any of the Flags associated +with messages other than DELETED. This means that +markseen="true" will most likely have no effect and +therefore, the fetchall tag will be inoperative. In this +situation, the only way to avoid repeatedly fetching the same mail is to delete +it from the server using leaveonserver="false"/>. +
    • +
+

+
+ + + + + diff --git a/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml b/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml new file mode 100644 index 00000000000..08bc7a5448d --- /dev/null +++ b/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml @@ -0,0 +1,105 @@ + + + + + + James 2.1 - Configuring FetchPOP + + + +
+

FetchPOP is being deprecated. +fetchMail provides a superset of +FetchPOP's functionality and is the preferred solution.

+
+ +
+

FetchPOP is controlled by a configuration block in the config.xml. +The fetchpop tag defines the boundaries of the configuration block. It encloses +all the relevant configuration for the FetchPOP scheduler. The behavior of the POP service is +controlled by the attributes and children of this tag.

+

This tag has an optional boolean attribute - enabled - that defines whether +the service is active or not. The value defaults to "false" if not present.

+

The only permitted children of the fetchpop tag are fetch elements. Each of +these fetch tags defines a single FetchPOP task.

+

The fetch tag has a single required attribute, name. The name +of each FetchPOP task must be unique.

+

In addition to the name attribute, the fetch tag has four +children, all of which are required.

+
    +
  • host - The host name or IP address of the POP3 server hosting the mail to be fetched.
    • +
  • user - The user name of the account whose mail is to be fetched.
    • +
  • password - The password for the account whose mail is to be fetched.
    • +
  • interval - A non-negative integer representing the number of milliseconds between fetches.
    • +
+
+
+

There are a number of issues which have to be considered when handling fetched mail, such as avoiding circular +routing of mail. Some scenarios are described below with suggested configurations.

+ + +

This is the intended primary use of FetchPOP. +If all mail for a domain being fetched is ultimately being handled by this server then it is enough to add +the domain name as a servername to the servernames section described here. +
This is the simplest solution and is used where James is being used to redistribute all mail from the +free catch-all POP accounts provided by many domain registration/hosting companies.

+ + +

If only part of a domain's mail (perhaps only a single user's POP account) is being handled by this instance +of James it is important that outgoing mail addressed to this domain that is not intended for James be properly delivered.

+

To enable this filtering the FetchPOP scheduler adds a header, X-fetchedby, to the fetched message. This header can be checked using +the provided matcher FetchedFrom. This matcher can be used to direct fetched mail to a processor set up +to handle mail fetched from one or more POP3 accounts. The matcher should be used exactly once in the mail +pipeline for each FetchPOP task, as the matcher removes a matching header to prevent outgoing replies or +redirections from looping.

+

The FetchedFrom matcher is configured with the name of the particular FetchPOP task it is supposed to match. In general, +this matcher will be used to direct mail to a custom processor for further processing. A mailet tag such as the +following

+ +<mailet match="FetchedFrom=fetchtaskname" class="ToProcessor">
+<processor>fetchprocessor</processor> +</mailet> + +

where fetchtaskname is the name of the FetchPOP task being matched and fetchprocessor is the name of the fetched mail +processor can be used to this purpose. The fetched mail processor should contain mailets which will filter +and forward mail to real local or remote users. This can be achieved in the usual fashion as described in the +SpoolManager configuration section and in the out of the box +configuration file.

+ + +

It is important to note that this first version of FetchPOP does not access the original intended recipient +address of the mail, but instead uses the To: address from the message headers. Since this header may contain an +alias for the intended recipient, or may never have contained the intended recipient address (it could have been +in the Cc: or Bcc: fields) it is possible that James will be unable to deliver the fetched mail. It is intended +that this behaviour be addressed in the next version of James, but in the meantime a catch-all forwarding of +locally undeliverable fetched mail is recommended.

+

To handle messages where the intended recipient can be determined but is not present in the To: header, the FetchedFrom +matcher can be used. Place a mailet tag with this matcher between the "RecipientIsLocal" and "HostIsLocal" in the +Transport processor as defined in the out of the box configuration. The mailet tag should be configured to use the +provided ToProcessor mailet to direct fetched mail to a custom processor. Thus all mail fetched by FetchPOP that +could not be trivially mapped to a local user account will undergo further processing, allowing more complex +delivery handling.

+

For safety the All matcher should be used at the end of your custom fetched mail processor. This can be used to +catch all mail not handled by previous mailets in the processor. This will enable you to ensure that your +configuration is correct and that any mail not correctly delivered is available for examination by the postmaster.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/index.xml b/server/2.2.0/src/site/xdoc/index.xml new file mode 100644 index 00000000000..837d82d68a1 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/index.xml @@ -0,0 +1,104 @@ + + + + + + James 2.1/2.2 - Table of Contents + + + +
+

+The Java Apache Mail Enterprise Server (a.k.a. Apache James) is a 100% pure Java SMTP and POP3 Mail +server and NNTP News server designed to be a complete and portable enterprise mail engine +solution. James is based on currently available open protocols. +

+

+The James server also serves as a mail application platform. The James project hosts the Apache Mailet API, +and the James server is a Mailet container. This feature makes it easy to design, write, and deploy +custom applications for mail processing. This modularity and ease of customization is one of James' +strengths, and can allow administrators to produce powerful applications surprisingly easily. +

+

+James is built on top of version 4.1.3 of the Avalon Application Framework. This +framework encourages a set of good development practices such as Component Oriented Programming and +Inversion of Control. The standard distribution of James includes version 4.0.1 of the +Phoenix Avalon Framework container. This stable +and robust container provides a strong foundation for the James server. +

+

+This documentation is intended to be an introduction to the concepts behind the James implementation, as well +as a guide to installing, configuring, (and for developers) building the James server. +

+ +

+I. James Concepts +

+II. How To Build James + +III. How To Install James + +IV. Configuring James + +V. Common Configurations + +VI. Customizing James + +V. Other Information + +

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/installation_instructions.xml b/server/2.2.0/src/site/xdoc/installation_instructions.xml new file mode 100644 index 00000000000..771619dfba6 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/installation_instructions.xml @@ -0,0 +1,110 @@ + + + + + + James 2.1 - Installation + + +
+

James requires a Java Runtime Environment of Java version 1.3 or higher installed to run the +James application. The exact JREs available depend on the platform. A JRE must be downloaded and +installed before James can run. In addition, the environment variable JAVA_HOME must be set to +the JRE home directory before running James.

+

+Warning! - Issues have been observed when using Sun's Java 1.3.0 on older Linux +distributions. It is recommended that users of these platforms run James using a more recent +Sun JRE or a JRE produced by an alternate vendor. +

+

+On Unix platforms, root access will be required to run James. On these platforms, access to ports +below 1024 is generally restricted to the root user. As SMTP, POP3, and NNTP all need to open +server sockets on such ports in standard configurations, James requires root access. +

+

+Obviously James also requires sufficient disk space, processor power, and network bandwidth. But, +other than what's been discussed here, it has no additional special requirements.

+
+
+

James installation involves a number of steps, each of which is described in some detail in the +following sections. But as this sequence of steps has confused some users in the past, additional +comments seem warranted.

+

It is important to realize that the James configuration files are not unpacked from the James +distribution until the first time James is started. This is a consequence of the design of the +Avalon Phoenix container used to run James. Once James has been started, the distribution will +be unpacked. The server should be stopped, the configuration files edited, and the server restarted.

+

So the installation sequence is: 1) Start, 2) Stop, 3) Edit, 4) Restart.

+
+
+ +

Obtain the full James binary distribution from the James +release mirrors. Unpack the archive into your James installation directory. Go to the bin subdirectory of the +installation directory and run the "run" script (either run.sh or run.bat, depending on your platform). The configuration +file is now unpacked and available for editing.

+ + +

Warning! - James requires Phoenix version 4.0.x to run. There is a known issue with logging in Phoenix 4.0, so version +4.0.1 or higher is strongly recommended. Before attempting to deploy James in a Phoenix container, please make sure +it meets these version criteria.

+

Deploying James in Phoenix is fairly easy. Obtain the james.sar file from the James +release mirrors. It can be found in the "Other Binaries" +area of the distribution directory. After downloading the james.sar, +simply place it in the apps subdirectory of your Phoenix installation. Restart Phoenix, and the james.sar should unpack and you +will be ready to configure your James installation.

+ +
+ +
+

+After installing the binary, the next step is to adjust the initial configuration. The server should be stopped, and then +configuration can proceed. The most essential configuration is set in the config.xml file. This file can be +found in the apps/james/SAR-INF subdirectory of the installation directory.

+

The out of the box configuration makes certain assumptions and has some default values that are unlikely to +be appropriate for real-world servers. There are a few issues that should be addressed immediately upon installation: +

+
    +
  • RemoteManager Administrator Account - Before the RemoteManager service can be used to add users to this server +installation an administrator account must be created. More information can be found here.
    • +
  • DNS Servers - James needs to have access to a DNS server for domain resolution. The out of the box +configuration assumes that there is a DNS server on localhost. In general administrators will have to change +the configuration to point to a valid DNS server. This can be done by adjusting the dnsserver configuration +block in the config.xml. More information can be found here.
    • +
  • Managed Domain Names/IP Addresses - Out of the box, James only handles mail that is sent to recipients at +localhost. It will attempt to deliver all other email to remote SMTP servers. To allow James to handle email +for your domain or IP address, you simply need to add the appropriate domain name or IP address to the servernames +section of the config.xml. More information can be found here.
    • +
  • Postmaster Address - More information can be found here.
    • +
+

In addition to adjusting these parameters, you may wish to consult the documentation for a discussion of +common configurations. A list of such configurations, as well as the steps necessary to configure them, can +be found here.

+
+
+

Once you have edited the configuration file you will need to restart James so that the changes take +effect. When James starts, a list of the James services and the ports on which they are listening should +be displayed on the console. Additional information about the system configuration is printed in the James log files +upon startup.

+

Finally, after configuration is complete, it will be necessary to create user accounts before the James server +will be fully operational. Instructions on creating user accounts can be found +here.

+
+ + + diff --git a/server/2.2.0/src/site/xdoc/james_and_sendmail.xml b/server/2.2.0/src/site/xdoc/james_and_sendmail.xml new file mode 100644 index 00000000000..067a7f4d755 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/james_and_sendmail.xml @@ -0,0 +1,124 @@ + + + + + + Sendmail integration + Danny Angus + + + + +
+ +

+ This document explains how to configure sendmail to route all mail generated by /usr/sbin/sendmail or local mail on a host through James on the same host, including mail to local addresses without @host.
+ All sendmail configuration file locations are for Redhat Linux 7.2, other installations may have different locations.
+ We take no responsibility for the quality of the information in this document.
You should back-up any configuration files *before* you alter them. +

+
+ +
+ +

+Ok so you want to use James for everything, including delivering mail from localhost to local users.
+Well the first step is to stop sendmail from starting up as the SMTP Daemon on port 25, otherwise it will route mail to itself and who knows what will happen then.
+Open the sendmail configuration file /etc/sysconfig/sendmail +Change the line:DAEMON=yesintoDAEMON=no +Restart sendmail with:[root@apache root]# /etc/rc.d/init.d/sendmail restartThis will make sendmail process its outgoing queue, but not listen on port 25 for incoming mail. +

+ + +

+Ok, so far so good, now you need to tell sendmail to relay everything, regardless of its rules, through James. James will take the roles of "local relay" (destination for all unqualified local addresses), "mail hub" (destination for all qualified local addresses) and "smart relay" (destination for all other mail) for this instance of sendmail, thereby catching everything.
+So open /etc/sendmail.cf and.. +

    +
  • Look for the line beginning DS make this line DSesmtp:localhost
    • +
  • Look for the line beginning DR make this line DResmtp:localhost
    • +
  • Look for the line beginning DH make this line DHesmtp:localhost
    • +
+Now that wasn't too hard was it?
+What we have done is to tell sendmail to use its "mailer" called esmtp to relay mail using ESMTP to localhost for each role.
+Of course no-one in their right mind would relay mail to localhost, because it would loop forever right? +

+ + + +

+The developers of sendmail have, wisely, built sendmail in such a way as to prevent, by default, mail being sent by sendmail back to itself, this is done by making a quick check on outgoing mail to see if its destination is our machine. If it is you'll see this message config error: mail loops back to me when you try to send mail.
+But we *want* to relay mail to localhost, and because sendmail isn't receiving our mail, James is, we won't be creating a loop. (make sure you've followed step one though).
+So open /etc/sendmail.cf again and go to the bottom of the file, start scrolling upwards until you see the declaration of the esmtp mailer it'll look something like this + +Mesmtp, P=[IPC], F=mDFMuXa, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990, + T=DNS/RFC822/SMTP, + A=TCP $h + +You need to change it so its more like this: :-D + +Mesmtp, P=[IPC], F=kmDFMuXa, S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP, E=\r\n, L=990, + T=DNS/RFC822/SMTP, + A=TCP $h + +But seriously, we've added a k to the "F=" list F=mDFMuXa becomes F=kmDFMuXa
+And again, thats it, sendmail will now skip the loopback test on mail leaving through the esmtp mailer. +

+

Now you have to make some tests.
Try each of the following, replace names in [] with names of the kind described. +/[root@apache root]# mail -v [real-localusername] + +[root@apache root]# mail -v [nonexistant-localusername] + +[root@apache root]# mail -v [real-localusername]@localhost + +[root@apache root]# mail -v [real-localusername]@[myhostname.mydomainname] + +[root@apache root]# mail -v [real-username]@[real-remote-account] + +Sendmail echoes each conversation to STDOUT so you can see what its trying to do with each mail.
+

+ + + +

+SMTP AUTH is a different Kettle of Fish.
+The scenario is that you're using SMTP AUTH on James to restrict SMTP relaying to authenticated users, allowing them to connect from any IP address but still not letting James become an open relay for spam, cool.
+However you now want to let sendmail relay through James, so you need to tell it how to authenticate.
+So open /etc/sendmail.cf again and this time.. +

    +
  • Look for the line beginning O AuthMechanisms= If this line is commented out with a leading #, remove the # then make sure LOGIN and PLAIN are at the beginning of this line like this O AuthMechanisms=LOGIN PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5
    • +
  • Look for the line beginning O DefaultAuthInfo= If this line is commented out with a leading #, remove the # then make this line O DefaultAuthInfo=/etc/mail/default-auth-info
    • +
  • Create a user account on James for sendmail to login as.
    • +
  • Create the file /etc/mail/default-auth-info
    • +
  • It should contain thisusername +username +password +localhostYes the username appears twice.
    • +
  • Replace username and password with the details of the account you just created.
    • +
  • This file has to be chmod'ed 600 (-rw------) or sendmail won't read it.
    • +
  • Look for the line beginning O AuthOptions= If this line is commented out with a leading #, remove the # and it should be O AuthOptions=A
    • +
+ +

Ta-da!

Now you're ready to run the tests in Step3, all of the mail should be accepted, the most likely rejection will be the final one. +

+ +

Thats it, good luck and happy mailing :)
Danny Angus

+
+ + + diff --git a/server/2.2.0/src/site/xdoc/mailet_api.xml b/server/2.2.0/src/site/xdoc/mailet_api.xml new file mode 100644 index 00000000000..489ab7e6401 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/mailet_api.xml @@ -0,0 +1,51 @@ + + + + + + James 2.1 - Mailet API + + + +
+

The Mailet API is a simple API used to build mail processing applications. James is a Mailet +container, allowing administrators to deploy Mailets (both custom and pre-made) to carry out a +variety of complex mail processing tasks. In the default configuration James uses Mailets to carry +out a number of tasks that are carried out deep in the source code of other mail servers (i.e. list +processing, remote and local delivery).

+

+As it stands today, the Mailet API defines interfaces for both Matchers and Mailets.

+

Matchers, as their name would suggest, match mail messages against certain conditions. They +return some subset (possibly the entire set) of the original recipients of the message if there +is a match. An inherent part of the Matcher contract is that a Matcher should not induce any changes +in a message under evaluation.

+

Mailets are responsible for actually processing the message. They may alter the message in any fashion, +or pass the message to an external API or component. This can include delivering a message to its destination +repository or SMTP server.

+

The Mailet API is currently in its second revision. Although, the Mailet API is expected to undergo substantial changes in the near future, it is our aim that existing Mailets that abided purely by the prior Mailet API interfaces will continue to run with the revised specification.

+ +

James bundles a number of Matchers and Mailets in its distribution. Descriptions of provided matchers +can be found here, while descriptions of provided mailets can be found +here.

+
+ + diff --git a/server/2.2.0/src/site/xdoc/mailing_lists.xml b/server/2.2.0/src/site/xdoc/mailing_lists.xml new file mode 100644 index 00000000000..ffdbb7515bf --- /dev/null +++ b/server/2.2.0/src/site/xdoc/mailing_lists.xml @@ -0,0 +1,115 @@ + + + + + James 2.1 - Creating Mailing Lists + + + +
+

One of the frequent questions on the James-User Mailing List is how +to create a mailing list. This document explains one way of using the +currently supplied Matchers and Mailets in James v2.1.

+ +

Basically, the process requires creating two <mailet> entries +and a repository. The first mailet handles list commands (currently +only list-name-on and list-name-off). The second mailet +handles list messages. The repository will hold the e-mail addresses +of list subscribers.

+ +

The mailets go into the processor chain (e.g., at the top of the +transport processor), the repository goes into the +<users-store> block.

+ + + +

You need to setup two mailets.

+ +

The first mailet that you need to setup is an instance of the Avalon Listserv +Manager mailet. This will handle subscribing and unsubscribing. +[Note: the current code does not support confirmed opt-in, just basic +commands.] The CommandForListserv +matcher is used to invoke match messages containing commands for the +mailing list.

+ +

The second mailet is an instance of the Avalon Listserv +mailet. That mailet actually receives messages for the list and +causes them to be distributed. The RecipientIs matcher +is used to match messages intended for the mailing list.

+ +

The following illustrates the two <mailet> elements that need to be added:

+ + + <mailet match="CommandForListserv=list-name@domain" + class="AvalonListservManager"> + <repositoryName>list-name</repositoryName> + </mailet> + + <mailet match="RecipientIs=list-name@domain" class="AvalonListserv"> + <repositoryName>list-name</repositoryName> + ... list options ... + </mailet> + + + + + + +

The mailing list mailets need a repository within which to store +the subscriber list. There is a separate repository for each mailing +list, and is completely independent of the user repository used by +James to manage e-mail accounts. This is configured in the +<users-store> block of config.xml.

+ +

The following illustrates a database-backed repository using JDBC +with the ListUsersJdbcRepository class. Notice that there will be a +single table, lists, created in the db://maildb resource +defined elsewhere. There are currently two columns: the list name and +the list subscriber.

+ + + <repository name="list-name" + class="org.apache.james.userrepository.ListUsersJdbcRepository" + destinationURL="db://maildb/lists/list-name"> + <sqlFile>file://conf/sqlResources.xml</sqlFile> + </repository> + + +

The following illustrates a file-system repository using the +UsersFileRepository class. [Note: the destination URL is a child +element when configuring a file-system repository, and an attribute +when configuring a database-backed repository. This inconsistency +will be addressed in a future version of James.]

+ + + <repository name="list-name" + class="org.apache.james.userrepository.UsersFileRepository"> + <destination URL="file://var/lists/list-name/" /> + </repository> + + + +
+ + diff --git a/server/2.2.0/src/site/xdoc/nntp_configuration.xml b/server/2.2.0/src/site/xdoc/nntp_configuration.xml new file mode 100644 index 00000000000..97ef95efe48 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/nntp_configuration.xml @@ -0,0 +1,98 @@ + + + + + + James 2.1 - Configuring the NNTP Service + + + +
+

The NNTP service is controlled by a two configuration blocks in the config.xml. These are the nntpserver block and the nntp-repository block.

+ +

The nntpserver tag defines the boundaries of the configuration block. It encloses +much of the relevant configuration for the NNTP server.

+ +

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if +not present.

+

The standard children of the nntpserver tag are:

+
    +
  • port - This is an optional integer value. This value is the port on which this NNTP server is configured +to listen.If the tag or value is omitted, the value will default to the standard NNTP port, 119.
    • +
  • bind - This is an optional value. If present, this value is a string describing +the IP address to which this service should be bound. If the tag or value is absent then the service +will bind to all network interfaces for the machine.
    • +
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" +server socket factory is used to generate the server socket for this service. If it is false, the +"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType +tag which is described under the expert configuration options.
    • +
  • handler - This is an artifact preserved for backwards compatibility. This tag +was used to group related parameters. It should disappear in future versions.
    • +
      +
    • helloName - This is a required tag with an optional body that defines the server name +used in the initial service greeting. The tag may have an optional attribute - autodetect. If +the autodetect attribute is present and true, the service will use the local hostname +returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In +this case, if no body is present, the value "localhost" will be used.
      • +
    • connectionTimeout - This is an optional tag with a non-negative integer body.
      • +
    • authRequired - This is an optional tag with a boolean body. If true, then the server will +require authentication before allowing the client to view news articles. If this tag is absent, or the value +is false then the client will not be prompted for authentication. Only simple user/password authentication is +supported at this time.
      • +
    +
+

There are a few additional children of the nntpserver tag that are appropriate for advanced +configurations. These should only be used by expert administrators. All tags in this group are optional.

+
    +
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the server socket factories specified in the socket manager block. Any other +value will result in an error. If present, this tag overrides the useTLS tag.
    • +
  • threadGroup - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the thread groups specified in the thread manager block. Any other +value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • +
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client +connections that this service will allow. If no value is specified, the value defaults to that specified in +the connectionmanager block. A value of 0 means that there is no limit imposed +by the service, although resource limitations imposed by other components +(i.e. max # of threads) may serve to limit the number of open connections.
    • +
+ + +The remainder of the NNTP service configuration is controlled by the nntp-repository configuration block. This +section of configuration data relates to the server-side NNTP article repository. +
    +
  • readOnly - This is a required boolean tag. If the value is true, posting will not be +permitted by the NNTP server.
    • +
  • rootPath - This is a required string tag. It must be in the form of a URL with a "file:" prefix. This +specifies the root directory for the NNTP repository. Groups hosted on the NNTP server will be represented as +folders under this root, and articles will be stored in the appropriate folders.
    • +
  • tempPath - This is a required string tag. It must be in the form of a URL with a "file:" prefix. This +specifies the directory where the NNTP server will store posted articles before they are added to the spool.
    • +
  • articleIDPath - This is a required string tag. It must be in the form of a URL with a "file:" prefix. This +specifies the directory where the NNTP server will store the mappings between article ID and the groups containing that article.
    • +
  • articleIDDomainSuffix - This is a required string tag. It is the suffix appended to all article IDs generated +by this NNTP server.
    • +
  • newsgroups - This is a required container tag. It has a single newsgroup child for each newsgroup +hosted on the server. The body of each of those newsgroup tags is the name of the newsgroup.
    • +
+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/pop3_configuration.xml b/server/2.2.0/src/site/xdoc/pop3_configuration.xml new file mode 100644 index 00000000000..2cc037aa6a7 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/pop3_configuration.xml @@ -0,0 +1,74 @@ + + + + + + James 2.1 - Configuring the POP3 Service + + + +
+

The POP3 service is controlled by a configuration block in the config.xml. +The pop3server tag defines the boundaries of the configuration block. It encloses +all the relevant configuration for the POP3 server. The behavior of the POP service is +controlled by the attributes and children of this tag.

+ +

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if +not present.

+

The standard children of the pop3server tag are:

+
    +
  • port - This is an optional integer value. This value is the port on which this POP3 server is configured +to listen.If the tag or value is omitted, the value will default to the standard POP3 port, 110.
    • +
  • bind - This is an optional value. If present, this value is a string describing +the IP address to which this service should be bound. If the tag or value is absent then the service +will bind to all network interfaces for the machine.
    • +
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" +server socket factory is used to generate the server socket for this service. If it is false, the +"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType +tag which is described under the expert configuration options.
    • +
  • handler - This is an artifact preserved for backwards compatibility. This tag +was used to group related parameters. It should disappear in future versions.
    • +
      +
    • helloName - This is a required tag with an optional body that defines the server name +used in the initial service greeting. The tag may have an optional attribute - autodetect. If +the autodetect attribute is present and true, the service will use the local hostname +returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In +this case, if no body is present, the value "localhost" will be used.
      • +
    • connectionTimeout - This is an optional tag with an integer body.
      • +
    +
+

There are a few additional children of the pop3server tag that are appropriate for advanced +configurations. These should only be used by expert administrators. All tags in this group are optional.

+
    +
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the server socket factories specified in the socket manager block. Any other +value will result in an error. If present, this tag overrides the useTLS tag.
    • +
  • threadGroup - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the thread groups specified in the thread manager block. Any other +value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • +
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client +connections that this service will allow. If no value is specified, the value defaults to that specified in +the connectionmanager block. A value of 0 means that there is no limit imposed +by the service, although resource limitations imposed by other components +(i.e. max # of threads) may serve to limit the number of open connections.
    • +
+
+ + diff --git a/server/2.2.0/src/site/xdoc/provided_mailets.xml b/server/2.2.0/src/site/xdoc/provided_mailets.xml new file mode 100644 index 00000000000..33c677961b7 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/provided_mailets.xml @@ -0,0 +1,253 @@ + + + + + + James 2.1 - Provided Mailets + + + + +
+ +

James provides a number of implemented Mailets for use by James administrators in their +configurations. These are primarily mailets that members of the James developer or user +communities have found useful in their own configurations. A description of how to configure +Mailets and use them in the James SpoolManager can be found here.

+ + +

Description: This mailet adds a text footer to the message.

+

Parameters: +

    +
  • text (required) - the text that will be added as a footer to the message.
    • +
+

+ + +

Description: This mailet adds a Habeas warrant mark (see http://habeas.com for details) to the message.

+

Parameters: None.

+ + +

Description: This mailet adds a text header to the message.

+

Parameters: +

    +
  • name (required) - the name of the header to be added to the message.
    • +
  • value (required) - the text that will be added as a header to the message.
    • +
+

+ + +

Provides basic list server functionality. Implements basic filters for emails sent to the list, +including restriction of senders to members, diallowing attachments in list messages, and subject line +processing

+

Parameters: +

    +
  • repositoryName (required) - the name of the user repository that contains the users +for this list.
    • +
  • membersonly (optional) - whether only members of the list can send messages to this +list. Defaults to false.
    • +
  • attachmentsallowed (optional) - whether attachments are allowed in messages sent to this +list. Defaults to true.
    • +
  • replytolist (optional) - whether the reply-to address for all messages sent to this +list is set to the list address. Defaults to true.
    • +
  • subjectprefix (optional) - a String value. If set, this value is prepended to the subject +line of all messages sent to the list.
    • +
  • autobracket (optional) - a boolean value. If a subjectprefix is set, this value determines +whether the prefix is bracketed before being prepended to the subject line. Defaults to true.
    • +
+

+ + +

Processes list management commands of the form <list-name>-on@<host> and +<list-name>-off@<host> where <list-name> and lt;host> are arbitrary. Note +that this should be used in tandem with a CommandForListserv matcher to ensure that only commands +intended for a specific list are processed.

+

Parameters: +

    +
  • repositoryName (required) - the name of the user repository that contains the users +for this list.
    • +
+

+ + +

Description: This mailet forwards the message to a set of recipients.

+

Parameters: +

    +
  • forwardto (required) - a comma delimited list of email addresses.
    • +
+

+ + +

Description: This mailet does alias translation for email addresses stored in a database table.

+

Parameters: +

    +
  • mappings (required) - a URL of the form db://<data-source>/<table>, where +<table> is the table in the database containing the alias info and <data-source> is the name +of the data-source in config.xml that is to be used.
    • +
  • source_column (required) - the column containing the aliases.
    • +
  • target_column (required) - the column containing the alias targets.
    • +
+

+ + +

Description: This mailet does complex alias translation for email addresses stored in a database table.

+

Parameters: +

    +
  • table (required) - the URL describing the database table. This URL has the form +db://<data-source>/<table> where <data-source> and <table> are the names of +the data-source as defined in config.xml and the table in the database.
    • +
  • sqlquery (optional) - the text of the SQL query used by the mailet to do user +lookup. The default is "select VirtualUserTable.target_address from VirtualUserTable, VirtualUserTable as VUTDomains where (VirtualUserTable.user like ? or VirtualUserTable.user like '\\%') and (VirtualUserTable.domain like ? or (VirtualUserTable.domain like '\\%' and VUTDomains.domain like ?)) order by concat(VirtualUserTable.user,'@',VirtualUserTable.domain) desc limit 1"
    • +
+

+ + +

Description: This mailet delivers messages to local mailboxes.

+

Parameters: None.

+ + +

Description: This mailet forwards the message as an attachment to the James postmaster.

+

Parameters: +

    +
  • sendingAddress (optional) - the address from which the forwarded email will be +sent. Defaults to the postmaster address.
    • +
  • notice (optional) - the text message that will accompany the forwarded message. Defaults +to "We were unable to deliver the attached message because of an error in the mail server."
    • +
  • attachStackTrace (optional) - whether an error stack trace is attached to the forwarded message.
    • +
+

+ + +

Description: This mailet forwards the message as an attachment to the original sender.

+

Parameters: +

    +
  • sendingAddress (optional) - the address from which the forwarded email will be +sent. Defaults to the postmaster address.
    • +
  • notice (optional) - the text message that will accompany the forwarded message. Defaults +to "We were unable to deliver the attached message because of an error in the mail server."
    • +
  • attachStackTrace (optional) - whether an error stack trace is attached to the forwarded message.
    • +
+

+ + +

Description: This mailet ends processing for this mail.

+

Parameters: None.

+ + +

Description: Intercepts all mails addressed to postmaster@<domain> where <domain> is one +of the domains managed by this James server and substitutes the configured James postmaster address for +the original recipient address. This mailet is inserted automatically by James at the head of the root +processor.

+

Parameters: None.

+ + + +

Description: A mailet providing powerful, configurable redirection services.
+ This mailet can produce listserver, forward and notify behaviour, with the + original message intact, attached, appended or left out altogether.
+ This built in functionality is controlled by the configuration as described + here.

+

It is also intended to be easily subclassed to make providing bespoke redirection + mailets simple.
+ By extending it and overriding one or more of its methods new behaviour can + be quickly created without the author having to address any other issue than + the relevant one. For more information see the javadocs + here.

+

Parameters: See javadocs.

+ + + +

Manages delivery of messages to recipients on remote SMTP hosts.

+

Parameters: +

    +
  • outgoing (required) - The URL for the repository that will hold messages being processed +by the RemoteDelivery Mailet.
    • +
  • delayTime (optional) - a non-negative Long value that is the time in +milliseconds between redelivery attempts for a particular mail. Defaults to six hours.
    • +
  • maxRetries (optional) - a non-negative Integer value that is number of times +the Mailet will attempt to deliver a particular mail. Defaults to five.
    • +
  • timeout (optional) - The SMTP connection timeout for SMTP connections generated +by this Mailet. Defaults to 60 seconds.
    • +
  • deliveryThreads (optional) - The number of threads this Mailet will use to generate +SMTP connections.
    • +
  • gateway (optional) - The host name of the SMTP server +to be used as a gateway for this server. If this value is set, then all +messages will be delivered to the gateway server, regardless of recipient +address. To specify more than one gateway server, add multiple gateway tags, +each containing one value. If more than one server is specified, they will be +tried in order until one is successful. In addition the port may be specified +for each gateway in the format <host>:<port>. If this +value is unset, delivery will occur to SMTP servers resolved by MX lookup.
    • +
  • gatewayPort (optional) - The default port number of the +SMTP server to be used as a gateway for this server. This value will be +employed when a gateway is set and the gateway value does not specify +a port as described above.
    • +
  • bind (optional) - If present, this value is a string +describing the local IP address to which the mailet should be bound while +delivering emails. If the tag is absent then the service will bind to the +default local address of the machine. This tag is useful for multihomed machines.
    +Note: Currently you must use the same IP address for all of those RemoteDelivery +instances where you explicitly supply a bind address.
    • +
  • debug (optional) - a boolean value (true/false) indicating whether debugging is +on. Defaults to false.
    • +
+

+ + +

Description: This mailet sends a message to the sender of the original mail message with a server timestamp.

+

Parameters: None.

+ + +

Redirects processing of the mail message to the specified processor.

+

Parameters: +

    +
  • processor (required) - the name of the processor to which the message +is to be redirected.
    • +
  • noticeText (optional) - a String value that, if present, +is set as the error message of the redirected message. If this value is not +present, no error message is set.
    • +
+

+ + +

Places a copy of the message in the specified repository.

+

Parameters: +

    +
  • repositoryPath (required) - the URL of the repository to which the message +is to be added.
    • +
  • passThrough (optional) - a boolean value (true/false) indicating whether +processing should continue on the message is on. If false, the original message is GHOSTed. Defaults to false.
    • +
+

+ + +

Description: Ignores the recipients associated with the Mail interface. Instead, it regenerates the +mail recipients from the MimeMessage headers (To, Cc, Bcc) and inserts a new message at the queue root +these new recipients. The original message is GHOSTed.

+

Parameters: +

    +
  • debug (optional) - a boolean value (true/false) indicating whether debugging is +on. Defaults to false.
    • +
+

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/provided_matchers.xml b/server/2.2.0/src/site/xdoc/provided_matchers.xml new file mode 100644 index 00000000000..9c461636aff --- /dev/null +++ b/server/2.2.0/src/site/xdoc/provided_matchers.xml @@ -0,0 +1,186 @@ + + + + + + James 2.1 - Provided Matchers + + + + +
+ +

James provides a number of implemented Matchers for use by James administrators in their +configurations. These are primarily matchers that members of the James developer or user +communities have found useful in their own configurations. A description of how to configure +Matchers and use them in the James SpoolManager can be found here.

+ + +

Description: This matcher is the trivial one - it matches all mails being processed. All recipients are returned.

+

Configuration string: None.

+ + +

Description: It can be used to refuse emails with SCR, PIF, EXE etc. attachments. +It matches mails that has a file attachment with a file name meeting one of the supplied filters. +All recipients are returned.

+

Configuration string: A comma or space delimited list of file names. +File names may start with a wildcard '*'. Example: *.scr,*.bat,*.pif,*.pi,*.com,*.exe

+ + +

Description: The CommandForListserv matcher is used as a simple filter to recognize emails that are list server +commands. It will match any email addressed to the list server host, as well as any email that is addressed +to a user named <prefix>-on or <prefix>-off on any host. Only those matching recipients will be returned.

+

Configuration string: An email address of the form <prefix>@<host>, where host is the hostname used for the listserver and prefix is the command prefix.

+ + +

Description: A matcher intended for use with the FetchPOP server. It matches a custom header (X-fetched-from) that is +set by the FetchPOP server. FetchPOP sets this header to the name of the FetchPOP task which originally fetched +the message. All recipients are returned.

+

Configuration string: The name of the FetchPOP task which originally fetched the message.

+ + +

Description: Matches those messages with a MIME type of "multipart/mixed". All recipients are returned.

+

Configuration string: None.

+ + +

Description: Matches mails that have the Habeas Warrant (see http://www.habeas.com for details). All recipients are returned.

+

Configuration string: None.

+ + +

Description: Matches mails that have the specified header. All recipients are returned.

+

Configuration string: The name of the header whose presence determines the match.

+ + +

Description: Matches mails that have the specified Mail Attribute. All +recipients are returned.

+

Configuration string: The name of the Mail Attribute to match. For example:
+


+<mailet match="HasMailAttribute=name" class="<any-class>">
+
+

+ + +

Description: Matches mails that have the specified Mail Attribute and the +specified MailAttribute value. All recipients are returned.

+

MailAttributes are types of Object whereas the value specified in the Matcher +condition is of type String. The toString() method is used to obtain a String +representation of the Mail Attribute value for matching. The +String.equals(String) method tests for a match.

+

Configuration string: The name of the Mail Attribute to be matched, a comma +and then the String value to be matched. For example:
+


+<mailet match="HasMailAttributeWithValue=name, value" class="<any-class>">
+
+

+ + +

Description: Matches mails that have the specified Mail Attribute and +a MailAttribute value that matches the specified regular expression. +All recipients are returned.

+

MailAttributes are types of Object whereas the value specified in the Matcher +condition is of type String. The toString() method is used to obtain a String +representation of the Mail Attribute value for matching. The regular +expression must follow Perl5 syntax.

+

Configuration string: The name of the Mail Attribute to be matched, a comma +and then the regular expression used to match the value against. For example:
+


+<mailet match="HasMailAttributeWithValueRegex=name, regex" class="<any-class>">
+
+

+ + +

Description: Matches mails that are sent to email addresses on hosts that are in the configuration list. Only +recipients that are on one of the hosts are returned.

+

Configuration string: A list of host names, comma or space delimited.

+ + +

Description: Matches mails that are sent to email addresses on local hosts. Only +recipients that are on one of the local hosts are returned.

+

Configuration string: None.

+ + +

Description: Checks the mail against one of a number of mail-abuse.org IP lists.

+

Configuration string: One of three strings - "blackholes.mail-abuse.org", "relays.mail-abuse.org", or "dialups.mail-abuse.org".

+ + +

Description: Matches those messages sent to only a single recipient. The single recipient is returned.

+

Configuration string: None.

+ + +

Description: A matcher derived from a Netscape Mail Server spam filter. If the matcher detects headers that +indicate spam, the message is matched. All recipients are returned.

+

Configuration string: None.

+ + +

Description: Matches mails that are sent to one of the recipients on a specified list. Only +matching recipients are returned.

+

Configuration string: A list of recipient addresses, comma, tab, or space delimited.

+ + +

Description: Matches mails that are sent to email addresses on local hosts with users that have local acccunts. Only +matching recipients are returned.

+

Configuration string: None.

+ + +

Description: Counts the number of Received headers in the mail (each of which represents a server +in the relay chain). If the number equals or exceeds the specified limit, the mail is +matched. All recipients are returned.

+

Configuration string: a positive integer that is the limit on the number of relays.

+ + +

Description: Checks the remote address from which the mail was received against the configured list. If the address matches one on the list, the matcher considers it a match. All recipients are returned.

+

Configuration string: A list of domain names, IP addresses, or wildcarded IP subnets of any class. The +list may be comma or space delimited.

+ + +

Description: Checks the remote address from which the mail was received against the configured list. If the address doesn't match one on the list, the matcher considers it a match. All recipients are returned.

+

Configuration string: A list of domain names, IP addresses, or wildcarded IP subnets of any class. The +list may be comma or space delimited.

+ + +

Description: Matches mails where the host name in the address of the sender cannot be resolved. All +recipients are returned.

+

Configuration string: None.

+ + +

Description: Matches mails that are sent by one of the senders on a specified list. All +recipients are returned.

+

Configuration string: A list of sender addresses, comma, tab, or space delimited.

+ + +

Description: Matches emails with a total message size (headers and body) greater than the specified limit. All recipients are returned.

+

Configuration string: a positive integer followed by an 'm' or a 'k'. This is the maximum message size permitted specified in megabytes or kilobytes respectively.

+ + +

Description: Matches emails with the specified subject. All recipients are returned.

+

Configuration string: The string against which mail subject headers are matched.

+ + +

Description: Matches emails whose subject header starts with the specified string. All recipients are returned.

+

Configuration string: The string against which mail subject headers are matched.

+ + +

Description: Matches mails that are sent to email addresses that have userids that are in the configuration list. Only +matching recipients are returned.

+

Configuration string: A list of user names, comma or space delimited.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml b/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml new file mode 100644 index 00000000000..1a3ef797089 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml @@ -0,0 +1,78 @@ + + + + + + James 2.1 - Configuring the RemoteManager + + + +
+

The RemoteManager is controlled by a configuration block in the config.xml. +The remotemanager tag defines the boundaries of the configuration block. It encloses +all the relevant configuration for the RemoteManager. The behavior of the RemoteManager is +controlled by the attributes and children of this tag.

+ +

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if +not present.

+

The standard children of the remotemanager tag are:

+
    +
  • port - This is an optional integer value. This value is the port on which this POP3 server is configured +to listen.If the tag or value is omitted, the value will default to 4555.
    • +
  • bind - This is an optional value. If present, this value is a string describing +the IP address to which this service should be bound. If the tag or value is absent then the service +will bind to all network interfaces for the machine.
    • +
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" +server socket factory is used to generate the server socket for this service. If it is false, the +"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType +tag which is described under the expert configuration options.
    • +
  • handler - This is an artifact preserved for backwards compatibility. This tag +was used to group related parameters. It should disappear in future versions.
    • +
      +
    • helloName - This is a required tag with an optional body that defines the server name +used in the initial service greeting. The tag may have an optional attribute - autodetect. If +the autodetect attribute is present and true, the service will use the local hostname +returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In +this case, if no body is present, the value "localhost" will be used.
      • +
    • administrator_accounts - This is an required container tag. It contains +one or more administrator_account elements, each of which has a login attribute +and a password attribute. These two attributes correspond to the login id and password for the +administrative account respectively. Obviously, for security reasons, these should be set upon James installation.
      • +
    • connectionTimeout - This is an optional tag with an integer body.
      • +
    +
+

There are a few additional children of the pop3server tag that are appropriate for advanced +configurations. These should only be used by expert administrators. All tags in this group are optional.

+
    +
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the server socket factories specified in the socket manager block. Any other +value will result in an error. If present, this tag overrides the useTLS tag.
    • +
  • threadGroup - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the thread groups specified in the thread manager block. Any other +value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • +
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client +connections that this service will allow. If no value is specified, the value defaults to that specified in +the connectionmanager block. A value of 0 means that there is no limit imposed +by the service, although resource limitations imposed by other components +(i.e. max # of threads) may serve to limit the number of open connections.
    • +
+
+ + diff --git a/server/2.2.0/src/site/xdoc/repositories.xml b/server/2.2.0/src/site/xdoc/repositories.xml new file mode 100644 index 00000000000..ca99c31ccf2 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/repositories.xml @@ -0,0 +1,86 @@ + + + + + + Repositories + + + +
+ +

James uses a number of different repositories to both store message data (email, news messages) and +user information. User repositories store user information, including user names, authentication +information, and aliases. Mail repositories store messages that have been delivered locally. Spool +repositories store messages that are still being processed. Finally, news repositories are used to +store news messages.

+ +
+
+ +

Aside from the type of data they store, repositories are distinguished by +where they store data. There are three types of storage - File, Database, and DBFile.

+ + +

File-based repositories store all data in the file system. In general, these repositories are extremely +simple to configure, but may compare poorly in terms of performance when compared to other repository +types. File repositories are not recommended for large or performance-critical configurations. In the +default configuration, all repositories are file repositories.

+ +

File repository paths typically begin with the prefix "file". Paths are relative to the application +base directory, unless the path begins with a slash. As an example, assume that James is running in +/usr/james/phoenix/apps/james. Then "file://var/mail/spool/" would refer to the directory /usr/james/phoenix/apps/james/var/mail/spool. +And "file:///var/mail/spool/" (note the extra '/') would refer to the directory /var/mail/spool.

+ +

All repository types (mail, spool, user, and news) have file-based implementations. No special configuration is required to enable file-based repositories

+ + + + +

Database repositories store all data in an administrator-supplied database. Configuration is somewhat +more complex, requiring that the administrator adjust the data-connections section. Detailed directions +are included in the sample configuration file. The administrator will need to know the JDBC driver class, +the appropriate URL for use with his database, and a valid username/password for the database.

+ +

If the administrator wants to configure a database other than MySQL, it will be necessary to add the jar +or zip file containing the JDBC driver classes to the lib subdirectory of the installation directory. This +will allow Phoenix to properly load the driver when it is initializing the database repository. The MySQL +driver is pre-packaged with James.

+ +

Database repository paths typically begin with the prefix "db". The format is "db://<data-source>/<table>" +where <data-source> is the name of the data-source defined in the data-connections section. And <table> is +the particular table associated with the repository.

+ +

Mail, spool, and user repositories have JDBC-based implementations.

+ + + + +

This is a special repository type used only for mail repositories. DBFile repositories store the body of +a mail message in the file system, while headers are stored in the database. This allows the administrator +to minimize the size of data stored in the database, while conserving most of the performance of the +database repository.

+ +

Only mail repositories have dbfile-based implementations.

+ + +
+ + diff --git a/server/2.2.0/src/site/xdoc/serverwide_configuration.xml b/server/2.2.0/src/site/xdoc/serverwide_configuration.xml new file mode 100644 index 00000000000..9d60dbc191a --- /dev/null +++ b/server/2.2.0/src/site/xdoc/serverwide_configuration.xml @@ -0,0 +1,100 @@ + + + + + + James 2.1 - Global Server Configuration + + + +
+

There are a number of global configuration blocks that do not fall into any one +component. They have effects that are global in scope across the server. Some of +these blocks are crucial, while others can be ignored by any but the most sophisticated +server administrators.

+ +

This configuration block is defined by the James tag. All administrators +need to adjust this configuration block upon installation. It no attributes, but several +children, all of which are required. +

    +
  • postmaster - the body of this element is the address that the server +will consider its postmaster address. This address will be listed as the sender address +of all error messages that originate from James. Also, all messages addressed to +postmaster@<servername>, where <servername> is one of the domain names whose +mail is being handled by James, will be redirected to this email address.
    • +
  • usernames - this element has no body, but instead has three required +boolean attributes. These are ignoreCase, enabledAliases, +and enableForwarding. The first of these determines whether email user names +will be treated as case-insensitive or not. The second attribute configures whether local user +aliasing will be enabled. Finally, the value of the third attribute determines whether forwarding +to potentially remote users will be enabled.
    • +
  • servernames - this element determines exactly which mail domains and IP +addresses the server will treat as local. It has two boolean attributes - +autodetect and autodetectIP. The first attribute, if true, +causes the server to attempt to determine its own host name and add that to the list of local +mail domains. The second attribute causes the server to attempt to determine its own IP +address and add it to the list of local mail domains. In addition to these attributes, this +tag has zero or more servername children.
    • +
      +
    • servername - a single host name or IP address that should be added to the list of +mail domains that the server considers local.
      • +
    +
  • inboxRepository - This is a simple container tag which contains a single child element.
    • +
      +
    • repository - this defines the mail repository that will be used to store +mail delivered locally. This element has no body. The required attribute type +is always set to "MAIL". The required attribute repositoryURL addresses the +repository as described in the repository configuration section.
      • +
    +
+

+ + +

+This block controls general connection management. There are two elements. +

    +
  • idle-timeout - the number of milliseconds that it will take for idle +client connections managed by this connection manager to be marked at timed out. If no +value is specified, the value defaults to 5 minutes, 300000 milliseconds. A value of 0 +means that client sockets will not timeout.
    • +
  • max-connections - The max-connections parameter specifies the default +maximum number of client connections that this connection manager will allow per managed +server socket. This value can be overridden by each individual service. If no value is +specified, the value defaults to 30. A value of 0 means that there is no limit imposed +by the connection manager, although resource limitations imposed by other components +(i.e. max # of threads) may serve to limit the number of open connections.
    • +
+

+ + +

This block controls the low level file repository to file mapping. There is no need to modify this.

+ + +

This block controls the socket types available inside James. Unless you are intending to enable SSL, it +shouldn't be necessary for you to adjust this block. For modifications to this block that are required to +enable TLS, see the using TLS section.

+ + +

This block controls the thread pools available inside James. Only expert administators should modify +this configuration.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/smtp_auth.xml b/server/2.2.0/src/site/xdoc/smtp_auth.xml new file mode 100644 index 00000000000..7e3577f3509 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/smtp_auth.xml @@ -0,0 +1,70 @@ + + + + + + James 2.1 - Using Authenticated SMTP + + + +
+

Authenticated SMTP is a method of securing your SMTP server. With SMTP AUTH enabled senders who wish to +relay mail through the SMTP server (that is, send mail that is eventually to be delivered to another SMTP +server) must authenticate themselves to James before sending their message. Mail that is to be delivered +locally does not require authentication. This method ensures that spammers cannot use your SMTP server +to send unauthorized mail, while still enabling users who may not have fixed IP addresses to send their +messages.

+

Mail servers that allow spammers to send unauthorized email are known as open relays. So SMTP AUTH +is a mechanism for ensuring that your server is not an open relay .

+

At this time James only supports simple user name / password authentication.

+ +

Configuring James for Authentication SMTP is a multi-step process. It requires several adjustments of +the config.xml. To enable SMTP AUTH, do the following:

+

First, as mentioned above, SMTP AUTH requires that James be able to distinguish between mail intended +for local delivery and mail intended for remote delivery. James makes this determination by matching the +domain to which the mail was sent against the <servernames> element of the James configuration block. Any +local domains should be explicitly listed as <servername> elements in this section.

+

Second, James is configured out of the box so as to not serve as an open relay for spammers. This is done +by restricting the IP addresses from which mail will be accepted using the RemoteAddrNotInNetwork mailet. This +restriction must be lifted before users can send from arbitrary clients. To do this, comment out or remove the +mailet tag containing the class attribute "RemoteAddrNotInNetwork". This tag can be found in the spoolmanager +configuration block, in the root processor configuration.

+

Third, set the authRequired element of the smtpserver configuration block to "true".

+

Fourth, if you wish to ensure that authenticated users can only send email from their own account, you may +optionally set the verifyIdentity element of the smtpserver configuration block to "true".

+

Fifth, restart James. This will pull in all of your configuration changes.

+ + +

Finally, you need to verify that your configuration was done correctly. This step is +important and should not be skipped.

+

Verify that you have not inadvertantly configured your server as an open relay. This is most easily +accomplished by using the service provided at ORDB.org. ORDB.org will +check your mail server and inform you if it is an open relay.

+

It is extremely important that your server not be configured as an open relay. Aside from potential +costs associated with usage by spammers, connections from servers that are determined to be open relays +are routinely rejected by SMTP servers. This can severely impede the ability of your mail server to +send mail.

+

Of course it is also necessary to confirm that users and log in and send +mail through your server. This can be accomplished using any standard mail client (i.e. Outlook, +Eudora, Evolution).

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/smtp_configuration.xml b/server/2.2.0/src/site/xdoc/smtp_configuration.xml new file mode 100644 index 00000000000..ef0ab3002c9 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/smtp_configuration.xml @@ -0,0 +1,85 @@ + + + + + + James 2.1 - Configuring the SMTP Service + + + +
+

The SMTP service is controlled by a configuration block in the config.xml. +The smtpserver tag defines the boundaries of the configuration block. It encloses +all the relevant configuration for the SMTP server. The behavior of the SMTP service is +controlled by the attributes and children of this tag.

+ +

This tag has an optional boolean attribute - enabled - that defines whether the service is active or not. The value defaults to "true" if +not present.

+

The standard children of the smtpserver tag are:

+
    +
  • port - This is an optional integer value. This value is the port on which this SMTP server is configured +to listen.If the tag or value is omitted, the value will default to the standard SMTP port, 25.
    • +
  • bind - This is an optional value. If present, this value is a string describing +the IP address to which this service should be bound. If the tag or value is absent then the service +will bind to all network interfaces for the machine.
    • +
  • useTLS - This is an optional boolean value. If this value is true, then the "ssl" +server socket factory is used to generate the server socket for this service. If it is false, the +"plain" server socket factory is used. In either case this behavior is overridden by the serverSocketType +tag which is described under the expert configuration options.
    • +
  • handler - This is an artifact preserved for backwards compatibility. This tag +was used to group related parameters. It should disappear in future versions.
    • +
      +
    • helloName - This is a required tag with an optional body that defines the server name +used in the initial service greeting. The tag may have an optional attribute - autodetect. If +the autodetect attribute is present and true, the service will use the local hostname +returned by the Java libraries. If autodetect is absent or false, the body of the tag will be used. In +this case, if no body is present, the value "localhost" will be used.
      • +
    • connectionTimeout - This is an optional tag with a non-negative integer body.
      • +
    • authRequired - This is an optional tag with a boolean body. If true, then the server will +require authentication before delivering mail to non-local email addresses. If this tag is absent, or the value +is false then the client will not be prompted for authentication. Only simple user/password authentication is +supported at this time.
      • +
    • verifyIdentity - This is an optional tag with a boolean body. This option can only be used +if SMTP authentication is required. If the parameter is set to true then the sender address for the submitted message +will be verified against the authenticated subject.
      • +
    • maxmessagesize - This is an optional tag with a non-negative integer body. It specifies the maximum +size, in kbytes, of any message that will be transmitted by this SMTP server. It is a service-wide, as opposed to +a per user, limit. If the value is zero then there is no limit. If the tag isn't specified, the service will +default to an unlimited message size.
      • +
    +
+

There are a few additional children of the smtpserver tag that are appropriate for advanced +configurations. These should only be used by expert administrators. All tags in this group are optional.

+
    +
  • serverSocketFactory - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the server socket factories specified in the socket manager block. Any other +value will result in an error. If present, this tag overrides the useTLS tag.
    • +
  • threadGroup - This is an optional tag with a string body. If the tag is present, +the body must be the name of one of the thread groups specified in the thread manager block. Any other +value will result in an error. This tag is best used to fine tune thread allocation between the services.
    • +
  • connectionLimit - The connectionLimit parameter specifies the maximum number of client +connections that this service will allow. If no value is specified, the value defaults to that specified in +the connectionmanager block. A value of 0 means that there is no limit imposed +by the service, although resource limitations imposed by other components +(i.e. max # of threads) may serve to limit the number of open connections.
    • +
+
+ + diff --git a/server/2.2.0/src/site/xdoc/spoolmanager.xml b/server/2.2.0/src/site/xdoc/spoolmanager.xml new file mode 100644 index 00000000000..245cd3e78c8 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/spoolmanager.xml @@ -0,0 +1,85 @@ + + + + + + James 2.1 - The SpoolManager, Matchers, and Mailets + + + +
+ +

James separates the services that deliver mail to James (i.e. SMTP, FetchPOP) +from the engine that processes mail after it is received by James. The +SpoolManager component is James' mail processing engine. James' SpoolManager component +is a Mailet container. It is these mailets and matchers that actually carry out mail processing.

+ +

Core to the SpoolManager operation are Matchers and Mailets. A Matcher is a +simple object that checks whether a mail message matches a particular condition. +A mailet is another type object that processes an email message in some way. Some +typical tasks appropriate for a mailet would be adding a header, delivering the message +to a local repository, or handling remote delivery. Both the Matcher and Mailet APIs are +public, allowing James users to write their own custom matchers and mailets. James +comes with a large set of pre-built matchers and mailets.

+ +

Matchers and mailets are used in pairs. At each stage in processing a message is checked +against a matcher. The matcher will attempt to match the mail message. The match is not simply +a yes or no issue. Instead, the match method returns a collection of matched recipients. If the +this collection of matched recipients is empty, the mailet is not invoked. If the collection of +matched recipients is the entire set of original recipients, the mail is then processed by the +associated mailet. Finally, if the matcher only matches a proper subset of the original recipients, +the original mail is duplicated. The recipients for one message are set to the matched recipients, +and that message is processed by the mailet. The recipients for the other mail are set to the +non-matching recipients, and that message is not processed by the mailet.

+ +

More on matchers and mailets can be found here.

+ +

One level up from the matchers and mailets are the processors. Each processor +is a list of matcher/mailet pairs. During mail processing, mail messages will be +processed by each pair, in order. In most cases, the message will be processed by +all the pairs in the processor. However, it is possible for a mailet to change the +state of the mail message so it is immediately directed to another processor, and no +additional processing occurs in the current processor. Typically this occurs when the mailet wants to prevent +future processing of this message (i.e. the mail message has been delivered locally, +and hence requires no further processing) or when the mail message has been identified +as a candidate for special processing (i.e. the message is spam and thus should be +routed to the spam processor). Because of this redirection, the processors in the +SpoolManager form a tree. The root processor, which must be present, is the root of +this tree.

+ +

The SpoolManager continually checks for mail in the spool repository. When +mail is first found in the repository, it is delivered to the root processor. +Mail can be placed on this spool from a number of sources (SMTP, FetchPOP, a +custom component). This spool repository is also used for storage of mail that is +being redirected from one processor to another. Mail messages are driven through +the processor tree until they reach the end of a processor or are marked completed +by a mailet.

+ +

More on configuration of the SpoolManager can be found here.

+ +

Much of the power of James lies in the SpoolManager component. Custom matchers and +mailets can be easily developed to address an administrator's particular needs. The +processor tree can easily be configured to sort, filter, and deliver mail based on any +number of criteria. Mail administrators new to James should spend some time learning how +to configure the SpoolManager to meet their needs.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml b/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml new file mode 100644 index 00000000000..da3f4846072 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml @@ -0,0 +1,99 @@ + + + + + + James 2.1 - Configuring the SpoolManager + + + +
+

The SpoolManager is controlled by a single configuration block in the config.xml. +The spoolmanager tag defines the boundaries of the configuration block. The behavior of +the SpoolManager, most importantly the routing of mail messages through the processor tree, +is controlled by this block.

+ +

The spoolmanager tag has a few simple children. These are:

+
    +
  • threads - This is a required positive integer element. It specifies +the number of threads the SpoolManager will use to process messages in the spool. This +parameter tends to substantially impact performance, so it is advisable to tune it in production +configurations.
    • +
  • mailetpackages - This is a required container tag. It contains some number +of mailetpackage children. The body of each of these mailetpackage +elements is a Java package name. It is these packages that contain the classes to be instantiated +as mailets.
    • +
  • matcherpackages - This is a required container tag. It contains some number +of matcherpackage children. The body of each of these matcherpackage +elements is a Java package name. It is these packages that contain the classes to be instantiated +as matchers.
    • +
+ +

The remaining SpoolManager configuration elements are complex enough to require a more in-depth +discussion.

+ + +

In addition to the child elements discussed above, the SpoolManager tag can have several +processor children. It is these tags and their children that define the processor tree +for the SpoolManager.

+

Each processor has a required attribute, name. The value of this attribute must be +unique for each processor tag. The name of a processor is significant. Certain processors are required +(specifically root and error). The name "ghost" is forbidden as a processor name, as it is used to denote +a message that should not undergo any further processing.

+

The James SpoolManager creates a correspondance between processor names and the "state" of a mail as defined +in the Mailet API. Specifically, after each mailet processes a mail, the state of the message is examined. If +the state has been changed, the message does not continue in the current processor. If the new state is "ghost" +then processing of that message terminates completely. If the new state is anything else, the message is +re-routed to the processor with the name matching the new state.

+

The root processor is a required processor. All new messages that the SpoolManager finds on the spool are +directed to this processor.

+

The error processor is another required processor. Under certain circumstances James itself will redirect messages +to the error processor. It is also the standard processor to which mailets redirect messages when an error +condition is encountered.

+

The transport and spam processors are two useful, but optional, processors that are included in the out of +the box configuration. These processors include logic for actual mail delivery and spam handling respectively. More +information on these processors can be found in the default config.xml.

+

Each processor element has zero or more mailet child elements. Each of these elements describes a +matcher/mailet pair. The ordering of the mailet children is crucial to the configuration, as +it is the order in which pairs will be traversed in the processor.

+

It is this mailet element that is at the core of the SpoolManager configuration.

+ + +

Consider the following simple mailet tag:

+<mailet match="RemoteAddrNotInNetwork=127.0.0.1" class="ToProcessor">
+<processor>spam</processor>
+</mailet>
+

The mailet tag has two required attributes, match and class.

+

The match attribute is set to the value of the specific Matcher class to be instantiated with a an +optional argument. If present, the argument is separated from the Matcher class name by an '='. Semantic +interpretation of the argument is left to the particular mailet.

+

The class attribute is set to the value of the Mailet class that is to be instantiated.

+

Finally, the children of the mailet tag define the configuration that is passed to the Mailet. The +tags used in this section should have no attributes or children. The names and bodies of the elements will be passed to +the mailet as (name, value) pairs.

+

So in the example above, a Matcher instance of RemoteAddrNotInNetwork would be instantiated, and the value "127.0.0.1" +would be passed to the matcher. The Mailet of the pair will be an instance of ToProcessor, and it will be passed the (name, value) +pair of ("processor", "spam").

+

James includes a number of pre-packaged Mailets and Matchers. A list of provided Mailets may be found +here. A list of provided Matchers may be found here.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/summary.xml b/server/2.2.0/src/site/xdoc/summary.xml new file mode 100644 index 00000000000..b534a06d675 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/summary.xml @@ -0,0 +1,116 @@ + + + + + + James 2.1 - Component Summary + + + + +
+ +

James is an open source project intended to produce a robust, flexible, and powerful +enterprise class server that provides email and email-related services. It is also designed to +be highly customizable, allowing administrators to configure James to process email in a +nearly endless variety of fashions.

+ +

The James server is built on top of the Avalon Framework. The standard James distribution +deploys inside the Phoenix Avalon Framework container. In addition to providing a robust +server architecuture for James, the use of Phoenix allows James administrators to deploy +their own applications inside the container. These applications can then be accessed during +mail processing.

+ +

The James server is implemented as a complete collection of servers and related components that, taken together, +provide an email solution. These components are described below.

+ +
+
+ +

The POP3 protocol allows users to retrieve email messages. It is the method +most commonly used by email clients to download and manage email messages.

+ +

The James version of the POP3 service is a simple and straightforward implementation that +provides full compliance with the specification and maximum compatibility with common +POP3 clients. In addition, James can be configured to require SSL/TLS connections for +POP3 client connecting to the server.

+ +

More information on configuring the POP3 service can be found here.

+ +
+
+ +

SMTP (Simple Mail Transport Protocol) is the standard method of sending and delivering +email on the internet. James provides a full-function implementation of the SMTP specification, +with support for some optional features such as message size limits, SMTP auth, and encrypted +client/server communication.

+ +

More information on configuring the SMTP service can be found here.

+ +
+
+ +

NNTP is used by clients to store messages on and retrieve messages from news servers. James provides +the server side of this interaction by implementing the NNTP specification as well as an appropriate +repository for storing news messages. The server implementation is simple and straightforward, but +supports some additional features such as NNTP authentication and encrypted client/server communication.

+ +

More information on configuring the NNTP service can be found here.

+ +
+
+ +

FetchPOP, unlike the other James components, is not an implementation of an RFC. Instead, it's a +component that allows the administrator to configure James to retrieve email from a number of POP3 +servers and deliver them to the local spool. This is useful for consolidating mail delivered to a +number of accounts on different machines to a single account.

+ +

More information on configuring FetchPOP can be found here.

+
+
+ +

James separates the services that deliver mail to James (i.e. SMTP, FetchPOP) +from the engine that processes mail after it is received by James. The +SpoolManager component is James' mail processing engine. James' SpoolManager component +is a Mailet container. It is these mailets and matchers that actually carry out mail processing.

+ +

More on the structure of the SpoolManager and the Mailet API can be found here.

+ +
+
+ +

James uses a number of different repositories to both store message data (email, news messages) and +user information. User repositories store user information, including user names, authentication +information, and aliases. Mail repositories store messages that have been delivered locally. Spool +repositories store messages that are still being processed. Finally, news repositories are used to +store news messages. Aside from what type of data they store, repositories are distinguished by +where they store data. There are three types of storage - File, Database, and DBFile.

+ +
+
+ +

James provides a simple telnet-based interface for control. Through this interface you can add +and delete users, configure per-user aliases and forward addresses, and shut down the server.

+ +

More on the configuring the RemoteManager can be found here.

+ +
+ + diff --git a/server/2.2.0/src/site/xdoc/usingTLS.xml b/server/2.2.0/src/site/xdoc/usingTLS.xml new file mode 100644 index 00000000000..a2d25ec76c2 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/usingTLS.xml @@ -0,0 +1,89 @@ + + + + + + James 2.1 - Using TLS + + + + +
+ +

+This document explains how to enable James 2.1 services to use Transport Layer Security (TLS) for encrypted client-server communication.

+ + +

James uses the Sun Java Secure Sockets Extension (JSSE) infrastructure to provide TLS/SSL +sockets. JSSE comes packaged with several vendor Java distributions (i.e. Sun Java 1.4.x, +IBM Java 1.3.x). For these distributions, please follow the vendor provided instructions for +configuring the JVM to use JSSE services.

+ +

If you are using a Java distribution that does not include JSSE as part of the +distribution you will need to download the JSSE package separately. It can be obtained from +here. Please follow Sun's instructions for installation +and configuration of JSSE.

+

In either case, you will need to statically define a JSSE TLS provider. In general, this +is the default installation.

+

Once you've installed JSSE, James still needs to be configured to take advantage of the JSSE +functionality.

+ + +

To use TLS/SSL inside James you will need a certificate keystore.

+ + +

The out of the box configuration file contains a template for the SSL configuration in place. Specifically, +in the sockets block, under the server-sockets element, there is a commented out factory with the +name "ssl". The first step to configuring the server socket factory is uncommenting out this element.

+

The factory element contains several children. Of these, it should only be necessary to adjust two or three children.

+

The required file element specifies the location of the keystore to be used by the factory. This is specified +as a file path using Unix-style formatting. The path is taken to be relative to the apps/james/ subdirectory of +the application installation directory unless an absolute path is specified.

+

The password element should be set to the keystore password. This password should have been specified +when the keystore was created, and it is required to open the keystore. This value is required.

+

Finally, it may be necessary to adjust the type element. This element can take on any keystore type +supported by the JSSE provider being used (see the JSSE documentation for details). The out of the box +configuration specifies JKS (Java Keystore).

+

The remaining children should not need to be deleted or adjusted.

+ + +

Each of the services - SMTP, +POP3, NNTP, +and RemoteManager - supports use of TLS. Each of +these services has an optional boolean configuration element useTLS which is used to toggle +use of TLS for the service. When this value is set to true, that particular service will use the "ssl" +server socket factory to spawn server sockets.

+ + +

After you've configured a particular service to use TLS/SSL connections, the service port +should no longer accept unencrypted TCP/IP connections. This can be tested by using a telnet +client to directly connect to the service port. The telnet connection should simply hang until +the client times out.

+

+To validate that the port is properly accepting SSL connections an SSL client can be used to +open a connection to the service port. One such client is OpenSSL, available from the +OpenSSL web site. Follow the instructions provided with +the SSL client to create a connection to the service port. Upon connection, the usual +service greeting should appear.

+ +
+ + + diff --git a/server/2.2.0/src/site/xdoc/using_database.xml b/server/2.2.0/src/site/xdoc/using_database.xml new file mode 100644 index 00000000000..b7b2d7ed156 --- /dev/null +++ b/server/2.2.0/src/site/xdoc/using_database.xml @@ -0,0 +1,143 @@ + + + + + + James 2.1 - Using a Database + + + +
+

James has the capacity to use a JDBC-compatible database for storage of both message and user +data. This section explains how to configure James to utilize a database for storage.

+ +

Using James with a database backend has certain requirements. Database configuration is +extremely vendor-specific, so we can only state the requirements in general terms.

+

There must be a database instance accessible from the James server. An account with appropriate +privileges (select, insert, delete into tables, and on initial startup creation of tables) and +with sufficient quota for the data to be inserted into the database must be available. Also, +since James will use JDBC to access the database, an appropriate JDBC driver must be +available for installation.

+

It is important to verify the functionality of the database before attempting to configure +James to use it as a repository. This will help ensure that configuration issues are properly +identified.

+ + +

Configuring the Phoenix container to work with JDBC is the first step in enabling James database support.

+

First, Phoenix must be able to load the JDBC classes. To make these classes available to Phoenix, place the +jar/zip files for the JDBC driver in the lib subdirectory of the James installation directory. Any additional +libraries upon which the JDBC library depends that are not part of the standard Java distribution should also be +added to this directory.

+

Please note that a MySQL driver is included as part of the James distribution and +so there is no need to add such a driver to the lib directory.

+

Second, the config.xml must be modified so that Phoenix initializes the database connections. The relevant +configuration is in the database-connections block. The database-connections tag has only a single child tag, +data-sources. This latter tag is a simple container tag for a number of child elements. It is these child +elements, data-source elements, that define the database connections.

+

Each data-source tag has a required attribute, name. This value +must be unique to each data-source element. It is this name that will +be used to specify the database connection in other parts of the config.xml file.

+

The data-source element has five children, all of whom are required. +

    +
  • driver - The class name of the database driver to be used.
    • +
  • dburl - The JDBC connection URL for your database/driver.
    • +
  • user - The user id of the database account to be used by this connection.
    • +
  • password - The password of the database account to be used by this connection.
    • +
  • max - The maximum number of JDBC connections to be used concurrently by this data-source.
    • +
+

+ +

Generally, you simply configure these entries in the config.xml +file, which are commented, in order to use a database with James. You +would then use the db: or dbfile: prefix instead of the file: prefix +for a particular repository. You are currently free to mix and match +your use of these different storage types for different repositories. +See Repository Configuration for +more details. A sample configuration is described below.

+ + + +

The precise SQL statements used by James to modify and view data stored in the database are specified in +an external configuration file. The sqlResources.xml file +(which can be found in the apps/james/conf directory) is a sample configuration file that contains the SQL +statements used by James. The purpose of each of these statements, as well as the repository with which +they are associated, is documented in situ.

+ +

If you are using a SQL database with unusual SQL commands or data types, you may +need to add special entries to this file. The James team +does try to keep sqlResources.xml updated, so if you do run into a +special case, please let us know.

+ +

Also, if the database tables are not created a priori, but rather are to be created by James +upon startup, special attention should be paid to the "create table" statements in this file. Such +statements tend to be both very database and very database instance specific.

+ + + +

The config.xml file has commented out examples for MySQL and +MSSQL data sources, and for each of the standard repositories. For +example, to use MySQL, you would uncomment and adjust the following +data-source element.

+ +

You must create the database, in this case named +mail, the user, and assign the user privileges. +You may create the tables before running James or, if you so choose, James +will automatically create the tables it needs. In the latter case the user +must have table creation privileges.

+ + +<data-source name="maildb" class="org.apache.james.util.mordred.JdbcDataSource"> + <driver>org.gjt.mm.mysql.Driver</driver> + <dburl>jdbc:mysql://127.0.0.1/mail</dburl> + <user>username</user> + <password>password</password> + <max>20</max> +</data-source> + + +

Once the data-source element has been created, it can be referenced elsewhere in the config.xml +file. For example, the following element tells James to use the maildb data-source and dbfile +storage mechanism for the message spool:

+ + +<spoolRepository> + <repository destinationURL="dbfile://maildb/spool/spool" type="SPOOL"/> +</spoolRepository> + + +

The following element tells James to store mailboxes in a the maildb data-source:

+ + +<inboxRepository> + <repository destinationURL="db://maildb/inbox/" type="MAIL"/> +</inboxRepository> + + +

The configuration file contains further examples.

+ + +

There are some vendor-specific subtleties in using databases with James that have been observed +by some users. These issues (and methods to resolve them) are recorded on the +James FAQ as they are reported. Please consult the FAQ if you encounter any +difficulties.

+ +
+ + diff --git a/server/pom.xml b/server/pom.xml new file mode 100644 index 00000000000..3ead2a35eea --- /dev/null +++ b/server/pom.xml @@ -0,0 +1,94 @@ + + + + 4.0.0 + org.apache.james + james-server-root + JAMES Server + 1.0-SNAPSHOT + + Apache JAMES Server + + pom + + org.apache.james + james-project + 1.1-SNAPSHOT + + + 2.2.0 + + http://james.apache.org/server/ + 2006 + + + scm:svn:http://svn.apache.org/repos/asf/james/project/server + scm:svn:https://svn.apache.org/repos/asf/james/project/server + http://svn.apache.org/viewvc/james/project/server + + + + + james-server-website + scp://minotaur.apache.org/www/james.apache.org/server/ + + + + + jira + http://issues.apache.org/jira/browse/JAMES + + + + continuum + + + mail + + +
server-dev@james.apache.org
+ + + + + + + Server User List + server-user-subscribe@james.apache.org + server-user-unsubscribe@james.apache.org + http://www.mail-archive.com/server-user@james.apache.org/ + + + Server Developer List + server-dev-subscribe@james.apache.org + server-dev-unsubscribe@james.apache.org + server-dev@james.apache.org + http://www.mail-archive.com/server-dev@james.apache.org/ + + + James General List + server-general-subscribe@james.apache.org + server-general-unsubscribe@james.apache.org + http://www.mail-archive.com/server-general@james.apache.org/ + + + + + \ No newline at end of file diff --git a/server/src/site/resources/css/site.css b/server/src/site/resources/css/site.css new file mode 100644 index 00000000000..315b8a9d8ea --- /dev/null +++ b/server/src/site/resources/css/site.css @@ -0,0 +1,31 @@ +/* + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +*/ +#apacheconbox { + margin: 20px 0px 0px 20px; + padding: 10px; + border: 1px solid #ccc; + background-color: white; + background-image: url(../images/button-top.gif); + background-repeat: repeat-x; +} +#apacheconspacer { + float: right; + margin: 0px 0px 10px 10px; + background-color: white; +} diff --git a/server/src/site/resources/images/asf-logo-reduced.gif b/server/src/site/resources/images/asf-logo-reduced.gif new file mode 100644 index 0000000000000000000000000000000000000000..93cc102077a940966a0bf6d77e74ac273a10ef8f GIT binary patch literal 6636 zcmW-jdpy&NB^`k5({Ud=*EWJLJM77(p_7Ubjo^?L{6ozBTG zrT8~-uT3`YA6z(iU(uWv#wdC?*LrZ+m}~LRdiKU&$f@Oy^oJ`=i6+hgRAVF_PDwp- ztgxs!1ZD4l68M_KW_UVk-#Q!$Pa@K2Br166_?3pnI2h|A-a0BAXQR5&A?Fpb?Gb8 z2*k5oCs=r^?5ey-sZ^AxYup^lC`5wE?{)1hj19^$$^{?dW+pEpj_VrXL%+<@Wf;^t zJCdiUvs(#-G^G|kfoFntz873~ctb_>t(@D#$7q=4Jv#>J`Qv=$b>~!(=u%)Bm4nQx4G0uy}~g_xl^(YUhBvak#5 zgOuvw;WT+BuH_Fe^Qfh^cx6`2s#Q)p=qizh0B=u>WgT3-Um`*}GI*J|%p$EpRN<4Y zGf~z{=<@Z%ciE4S^38-`SDls-3H17pfQxW&*i~EFS~THa;&q8l$;Vfpq4`<-XV(d$ z`-SexHAn1eerw`+&nuVTz17YrVcMN=n%6b~Pk7R#fQs2Gpwl_l;)!9Zix3)AS!c&C zQ34C)+gAHfADmZ#J!@ouF>Xj{z_YVB18pQxGV z#8&ZYQIjf}4+ukXt98XP)EbGFTjdXCr7XQ<39V`EX@7dX7sgi%K^WawfM#Gv=)Aa1 z+o?NS!01`I1iDVjJKI}zgx$&^C5Ef~EU7JH?OH!a+{=QV@_zU`-5PH*I zPuRv#n3aaLEiBR7@r{SVvX-}mUhuV3xb?k!BFIAH>qbPzbWFRFgIRYuh*K-nKBmlY zXo!mHbNn_F82LJk8Y(6HVBaJGfDmIP$=s!3^Huul_S2gBtEE}_T2@5k_$OT|Hfb(5 z)X<#6D%iKo^EXxX4F^7^85Vz6sG)}#XEvtZDoScZ&v0xHPB;j%ar+w*l2aoKKDo2- zb9>!cbUD@Cqd08ehtuEgl-E^3le=d;7%p1%H-?USDXO&=Ns#x}Gv34#dLGHj^Mbev){8$exY)@D8txn4_GgU^Q#nGSmQLy^q-T1(e6TLYS zkyodfAaB@J5Bc38m*mNB>VrC0Ux|ebUq~Fex!-O z_3SLrfr{Ra$gx{pd(y!YKvCLGkH;%6{CVnQ{;UW?4*=tq1vDz`SEy-1yIj(V2R)ZFCY__!(Zs!f z`rl=^e16E7%Pt1a*QGNC=$-{`qOzJAu$vUT+P&2n>8pCwFvLX7zj^SYb`8p=S+0`E z$XYnM2{X2F1lL-FD1N}lfYe#DT)AY*L<*-3n_K(QvY5+XtlTfjs_Xqib0@!ESbnk! zSA5ArtJN=qF`{-hEnA~6zDFo%d=8mF^^sHw%D{yEh@{rPMqBF5>hB{?M8h{}t@d0a z$TBh@8x%i2xYqf->Z_kO?ik9N@?Tnd1s`-Sm~BEsL0u8q&B1GhLXeauby8lte(=TH z=AV&6s2Bxw4Bv}#m_ApmU%KiQkf8nY=}IGzQPzj<_?tbT?S^q>@387$GCgoZ>{a?} zs*!BKHygc@UGbJ=GHbM@>qZ!K2AH8?ChBt!Rc8lW$zk7VEIyd*pHZ< zE$>3tEVKs2MMV7_y;EJ&`Ixn`WSsRp6bJd9jN0ez7 z|Ma|Lc!>!cW3KHdjTYX+6Ie1ce`!;(oJVsG#TcaQP4A00xHl)OMsj5M5|l7eC(3az zDJOcF{El8dJ#Rzx_qnmF*i5mBua?=I@#wMvrXgR?ichil(W`n;21chubB`0YX{t^$lR@)6e zzxHWowXNRH^1Qj<$tzEf&Y^`bdfs&ERfbPdDZ3B53tO443vu5as^NZ_IwXJfQLrGe z*svE7@rd$rX)~s^qXx&9l&pV0F0Lg#>vRaEt0D{^yK6JYuX|TyX#+v*D)2mcq;*Cp zfmg+{`z{X8I**n$^E#AvnZc#GzrRAukx7ov5b^QQouH>j)7lqpVBE5P^}wWc9VJMF zl|RDZCikc^4kDE8%0ixL8a>;T0`GN{#v6|OnR?@tEUXAkxLJ7eVdS$v?N0>>6O+H` z^2{Fo2$O4$vb6y!ta9)n;7$uEBjvIC)aTjix?Ev&58b zTHCwd`4prf7n;f;4aFhXHwe2DD!6nD&voHBVW_e^kk z4BA-^s7S#3%MdJ4#z`=;Gr>L_NJXrykOQM%3PUrC{5VkM211p-l*eeZE_gIfIC*wHsp5pD4ONn{s>gfc~b%Z~YZ zfnp?qAD#z;w}Pl!;NNdN^7{Ah$UuBd#BGr$q;yX1IYErS2Le0Dx zqKPdB6#2#+aF1s2nU>;y3GRIxtU@)ZW|^FpfQ~=ZZp%^@YPfu9&Thx@P=y`kq&RXQ zrP!}nk8sM64X>6!PGY$JGH6aPF_geaVX2e20;v#Fg(T&7r%qiezhli!WB6VLkCZ*B zG&`?pe<1&KTg6Y!%9gm&{(-Dz0m4ZN2hm-2e=EFq8EYj6+(TS9F#>*%LhWhDO$Eqg(i@Bw z)ysu*&R-5ba{&B^X%ph=;~Ze6V^@UXC;oaVAh3nK4e=SJ+})Q!mhX`!p&LC@;->&y z*%W2taFQ)dn8M%$JL=tRX3)qPH=>dPFsJGwCA2L|HJ%mKj z+y{JohjEIwLdk)ki%L3nlF_un1W|C)_?oXdHHJxWEt5OSuAY78a@UvZQv>#fngy#D zda$eabAW`YbKVk=e-xVk`<#M<0C`~Vq#5R;JN!<{#bsQ{XJ#H_~xNkfws>)tk=Nd2=DuVh(`? zKbj9|62X&jT2m5yRsj^6*w}MyONIWHK+*)q!^jL_U2(Mwdv&9cwJ)Nvvpa7o8k)iy zo$y3h|0JtOk~^bd8{WmujPMc%sHVchB03^Sb~uD=9ux_+r#L6jz0P(=Y$!X|c){Km z?fLK}si+@jkFBv!Q@K0>0$w#6{ub%)YMSm>%~9uFy#et(ya<}gRQ2;ElN`gOWOB)M z?>DekR{i9Jsx8$4$*0#w)Bf5RkUxJ!K+o^z4rbhv;V_6(p-7uz?>a# zDmQ!+XacocAKJy4EE*aJ5_O zOl7@}o4eoGZTmg|$@UZeg7>|qstB=;z~yyP7^X&>6Iul9wdDbqR!|(HgI(~y4bEgj z%tqp_C+GnG6Eu5vYZwFarm%kO0S`>W{wXs4Bc*Kx9v*U#|E11@P&c^;w33o+rS3mX zZ^{t6E||fFhT*& z$DjcTq$Y2;o9%Wf9FZevyFIOXQdsN9MYJA58+<3}B-N#2cE!;z5WI==7sz?xMoOhz zCcFEp2Joy;%Tm{v(b4hj?*Q^*NLZjte-Cvs+}BwF*3RDM+ZvgK2YRtLoAP1um6~CC zw@>rEM)H;)OM3k2JaP$*d$h-ya-e6dr-4L468u-H8afR_e5*9CiF(K(Cm9J@isrWu;W$PP1TA^Q5f6Fvm^0E!e%5G?i3bKu z{Y_bc)_ET~Je&J>&|Ppxty-gD7^mFzg)*;3yK$m!uh89nW?=u;;J(Ukj}X{@$o$uk z$D||T{CMs~RQp&nti<#1&O(x{p7CHf|PgnQpY-@>Nvror76~GP}JT(kgx;Nb}5NhSZnAlLKawpPv{}C;)2hij} z-VORkhG$HWlVpA6+QO`}!i1jeMpnIN(Qw3S+*Ou5@BOsu;ShlNeakxDSlH5X@`wsZ-B=B^}t8EVN2WpeWtGP7&oYjaRX;8E)O+J)+0Eg`%&btht7o@_=5B zG}L1PyFKiFGCjmEgcCDdUcVCjw?p#*6+*WFo_@ZNNb6~LvrE2P1Ru4##STL3u4F3L z*$=Vae1mATs5Qf%z+bemF7Xbf3~@o!*q#q%6(KZ*3pVUEz8tvgS;Lvcg@LO8O#eXH zq>p^m_Q3Yl@-yi5M)=KD;6NHM`7vBn)9`{|U3AEtE=_e1P?$VMP7CLdHrY4?p-KJt z?4I-SV<|g?s@V3;aUsaKmh-9j@-TT;R2b6YKEmiZGJXW%GmD56}7a!qg*ZT093>v zRz?yK$i^kR0fx>=K=sg4p)3658SV*r>97F6DgYB65WZigcl|(D>z%LO=H`Mnn`wZ$ z17R)!YJR$CP66?+0Ra!Q>N@l%0q;r2xtIPhwW?=e^`9!vZwV17-} z`v&|Lxi`;X*yrlGVH2dVIefugw~g0%h=SUIP?B$j31DUvBdWX!RR_#(g^grxEaBNF zPBtudN<)iV+FZ!d+5hg+5J&Kc{8OETWxW%AhS&-JAzgnD!y2*9@s(5EO^-9pGAbx= zg#EdZxG!MeuOgDwu1+Avr1pU-1JvD&F&{S%|h`1jKPE8AZ9k@JRFi0v2K#muJ(ewI`fD=fye1%bs?&BeGF zZ;Kf*o`hYW^tpt?tq$ty>AH5Dulshs%z~6tiW1;GG`f9=Ly2Rh*sacZBEQUkRMCso zF(ECs$v<#4B+Ci`W8DE(IH(va?>eRhd&*Ws)cPcdW>57a3zdK*%pb*f<;JNtKI0 z-OK4Xju4k0B=B+2Gi?d-6YhU0Hg-u4T3_eoi!hE{=_4w2X!!hhR9UR3Z*bVfO^dB@ z%PGwF+v0V23+}E!LbhW#s?0(LXH?3&zWt$Tk-C=x5J4Uxye3j?S>N?L*6t@Ap4dt zcM)kz>l6V3L(wORWE4ZuXZU>MMajkfSMTVD^jZMsMn!gIo{f6w>v(K0>sOvxzEw=a zrNq05F^F4qmE!-zC(QGQ`ALI5Ao<%CXooIt<-mU(5n<_HaS8j zDuLZSYT+|{!Wh1VGuH~Ji%q}YTBR-VL>(y61_$YZ82tG5K;VJrr`+k+V ifk3o@FNQYto?ua@#Ta7 literal 0 HcmV?d00001 diff --git a/server/src/site/resources/images/james-server-logo.gif b/server/src/site/resources/images/james-server-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..f69394f6bbee48b5b336395a573aa484fe1e05dc GIT binary patch literal 6944 zcmWkxc|6mPAO3tk+w8E-%ze)>cNs;Y_%OH9=^LqY!p6C5~|M5J|u1;GmLv_J0U;+RJRY#^L#+n)$-(9#+ zy+3^Y&w6}p-1uGlNG0VswXXG*g(dO&`uZY+!B`s}&P~lsA(7YD*FJoB|F25w^6WKb zd99Ji1M9yA*2H4*>UwK-`ufKY$$R6)OMgGF{}C@Oj%r!KTWpd%yu_b>F5GSvul+J5 z$1bgZUlp%brx6yve_35y`8z8-Zejk+!>YIX>X*MCYpScS+S~8<3O^L~&+P1r)wRDr zmzS?JTswcZq@(55)cg67fyaFQLjVB&)6`r={zm}7`2X<#On`)#ewY`pk%{&wQXk&ai<(K@^JgErzM-gvFd(D2gsijs=b ziMEO;C26XnVoXu-*%Ie`l$z;QS$$kQDm^wWBN5NZqe>T^t8ZvLgwn$q7@*N7GLmgk zu~(Y)JCx4or#3z6f9w~Zg}&Wpt}hwSxqn5!CQqriZ{XjTublPuskUt!+R#L*o}z_P z;&|qLNlE?h!j;v>v^N^EZLP$E7yv=fB#PjHYWmSGDbF=6w+h)%@Qfr7;U7IGq-VzC zw?v8dHt~{0bazl|Q_ts(QPtv-d=>$nLa{GH)O|YjbxCX=|IOqT1b3uF_vyGWVtPcsvaZ(clg4kUw_ryM zS{`6SG-Dx~#(|H$N`FO)PXh^x6j*8t_ncT!lPy9a@Hn0zDDl%yRJWu;m_((a?4$BC z1X~)1j?ml&r-9qw#tcX;JuAvJw1^Wzi9k759T;KLfMg|E$`kBQxuViDel4LrICBB3 zxKTBES!@g>{UR3El;n!=GEJRfR(aM+8jZhk6AmS^| zx9&s}NrH-FZXS~rk~(3&Fm`BOzM>}SxS=x^RD=-(&COhG!lt(zITQ6lE(9kj|rZKWx!)+CkEM9DSotW zAL%$wc2hPg;;VehRV}d{QR4PZV}fcllaH5roMV6GSzil)z18Mxbf?t+_G3e*wSP<*?VC1r68u=L)VR173Y%55{^Mit~opR}< zqn*Rw8IV0rP|d2ZzgDXrNjb>r$8NtC87F%}{tu(sa+s1jZu)eaAwfW_ooM}QxQE@a zlgNb~$z;1XqhVgA{i@m`!AA6^$eoLIvauuwXABhh0DW}}5E%>f?L&Z+Ckvxz2J-KOohq*THAPi3)8RUok zqZ35y58bbFwEeY1`Xz#-M9>qEAm>d#ec?(AYYfWBHnm zy~Zk)<5B?2Y&Ou=uBrYEMr}5no%Zu7)nK`$s8YOthXYN|M_FiDk!tbsByc1~oUTr* zNYl&?wc20Dg={!l(g}iIz4y#q2Hhr&_~^F#+etCCORUU{Whv-zL_h^_iiFL8TU zxG3-nQDosv^?`SLH3NaZFk$0yV%sZXbZ; z(*HJtq28i2bxL%2)Y;%AWf&kN*B@wIJHOs(vGKLb5XHH|LB@!i4s2cIv?r%hGJ9Rr zgg|Y#}$n)kX?dhIZVTN=oTa2CJt21Lp!wbFCB|ciprB-HZ zwi^B!3~XhE;nhVfRR?l0{|}XVexPiXMvV$~$rMB7wZw$z;Y1n}VVV8n-I4Z3=X2l! zxyZfiHTKspeyNJKPC*eaPXoG3%sO|!3~Sj`XZ3mDYGBwDBKz*MI;UfK+bF&#9D1r8maluh^IZ(XHL_sf(BxSx1z@J1reMKfis;a9&Ejp;TBG z3lLC_-0tC!|M6|kpC8$|f%gV{@;r-96DmRpRiDiQQIH`d`_r!rt=gr4g?~2o)Q6V; z8SML5P=czAD~*&fGK7MT)&zbEJR8JglS%vKz6r%8Iy#gf4el*Tkb48EOMV3m-@!k+ zMxOO{uvkJ$FvQ}U7Vo4oL3B_mH6jk`u*?kTe z?vCGXD&Z>Pf$6l@dQa}2@6NB2QD1Y=t(!qdI)xHnsvfW&zkC0LN2(@9`mLM@s4+k2 zsu4+H8|1a!8a^lySXWXH<}{8 zz?t(y%J{`g`r!BBU6_saWwcKLl5>+DJL06{Mk3}OOp)b^GPSm_03-|}HCEh}&JF+f zjy`#x_f4|*l6+K!!okrW#d>|pFalUd_f1O=Y3U|Mu-|_>ex?7ja zq7DQ;f>EF4z9wt_@zN7LpLSf?LPlQxl-lu2V$C;!{GO!aD8YS>ImkXqnA2oTQvk$E zMy<;E2lv-^UxyOxzEt@1#Iym~~groMgMq*${F1wcp$Y2azZMePl?F*vUlcr!Oc9fe1PmrBY5mk@+FZ zEh4V?y}E9Pn~G2916IDpRkd^@Ch#KFgBx~@kFp;v4g-pNcbEU1$>&7twM{IfsN25- zgLUVs&SMJ;&B;1V>3aiTVw#pgX^YdV+M-laO&%W|0Dzc-T!hh&r*xth%PrPZhNiKh zBo-J@5K<&c(sW;xltU&5V!0mo;LTyXvcn=zePl4_KMah$BopT*1|P6LWbj1|o4S@r z3aQIwywtDzU!vzU9+Ep_-)bcD2T%C3{_VBH%P#4;Z4rW{zW+R(aA(LP-qs+@6t+ih z^4N;DGSxo1k(VI;E<(30#I}>lE}8}6^ccpe0zLTz3nCPT%W&RJLj0CE&i&wE zDnOWRP1`(;2>F08l|SB%+DB)k*)!rr{Ydu@DUPB9Q@=Fxgfz>Q6l*`EO&zjRB=<%u zNdw-T!IbKahN!>LimVt=5M?5Ql&L$+OPqq1fC+~kDt)`ZS~y!$O!mKnDgyUZ}FJ!_**y8jd8NhC)h)`Fev@x*LGyQyo)>2e*s;%q+ht`7rg9(YKRMo zCjmMzM269wKIqqE5XVJGQJ@WsqC>rit#W|dHI}w8FT@*hyb>~j0a>iqb_SqA@*>h8 z6Izk{Dx}Sa6XTp8Hv(ypJu(e$U_^M8A~Li+gX4z7Xea= zCMO{T542`^TG1dRBg#w!s&GLwZHOQ|e)L3{3Jl53KrTv9>lCEJ0mEC^ik#D5xI3hI zU_Ml)!$&|AXu<**if0tbrGgX$hGDW@P)x}JOlUf^*GGRJS8UV^@~4#Uh|Z~MN7f!d zqL>#$bIy4(IKBHzCrS~QIfOzuTbUU}5d!Z_^|Xb+(d!_Mhj9A`k%9%yVCX4S&U+1* zF_K6?S;}=#V3}v;dfBv8DT9={oh@%gg3N@#cnl=Xhf=U*p$=+4qybG9Km>~V$Y&9Z zs3zBZU0qb+FNcfSNMnqn_>Muvihhuc_3RKY4o)(zEu{@kwH=Nu@JPW|Z` ziKs({sJw6tik76K9H*x#c_0VS;wefC^j=3JsI<$Pzd(I1q#j*Og5?SX?3wv9nX3@v zf`ToNZO8>CWSODC)KdRruYCEIA#hH6*+Qpb07_d-X6MQ z4+HNE5I2|&I~Fm|7miyo;cgbB>9>7S7qLviEaXDtN*7eP0KM&uwy2uK<4jdH%=$NN zosnINhWNY!Uy^k<>OgQAPe!?RC#TR$$r{(eOMhR<)klr<2`#^>l?C-bnj2Lp;H3+o zktn~+EZbx5xCv#WEff557bUq>&l2ri@pfd5|zu%0C{)I zC&Qy0!mbg4t4JPbBp|6Iq#ief8PO?cT#&aU(g;b-JAw4b!-}`!kb$2NVwnh3zm?~A zPmP4ZdP^*JT$*}f(eOjImqQ!)b`=U}hPLDaW*p4q!Bq8VZbPnae6+4wG&CUr5^0S# zo|IG9!GaP*vGrZ$=(}Yqe(9`+wZmn7qk)b38j@}()xlQp0iJxv%}#8Eq;-8)?!99H z^$sZ90V*=;MRNvxar-@tq3BSGGWV(0<%YqQjYF4M9i-7^$n_?|Vn)ucC7+80-EYcB zj@K?_<~QeJU-+pzWd_OH-Flk?r~<934ysi*QJ9M->72r+zNkYtk*f#KrCFT(^eHm< z=Dn*JO%}g-#EM2t1$P8QZJ?1f7-vivMDvw~;KUdAAR;5NN8fc6(F&^l2~#|xXB9`0G_*(nHd zV%>BR^>5jRdUWj}p5I))kAUYxwr&7E74kQ2eYaTMWU%#&AtF$@Wa}z|{0CynU`9D% z6Z9&J>!fGCNl3=Eu~LkgktY2QM%|9Mxfm3ad6(WEO1iLLt%HXOpRCN1=-nlHATkPS z4fk02jaZ!?X0V219N{y=4<&S{cwvKh5YQ7*l;HDyW3?uvj7!GI8P4%d7w<%lV#e>7 zng|EeaqUqb266D_=|wsIHVm&Ht(yf>d0_nP(5c+Io1zj1=YfAmME6AE!H8jJPLF48 zp^G3A|F&iR!lH0!A?OCa3z-FzO;Y+VgtI=x2d5&`cLT^Oz3FO&LD(#Yj0HTW}^woeLb% zgM82Avf7&)*0A~w@rgbM;i#~8=C8hKNcGmPN_LGTWW}aBhJuU0jjgDGT{6@ zZ{c)F5AvEynVOXqo8SyV6_*XWL9{40>VoD;Ez7#=}pJP?K>+N)SI z%BOr6cU~^(^m-pW=D8cvJAyG-S1^7l7rv2-V=lys(8YhcG(;Flf#f!}^G~~N-z!u5 zeSq^t4dTYmk2{zE`U%p(`QatMnv#_Ho4>t+XR_rJXUFnKpQXH0HTr~Nj=yLC%8%@$ zruc?Oy?2(kI7FP?{hBlcUp{TQQH^%{-Q6y#Bfe~mWE+f^bNnA_zfjtCgdo&2_oYY&L$%SJ{!Xd2Jero?$zjZyNxkPXj`5urL7bl$tq zhuS-%r*2zMlV}%~xQN#tn@i2q|0R4)cwp)3qfeZ6!XKlmOT9LyM+zo%0`OnB*Iko9@$XyZ`=s_Y_A5M{a^y}f1fxHCbUep{ zVvq!G;eSla2SCAyI%N@O-nufD^r{@w3*H#;US=_-mOYTJ$j45ii0+q>_d`6wFN%Bw z+@}N->l^ZYT$}fU7*0rqKVcy(G73S1+PT>>AVR|Y{9|VS)-|lnDENm1#7#=omHWu>n zW;BK|i4+z|lw2y-3Lzomtr*`|zMsPRsxqVlY>wc}%oJrE7@DdUvWkjFv@G^GIRsc7 z2|=1WF+CIw-F@8*(If|7j?=`27W;(y8vC!s$6Av2wI8;ht(s5%Ja*TxV(?qp>ii@LwpigzE-dgfw_;neJY(XQzRBfmcQv7e_FKPAQWE0nt zhj?9Q^~koqVe{}A6lk}>#X(UXL>Xa`4m`z0JG3KGHIdI0i|o3xim4vbeu+9gYT)X$ zxxka&mk&rJ3ur5dkW!pff(yfw-hbwH(ELo`MWp+=`>xO1*hXcI!L7dE*Z+@h(ZmN4vY|J_Bzna@DkqjBlpQhQnl$6SfCZ zQQ9XA@15C%g*I&7R@F9#IX=Y#1=5@}!fcbzlT z@ibPZ7OGwIfsT&Q4h<&Og$@{$MSdU9zuuXqk3ZHNYK@}&28!ra@It0?!n9pRW9jFO zkE!?1=Vd9sY=4ufmf-ROQxP%~+hPn7yajgPJ6an3!JiDIEb(Vern4r2<$=}DcsAy4 zIW{^?qDhxCHLpQ9x74S(Dq!Ze#G}h)ZH(WFOGH*_RPi%Y?zvj9o@Mn zIOfX&H(h#(rt7%Nn90o8W}j2}I7Pf_-ty`+Nc0o3u^XqEr=>jn<}ze#is!O43ly1I zs3(;rHZ;TL^e6{KcAZLlI<-V+*&%gk%bPq@>A4p=<6$Lb(W}JryNr{v7p8LI@beAA z^Ma$DcTc)qN?WoFuc(F{axgmjxB!%eCwQp0Y-^ z8YTwW!jvT=Yl$Mu`A*-i>vz4^`~B;8uJhdI+@JeC=X&nXIoI=fNT$a6B0`cv000p~ z1A-X<+z0?%8w56R5LJqfI|sOIdeY(q{BPrczZ=KnO#TV}bN)N@&xHTY|KA)A@*Dh} z{Qq+QxqoPAC@hnKuLzLg0(&FjXfB*(V6i}7AK2LePfu|BHlR>IemxX6G|ML@xVQcb`hfN>N+ODX88 z0YlEfSU;Hg06s5-EetpWurlB;CE%zF0!%=RJ;=HOs;+^~XfQzoFjoea5#TEq$cTi! zxp0&LX90&G6a_9WAT;zBJEf(7!2sjq9A2a#)PV2|gnke{fUuCm4u>yEEZA=f)GmV) zcY(zd;M4@XMnEW(jD}bWM6;nwDGaTJ6b3Bqhm3K~ZQ&Gb2|xe<6acCK7~)jBZ5upz z5E2N`))sns!N^FMnhMLx;AZ0CTF&uvIT`5_KqRk}0ml*aG_dvoKv?|O!__%-eU$_9 z`x>Gr_`A5dHty$rdC1(E6FY54z*__+%_K*~XYP^EJ>u(Z`PuPtf`ziwNtCuUdeb#! zzAJDp#Sn?CYup)_=5mh#3^yHpD{P(!nNZ?Slu zlP)?jc{KIVFdU96HW9gl=MUjS>j@m^39?b+W5Y>)i8R6ej!Z7z6vW3Q4EZ>GNm(vk z&;UVK%X!eca6G@n;Vv#-I|Cpzf$DNiA!)i7mHlL0xw%Ra?{Ylm3uysqM8w2ND3j+{ z;^)w?T&k}ku~0y{l-U^fju<>$O~4(|YVFJN^aw-F5c_Eoo6a4@RqQEK3G$QUk?WPs zAjvx5cyH{GS7 z+$oyz31L(rqUf@U^{$Yr`Kt%!+$JtGG@s?3N|``~EU&1krgUSDuKI|6>r!(o*_tS! zqtGEV-P}wL?mR|*zt=s4*X#0whZU2HV@u6G!QN!nAM>?p7EEH)XCJKeOxeVLxG?}1Z4kjNiE=L5NQ`^Z^7tO9S@nqbrQkS8^ zPv4ZmY&ASt;z}l6x$Fr-+L!v4Y`#(Bwu0nW+-Bh-*NoS!k)#-AqtP+Uz8~fH9X(~# zlg-V@V__!ahEc36`pFByHxd1ERKWI9_Id2J`a8(uhvbMV*AiK+oIj_e+s(}QrW26c z)V_%%=tpwRl{J zI{nnVN{D7oF0@mV586MlfJD6M1-K(;hUGpTJ!E8K`%3XlU^lmTo({A9nS+{JIw>P} z@j%Xud$rz$w>Nc$75S3`4dptr21(nT7iUkItTg@HTNZ;fn0x%hX^cbUW?dBivHR@;%-T4DKH$vh|Ht}$=!>sM?Luq|Pij4#2hHmG~L;kB*pc)`RQK)pIwB!-I^B zN?c3W0xK`{9=M{H-MWGYx+x}^NBzY-J{5l3SRwWQ|IlBb2qFVy;bE6sR$ zocATX@UK5^?p-SOyf8$+?I)F}exSc^M@xSE=Bj5#a(k#mSNr+d+-hr_ASRx=E3bOJ z`_jWM;=_GZM$Rk4XKG3|=%!O}V{yK>vE0+LmbP4=WF%0P7#!b|weD=lue#-_%7>R! z601$-On}LD-%VbztUn&PpM92Yrz7S(JJ{sWA%e@!=v|prj*Hp@JFNA>pHx}`D}mS0&0Rrd^M%~fa1uM5pt6jNx2XNKP&-Y0#f z;e{EVylh~tXdgt4Wb>fo8d-Nn4*lKTE<#oLYAYyhsY0<=-Ig7dS2Yn$>X{N zgE6CSW^PO+mMX?|L@rEU7InXh*0UN-cw#5RjR}cvxRwIL1FFS{yD3u)M>2K5c;p}B zIk0@5T=7`Q2{W2t5FIivjyF4wDc9sEF-NW5C4R2^WGyJ!!Sly&fFra;$aT3#c#Nle zc_?!DCX%*iUg}s6RM-nJ%X%dWAMOY~HIy62#ruDYbTOu($S;li6=*#owX~5l z@=5&$KVtojFq&NFo7Md?)$nlx*c)iW_{rB!Eyb<8wx8+q)*L8++f73 zIqqp0D%x4tqn1v88_5#>N$GjZ_xqRiO*C!B=0|Fp5-(qBkR|b_^1-NmMSI>6)g1<( z8G33Xib+y-6@0=nR3=6DjTuG*V|Dn})2^=jVRB+c%v)kx6FBt=sCbD2tW$TqrIl4f zZ=-lK_wT*`W$Wmt?B=yU2oH9x&Ah*Hb;abuOsVa_&%nzwalKJ*7k`YyZg1+O;2F*Z5cF zj;w#zz9s5F{_57!S?hi1r&oQVSKU(bl{GSbXwJe>&G%&O(D5E^cFHvIQuU!?v8$hpZ4oW&dJ8HlBBm`sx4$t+!4Tx+RYjcy4RPNPg z`$w>55S1YIvhCPC2_CvS`txP&jllO2pLMFvn~Bj@xBvZVP1fGG2G@`h>sFO|K-hQ2 zv#e^+r+V0*OkEWo*!wM*7q2jTHe{22TCAot3=3D*Y>n({EqSA}ZKqL;+sH*x@4_vI zXAa~^C!O8OlT#khQIi+TR)0r`ovgjSaNk;H*^;W+wAoJOoGqqyGQVZdZ7Yw?{u`pp z^o`o9$9uJ1tgHLd>D%kIS$n5nu^J1htSpJ*zQ*?-daDBt#w~p-*{CyeJ4#IY&s*{I zf;#=(Y)!kSp=bJOq-b9od4ALROp?{pZLLzxJk-b`R)ur{vtlxp9VcrhW+%Ktt$oQy zsxjKZ9}pg;9JAv_s?T_zNWot}q&Kg3zZdz}t@^k7QE^H1ob0_F$9d-sf5i+>7!wMP HIfnfQdu`W3 literal 0 HcmV?d00001 diff --git a/server/src/site/resources/images/james_config_secondary.png b/server/src/site/resources/images/james_config_secondary.png new file mode 100644 index 0000000000000000000000000000000000000000..2c29a53eba69116be76ab49f8679b18071103e99 GIT binary patch literal 5758 zcmbVPXIK;6wjMwM6-A0e6T|?DK;%FG0YL#7ngRytARtI@h9XM00)~JAQE8$HO79Sw z(xekg=zPD8LPKqhORatZfI|1;fFyaBKlwKt8Z%0kpXRI|L9c3dEv-0tJAq3QTDOumLaZ zAP@T+!I9oDF$yN-z|CZM2tXkKEeXI%3GmScA}oMpH=sNK=nMyD;sH1v0T-#l)pjsB z6z)rh$I0*#fIepG z07KMhIXGY>5>{1(&CFm71`Z8{lak<~BDgnm?a!kv#V{*G&Xlu-$16_ zmG6&}K|gA_HO#+nU#T6=T+(=iUmg`sbFfMT^S3y8IZIeV{$XjKdWq)=#E&CRK7!se z8Xs!zFE4E6JA;cj_B~X)f`Ftg9pygWP3y`c%m6;}_(vK2Au6TaiGo{$({(P3Xd4M|P9y=l@=QP;wMvh6OOp7C&hEuqa7{ho=f8+R`B>~*Uy zuQgKY=8Uf$R_s!V{kNiJ{r5=j=K?`|{j&1kGj7fDNQqga8^(mxrYvU%WXt4^PK*o@ z_7%B(PQ7e(q?GounZ61AVs!QqdjAgop|DvxGGFIL!Pv*cQ@77#W}WMAGvs;uTny~Y+dsYq@ znKgIvS~MRTBy4}X{i%P^gtZV#bddhW(LazAEc6TFYW?Lojg6ZCwF>Q5kBT*?h2;^Q zi%8|r@$uMZM_3I2K-LZfcN zo+$2$y}Mc#iRHGN)F^}L1|s;7)r5%$&bNt>z00NpotRT>bb0a8jV9@VDvI}7Z3}y! zgCde!@{Q?(k5^OGyBILlyytUM1JvejgvY<^3!q2NSoGBNJk_lyO7)+ z#L{+~Nu~$u`nTvb@)|Mzw5J9MjlAwwXvg@g`uwpz!!z=t8|Ndk6*)pf8gE$N~hRf@zi+gT(}`cwr341Yv)j0 zIUhDKiNdN5A+6ivyIpxG1_63dI(+ zP}*OR>8P@ZNSC8n)4O%J&3yf%-^~1fMmtQn4wHm`431wgBaR)ead>5Qr^Xv8Z&_IE zh&;M~-?yP6B7bNI;fB0BX(pPv1jcMSXyUc4(UW8m&043Spq64`(M@hw3KE$f7r)SU z(P^ghq<3Yu?0Ye+ByYAAdH~v%0(*9w?D?Xt{4d{{KZ-M%$|k8fzJvy*l|p z854Pb^<(a4QY&H1WjyDmO@+-|(Ni)8T>%Z*^Kujj3$4t{Yw_HD9@SK?#v@ZUjMDA* zl))bTg>!!~7F9kO69`}CcQ$#&>60Qkj9HR@b_6NX^x$qkjSe<~C1aoT0?N)G>LYLo z&AFpDr?FE7!dIs?;}L5P*BZ&bhGA9|&YwTu6<(cpN5e@prHRmf)39Sa;XSl&vor*5 zHP;Wai=WM{0^3O@Lh=>(N2Jv4uq7uJpV@1J1U%niHy2+L4%hcp&bjGppM&?5j8KGg zq1qnz1&dMcERWSFTBb~IS02uE=2LnzcCn@Ia@iyY=MKbi5ewD`e}n#B5*II`<|0EoE$7;*nQUG#ms<>Xd?Bg1ZE#jS^<-`H_mid)x0U!#gFTmH z^JV0=l1)^He<7nxZfb@>Qa)Ufg&NEr7tb*@g}I{ZI$Gmwn>n3y(xA1vsB2$l2c^<@ z)>G@qoYBWtSETKcgNW7YLX9b-Rz%#`8hG3GAxD@C)+sVO1{&KhJuNDs{Xq*vU%+8l z!h$J`GtJpmgw$HDB8{vVaDA5YmW1O1XGP0B@RP2B`C>n>$i&3R7Kn{~MM@4L0&I<5 z=WDbXXMB`D+#%-iTd=Hb04%MC5@J_5F*ocf0fLfZl2ZmR*zA3?9GRD!s`b_}c$cYg z3_e_`pwakSw5=E|-4S2fFeP>>4boBB@GP32C6tazl~ydm=dF$k(&7)eQtU6vjIcbV zambolgVR)=Js5ICUoxsvy{=J>59syJz@AW{gn0S9h12*DD@K^AX0Nu~WB!Y2+3CWR zyJ= zLcUQ>hwg5qe)?ZOH&u5vO*^7x zjb^x7kYm!0;2BVe&r~p~flv^U23f~!xA$D>J<%qx_EnR0JLDSISR~#}ue5h^w_N^P zd+N7D9g>EZS61d|y+~OKskJcF@bffd5NlhwrfIImS9ndu<;S883i2=$WLt2>zs`%j zEY`Vtg*Lil^)h!p6FwD6zQiV-=6%y+^lQw&b!js!$_uZs};pgw0O9&+s)`CsV@>I|i$98kyL(ax`(YWreq{SmB`} zYhUj$R>z+OiM+!TlW`|uu5yqn9mj67cucA!r?uZ#F23qrYA5ud;@Y1I8QENnJH0IY z84_d5bt;YX#Efa3Z&|KOpLA+pzd3-}$wG?}O^VDFOZXz<5XWa`$Z2QXkg{|V%tt~P zv09-enH1IZAQDk8yf`%e7-p-AAZgu}#CimzIgcq2TjQ(EQ+j8uSkAPnnkgIHwbz|> z@z;saz!ud-mn+YlKQ$VNh}_tVh#Ob7&|S4|qhVz6W5#(}<1={!lyiLSt~P7=bT}Ew zUbu4ar`x9)9p%dwmuvf5(4|ZPCTn!uFp37E8)szJu>M}}D@8~B8M%v{!_JP$1 zj`SnNz6GZCX9oo4t;u)r%V@)T9PISub*Pr|b&5jV^95#FFmYj;m<3TTa23dqQ>#Xa znFQb2czKmLb-j*TUacG$(TD1+bssHgbSk?&Y;CdD_Gj7HTEmhB3L1=9?9FPO%-E+{ z#L7fdp!%|Hu`H-vNDUf>0;eF0=p-apDlXe)bjm$(*llu zzdc|GDmD=t*bDv4YL9jmMIKL{LaHWh2P8nf1FylJJxyg@Q-#l^47x=cq-(B7krhTz zJIoDl-qVkWRL>XvSp1K|!}IhZ591&2_nPR1eh&%OUsE@g>GO zDp&Y;LkS~TO;G*)ZGgF4Exv=G#hg<`_y8hn(kDHvOlqyrLWamUbbjWCup)U*rKjH` zo$3!XW`#LlvLOF=1Mxx;C&6st~RYjy8qjn?O{v`w2& z?r}*H1(sbj*4N{OKX)$Z%Ig+5M3FRxW(ja)xwSQ_)S$lbOOM)i-h5y6Cb9%5_;vhi{|A`X%4w@_DbqkHyU(w(DzB{#s!|D#H z7)KklOa`BUXLvY7%b(?*`?n2%jr-eNxv771|Hl(3qjPpwyXp}5Xz+j$|4EGgy8%-7 z{LYo6FuO4iP${wgFB*LD<1F?)OX%qDF!3O>wNw-TmvkIg6*w0t{H!a4iP1NG4l9f$ z?=60x$_sqK1%zd*hC{u|qpK@bDG7U3Y}F{EgWuVMR;8#}p~AdKo@FgId<<#Alj+LX z!W}1KAVzfNhMFIXI}6WmY_hU?_>R@Kd$bIk&3UVMwcYKdi=1VVkMY{c@XMQ~lPz!? zb2w`K^70V)13!@Ro|}I)ebXaB_N)0Z^Tq3ij$w}(s@C&XsKw(i7?DJ(n5_wye8!!z z#rL=0p*T`QVt(2fJwT*@44@*b-d^cAq7pJ?W(1#i7sA}yW*3Tn8sF7mz`X-X>Bf@8 zqr|8ES*9o4qhb?(Y!N0Nsqxb~&>nmjuqzZY|B34V(`#7pOfN5rucl^L?zhXq=e9QY z*kprtzvTG+LcQS_2?t1fb!}r%pX;vBo1o3qfYRkOXg}bw;;~)i6Uo5Hs~lT8-NH45 z5tMiR{^Dbo-H}rK+)B*+t;rp1;; z7M(pY6Z$B2LS-O%|JO7+Np0Z18D{-MhGx5Rel92QAyo zrwl!G&mWYJ9?IBtVX;WUxqk!pex8YvdXo@;b+L12!M3djk)8A>2+LRC%z)d^4&(iu7dca! z1E&XXEo8NxyOOt;urDw#J81Uim*2iXx-rwk3h9CX=bcwi?qA`t_w5Yd5VfC-#^C3e zAw(gEN1brAezhL9;!5=BdO*=rC9%rEErTG>Zwd+V5lfm`of+e|2CpVRFRX62@7b8G zld+|k**yqcElM_s37A`*Hfp(1FSJQGwSc2|satkFxmv+~Uxois-?jpTU zwFtYr`v*?quO?+rgvj|y5pagMhNSwvL7oOn*Z7$gRV#PB>S4~W;B58I#$ik&C0B^q zGe~j7V^*LE%lF%{<1W_oguMk>qHKc%rHBT>GI_(4!2mh+zMRFFA*vSZoLb964;$i#hX%N3#oqFH_s0FP6)u z%w!Tp)nb#&)CR-%P3hq)+1=ldJTk8MRqqiuvnL9+adF8#tEtV16CbE3)+sry+;uE( zIeock->3RB9ig2g7Nl$;Hg<;3bF`IA_~Y+0)Upt@Jlu2ItlD#JTOJ;&w8yL^N7OuC z`fPw?Xi5zG7B%nfUK8l~i*8S@{0ZaQjsxX$r>pEvUQnOkW4Q;v`p?rzdi{uxO^Ez zL;wT<4<3M~CeYUhW@mYY@P;CUW)KEKmJRL101pPZS_|TPK-M%U zhM*G4KZAGTJfngrxsfD#R05un8ccn%b3B|@t_=vxI- zUck~}$N^XY$N;zl5DP#N04xB;ctC+Pl*U3V36fl(3k}i`h%h0O^M_v?kfec&JfJB7 z1Php2fP)8I5`Y%6@H`F%TfszMn3n>pO5qC*90vagNFG+=;WHP=iH7~faGV3@0S^#~ z1YBGIjrIo}CKGTtfXn4^k%bTkp%sL_5T-y_%A>>MC5;7p$w1v57{mheBH+XVo@0Op zrQ;zMfusWH!i2O&h;ShDE#z={-NGx_0swyi5CCcc80J+gApw<@As!Fy?4YM7jE;sm zIk2)4Qad{-yhh=3GBL!1=zqx?@e-lSMmF96tl#vZ z{@As=b7=4Ic*$Ya16$0*$9}j9OHuf>uG5H5{pC=L3A@B~z4%ksEv=*Sk2&TGRD`MX zNgYGW3E*Xu`09k(0ESOWj!P36B^_Iv#7lJrDS*n4p%Ft+w{vy9>#O^5VyeRtDf;x} zX-5>|^9`LHrR5po+qCObmiBRU zc?)CNLg?^Ql%PT%Tg^e%x#vj42C+onBtnah>9$)|3eN&4iJ#G7?|I7Wy3CQg^yA(g zc~;*JB3GPcDJc~?fy)-U=eOH*=Dx}mk84}Ze90L2!N4VdnU>JuWc`R}clK)jb_*xe zG5#vNqw>)M;(W$!8?^Ndxf(Y;Vfi(kEuxg&hpBN5a6(QS=cF~+n<%8SQ*oZ$ZjBVz z0Myd)1Tl;vE8B2sk&I{0WFT&egqg$v;M`g&ZRg!Ib{`Gac zQ*?Y=u=d6LQ{<3B#m~!`Mtc|0KFZzLgcD^prhVk~F5NMQ5-pDf4;fEgagQ`qp$FU~ z9h?q$)Z8vmA0u&MCmr)}WFoAFy*wb2Xp7#U%H4*mS-Vh$k@}r2N--0##2tKaPyiD~ zjFjn|#3a^V>p*#!#LkUYVn=#GZCci?-dM>-Dn<`2MPl6_np0rgd(^An^U_EZ!JRds zx9u*gwRUFRWS{(bMqntAhhtGxZ@_g%rTGlieeIzLNNL#-Qs8 zeZ^An<#nw0o!6;P{4c(Nah!K^w@;0`rDZ8){~BSOP^g)^u>m&}$PKx(L@@nc5Jha@ z-Z_g!Fj8q*6ot<6^#FNn(LkEkreetG06nBFt0=(Nc`TKiDR#PaW5=>V;dMc8P3fBi zU%}n|8K=Dbo;~hqmf?~zROycrs8Jq1oew^{?=x{Wd(+SYyI%LR;V)klv zXAOHZrrXw&GM1j6(Kx7Gc>IQ8Q7XY=p|!;4VScvr*nHMwv7wL`>Y>#^tV18n-qZ~} zbzNzQ`RFT%ti&$wm;aKMmSui`B2krFSCt&e$xWHZNPWsap&Q_kC7(MmlUF#-Tc(1$U<~=vxwWbUXGKYf&vC-_c@(v)P9YWpb;(2aPb= zWc1Mo6+1fFjE{o_;+PsYBv|O%HB60+H)l8u>CI85a|Th=Q>ygh=fB=f{P4yo3f+_X zbe)K{csFCdR%;Wo`BD3ktA*p$1CtZPw0JsUsra^I{;ABS-x)-&&h|lD#rSTaBa^yQ z&$*qU;yxZ{GB~H2)$Jmv^LV4V}r2S~{!a5o4dkW^@%UhQD5o?hvB(SngFDkKs%GURXms5$dP_=jq14NJi{| zkJb#uPm4LAnb~F>C4Z?kC~5D8?OBU5M|<-rBHH&i`5oQtvu5>si`Kbd<;bb;^7fl? zeZ@P{ez-+iADUfLTp)lEpQuK?8E$894H9BmF#0c!o8OZxosEg@rhgEkmL`vol8!WN zZ8rIe9&|zm-<|rBnV|y|B`qxm@)$bZfo)(=@%k7G`El)}9Dr^rEwTBOxDS zZ-&AklKH}UqEGB(JzLgs;3_$y_v#f5KBSA3 z-e5ZvIMvn?*sv2d9I32tg7*9JMBf(ep{g5wpSVuDGITN{`MPq#Af|kWiq$)U%hJ@Z_Vef-_dr)?M_8v~YVQiW>C3%9Crq#jUi-*m~L z>OlETo{^W_^()LT_hkRliM%qnL|qrEuj(3<&kW-(W}>JDYAM+<(jz8~H6+sR-AU)0}J zzD*+zc_BC}9+JVnUSiUCc}vJ8ROEljRiJA_n`)hUeP3DLr#ChBl(iSV;ZM+*3Wj*$ zB{#>8N2%rfh~&#KX5C#2mZqW5x46;!?XOmZ3O(93=AP9&8ZxM7aLKF8@>tMo&5?&% zT!~8;N-Vp|d4F;$sLS~?y;nsGdw^-(rEDB05uBZO1 zpU3A<6{+e$2Htd|+T3u9!otAxYKc~8U_3Dpw!qE(7ok>jf&uHs#swDTCvx-;!QkwC%7PZYFP#cvEOuyU;?d6Vo|FPS{j z_g+ldwhhdadn<{I){~gcacNDltFyGZ(c~kt&V2f#jiZZ3svl`9a((+AYq}OK`N$lbehiyf2-5zCUjEzGXzLF_=`A*|Jw@5POEUljgA@3NdXC}$2BZoUHUIzs literal 0 HcmV?d00001 diff --git a/server/src/site/resources/rfclist/basic/rfc0822.txt b/server/src/site/resources/rfclist/basic/rfc0822.txt new file mode 100644 index 00000000000..32041b362d5 --- /dev/null +++ b/server/src/site/resources/rfclist/basic/rfc0822.txt @@ -0,0 +1,2902 @@ + + + + + + RFC # 822 + + Obsoletes: RFC #733 (NIC #41952) + + + + + + + + + + + + + STANDARD FOR THE FORMAT OF + + ARPA INTERNET TEXT MESSAGES + + + + + + + August 13, 1982 + + + + + + + Revised by + + David H. Crocker + + + Dept. of Electrical Engineering + University of Delaware, Newark, DE 19711 + Network: DCrocker @ UDel-Relay + + + + + + + + + + + + + + + + Standard for ARPA Internet Text Messages + + + TABLE OF CONTENTS + + + PREFACE .................................................... ii + + 1. INTRODUCTION ........................................... 1 + + 1.1. Scope ............................................ 1 + 1.2. Communication Framework .......................... 2 + + 2. NOTATIONAL CONVENTIONS ................................. 3 + + 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 + + 3.1. General Description .............................. 5 + 3.2. Header Field Definitions ......................... 9 + 3.3. Lexical Tokens ................................... 10 + 3.4. Clarifications ................................... 11 + + 4. MESSAGE SPECIFICATION .................................. 17 + + 4.1. Syntax ........................................... 17 + 4.2. Forwarding ....................................... 19 + 4.3. Trace Fields ..................................... 20 + 4.4. Originator Fields ................................ 21 + 4.5. Receiver Fields .................................. 23 + 4.6. Reference Fields ................................. 23 + 4.7. Other Fields ..................................... 24 + + 5. DATE AND TIME SPECIFICATION ............................ 26 + + 5.1. Syntax ........................................... 26 + 5.2. Semantics ........................................ 26 + + 6. ADDRESS SPECIFICATION .................................. 27 + + 6.1. Syntax ........................................... 27 + 6.2. Semantics ........................................ 27 + 6.3. Reserved Address ................................. 33 + + 7. BIBLIOGRAPHY ........................................... 34 + + + APPENDIX + + A. EXAMPLES ............................................... 36 + B. SIMPLE FIELD PARSING ................................... 40 + C. DIFFERENCES FROM RFC #733 .............................. 41 + D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 + + + August 13, 1982 - i - RFC #822 + + + + + Standard for ARPA Internet Text Messages + + + PREFACE + + + By 1977, the Arpanet employed several informal standards for + the text messages (mail) sent among its host computers. It was + felt necessary to codify these practices and provide for those + features that seemed imminent. The result of that effort was + Request for Comments (RFC) #733, "Standard for the Format of ARPA + Network Text Message", by Crocker, Vittal, Pogran, and Henderson. + The specification attempted to avoid major changes in existing + software, while permitting several new features. + + This document revises the specifications in RFC #733, in + order to serve the needs of the larger and more complex ARPA + Internet. Some of RFC #733's features failed to gain adequate + acceptance. In order to simplify the standard and the software + that follows it, these features have been removed. A different + addressing scheme is used, to handle the case of inter-network + mail; and the concept of re-transmission has been introduced. + + This specification is intended for use in the ARPA Internet. + However, an attempt has been made to free it of any dependence on + that environment, so that it can be applied to other network text + message systems. + + The specification of RFC #733 took place over the course of + one year, using the ARPANET mail environment, itself, to provide + an on-going forum for discussing the capabilities to be included. + More than twenty individuals, from across the country, partici- + pated in the original discussion. The development of this + revised specification has, similarly, utilized network mail-based + group discussion. Both specification efforts greatly benefited + from the comments and ideas of the participants. + + The syntax of the standard, in RFC #733, was originally + specified in the Backus-Naur Form (BNF) meta-language. Ken L. + Harrenstien, of SRI International, was responsible for re-coding + the BNF into an augmented BNF that makes the representation + smaller and easier to understand. + + + + + + + + + + + + + August 13, 1982 - ii - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1. INTRODUCTION + + 1.1. SCOPE + + This standard specifies a syntax for text messages that are + sent among computer users, within the framework of "electronic + mail". The standard supersedes the one specified in ARPANET + Request for Comments #733, "Standard for the Format of ARPA Net- + work Text Messages". + + In this context, messages are viewed as having an envelope + and contents. The envelope contains whatever information is + needed to accomplish transmission and delivery. The contents + compose the object to be delivered to the recipient. This stan- + dard applies only to the format and some of the semantics of mes- + sage contents. It contains no specification of the information + in the envelope. + + However, some message systems may use information from the + contents to create the envelope. It is intended that this stan- + dard facilitate the acquisition of such information by programs. + + Some message systems may store messages in formats that + differ from the one specified in this standard. This specifica- + tion is intended strictly as a definition of what message content + format is to be passed BETWEEN hosts. + + Note: This standard is NOT intended to dictate the internal for- + mats used by sites, the specific message system features + that they are expected to support, or any of the charac- + teristics of user interface programs that create or read + messages. + + A distinction should be made between what the specification + REQUIRES and what it ALLOWS. Messages can be made complex and + rich with formally-structured components of information or can be + kept small and simple, with a minimum of such information. Also, + the standard simplifies the interpretation of differing visual + formats in messages; only the visual aspect of a message is + affected and not the interpretation of information within it. + Implementors may choose to retain such visual distinctions. + + The formal definition is divided into four levels. The bot- + tom level describes the meta-notation used in this document. The + second level describes basic lexical analyzers that feed tokens + to higher-level parsers. Next is an overall specification for + messages; it permits distinguishing individual fields. Finally, + there is definition of the contents of several structured fields. + + + + August 13, 1982 - 1 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1.2. COMMUNICATION FRAMEWORK + + Messages consist of lines of text. No special provisions + are made for encoding drawings, facsimile, speech, or structured + text. No significant consideration has been given to questions + of data compression or to transmission and storage efficiency, + and the standard tends to be free with the number of bits con- + sumed. For example, field names are specified as free text, + rather than special terse codes. + + A general "memo" framework is used. That is, a message con- + sists of some information in a rigid format, followed by the main + part of the message, with a format that is not specified in this + document. The syntax of several fields of the rigidly-formated + ("headers") section is defined in this specification; some of + these fields must be included in all messages. + + The syntax that distinguishes between header fields is + specified separately from the internal syntax for particular + fields. This separation is intended to allow simple parsers to + operate on the general structure of messages, without concern for + the detailed structure of individual header fields. Appendix B + is provided to facilitate construction of these parsers. + + In addition to the fields specified in this document, it is + expected that other fields will gain common use. As necessary, + the specifications for these "extension-fields" will be published + through the same mechanism used to publish this document. Users + may also wish to extend the set of fields that they use + privately. Such "user-defined fields" are permitted. + + The framework severely constrains document tone and appear- + ance and is primarily useful for most intra-organization communi- + cations and well-structured inter-organization communication. + It also can be used for some types of inter-process communica- + tion, such as simple file transfer and remote job entry. A more + robust framework might allow for multi-font, multi-color, multi- + dimension encoding of information. A less robust one, as is + present in most single-machine message systems, would more + severely constrain the ability to add fields and the decision to + include specific fields. In contrast with paper-based communica- + tion, it is interesting to note that the RECEIVER of a message + can exercise an extraordinary amount of control over the + message's appearance. The amount of actual control available to + message receivers is contingent upon the capabilities of their + individual message systems. + + + + + + August 13, 1982 - 2 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2. NOTATIONAL CONVENTIONS + + This specification uses an augmented Backus-Naur Form (BNF) + notation. The differences from standard BNF involve naming rules + and indicating repetition and "local" alternatives. + + 2.1. RULE NAMING + + Angle brackets ("<", ">") are not used, in general. The + name of a rule is simply the name itself, rather than "". + Quotation-marks enclose literal text (which may be upper and/or + lower case). Certain basic rules are in uppercase, such as + SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in + rule definitions, and in the rest of this document, whenever + their presence will facilitate discerning the use of rule names. + + 2.2. RULE1 / RULE2: ALTERNATIVES + + Elements separated by slash ("/") are alternatives. There- + fore "foo / bar" will accept foo or bar. + + 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES + + Elements enclosed in parentheses are treated as a single + element. Thus, "(elem (foo / bar) elem)" allows the token + sequences "elem foo elem" and "elem bar elem". + + 2.4. *RULE: REPETITION + + The character "*" preceding an element indicates repetition. + The full form is: + + *element + + indicating at least and at most occurrences of element. + Default values are 0 and infinity so that "*(element)" allows any + number, including zero; "1*element" requires at least one; and + "1*2element" allows one or two. + + 2.5. [RULE]: OPTIONAL + + Square brackets enclose optional elements; "[foo bar]" is + equivalent to "*1(foo bar)". + + 2.6. NRULE: SPECIFIC REPETITION + + "(element)" is equivalent to "*(element)"; that is, + exactly occurrences of (element). Thus 2DIGIT is a 2-digit + number, and 3ALPHA is a string of three alphabetic characters. + + + August 13, 1982 - 3 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2.7. #RULE: LISTS + + A construct "#" is defined, similar to "*", as follows: + + #element + + indicating at least and at most elements, each separated + by one or more commas (","). This makes the usual form of lists + very easy; a rule such as '(element *("," element))' can be shown + as "1#element". Wherever this construct is used, null elements + are allowed, but do not contribute to the count of elements + present. That is, "(element),,(element)" is permitted, but + counts as only two elements. Therefore, where at least one ele- + ment is required, at least one non-null element must be present. + Default values are 0 and infinity so that "#(element)" allows any + number, including zero; "1#element" requires at least one; and + "1#2element" allows one or two. + + 2.8. ; COMMENTS + + A semi-colon, set off some distance to the right of rule + text, starts a comment that continues to the end of line. This + is a simple way of including useful notes in parallel with the + specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 4 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3. LEXICAL ANALYSIS OF MESSAGES + + 3.1. GENERAL DESCRIPTION + + A message consists of header fields and, optionally, a body. + The body is simply a sequence of lines containing ASCII charac- + ters. It is separated from the headers by a null line (i.e., a + line with nothing preceding the CRLF). + + 3.1.1. LONG HEADER FIELDS + + Each header field can be viewed as a single, logical line of + ASCII characters, comprising a field-name and a field-body. + For convenience, the field-body portion of this conceptual + entity can be split into a multiple-line representation; this + is called "folding". The general rule is that wherever there + may be linear-white-space (NOT simply LWSP-chars), a CRLF + immediately followed by AT LEAST one LWSP-char may instead be + inserted. Thus, the single line + + To: "Joe & J. Harvey" , JJV @ BBN + + can be represented as: + + To: "Joe & J. Harvey" , + JJV@BBN + + and + + To: "Joe & J. Harvey" + , JJV + @BBN + + and + + To: "Joe & + J. Harvey" , JJV @ BBN + + The process of moving from this folded multiple-line + representation of a header field to its single line represen- + tation is called "unfolding". Unfolding is accomplished by + regarding CRLF immediately followed by a LWSP-char as + equivalent to the LWSP-char. + + Note: While the standard permits folding wherever linear- + white-space is permitted, it is recommended that struc- + tured fields, such as those containing addresses, limit + folding to higher-level syntactic breaks. For address + fields, it is recommended that such folding occur + + + August 13, 1982 - 5 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + between addresses, after the separating comma. + + 3.1.2. STRUCTURE OF HEADER FIELDS + + Once a field has been unfolded, it may be viewed as being com- + posed of a field-name followed by a colon (":"), followed by a + field-body, and terminated by a carriage-return/line-feed. + The field-name must be composed of printable ASCII characters + (i.e., characters that have values between 33. and 126., + decimal, except colon). The field-body may be composed of any + ASCII characters, except CR or LF. (While CR and/or LF may be + present in the actual text, they are removed by the action of + unfolding the field.) + + Certain field-bodies of headers may be interpreted according + to an internal syntax that some systems may wish to parse. + These fields are called "structured fields". Examples + include fields containing dates and addresses. Other fields, + such as "Subject" and "Comments", are regarded simply as + strings of text. + + Note: Any field which has a field-body that is defined as + other than simply is to be treated as a struc- + tured field. + + Field-names, unstructured field bodies and structured + field bodies each are scanned by their own, independent + "lexical" analyzers. + + 3.1.3. UNSTRUCTURED FIELD BODIES + + For some fields, such as "Subject" and "Comments", no struc- + turing is assumed, and they are treated simply as s, as + in the message body. Rules of folding apply to these fields, + so that such field bodies which occupy several lines must + therefore have the second and successive lines indented by at + least one LWSP-char. + + 3.1.4. STRUCTURED FIELD BODIES + + To aid in the creation and reading of structured fields, the + free insertion of linear-white-space (which permits folding + by inclusion of CRLFs) is allowed between lexical tokens. + Rather than obscuring the syntax specifications for these + structured fields with explicit syntax for this linear-white- + space, the existence of another "lexical" analyzer is assumed. + This analyzer does not apply for unstructured field bodies + that are simply strings of text, as described above. The + analyzer provides an interpretation of the unfolded text + + + August 13, 1982 - 6 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + composing the body of the field as a sequence of lexical sym- + bols. + + These symbols are: + + - individual special characters + - quoted-strings + - domain-literals + - comments + - atoms + + The first four of these symbols are self-delimiting. Atoms + are not; they are delimited by the self-delimiting symbols and + by linear-white-space. For the purposes of regenerating + sequences of atoms and quoted-strings, exactly one SPACE is + assumed to exist, and should be used, between them. (Also, in + the "Clarifications" section on "White Space", below, note the + rules about treatment of multiple contiguous LWSP-chars.) + + So, for example, the folded body of an address field + + ":sysmail"@ Some-Group. Some-Org, + Muhammed.(I am the greatest) Ali @(the)Vegas.WBA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 7 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + is analyzed into the following lexical symbols and types: + + :sysmail quoted string + @ special + Some-Group atom + . special + Some-Org atom + , special + Muhammed atom + . special + (I am the greatest) comment + Ali atom + @ atom + (the) comment + Vegas atom + . special + WBA atom + + The canonical representations for the data in these addresses + are the following strings: + + ":sysmail"@Some-Group.Some-Org + + and + + Muhammed.Ali@Vegas.WBA + + Note: For purposes of display, and when passing such struc- + tured information to other systems, such as mail proto- + col services, there must be NO linear-white-space + between s that are separated by period (".") or + at-sign ("@") and exactly one SPACE between all other + s. Also, headers should be in a folded form. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 8 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.2. HEADER FIELD DEFINITIONS + + These rules show a field meta-syntax, without regard for the + particular type or internal syntax. Their purpose is to permit + detection of fields; also, they present to higher-level parsers + an image of each field as fitting on one line. + + field = field-name ":" [ field-body ] CRLF + + field-name = 1* + + field-body = field-body-contents + [CRLF LWSP-char field-body] + + field-body-contents = + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 9 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.3. LEXICAL TOKENS + + The following rules are used to define an underlying lexical + analyzer, which feeds tokens to higher level parsers. See the + ANSI references, in the Bibliography. + + ; ( Octal, Decimal.) + CHAR = ; ( 0-177, 0.-127.) + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + DIGIT = ; ( 60- 71, 48.- 57.) + CTL = ; ( 177, 127.) + CR = ; ( 15, 13.) + LF = ; ( 12, 10.) + SPACE = ; ( 40, 32.) + HTAB = ; ( 11, 9.) + <"> = ; ( 42, 34.) + CRLF = CR LF + + LWSP-char = SPACE / HTAB ; semantics = SPACE + + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + + delimiters = specials / linear-white-space / comment + + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + + atom = 1* + + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + + domain-literal = "[" *(dtext / quoted-pair) "]" + + + + + August 13, 1982 - 10 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + + comment = "(" *(ctext / quoted-pair / comment) ")" + + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + + quoted-pair = "\" CHAR ; may quote any char + + phrase = 1*word ; Sequence of words + + word = atom / quoted-string + + + 3.4. CLARIFICATIONS + + 3.4.1. QUOTING + + Some characters are reserved for special interpretation, such + as delimiting lexical tokens. To permit use of these charac- + ters as uninterpreted data, a quoting mechanism is provided. + To quote a character, precede it with a backslash ("\"). + + This mechanism is not fully general. Characters may be quoted + only within a subset of the lexical constructs. In particu- + lar, quoting is limited to use within: + + - quoted-string + - domain-literal + - comment + + Within these constructs, quoting is REQUIRED for CR and "\" + and for the character(s) that delimit the token (e.g., "(" and + ")" for a comment). However, quoting is PERMITTED for any + character. + + Note: In particular, quoting is NOT permitted within atoms. + For example when the local-part of an addr-spec must + contain a special character, a quoted string must be + used. Therefore, a specification such as: + + Full\ Name@Domain + + is not legal and must be specified as: + + "Full Name"@Domain + + + August 13, 1982 - 11 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.2. WHITE SPACE + + Note: In structured field bodies, multiple linear space ASCII + characters (namely HTABs and SPACEs) are treated as + single spaces and may freely surround any symbol. In + all header fields, the only place in which at least one + LWSP-char is REQUIRED is at the beginning of continua- + tion lines in a folded field. + + When passing text to processes that do not interpret text + according to this standard (e.g., mail protocol servers), then + NO linear-white-space characters should occur between a period + (".") or at-sign ("@") and a . Exactly ONE SPACE should + be used in place of arbitrary linear-white-space and comment + sequences. + + Note: Within systems conforming to this standard, wherever a + member of the list of delimiters is allowed, LWSP-chars + may also occur before and/or after it. + + Writers of mail-sending (i.e., header-generating) programs + should realize that there is no network-wide definition of the + effect of ASCII HT (horizontal-tab) characters on the appear- + ance of text at another network host; therefore, the use of + tabs in message headers, though permitted, is discouraged. + + 3.4.3. COMMENTS + + A comment is a set of ASCII characters, which is enclosed in + matching parentheses and which is not within a quoted-string + The comment construct permits message originators to add text + which will be useful for human readers, but which will be + ignored by the formal semantics. Comments should be retained + while the message is subject to interpretation according to + this standard. However, comments must NOT be included in + other cases, such as during protocol exchanges with mail + servers. + + Comments nest, so that if an unquoted left parenthesis occurs + in a comment string, there must also be a matching right + parenthesis. When a comment acts as the delimiter between a + sequence of two lexical symbols, such as two atoms, it is lex- + ically equivalent with a single SPACE, for the purposes of + regenerating the sequence, such as when passing the sequence + onto a mail protocol server. Comments are detected as such + only within field-bodies of structured fields. + + If a comment is to be "folded" onto multiple lines, then the + syntax for folding must be adhered to. (See the "Lexical + + + August 13, 1982 - 12 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Analysis of Messages" section on "Folding Long Header Fields" + above, and the section on "Case Independence" below.) Note + that the official semantics therefore do not "see" any + unquoted CRLFs that are in comments, although particular pars- + ing programs may wish to note their presence. For these pro- + grams, it would be reasonable to interpret a "CRLF LWSP-char" + as being a CRLF that is part of the comment; i.e., the CRLF is + kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a + backslash followed by a CR followed by a LF) still must be + followed by at least one LWSP-char. + + 3.4.4. DELIMITING AND QUOTING CHARACTERS + + The quote character (backslash) and characters that delimit + syntactic units are not, generally, to be taken as data that + are part of the delimited or quoted unit(s). In particular, + the quotation-marks that define a quoted-string, the + parentheses that define a comment and the backslash that + quotes a following character are NOT part of the quoted- + string, comment or quoted character. A quotation-mark that is + to be part of a quoted-string, a parenthesis that is to be + part of a comment and a backslash that is to be part of either + must each be preceded by the quote-character backslash ("\"). + Note that the syntax allows any character to be quoted within + a quoted-string or comment; however only certain characters + MUST be quoted to be included as data. These characters are + the ones that are not part of the alternate text group (i.e., + ctext or qtext). + + The one exception to this rule is that a single SPACE is + assumed to exist between contiguous words in a phrase, and + this interpretation is independent of the actual number of + LWSP-chars that the creator places between the words. To + include more than one SPACE, the creator must make the LWSP- + chars be part of a quoted-string. + + Quotation marks that delimit a quoted string and backslashes + that quote the following character should NOT accompany the + quoted-string when the string is passed to processes that do + not interpret data according to this specification (e.g., mail + protocol servers). + + 3.4.5. QUOTED-STRINGS + + Where permitted (i.e., in words in structured fields) quoted- + strings are treated as a single symbol. That is, a quoted- + string is equivalent to an atom, syntactically. If a quoted- + string is to be "folded" onto multiple lines, then the syntax + for folding must be adhered to. (See the "Lexical Analysis of + + + August 13, 1982 - 13 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Messages" section on "Folding Long Header Fields" above, and + the section on "Case Independence" below.) Therefore, the + official semantics do not "see" any bare CRLFs that are in + quoted-strings; however particular parsing programs may wish + to note their presence. For such programs, it would be rea- + sonable to interpret a "CRLF LWSP-char" as being a CRLF which + is part of the quoted-string; i.e., the CRLF is kept and the + LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- + lowed by a CR followed by a LF) are also subject to rules of + folding, but the presence of the quoting character (backslash) + explicitly indicates that the CRLF is data to the quoted + string. Stripping off the first following LWSP-char is also + appropriate when parsing quoted CRLFs. + + 3.4.6. BRACKETING CHARACTERS + + There is one type of bracket which must occur in matched pairs + and may have pairs nested within each other: + + o Parentheses ("(" and ")") are used to indicate com- + ments. + + There are three types of brackets which must occur in matched + pairs, and which may NOT be nested: + + o Colon/semi-colon (":" and ";") are used in address + specifications to indicate that the included list of + addresses are to be treated as a group. + + o Angle brackets ("<" and ">") are generally used to + indicate the presence of a one machine-usable refer- + ence (e.g., delimiting mailboxes), possibly including + source-routing to the machine. + + o Square brackets ("[" and "]") are used to indicate the + presence of a domain-literal, which the appropriate + name-domain is to use directly, bypassing normal + name-resolution mechanisms. + + 3.4.7. CASE INDEPENDENCE + + Except as noted, alphabetic strings may be represented in any + combination of upper and lower case. The only syntactic units + + + + + + + + + August 13, 1982 - 14 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + which requires preservation of case information are: + + - text + - qtext + - dtext + - ctext + - quoted-pair + - local-part, except "Postmaster" + + When matching any other syntactic unit, case is to be ignored. + For example, the field-names "From", "FROM", "from", and even + "FroM" are semantically equal and should all be treated ident- + ically. + + When generating these units, any mix of upper and lower case + alphabetic characters may be used. The case shown in this + specification is suggested for message-creating processes. + + Note: The reserved local-part address unit, "Postmaster", is + an exception. When the value "Postmaster" is being + interpreted, it must be accepted in any mixture of + case, including "POSTMASTER", and "postmaster". + + 3.4.8. FOLDING LONG HEADER FIELDS + + Each header field may be represented on exactly one line con- + sisting of the name of the field and its body, and terminated + by a CRLF; this is what the parser sees. For readability, the + field-body portion of long header fields may be "folded" onto + multiple lines of the actual field. "Long" is commonly inter- + preted to mean greater than 65 or 72 characters. The former + length serves as a limit, when the message is to be viewed on + most simple terminals which use simple display software; how- + ever, the limit is not imposed by this standard. + + Note: Some display software often can selectively fold lines, + to suit the display terminal. In such cases, sender- + provided folding can interfere with the display + software. + + 3.4.9. BACKSPACE CHARACTERS + + ASCII BS characters (Backspace, decimal 8) may be included in + texts and quoted-strings to effect overstriking. However, any + use of backspaces which effects an overstrike to the left of + the beginning of the text or quoted-string is prohibited. + + + + + + August 13, 1982 - 15 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS + + During transmission through heterogeneous networks, it may be + necessary to force data to conform to a network's local con- + ventions. For example, it may be required that a CR be fol- + lowed either by LF, making a CRLF, or by , if the CR is + to stand alone). Such transformations are reversed, when the + message exits that network. + + When crossing network boundaries, the message should be + treated as passing through two modules. It will enter the + first module containing whatever network-specific transforma- + tions that were necessary to permit migration through the + "current" network. It then passes through the modules: + + o Transformation Reversal + + The "current" network's idiosyncracies are removed and + the message is returned to the canonical form speci- + fied in this standard. + + o Transformation + + The "next" network's local idiosyncracies are imposed + on the message. + + ------------------ + From ==> | Remove Net-A | + Net-A | idiosyncracies | + ------------------ + || + \/ + Conformance + with standard + || + \/ + ------------------ + | Impose Net-B | ==> To + | idiosyncracies | Net-B + ------------------ + + + + + + + + + + + + August 13, 1982 - 16 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 4. MESSAGE SPECIFICATION + + 4.1. SYNTAX + + Note: Due to an artifact of the notational conventions, the syn- + tax indicates that, when present, some fields, must be in + a particular order. Header fields are NOT required to + occur in any particular order, except that the message + body must occur AFTER the headers. It is recommended + that, if present, headers be sent in the order "Return- + Path", "Received", "Date", "From", "Subject", "Sender", + "To", "cc", etc. + + This specification permits multiple occurrences of most + fields. Except as noted, their interpretation is not + specified here, and their use is discouraged. + + The following syntax for the bodies of various fields should + be thought of as describing each field body as a single long + string (or line). The "Lexical Analysis of Message" section on + "Long Header Fields", above, indicates how such long strings can + be represented on more than one line in the actual transmitted + message. + + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + + trace = return ; path to sender + 1*received ; receipt tags + + return = "Return-path" ":" route-addr ; return address + + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + + + August 13, 1982 - 17 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + ";" date-time ; time received + + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + + dates = orig-date ; Original + [ resent-date ] ; Forwarded + + orig-date = "Date" ":" date-time + + resent-date = "Resent-Date" ":" date-time + + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + + msg-id = "<" addr-spec ">" ; Unique message id + + + + + + + August 13, 1982 - 18 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + extension-field = + + + user-defined-field = + + + 4.2. FORWARDING + + Some systems permit mail recipients to forward a message, + retaining the original headers, by adding some new fields. This + standard supports such a service, through the "Resent-" prefix to + field names. + + Whenever the string "Resent-" begins a field name, the field + has the same semantics as a field whose name does not have the + prefix. However, the message is assumed to have been forwarded + by an original recipient who attached the "Resent-" field. This + new field is treated as being more recent than the equivalent, + original field. For example, the "Resent-From", indicates the + person that forwarded the message, whereas the "From" field indi- + cates the original author. + + Use of such precedence information depends upon partici- + pants' communication needs. For example, this standard does not + dictate when a "Resent-From:" address should receive replies, in + lieu of sending them to the "From:" address. + + Note: In general, the "Resent-" fields should be treated as con- + taining a set of information that is independent of the + set of original fields. Information for one set should + not automatically be taken from the other. The interpre- + tation of multiple "Resent-" fields, of the same type, is + undefined. + + In the remainder of this specification, occurrence of legal + "Resent-" fields are treated identically with the occurrence of + + + + + + + + + August 13, 1982 - 19 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + fields whose names do not contain this prefix. + + 4.3. TRACE FIELDS + + Trace information is used to provide an audit trail of mes- + sage handling. In addition, it indicates a route back to the + sender of the message. + + The list of known "via" and "with" values are registered + with the Network Information Center, SRI International, Menlo + Park, California. + + 4.3.1. RETURN-PATH + + This field is added by the final transport system that + delivers the message to its recipient. The field is intended + to contain definitive information about the address and route + back to the message's originator. + + Note: The "Reply-To" field is added by the originator and + serves to direct replies, whereas the "Return-Path" + field is used to identify a path back to the origina- + tor. + + While the syntax indicates that a route specification is + optional, every attempt should be made to provide that infor- + mation in this field. + + 4.3.2. RECEIVED + + A copy of this field is added by each transport service that + relays the message. The information in the field can be quite + useful for tracing transport problems. + + The names of the sending and receiving hosts and time-of- + receipt may be specified. The "via" parameter may be used, to + indicate what physical mechanism the message was sent over, + such as Arpanet or Phonenet, and the "with" parameter may be + used to indicate the mail-, or connection-, level protocol + that was used, such as the SMTP mail protocol, or X.25 tran- + sport protocol. + + Note: Several "with" parameters may be included, to fully + specify the set of protocols that were used. + + Some transport services queue mail; the internal message iden- + tifier that is assigned to the message may be noted, using the + "id" parameter. When the sending host uses a destination + address specification that the receiving host reinterprets, by + + + August 13, 1982 - 20 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + expansion or transformation, the receiving host may wish to + record the original specification, using the "for" parameter. + For example, when a copy of mail is sent to the member of a + distribution list, this parameter may be used to record the + original address that was used to specify the list. + + 4.4. ORIGINATOR FIELDS + + The standard allows only a subset of the combinations possi- + ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, + and Resent-Reply-To fields. The limitation is intentional. + + 4.4.1. FROM / RESENT-FROM + + This field contains the identity of the person(s) who wished + this message to be sent. The message-creation process should + default this field to be a single, authenticated machine + address, indicating the AGENT (person, system or process) + entering the message. If this is not done, the "Sender" field + MUST be present. If the "From" field IS defaulted this way, + the "Sender" field is optional and is redundant with the + "From" field. In all cases, addresses in the "From" field + must be machine-usable (addr-specs) and may not contain named + lists (groups). + + 4.4.2. SENDER / RESENT-SENDER + + This field contains the authenticated identity of the AGENT + (person, system or process) that sends the message. It is + intended for use when the sender is not the author of the mes- + sage, or to indicate who among a group of authors actually + sent the message. If the contents of the "Sender" field would + be completely redundant with the "From" field, then the + "Sender" field need not be present and its use is discouraged + (though still legal). In particular, the "Sender" field MUST + be present if it is NOT the same as the "From" Field. + + The Sender mailbox specification includes a word sequence + which must correspond to a specific agent (i.e., a human user + or a computer program) rather than a standard address. This + indicates the expectation that the field will identify the + single AGENT (person, system, or process) responsible for + sending the mail and not simply include the name of a mailbox + from which the mail was sent. For example in the case of a + shared login name, the name, by itself, would not be adequate. + The local-part address unit, which refers to this agent, is + expected to be a computer system term, and not (for example) a + generalized person reference which can be used outside the + network text message context. + + + August 13, 1982 - 21 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Since the critical function served by the "Sender" field is + identification of the agent responsible for sending mail and + since computer programs cannot be held accountable for their + behavior, it is strongly recommended that when a computer pro- + gram generates a message, the HUMAN who is responsible for + that program be referenced as part of the "Sender" field mail- + box specification. + + 4.4.3. REPLY-TO / RESENT-REPLY-TO + + This field provides a general mechanism for indicating any + mailbox(es) to which responses are to be sent. Three typical + uses for this feature can be distinguished. In the first + case, the author(s) may not have regular machine-based mail- + boxes and therefore wish(es) to indicate an alternate machine + address. In the second case, an author may wish additional + persons to be made aware of, or responsible for, replies. A + somewhat different use may be of some help to "text message + teleconferencing" groups equipped with automatic distribution + services: include the address of that service in the "Reply- + To" field of all messages submitted to the teleconference; + then participants can "reply" to conference submissions to + guarantee the correct distribution of any submission of their + own. + + Note: The "Return-Path" field is added by the mail transport + service, at the time of final deliver. It is intended + to identify a path back to the orginator of the mes- + sage. The "Reply-To" field is added by the message + originator and is intended to direct replies. + + 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO + + For systems which automatically generate address lists for + replies to messages, the following recommendations are made: + + o The "Sender" field mailbox should be sent notices of + any problems in transport or delivery of the original + messages. If there is no "Sender" field, then the + "From" field mailbox should be used. + + o The "Sender" field mailbox should NEVER be used + automatically, in a recipient's reply message. + + o If the "Reply-To" field exists, then the reply should + go to the addresses indicated in that field and not to + the address(es) indicated in the "From" field. + + + + + August 13, 1982 - 22 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + o If there is a "From" field, but no "Reply-To" field, + the reply should be sent to the address(es) indicated + in the "From" field. + + Sometimes, a recipient may actually wish to communicate with + the person that initiated the message transfer. In such + cases, it is reasonable to use the "Sender" address. + + This recommendation is intended only for automated use of + originator-fields and is not intended to suggest that replies + may not also be sent to other recipients of messages. It is + up to the respective mail-handling programs to decide what + additional facilities will be provided. + + Examples are provided in Appendix A. + + 4.5. RECEIVER FIELDS + + 4.5.1. TO / RESENT-TO + + This field contains the identity of the primary recipients of + the message. + + 4.5.2. CC / RESENT-CC + + This field contains the identity of the secondary (informa- + tional) recipients of the message. + + 4.5.3. BCC / RESENT-BCC + + This field contains the identity of additional recipients of + the message. The contents of this field are not included in + copies of the message sent to the primary and secondary reci- + pients. Some systems may choose to include the text of the + "Bcc" field only in the author(s)'s copy, while others may + also include it in the text sent to all those indicated in the + "Bcc" list. + + 4.6. REFERENCE FIELDS + + 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID + + This field contains a unique identifier (the local-part + address unit) which refers to THIS version of THIS message. + The uniqueness of the message identifier is guaranteed by the + host which generates it. This identifier is intended to be + machine readable and not necessarily meaningful to humans. A + message identifier pertains to exactly one instantiation of a + particular message; subsequent revisions to the message should + + + August 13, 1982 - 23 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + each receive new message identifiers. + + 4.6.2. IN-REPLY-TO + + The contents of this field identify previous correspon- + dence which this message answers. Note that if message iden- + tifiers are used in this field, they must use the msg-id + specification format. + + 4.6.3. REFERENCES + + The contents of this field identify other correspondence + which this message references. Note that if message identif- + iers are used, they must use the msg-id specification format. + + 4.6.4. KEYWORDS + + This field contains keywords or phrases, separated by + commas. + + 4.7. OTHER FIELDS + + 4.7.1. SUBJECT + + This is intended to provide a summary, or indicate the + nature, of the message. + + 4.7.2. COMMENTS + + Permits adding text comments onto the message without + disturbing the contents of the message's body. + + 4.7.3. ENCRYPTED + + Sometimes, data encryption is used to increase the + privacy of message contents. If the body of a message has + been encrypted, to keep its contents private, the "Encrypted" + field can be used to note the fact and to indicate the nature + of the encryption. The first parameter indicates the + software used to encrypt the body, and the second, optional + is intended to aid the recipient in selecting the + proper decryption key. This code word may be viewed as an + index to a table of keys held by the recipient. + + Note: Unfortunately, headers must contain envelope, as well + as contents, information. Consequently, it is neces- + sary that they remain unencrypted, so that mail tran- + sport services may access them. Since names, + addresses, and "Subject" field contents may contain + + + August 13, 1982 - 24 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + sensitive information, this requirement limits total + message privacy. + + Names of encryption software are registered with the Net- + work Information Center, SRI International, Menlo Park, Cali- + fornia. + + 4.7.4. EXTENSION-FIELD + + A limited number of common fields have been defined in + this document. As network mail requirements dictate, addi- + tional fields may be standardized. To provide user-defined + fields with a measure of safety, in name selection, such + extension-fields will never have names that begin with the + string "X-". + + Names of Extension-fields are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 4.7.5. USER-DEFINED-FIELD + + Individual users of network mail are free to define and + use additional header fields. Such fields must have names + which are not already used in the current specification or in + any definitions of extension-fields, and the overall syntax of + these user-defined-fields must conform to this specification's + rules for delimiting and folding fields. Due to the + extension-field publishing process, the name of a user- + defined-field may be pre-empted + + Note: The prefatory string "X-" will never be used in the + names of Extension-fields. This provides user-defined + fields with a protected set of names. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 25 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 5. DATE AND TIME SPECIFICATION + + 5.1. SYNTAX + + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + + time = hour zone ; ANSI and Military + + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + ; A:-1; (J not used) + ; M:-12; N:+1; Y:+12 + / ( ("+" / "-") 4DIGIT ) ; Local differential + ; hours+min. (HHMM) + + 5.2. SEMANTICS + + If included, day-of-week must be the day implied by the date + specification. + + Time zone may be indicated in several ways. "UT" is Univer- + sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- + mitted as a reference to Universal Time. The military standard + uses a single character for each zone. "Z" is Universal Time. + "A" indicates one hour earlier, and "M" indicates 12 hours ear- + lier; "N" is one hour later, and "Y" is 12 hours later. The + letter "J" is not used. The other remaining two forms are taken + from ANSI standard X3.51-1975. One allows explicit indication of + the amount of offset from UT; the other uses common 3-character + strings for indicating time zones in North America. + + + August 13, 1982 - 26 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 6. ADDRESS SPECIFICATION + + 6.1. SYNTAX + + address = mailbox ; one addressee + / group ; named list + + group = phrase ":" [#mailbox] ";" + + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + + route-addr = "<" [route] addr-spec ">" + + route = 1#("@" domain) ":" ; path-relative + + addr-spec = local-part "@" domain ; global address + + local-part = word *("." word) ; uninterpreted + ; case-preserved + + domain = sub-domain *("." sub-domain) + + sub-domain = domain-ref / domain-literal + + domain-ref = atom ; symbolic reference + + 6.2. SEMANTICS + + A mailbox receives mail. It is a conceptual entity which + does not necessarily pertain to file storage. For example, some + sites may choose to print mail on their line printer and deliver + the output to the addressee's desk. + + A mailbox specification comprises a person, system or pro- + cess name reference, a domain-dependent string, and a name-domain + reference. The name reference is optional and is usually used to + indicate the human name of a recipient. The name-domain refer- + ence specifies a sequence of sub-domains. The domain-dependent + string is uninterpreted, except by the final sub-domain; the rest + of the mail service merely transmits it as a literal string. + + 6.2.1. DOMAINS + + A name-domain is a set of registered (mail) names. A name- + domain specification resolves to a subordinate name-domain + specification or to a terminal domain-dependent string. + Hence, domain specification is extensible, permitting any + number of registration levels. + + + August 13, 1982 - 27 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Name-domains model a global, logical, hierarchical addressing + scheme. The model is logical, in that an address specifica- + tion is related to name registration and is not necessarily + tied to transmission path. The model's hierarchy is a + directed graph, called an in-tree, such that there is a single + path from the root of the tree to any node in the hierarchy. + If more than one path actually exists, they are considered to + be different addresses. + + The root node is common to all addresses; consequently, it is + not referenced. Its children constitute "top-level" name- + domains. Usually, a service has access to its own full domain + specification and to the names of all top-level name-domains. + + The "top" of the domain addressing hierarchy -- a child of the + root -- is indicated by the right-most field, in a domain + specification. Its child is specified to the left, its child + to the left, and so on. + + Some groups provide formal registration services; these con- + stitute name-domains that are independent logically of + specific machines. In addition, networks and machines impli- + citly compose name-domains, since their membership usually is + registered in name tables. + + In the case of formal registration, an organization implements + a (distributed) data base which provides an address-to-route + mapping service for addresses of the form: + + person@registry.organization + + Note that "organization" is a logical entity, separate from + any particular communication network. + + A mechanism for accessing "organization" is universally avail- + able. That mechanism, in turn, seeks an instantiation of the + registry; its location is not indicated in the address specif- + ication. It is assumed that the system which operates under + the name "organization" knows how to find a subordinate regis- + try. The registry will then use the "person" string to deter- + mine where to send the mail specification. + + The latter, network-oriented case permits simple, direct, + attachment-related address specification, such as: + + user@host.network + + Once the network is accessed, it is expected that a message + will go directly to the host and that the host will resolve + + + August 13, 1982 - 28 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + the user name, placing the message in the user's mailbox. + + 6.2.2. ABBREVIATED DOMAIN SPECIFICATION + + Since any number of levels is possible within the domain + hierarchy, specification of a fully qualified address can + become inconvenient. This standard permits abbreviated domain + specification, in a special case: + + For the address of the sender, call the left-most + sub-domain Level N. In a header address, if all of + the sub-domains above (i.e., to the right of) Level N + are the same as those of the sender, then they do not + have to appear in the specification. Otherwise, the + address must be fully qualified. + + This feature is subject to approval by local sub- + domains. Individual sub-domains may require their + member systems, which originate mail, to provide full + domain specification only. When permitted, abbrevia- + tions may be present only while the message stays + within the sub-domain of the sender. + + Use of this mechanism requires the sender's sub-domain + to reserve the names of all top-level domains, so that + full specifications can be distinguished from abbrevi- + ated specifications. + + For example, if a sender's address is: + + sender@registry-A.registry-1.organization-X + + and one recipient's address is: + + recipient@registry-B.registry-1.organization-X + + and another's is: + + recipient@registry-C.registry-2.organization-X + + then ".registry-1.organization-X" need not be specified in the + the message, but "registry-C.registry-2" DOES have to be + specified. That is, the first two addresses may be abbrevi- + ated, but the third address must be fully specified. + + When a message crosses a domain boundary, all addresses must + be specified in the full format, ending with the top-level + name-domain in the right-most field. It is the responsibility + of mail forwarding services to ensure that addresses conform + + + August 13, 1982 - 29 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + with this requirement. In the case of abbreviated addresses, + the relaying service must make the necessary expansions. It + should be noted that it often is difficult for such a service + to locate all occurrences of address abbreviations. For exam- + ple, it will not be possible to find such abbreviations within + the body of the message. The "Return-Path" field can aid + recipients in recovering from these errors. + + Note: When passing any portion of an addr-spec onto a process + which does not interpret data according to this stan- + dard (e.g., mail protocol servers). There must be NO + LWSP-chars preceding or following the at-sign or any + delimiting period ("."), such as shown in the above + examples, and only ONE SPACE between contiguous + s. + + 6.2.3. DOMAIN TERMS + + A domain-ref must be THE official name of a registry, network, + or host. It is a symbolic reference, within a name sub- + domain. At times, it is necessary to bypass standard mechan- + isms for resolving such references, using more primitive + information, such as a network host address rather than its + associated host name. + + To permit such references, this standard provides the domain- + literal construct. Its contents must conform with the needs + of the sub-domain in which it is interpreted. + + Domain-literals which refer to domains within the ARPA Inter- + net specify 32-bit Internet addresses, in four 8-bit fields + noted in decimal, as described in Request for Comments #820, + "Assigned Numbers." For example: + + [10.0.3.19] + + Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It + is permitted only as a means of bypassing temporary + system limitations, such as name tables which are not + complete. + + The names of "top-level" domains, and the names of domains + under in the ARPA Internet, are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 6.2.4. DOMAIN-DEPENDENT LOCAL STRING + + The local-part of an addr-spec in a mailbox specification + (i.e., the host's name for the mailbox) is understood to be + + + August 13, 1982 - 30 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + whatever the receiving mail protocol server allows. For exam- + ple, some systems do not understand mailbox references of the + form "P. D. Q. Bach", but others do. + + This specification treats periods (".") as lexical separators. + Hence, their presence in local-parts which are not quoted- + strings, is detected. However, such occurrences carry NO + semantics. That is, if a local-part has periods within it, an + address parser will divide the local-part into several tokens, + but the sequence of tokens will be treated as one uninter- + preted unit. The sequence will be re-assembled, when the + address is passed outside of the system such as to a mail pro- + tocol service. + + For example, the address: + + First.Last@Registry.Org + + is legal and does not require the local-part to be surrounded + with quotation-marks. (However, "First Last" DOES require + quoting.) The local-part of the address, when passed outside + of the mail system, within the Registry.Org domain, is + "First.Last", again without quotation marks. + + 6.2.5. BALANCING LOCAL-PART AND DOMAIN + + In some cases, the boundary between local-part and domain can + be flexible. The local-part may be a simple string, which is + used for the final determination of the recipient's mailbox. + All other levels of reference are, therefore, part of the + domain. + + For some systems, in the case of abbreviated reference to the + local and subordinate sub-domains, it may be possible to + specify only one reference within the domain part and place + the other, subordinate name-domain references within the + local-part. This would appear as: + + mailbox.sub1.sub2@this-domain + + Such a specification would be acceptable to address parsers + which conform to RFC #733, but do not support this newer + Internet standard. While contrary to the intent of this stan- + dard, the form is legal. + + Also, some sub-domains have a specification syntax which does + not conform to this standard. For example: + + sub-net.mailbox@sub-domain.domain + + + August 13, 1982 - 31 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + uses a different parsing sequence for local-part than for + domain. + + Note: As a rule, the domain specification should contain + fields which are encoded according to the syntax of + this standard and which contain generally-standardized + information. The local-part specification should con- + tain only that portion of the address which deviates + from the form or intention of the domain field. + + 6.2.6. MULTIPLE MAILBOXES + + An individual may have several mailboxes and wish to receive + mail at whatever mailbox is convenient for the sender to + access. This standard does not provide a means of specifying + "any member of" a list of mailboxes. + + A set of individuals may wish to receive mail as a single unit + (i.e., a distribution list). The construct permits + specification of such a list. Recipient mailboxes are speci- + fied within the bracketed part (":" - ";"). A copy of the + transmitted message is to be sent to each mailbox listed. + This standard does not permit recursive specification of + groups within groups. + + While a list must be named, it is not required that the con- + tents of the list be included. In this case, the
+ serves only as an indication of group distribution and would + appear in the form: + + name:; + + Some mail services may provide a group-list distribution + facility, accepting a single mailbox reference, expanding it + to the full distribution list, and relaying the mail to the + list's members. This standard provides no additional syntax + for indicating such a service. Using the address + alternative, while listing one mailbox in it, can mean either + that the mailbox reference will be expanded to a list or that + there is a group with one member. + + 6.2.7. EXPLICIT PATH SPECIFICATION + + At times, a message originator may wish to indicate the + transmission path that a message should follow. This is + called source routing. The normal addressing scheme, used in + an addr-spec, is carefully separated from such information; + the portion of a route-addr is provided for such occa- + sions. It specifies the sequence of hosts and/or transmission + + + August 13, 1982 - 32 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + services that are to be traversed. Both domain-refs and + domain-literals may be used. + + Note: The use of source routing is discouraged. Unless the + sender has special need of path restriction, the choice + of transmission route should be left to the mail tran- + sport service. + + 6.3. RESERVED ADDRESS + + It often is necessary to send mail to a site, without know- + ing any of its valid addresses. For example, there may be mail + system dysfunctions, or a user may wish to find out a person's + correct address, at that site. + + This standard specifies a single, reserved mailbox address + (local-part) which is to be valid at each site. Mail sent to + that address is to be routed to a person responsible for the + site's mail system or to a person with responsibility for general + site operation. The name of the reserved local-part address is: + + Postmaster + + so that "Postmaster@domain" is required to be valid. + + Note: This reserved local-part must be matched without sensi- + tivity to alphabetic case, so that "POSTMASTER", "postmas- + ter", and even "poStmASteR" is to be accepted. + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 33 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 7. BIBLIOGRAPHY + + + ANSI. "USA Standard Code for Information Interchange," X3.4. + American National Standards Institute: New York (1968). Also + in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- + book", NIC 7104. + + ANSI. "Representations of Universal Time, Local Time Differen- + tials, and United States Time Zone References for Information + Interchange," X3.51-1975. American National Standards Insti- + tute: New York (1975). + + Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. + 1979). + + Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- + ford and Appleton Laboratory: Didcot, England. + + Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. + "Standardizing Network Mail Headers," ARPANET Request for + Comments No. 561, Network Information Center No. 18516; SRI + International: Menlo Park (September 1973). + + Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. + "Grapevine: An Exercise in Distributed Computing," Communica- + tions of the ACM 25, 4 (April 1982), 260-274. + + Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. + "Standard for the Format of ARPA Network Text Message," + ARPANET Request for Comments No. 733, Network Information + Center No. 41952. SRI International: Menlo Park (November + 1977). + + Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- + work Information Center No. 7104 (NTIS AD A003890). SRI + International: Menlo Park (April 1976). + + Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. + (1969). + + Levin, R. and Schroeder, M. "Transport of Electronic Messages + through a Network," TeleInformatics 79, pp. 29-33. North + Holland (1979). Also as Xerox Palo Alto Research Center + Technical Report CSL-79-4. + + Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," + ARPANET Request for Comments, No. 680, Network Information + Center No. 32116. SRI International: Menlo Park (1975). + + + August 13, 1982 - 34 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + NBS. "Specification of Message Format for Computer Based Message + Systems, Recommended Federal Information Processing Standard." + National Bureau of Standards: Gaithersburg, Maryland + (October 1981). + + NIC. Internet Protocol Transition Workbook. Network Information + Center, SRI-International, Menlo Park, California (March + 1982). + + Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized + Agent for Locating Named Objects in a Distributed Environ- + ment," OPD-T8103. Xerox Office Products Division: Palo Alto, + CA. (October 1981). + + Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, + No. 820. SRI International: Menlo Park (August 1982). + + Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request + for Comments, No. 821. SRI International: Menlo Park (August + 1982). + + Shoch, J.F. "Internetwork naming, addressing and routing," in + Proc. 17th IEEE Computer Society International Conference, pp. + 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. + + Su, Z. and Postel, J. "The Domain Naming Convention for Internet + User Applications," ARPANET Request for Comments, No. 819. + SRI International: Menlo Park (August 1982). + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 35 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + APPENDIX + + + A. EXAMPLES + + A.1. ADDRESSES + + A.1.1. Alfred Neuman + + A.1.2. Neuman@BBN-TENEXA + + These two "Alfred Neuman" examples have identical seman- + tics, as far as the operation of the local host's mail sending + (distribution) program (also sometimes called its "mailer") + and the remote host's mail protocol server are concerned. In + the first example, the "Alfred Neuman" is ignored by the + mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- + pient. The second example contains no superfluous informa- + tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- + pient. + + Note: When the message crosses name-domain boundaries, then + these specifications must be changed, so as to indicate + the remainder of the hierarchy, starting with the top + level. + + A.1.3. "George, Ted" + + This form might be used to indicate that a single mailbox + is shared by several users. The quoted string is ignored by + the originating host's mailer, because "Shared@Group.Arpanet" + completely specifies the destination mailbox. + + A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US + + The "(the Stilt)" is a comment, which is NOT included in + the destination mailbox address handed to the originating + system's mailer. The local-part of the address is the string + "Wilt.Chamberlain", with NO space between the first and second + words. + + A.1.5. Address Lists + + Gourmets: Pompous Person , + Childs@WGBH.Boston, Galloping Gourmet@ + ANT.Down-Under (Australian National Television), + Cheapie@Discount-Liquors;, + Cruisers: Port@Portugal, Jones@SEA;, + Another@Somewhere.SomeOrg + + + August 13, 1982 - 36 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + This group list example points out the use of comments and the + mixing of addresses and groups. + + A.2. ORIGINATOR ITEMS + + A.2.1. Author-sent + + George Jones logs into his host as "Jones". He sends + mail himself. + + From: Jones@Group.Org + + or + + From: George Jones + + A.2.2. Secretary-sent + + George Jones logs in as Jones on his host. His secre- + tary, who logs in as Secy sends mail for him. Replies to the + mail should go to George. + + From: George Jones + Sender: Secy@Other-Group + + A.2.3. Secretary-sent, for user of shared directory + + George Jones' secretary sends mail for George. Replies + should go to George. + + From: George Jones + Sender: Secy@Other-Group + + Note that there need not be a space between "Jones" and the + "<", but adding a space enhances readability (as is the case + in other examples. + + A.2.4. Committee activity, with one author + + George is a member of a committee. He wishes to have any + replies to his message go to all committee members. + + From: George Jones + Sender: Jones@Host + Reply-To: The Committee: Jones@Host.Net, + Smith@Other.Org, + Doe@Somewhere-Else; + + Note that if George had not included himself in the + + + August 13, 1982 - 37 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + enumeration of The Committee, he would not have gotten an + implicit reply; the presence of the "Reply-to" field SUPER- + SEDES the sending of a reply to the person named in the "From" + field. + + A.2.5. Secretary acting as full agent of author + + George Jones asks his secretary (Secy@Host) to send a + message for him in his capacity as Group. He wants his secre- + tary to handle all replies. + + From: George Jones + Sender: Secy@Host + Reply-To: Secy@Host + + A.2.6. Agent for user without online mailbox + + A friend of George's, Sarah, is visiting. George's + secretary sends some mail to a friend of Sarah in computer- + land. Replies should go to George, whose mailbox is Jones at + Registry. + + From: Sarah Friendly + Sender: Secy-Name + Reply-To: Jones@Registry. + + A.2.7. Agent for member of a committee + + George's secretary sends out a message which was authored + jointly by all the members of a committee. Note that the name + of the committee cannot be specified, since names are + not permitted in the From field. + + From: Jones@Host, + Smith@Other-Host, + Doe@Somewhere-Else + Sender: Secy@SHost + + + + + + + + + + + + + + + August 13, 1982 - 38 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + A.3. COMPLETE HEADERS + + A.3.1. Minimum required + + Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT + From: Jones@Registry.Org or From: Jones@Registry.Org + Bcc: To: Smith@Registry.Org + + Note that the "Bcc" field may be empty, while the "To" field + is required to have at least one address. + + A.3.2. Using some of the additional fields + + Date: 26 Aug 76 1430 EDT + From: George Jones + Sender: Secy@SHOST + To: "Al Neuman"@Mad-Host, + Sam.Irving@Other-Host + Message-ID: + + A.3.3. About as complex as you're going to get + + Date : 27 Aug 76 0932 PDT + From : Ken Davis + Subject : Re: The Syntax in the RFC + Sender : KSecy@Other-Host + Reply-To : Sam.Irving@Reg.Organization + To : George Jones , + Al.Neuman@MAD.Publisher + cc : Important folk: + Tom Softwood , + "Sam Irving"@Other-Host;, + Standard Distribution: + /main/davis/people/standard@Other-Host, + "standard.dist.3"@Tops-20-Host>; + Comment : Sam is away on business. He asked me to handle + his mail for him. He'll be able to provide a + more accurate explanation when he returns + next week. + In-Reply-To: , George's message + X-Special-action: This is a sample of user-defined field- + names. There could also be a field-name + "Special-action", but its name might later be + preempted + Message-ID: <4231.629.XYzi-What@Other-Host> + + + + + + + August 13, 1982 - 39 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + B. SIMPLE FIELD PARSING + + Some mail-reading software systems may wish to perform only + minimal processing, ignoring the internal syntax of structured + field-bodies and treating them the same as unstructured-field- + bodies. Such software will need only to distinguish: + + o Header fields from the message body, + + o Beginnings of fields from lines which continue fields, + + o Field-names from field-contents. + + The abbreviated set of syntactic rules which follows will + suffice for this purpose. It describes a limited view of mes- + sages and is a subset of the syntactic rules provided in the main + part of this specification. One small exception is that the con- + tents of field-bodies consist only of text: + + B.1. SYNTAX + + + message = *field *(CRLF *text) + + field = field-name ":" [field-body] CRLF + + field-name = 1* + + field-body = *text [CRLF LWSP-char field-body] + + + B.2. SEMANTICS + + Headers occur before the message body and are terminated by + a null line (i.e., two contiguous CRLFs). + + A line which continues a header field begins with a SPACE or + HTAB character, while a line beginning a field starts with a + printable character which is not a colon. + + A field-name consists of one or more printable characters + (excluding colon, space, and control-characters). A field-name + MUST be contained on one line. Upper and lower case are not dis- + tinguished when comparing field-names. + + + + + + + + August 13, 1982 - 40 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C. DIFFERENCES FROM RFC #733 + + The following summarizes the differences between this stan- + dard and the one specified in Arpanet Request for Comments #733, + "Standard for the Format of ARPA Network Text Messages". The + differences are listed in the order of their occurrence in the + current specification. + + C.1. FIELD DEFINITIONS + + C.1.1. FIELD NAMES + + These now must be a sequence of printable characters. They + may not contain any LWSP-chars. + + C.2. LEXICAL TOKENS + + C.2.1. SPECIALS + + The characters period ("."), left-square bracket ("["), and + right-square bracket ("]") have been added. For presentation + purposes, and when passing a specification to a system that + does not conform to this standard, periods are to be contigu- + ous with their surrounding lexical tokens. No linear-white- + space is permitted between them. The presence of one LWSP- + char between other tokens is still directed. + + C.2.2. ATOM + + Atoms may not contain SPACE. + + C.2.3. SPECIAL TEXT + + ctext and qtext have had backslash ("\") added to the list of + prohibited characters. + + C.2.4. DOMAINS + + The lexical tokens and have been + added. + + C.3. MESSAGE SPECIFICATION + + C.3.1. TRACE + + The "Return-path:" and "Received:" fields have been specified. + + + + + + August 13, 1982 - 41 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.3.2. FROM + + The "From" field must contain machine-usable addresses (addr- + spec). Multiple addresses may be specified, but named-lists + (groups) may not. + + C.3.3. RESENT + + The meta-construct of prefacing field names with the string + "Resent-" has been added, to indicate that a message has been + forwarded by an intermediate recipient. + + C.3.4. DESTINATION + + A message must contain at least one destination address field. + "To" and "CC" are required to contain at least one address. + + C.3.5. IN-REPLY-TO + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.6. REFERENCE + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.7. ENCRYPTED + + A field has been specified that permits senders to indicate + that the body of a message has been encrypted. + + C.3.8. EXTENSION-FIELD + + Extension fields are prohibited from beginning with the char- + acters "X-". + + C.4. DATE AND TIME SPECIFICATION + + C.4.1. SIMPLIFICATION + + Fewer optional forms are permitted and the list of three- + letter time zones has been shortened. + + C.5. ADDRESS SPECIFICATION + + + + + + + August 13, 1982 - 42 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.5.1. ADDRESS + + The use of quoted-string, and the ":"-atom-":" construct, have + been removed. An address now is either a single mailbox + reference or is a named list of addresses. The latter indi- + cates a group distribution. + + C.5.2. GROUPS + + Group lists are now required to to have a name. Group lists + may not be nested. + + C.5.3. MAILBOX + + A mailbox specification may indicate a person's name, as + before. Such a named list no longer may specify multiple + mailboxes and may not be nested. + + C.5.4. ROUTE ADDRESSING + + Addresses now are taken to be absolute, global specifications, + independent of transmission paths. The construct has + been provided, to permit explicit specification of transmis- + sion path. RFC #733's use of multiple at-signs ("@") was + intended as a general syntax for indicating routing and/or + hierarchical addressing. The current standard separates these + specifications and only one at-sign is permitted. + + C.5.5. AT-SIGN + + The string " at " no longer is used as an address delimiter. + Only at-sign ("@") serves the function. + + C.5.6. DOMAINS + + Hierarchical, logical name-domains have been added. + + C.6. RESERVED ADDRESS + + The local-part "Postmaster" has been reserved, so that users can + be guaranteed at least one valid address at a site. + + + + + + + + + + + August 13, 1982 - 43 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + D. ALPHABETICAL LISTING OF SYNTAX RULES + + address = mailbox ; one addressee + / group ; named list + addr-spec = local-part "@" domain ; global address + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + atom = 1* + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + CHAR = ; ( 0-177, 0.-127.) + comment = "(" *(ctext / quoted-pair / comment) ")" + CR = ; ( 15, 13.) + CRLF = CR LF + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + CTL = ; ( 177, 127.) + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + dates = orig-date ; Original + [ resent-date ] ; Forwarded + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + delimiters = specials / linear-white-space / comment + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + DIGIT = ; ( 60- 71, 48.- 57.) + domain = sub-domain *("." sub-domain) + domain-literal = "[" *(dtext / quoted-pair) "]" + domain-ref = atom ; symbolic reference + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + extension-field = + + + + August 13, 1982 - 44 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + field = field-name ":" [ field-body ] CRLF + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + field-body = field-body-contents + [CRLF LWSP-char field-body] + field-body-contents = + + field-name = 1* + group = phrase ":" [#mailbox] ";" + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + HTAB = ; ( 11, 9.) + LF = ; ( 12, 10.) + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + local-part = word *("." word) ; uninterpreted + ; case-preserved + LWSP-char = SPACE / HTAB ; semantics = SPACE + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + msg-id = "<" addr-spec ">" ; Unique message id + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + orig-date = "Date" ":" date-time + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + phrase = 1*word ; Sequence of words + + + + + August 13, 1982 - 45 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + quoted-pair = "\" CHAR ; may quote any char + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + ";" date-time ; time received + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + resent-date = "Resent-Date" ":" date-time + return = "Return-path" ":" route-addr ; return address + route = 1#("@" domain) ":" ; path-relative + route-addr = "<" [route] addr-spec ">" + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + SPACE = ; ( 40, 32.) + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + sub-domain = domain-ref / domain-literal + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + time = hour zone ; ANSI and Military + trace = return ; path to sender + 1*received ; receipt tags + user-defined-field = + + word = atom / quoted-string + + + + + August 13, 1982 - 46 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + <"> = ; ( 42, 34.) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 47 - RFC #822 + + + diff --git a/server/src/site/resources/rfclist/basic/rfc1123.txt b/server/src/site/resources/rfclist/basic/rfc1123.txt new file mode 100644 index 00000000000..514528a43bc --- /dev/null +++ b/server/src/site/resources/rfclist/basic/rfc1123.txt @@ -0,0 +1,5781 @@ + + + + + +Network Working Group Internet Engineering Task Force +Request for Comments: 1123 R. Braden, Editor + October 1989 + + + Requirements for Internet Hosts -- Application and Support + +Status of This Memo + + This RFC is an official specification for the Internet community. It + incorporates by reference, amends, corrects, and supplements the + primary protocol standards documents relating to hosts. Distribution + of this document is unlimited. + +Summary + + This RFC is one of a pair that defines and discusses the requirements + for Internet host software. This RFC covers the application and + support protocols; its companion RFC-1122 covers the communication + protocol layers: link layer, IP layer, and transport layer. + + + + Table of Contents + + + + + 1. INTRODUCTION ............................................... 5 + 1.1 The Internet Architecture .............................. 6 + 1.2 General Considerations ................................. 6 + 1.2.1 Continuing Internet Evolution ..................... 6 + 1.2.2 Robustness Principle .............................. 7 + 1.2.3 Error Logging ..................................... 8 + 1.2.4 Configuration ..................................... 8 + 1.3 Reading this Document .................................. 10 + 1.3.1 Organization ...................................... 10 + 1.3.2 Requirements ...................................... 10 + 1.3.3 Terminology ....................................... 11 + 1.4 Acknowledgments ........................................ 12 + + 2. GENERAL ISSUES ............................................. 13 + 2.1 Host Names and Numbers ................................. 13 + 2.2 Using Domain Name Service .............................. 13 + 2.3 Applications on Multihomed hosts ....................... 14 + 2.4 Type-of-Service ........................................ 14 + 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15 + + + + +Internet Engineering Task Force [Page 1] + + + + +RFC1123 INTRODUCTION October 1989 + + + 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16 + 3.1 INTRODUCTION ........................................... 16 + 3.2 PROTOCOL WALK-THROUGH .................................. 16 + 3.2.1 Option Negotiation ................................ 16 + 3.2.2 Telnet Go-Ahead Function .......................... 16 + 3.2.3 Control Functions ................................. 17 + 3.2.4 Telnet "Synch" Signal ............................. 18 + 3.2.5 NVT Printer and Keyboard .......................... 19 + 3.2.6 Telnet Command Structure .......................... 20 + 3.2.7 Telnet Binary Option .............................. 20 + 3.2.8 Telnet Terminal-Type Option ....................... 20 + 3.3 SPECIFIC ISSUES ........................................ 21 + 3.3.1 Telnet End-of-Line Convention ..................... 21 + 3.3.2 Data Entry Terminals .............................. 23 + 3.3.3 Option Requirements ............................... 24 + 3.3.4 Option Initiation ................................. 24 + 3.3.5 Telnet Linemode Option ............................ 25 + 3.4 TELNET/USER INTERFACE .................................. 25 + 3.4.1 Character Set Transparency ........................ 25 + 3.4.2 Telnet Commands ................................... 26 + 3.4.3 TCP Connection Errors ............................. 26 + 3.4.4 Non-Default Telnet Contact Port ................... 26 + 3.4.5 Flushing Output ................................... 26 + 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27 + + 4. FILE TRANSFER .............................................. 29 + 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29 + 4.1.1 INTRODUCTION ...................................... 29 + 4.1.2. PROTOCOL WALK-THROUGH ............................ 29 + 4.1.2.1 LOCAL Type ................................... 29 + 4.1.2.2 Telnet Format Control ........................ 30 + 4.1.2.3 Page Structure ............................... 30 + 4.1.2.4 Data Structure Transformations ............... 30 + 4.1.2.5 Data Connection Management ................... 31 + 4.1.2.6 PASV Command ................................. 31 + 4.1.2.7 LIST and NLST Commands ....................... 31 + 4.1.2.8 SITE Command ................................. 32 + 4.1.2.9 STOU Command ................................. 32 + 4.1.2.10 Telnet End-of-line Code ..................... 32 + 4.1.2.11 FTP Replies ................................. 33 + 4.1.2.12 Connections ................................. 34 + 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34 + 4.1.3 SPECIFIC ISSUES ................................... 35 + 4.1.3.1 Non-standard Command Verbs ................... 35 + 4.1.3.2 Idle Timeout ................................. 36 + 4.1.3.3 Concurrency of Data and Control .............. 36 + 4.1.3.4 FTP Restart Mechanism ........................ 36 + 4.1.4 FTP/USER INTERFACE ................................ 39 + + + +Internet Engineering Task Force [Page 2] + + + + +RFC1123 INTRODUCTION October 1989 + + + 4.1.4.1 Pathname Specification ....................... 39 + 4.1.4.2 "QUOTE" Command .............................. 40 + 4.1.4.3 Displaying Replies to User ................... 40 + 4.1.4.4 Maintaining Synchronization .................. 40 + 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41 + 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44 + 4.2.1 INTRODUCTION ...................................... 44 + 4.2.2 PROTOCOL WALK-THROUGH ............................. 44 + 4.2.2.1 Transfer Modes ............................... 44 + 4.2.2.2 UDP Header ................................... 44 + 4.2.3 SPECIFIC ISSUES ................................... 44 + 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44 + 4.2.3.2 Timeout Algorithms ........................... 46 + 4.2.3.3 Extensions ................................... 46 + 4.2.3.4 Access Control ............................... 46 + 4.2.3.5 Broadcast Request ............................ 46 + 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47 + + 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48 + 5.1 INTRODUCTION ........................................... 48 + 5.2 PROTOCOL WALK-THROUGH .................................. 48 + 5.2.1 The SMTP Model .................................... 48 + 5.2.2 Canonicalization .................................. 49 + 5.2.3 VRFY and EXPN Commands ............................ 50 + 5.2.4 SEND, SOML, and SAML Commands ..................... 50 + 5.2.5 HELO Command ...................................... 50 + 5.2.6 Mail Relay ........................................ 51 + 5.2.7 RCPT Command ...................................... 52 + 5.2.8 DATA Command ...................................... 53 + 5.2.9 Command Syntax .................................... 54 + 5.2.10 SMTP Replies ..................................... 54 + 5.2.11 Transparency ..................................... 55 + 5.2.12 WKS Use in MX Processing ......................... 55 + 5.2.13 RFC-822 Message Specification .................... 55 + 5.2.14 RFC-822 Date and Time Specification .............. 55 + 5.2.15 RFC-822 Syntax Change ............................ 56 + 5.2.16 RFC-822 Local-part .............................. 56 + 5.2.17 Domain Literals .................................. 57 + 5.2.18 Common Address Formatting Errors ................. 58 + 5.2.19 Explicit Source Routes ........................... 58 + 5.3 SPECIFIC ISSUES ........................................ 59 + 5.3.1 SMTP Queueing Strategies .......................... 59 + 5.3.1.1 Sending Strategy .............................. 59 + 5.3.1.2 Receiving strategy ........................... 61 + 5.3.2 Timeouts in SMTP .................................. 61 + 5.3.3 Reliable Mail Receipt ............................. 63 + 5.3.4 Reliable Mail Transmission ........................ 63 + 5.3.5 Domain Name Support ............................... 65 + + + +Internet Engineering Task Force [Page 3] + + + + +RFC1123 INTRODUCTION October 1989 + + + 5.3.6 Mailing Lists and Aliases ......................... 65 + 5.3.7 Mail Gatewaying ................................... 66 + 5.3.8 Maximum Message Size .............................. 68 + 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69 + + 6. SUPPORT SERVICES ............................................ 72 + 6.1 DOMAIN NAME TRANSLATION ................................. 72 + 6.1.1 INTRODUCTION ....................................... 72 + 6.1.2 PROTOCOL WALK-THROUGH ............................. 72 + 6.1.2.1 Resource Records with Zero TTL ............... 73 + 6.1.2.2 QCLASS Values ................................ 73 + 6.1.2.3 Unused Fields ................................ 73 + 6.1.2.4 Compression .................................. 73 + 6.1.2.5 Misusing Configuration Info .................. 73 + 6.1.3 SPECIFIC ISSUES ................................... 74 + 6.1.3.1 Resolver Implementation ...................... 74 + 6.1.3.2 Transport Protocols .......................... 75 + 6.1.3.3 Efficient Resource Usage ..................... 77 + 6.1.3.4 Multihomed Hosts ............................. 78 + 6.1.3.5 Extensibility ................................ 79 + 6.1.3.6 Status of RR Types ........................... 79 + 6.1.3.7 Robustness ................................... 80 + 6.1.3.8 Local Host Table ............................. 80 + 6.1.4 DNS USER INTERFACE ................................ 81 + 6.1.4.1 DNS Administration ........................... 81 + 6.1.4.2 DNS User Interface ........................... 81 + 6.1.4.3 Interface Abbreviation Facilities ............. 82 + 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84 + 6.2 HOST INITIALIZATION .................................... 87 + 6.2.1 INTRODUCTION ...................................... 87 + 6.2.2 REQUIREMENTS ...................................... 87 + 6.2.2.1 Dynamic Configuration ........................ 87 + 6.2.2.2 Loading Phase ................................ 89 + 6.3 REMOTE MANAGEMENT ...................................... 90 + 6.3.1 INTRODUCTION ...................................... 90 + 6.3.2 PROTOCOL WALK-THROUGH ............................. 90 + 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92 + + 7. REFERENCES ................................................. 93 + + + + + + + + + + + + +Internet Engineering Task Force [Page 4] + + + + +RFC1123 INTRODUCTION October 1989 + + +1. INTRODUCTION + + This document is one of a pair that defines and discusses the + requirements for host system implementations of the Internet protocol + suite. This RFC covers the applications layer and support protocols. + Its companion RFC, "Requirements for Internet Hosts -- Communications + Layers" [INTRO:1] covers the lower layer protocols: transport layer, + IP layer, and link layer. + + These documents are intended to provide guidance for vendors, + implementors, and users of Internet communication software. They + represent the consensus of a large body of technical experience and + wisdom, contributed by members of the Internet research and vendor + communities. + + This RFC enumerates standard protocols that a host connected to the + Internet must use, and it incorporates by reference the RFCs and + other documents describing the current specifications for these + protocols. It corrects errors in the referenced documents and adds + additional discussion and guidance for an implementor. + + For each protocol, this document also contains an explicit set of + requirements, recommendations, and options. The reader must + understand that the list of requirements in this document is + incomplete by itself; the complete set of requirements for an + Internet host is primarily defined in the standard protocol + specification documents, with the corrections, amendments, and + supplements contained in this RFC. + + A good-faith implementation of the protocols that was produced after + careful reading of the RFC's and with some interaction with the + Internet technical community, and that followed good communications + software engineering practices, should differ from the requirements + of this document in only minor ways. Thus, in many cases, the + "requirements" in this RFC are already stated or implied in the + standard protocol documents, so that their inclusion here is, in a + sense, redundant. However, they were included because some past + implementation has made the wrong choice, causing problems of + interoperability, performance, and/or robustness. + + This document includes discussion and explanation of many of the + requirements and recommendations. A simple list of requirements + would be dangerous, because: + + o Some required features are more important than others, and some + features are optional. + + o There may be valid reasons why particular vendor products that + + + +Internet Engineering Task Force [Page 5] + + + + +RFC1123 INTRODUCTION October 1989 + + + are designed for restricted contexts might choose to use + different specifications. + + However, the specifications of this document must be followed to meet + the general goal of arbitrary host interoperation across the + diversity and complexity of the Internet system. Although most + current implementations fail to meet these requirements in various + ways, some minor and some major, this specification is the ideal + towards which we need to move. + + These requirements are based on the current level of Internet + architecture. This document will be updated as required to provide + additional clarifications or to include additional information in + those areas in which specifications are still evolving. + + This introductory section begins with general advice to host software + vendors, and then gives some guidance on reading the rest of the + document. Section 2 contains general requirements that may be + applicable to all application and support protocols. Sections 3, 4, + and 5 contain the requirements on protocols for the three major + applications: Telnet, file transfer, and electronic mail, + respectively. Section 6 covers the support applications: the domain + name system, system initialization, and management. Finally, all + references will be found in Section 7. + + 1.1 The Internet Architecture + + For a brief introduction to the Internet architecture from a host + viewpoint, see Section 1.1 of [INTRO:1]. That section also + contains recommended references for general background on the + Internet architecture. + + 1.2 General Considerations + + There are two important lessons that vendors of Internet host + software have learned and which a new vendor should consider + seriously. + + 1.2.1 Continuing Internet Evolution + + The enormous growth of the Internet has revealed problems of + management and scaling in a large datagram-based packet + communication system. These problems are being addressed, and + as a result there will be continuing evolution of the + specifications described in this document. These changes will + be carefully planned and controlled, since there is extensive + participation in this planning by the vendors and by the + organizations responsible for operations of the networks. + + + +Internet Engineering Task Force [Page 6] + + + + +RFC1123 INTRODUCTION October 1989 + + + Development, evolution, and revision are characteristic of + computer network protocols today, and this situation will + persist for some years. A vendor who develops computer + communication software for the Internet protocol suite (or any + other protocol suite!) and then fails to maintain and update + that software for changing specifications is going to leave a + trail of unhappy customers. The Internet is a large + communication network, and the users are in constant contact + through it. Experience has shown that knowledge of + deficiencies in vendor software propagates quickly through the + Internet technical community. + + 1.2.2 Robustness Principle + + At every layer of the protocols, there is a general rule whose + application can lead to enormous benefits in robustness and + interoperability: + + "Be liberal in what you accept, and + conservative in what you send" + + Software should be written to deal with every conceivable + error, no matter how unlikely; sooner or later a packet will + come in with that particular combination of errors and + attributes, and unless the software is prepared, chaos can + ensue. In general, it is best to assume that the network is + filled with malevolent entities that will send in packets + designed to have the worst possible effect. This assumption + will lead to suitable protective design, although the most + serious problems in the Internet have been caused by + unenvisaged mechanisms triggered by low-probability events; + mere human malice would never have taken so devious a course! + + Adaptability to change must be designed into all levels of + Internet host software. As a simple example, consider a + protocol specification that contains an enumeration of values + for a particular header field -- e.g., a type field, a port + number, or an error code; this enumeration must be assumed to + be incomplete. Thus, if a protocol specification defines four + possible error codes, the software must not break when a fifth + code shows up. An undefined code might be logged (see below), + but it must not cause a failure. + + The second part of the principle is almost as important: + software on other hosts may contain deficiencies that make it + unwise to exploit legal but obscure protocol features. It is + unwise to stray far from the obvious and simple, lest untoward + effects result elsewhere. A corollary of this is "watch out + + + +Internet Engineering Task Force [Page 7] + + + + +RFC1123 INTRODUCTION October 1989 + + + for misbehaving hosts"; host software should be prepared, not + just to survive other misbehaving hosts, but also to cooperate + to limit the amount of disruption such hosts can cause to the + shared communication facility. + + 1.2.3 Error Logging + + The Internet includes a great variety of host and gateway + systems, each implementing many protocols and protocol layers, + and some of these contain bugs and mis-features in their + Internet protocol software. As a result of complexity, + diversity, and distribution of function, the diagnosis of user + problems is often very difficult. + + Problem diagnosis will be aided if host implementations include + a carefully designed facility for logging erroneous or + "strange" protocol events. It is important to include as much + diagnostic information as possible when an error is logged. In + particular, it is often useful to record the header(s) of a + packet that caused an error. However, care must be taken to + ensure that error logging does not consume prohibitive amounts + of resources or otherwise interfere with the operation of the + host. + + There is a tendency for abnormal but harmless protocol events + to overflow error logging files; this can be avoided by using a + "circular" log, or by enabling logging only while diagnosing a + known failure. It may be useful to filter and count duplicate + successive messages. One strategy that seems to work well is: + (1) always count abnormalities and make such counts accessible + through the management protocol (see Section 6.3); and (2) + allow the logging of a great variety of events to be + selectively enabled. For example, it might useful to be able + to "log everything" or to "log everything for host X". + + Note that different managements may have differing policies + about the amount of error logging that they want normally + enabled in a host. Some will say, "if it doesn't hurt me, I + don't want to know about it", while others will want to take a + more watchful and aggressive attitude about detecting and + removing protocol abnormalities. + + 1.2.4 Configuration + + It would be ideal if a host implementation of the Internet + protocol suite could be entirely self-configuring. This would + allow the whole suite to be implemented in ROM or cast into + silicon, it would simplify diskless workstations, and it would + + + +Internet Engineering Task Force [Page 8] + + + + +RFC1123 INTRODUCTION October 1989 + + + be an immense boon to harried LAN administrators as well as + system vendors. We have not reached this ideal; in fact, we + are not even close. + + At many points in this document, you will find a requirement + that a parameter be a configurable option. There are several + different reasons behind such requirements. In a few cases, + there is current uncertainty or disagreement about the best + value, and it may be necessary to update the recommended value + in the future. In other cases, the value really depends on + external factors -- e.g., the size of the host and the + distribution of its communication load, or the speeds and + topology of nearby networks -- and self-tuning algorithms are + unavailable and may be insufficient. In some cases, + configurability is needed because of administrative + requirements. + + Finally, some configuration options are required to communicate + with obsolete or incorrect implementations of the protocols, + distributed without sources, that unfortunately persist in many + parts of the Internet. To make correct systems coexist with + these faulty systems, administrators often have to "mis- + configure" the correct systems. This problem will correct + itself gradually as the faulty systems are retired, but it + cannot be ignored by vendors. + + When we say that a parameter must be configurable, we do not + intend to require that its value be explicitly read from a + configuration file at every boot time. We recommend that + implementors set up a default for each parameter, so a + configuration file is only necessary to override those defaults + that are inappropriate in a particular installation. Thus, the + configurability requirement is an assurance that it will be + POSSIBLE to override the default when necessary, even in a + binary-only or ROM-based product. + + This document requires a particular value for such defaults in + some cases. The choice of default is a sensitive issue when + the configuration item controls the accommodation to existing + faulty systems. If the Internet is to converge successfully to + complete interoperability, the default values built into + implementations must implement the official protocol, not + "mis-configurations" to accommodate faulty implementations. + Although marketing considerations have led some vendors to + choose mis-configuration defaults, we urge vendors to choose + defaults that will conform to the standard. + + Finally, we note that a vendor needs to provide adequate + + + +Internet Engineering Task Force [Page 9] + + + + +RFC1123 INTRODUCTION October 1989 + + + documentation on all configuration parameters, their limits and + effects. + + + 1.3 Reading this Document + + 1.3.1 Organization + + In general, each major section is organized into the following + subsections: + + (1) Introduction + + (2) Protocol Walk-Through -- considers the protocol + specification documents section-by-section, correcting + errors, stating requirements that may be ambiguous or + ill-defined, and providing further clarification or + explanation. + + (3) Specific Issues -- discusses protocol design and + implementation issues that were not included in the walk- + through. + + (4) Interfaces -- discusses the service interface to the next + higher layer. + + (5) Summary -- contains a summary of the requirements of the + section. + + Under many of the individual topics in this document, there is + parenthetical material labeled "DISCUSSION" or + "IMPLEMENTATION". This material is intended to give + clarification and explanation of the preceding requirements + text. It also includes some suggestions on possible future + directions or developments. The implementation material + contains suggested approaches that an implementor may want to + consider. + + The summary sections are intended to be guides and indexes to + the text, but are necessarily cryptic and incomplete. The + summaries should never be used or referenced separately from + the complete RFC. + + 1.3.2 Requirements + + In this document, the words that are used to define the + significance of each particular requirement are capitalized. + These words are: + + + +Internet Engineering Task Force [Page 10] + + + + +RFC1123 INTRODUCTION October 1989 + + + * "MUST" + + This word or the adjective "REQUIRED" means that the item + is an absolute requirement of the specification. + + * "SHOULD" + + This word or the adjective "RECOMMENDED" means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications should be + understood and the case carefully weighed before choosing + a different course. + + * "MAY" + + This word or the adjective "OPTIONAL" means that this item + is truly optional. One vendor may choose to include the + item because a particular marketplace requires it or + because it enhances the product, for example; another + vendor may omit the same item. + + + An implementation is not compliant if it fails to satisfy one + or more of the MUST requirements for the protocols it + implements. An implementation that satisfies all the MUST and + all the SHOULD requirements for its protocols is said to be + "unconditionally compliant"; one that satisfies all the MUST + requirements but not all the SHOULD requirements for its + protocols is said to be "conditionally compliant". + + 1.3.3 Terminology + + This document uses the following technical terms: + + Segment + A segment is the unit of end-to-end transmission in the + TCP protocol. A segment consists of a TCP header followed + by application data. A segment is transmitted by + encapsulation in an IP datagram. + + Message + This term is used by some application layer protocols + (particularly SMTP) for an application data unit. + + Datagram + A [UDP] datagram is the unit of end-to-end transmission in + the UDP protocol. + + + + +Internet Engineering Task Force [Page 11] + + + + +RFC1123 INTRODUCTION October 1989 + + + Multihomed + A host is said to be multihomed if it has multiple IP + addresses to connected networks. + + + + 1.4 Acknowledgments + + This document incorporates contributions and comments from a large + group of Internet protocol experts, including representatives of + university and research labs, vendors, and government agencies. + It was assembled primarily by the Host Requirements Working Group + of the Internet Engineering Task Force (IETF). + + The Editor would especially like to acknowledge the tireless + dedication of the following people, who attended many long + meetings and generated 3 million bytes of electronic mail over the + past 18 months in pursuit of this document: Philip Almquist, Dave + Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve + Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), + John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), + Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge + (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). + + In addition, the following people made major contributions to the + effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia + (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), + Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), + John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill + Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul + (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue + Technology), and Mike StJohns (DCA). The following also made + significant contributions to particular areas: Eric Allman + (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic + (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn + (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann + (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun + Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen + (Toronto). + + We are grateful to all, including any contributors who may have + been inadvertently omitted from this list. + + + + + + + + + +Internet Engineering Task Force [Page 12] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + +2. GENERAL ISSUES + + This section contains general requirements that may be applicable to + all application-layer protocols. + + 2.1 Host Names and Numbers + + The syntax of a legal Internet host name was specified in RFC-952 + [DNS:4]. One aspect of host name syntax is hereby changed: the + restriction on the first character is relaxed to allow either a + letter or a digit. Host software MUST support this more liberal + syntax. + + Host software MUST handle host names of up to 63 characters and + SHOULD handle host names of up to 255 characters. + + Whenever a user inputs the identity of an Internet host, it SHOULD + be possible to enter either (1) a host domain name or (2) an IP + address in dotted-decimal ("#.#.#.#") form. The host SHOULD check + the string syntactically for a dotted-decimal number before + looking it up in the Domain Name System. + + DISCUSSION: + This last requirement is not intended to specify the complete + syntactic form for entering a dotted-decimal host number; + that is considered to be a user-interface issue. For + example, a dotted-decimal number must be enclosed within + "[ ]" brackets for SMTP mail (see Section 5.2.17). This + notation could be made universal within a host system, + simplifying the syntactic checking for a dotted-decimal + number. + + If a dotted-decimal number can be entered without such + identifying delimiters, then a full syntactic check must be + made, because a segment of a host domain name is now allowed + to begin with a digit and could legally be entirely numeric + (see Section 6.1.2.4). However, a valid host name can never + have the dotted-decimal form #.#.#.#, since at least the + highest-level component label will be alphabetic. + + 2.2 Using Domain Name Service + + Host domain names MUST be translated to IP addresses as described + in Section 6.1. + + Applications using domain name services MUST be able to cope with + soft error conditions. Applications MUST wait a reasonable + interval between successive retries due to a soft error, and MUST + + + +Internet Engineering Task Force [Page 13] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + + allow for the possibility that network problems may deny service + for hours or even days. + + An application SHOULD NOT rely on the ability to locate a WKS + record containing an accurate listing of all services at a + particular host address, since the WKS RR type is not often used + by Internet sites. To confirm that a service is present, simply + attempt to use it. + + 2.3 Applications on Multihomed hosts + + When the remote host is multihomed, the name-to-address + translation will return a list of alternative IP addresses. As + specified in Section 6.1.3.4, this list should be in order of + decreasing preference. Application protocol implementations + SHOULD be prepared to try multiple addresses from the list until + success is obtained. More specific requirements for SMTP are + given in Section 5.3.4. + + When the local host is multihomed, a UDP-based request/response + application SHOULD send the response with an IP source address + that is the same as the specific destination address of the UDP + request datagram. The "specific destination address" is defined + in the "IP Addressing" section of the companion RFC [INTRO:1]. + + Similarly, a server application that opens multiple TCP + connections to the same client SHOULD use the same local IP + address for all. + + 2.4 Type-of-Service + + Applications MUST select appropriate TOS values when they invoke + transport layer services, and these values MUST be configurable. + Note that a TOS value contains 5 bits, of which only the most- + significant 3 bits are currently defined; the other two bits MUST + be zero. + + DISCUSSION: + As gateway algorithms are developed to implement Type-of- + Service, the recommended values for various application + protocols may change. In addition, it is likely that + particular combinations of users and Internet paths will want + non-standard TOS values. For these reasons, the TOS values + must be configurable. + + See the latest version of the "Assigned Numbers" RFC + [INTRO:5] for the recommended TOS values for the major + application protocols. + + + +Internet Engineering Task Force [Page 14] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + + 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +User interfaces: | | | | | | | + Allow host name to begin with digit |2.1 |x| | | | | + Host names of up to 635 characters |2.1 |x| | | | | + Host names of up to 255 characters |2.1 | |x| | | | + Support dotted-decimal host numbers |2.1 | |x| | | | + Check syntactically for dotted-dec first |2.1 | |x| | | | + | | | | | | | +Map domain names per Section 6.1 |2.2 |x| | | | | +Cope with soft DNS errors |2.2 |x| | | | | + Reasonable interval between retries |2.2 |x| | | | | + Allow for long outages |2.2 |x| | | | | +Expect WKS records to be available |2.2 | | | |x| | + | | | | | | | +Try multiple addr's for remote multihomed host |2.3 | |x| | | | +UDP reply src addr is specific dest of request |2.3 | |x| | | | +Use same IP addr for related TCP connections |2.3 | |x| | | | +Specify appropriate TOS values |2.4 |x| | | | | + TOS values configurable |2.4 |x| | | | | + Unused TOS bits zero |2.4 |x| | | | | + | | | | | | | + | | | | | | | + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 15] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + +3. REMOTE LOGIN -- TELNET PROTOCOL + + 3.1 INTRODUCTION + + Telnet is the standard Internet application protocol for remote + login. It provides the encoding rules to link a user's + keyboard/display on a client ("user") system with a command + interpreter on a remote server system. A subset of the Telnet + protocol is also incorporated within other application protocols, + e.g., FTP and SMTP. + + Telnet uses a single TCP connection, and its normal data stream + ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with + escape sequences to embed control functions. Telnet also allows + the negotiation of many optional modes and functions. + + The primary Telnet specification is to be found in RFC-854 + [TELNET:1], while the options are defined in many other RFCs; see + Section 7 for references. + + 3.2 PROTOCOL WALK-THROUGH + + 3.2.1 Option Negotiation: RFC-854, pp. 2-3 + + Every Telnet implementation MUST include option negotiation and + subnegotiation machinery [TELNET:2]. + + A host MUST carefully follow the rules of RFC-854 to avoid + option-negotiation loops. A host MUST refuse (i.e, reply + WONT/DONT to a DO/WILL) an unsupported option. Option + negotiation SHOULD continue to function (even if all requests + are refused) throughout the lifetime of a Telnet connection. + + If all option negotiations fail, a Telnet implementation MUST + default to, and support, an NVT. + + DISCUSSION: + Even though more sophisticated "terminals" and supporting + option negotiations are becoming the norm, all + implementations must be prepared to support an NVT for any + user-server communication. + + 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 + + On a host that never sends the Telnet command Go Ahead (GA), + the Telnet Server MUST attempt to negotiate the Suppress Go + Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or + Server Telnet MUST always accept negotiation of the Suppress Go + + + +Internet Engineering Task Force [Page 16] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Ahead option. + + When it is driving a full-duplex terminal for which GA has no + meaning, a User Telnet implementation MAY ignore GA commands. + + DISCUSSION: + Half-duplex ("locked-keyboard") line-at-a-time terminals + for which the Go-Ahead mechanism was designed have largely + disappeared from the scene. It turned out to be difficult + to implement sending the Go-Ahead signal in many operating + systems, even some systems that support native half-duplex + terminals. The difficulty is typically that the Telnet + server code does not have access to information about + whether the user process is blocked awaiting input from + the Telnet connection, i.e., it cannot reliably determine + when to send a GA command. Therefore, most Telnet Server + hosts do not send GA commands. + + The effect of the rules in this section is to allow either + end of a Telnet connection to veto the use of GA commands. + + There is a class of half-duplex terminals that is still + commercially important: "data entry terminals," which + interact in a full-screen manner. However, supporting + data entry terminals using the Telnet protocol does not + require the Go Ahead signal; see Section 3.3.2. + + 3.2.3 Control Functions: RFC-854, pp. 7-8 + + The list of Telnet commands has been extended to include EOR + (End-of-Record), with code 239 [TELNET:9]. + + Both User and Server Telnets MAY support the control functions + EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP, + SB, and SE. + + A host MUST be able to receive and ignore any Telnet control + functions that it does not support. + + DISCUSSION: + Note that a Server Telnet is required to support the + Telnet IP (Interrupt Process) function, even if the server + host has an equivalent in-stream function (e.g., Control-C + in many systems). The Telnet IP function may be stronger + than an in-stream interrupt command, because of the out- + of-band effect of TCP urgent data. + + The EOR control function may be used to delimit the + + + +Internet Engineering Task Force [Page 17] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + stream. An important application is data entry terminal + support (see Section 3.3.2). There was concern that since + EOR had not been defined in RFC-854, a host that was not + prepared to correctly ignore unknown Telnet commands might + crash if it received an EOR. To protect such hosts, the + End-of-Record option [TELNET:9] was introduced; however, a + properly implemented Telnet program will not require this + protection. + + 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10 + + When it receives "urgent" TCP data, a User or Server Telnet + MUST discard all data except Telnet commands until the DM (and + end of urgent) is reached. + + When it sends Telnet IP (Interrupt Process), a User Telnet + SHOULD follow it by the Telnet "Synch" sequence, i.e., send as + TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent + pointer points to the DM octet. + + When it receives a Telnet IP command, a Server Telnet MAY send + a Telnet "Synch" sequence back to the user, to flush the output + stream. The choice ought to be consistent with the way the + server operating system behaves when a local user interrupts a + process. + + When it receives a Telnet AO command, a Server Telnet MUST send + a Telnet "Synch" sequence back to the user, to flush the output + stream. + + A User Telnet SHOULD have the capability of flushing output + when it sends a Telnet IP; see also Section 3.4.5. + + DISCUSSION: + There are three possible ways for a User Telnet to flush + the stream of server output data: + + (1) Send AO after IP. + + This will cause the server host to send a "flush- + buffered-output" signal to its operating system. + However, the AO may not take effect locally, i.e., + stop terminal output at the User Telnet end, until + the Server Telnet has received and processed the AO + and has sent back a "Synch". + + (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard + all output locally until a WILL/WONT TIMING-MARK is + + + +Internet Engineering Task Force [Page 18] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + received from the Server Telnet. + + Since the DO TIMING-MARK will be processed after the + IP at the server, the reply to it should be in the + right place in the output data stream. However, the + TIMING-MARK will not send a "flush buffered output" + signal to the server operating system. Whether or + not this is needed is dependent upon the server + system. + + (3) Do both. + + The best method is not entirely clear, since it must + accommodate a number of existing server hosts that do not + follow the Telnet standards in various ways. The safest + approach is probably to provide a user-controllable option + to select (1), (2), or (3). + + 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11 + + In NVT mode, a Telnet SHOULD NOT send characters with the + high-order bit 1, and MUST NOT send it as a parity bit. + Implementations that pass the high-order bit to applications + SHOULD negotiate binary mode (see Section 3.2.6). + + + DISCUSSION: + Implementors should be aware that a strict reading of + RFC-854 allows a client or server expecting NVT ASCII to + ignore characters with the high-order bit set. In + general, binary mode is expected to be used for + transmission of an extended (beyond 7-bit) character set + with Telnet. + + However, there exist applications that really need an 8- + bit NVT mode, which is currently not defined, and these + existing applications do set the high-order bit during + part or all of the life of a Telnet connection. Note that + binary mode is not the same as 8-bit NVT mode, since + binary mode turns off end-of-line processing. For this + reason, the requirements on the high-order bit are stated + as SHOULD, not MUST. + + RFC-854 defines a minimal set of properties of a "network + virtual terminal" or NVT; this is not meant to preclude + additional features in a real terminal. A Telnet + connection is fully transparent to all 7-bit ASCII + characters, including arbitrary ASCII control characters. + + + +Internet Engineering Task Force [Page 19] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + For example, a terminal might support full-screen commands + coded as ASCII escape sequences; a Telnet implementation + would pass these sequences as uninterpreted data. Thus, + an NVT should not be conceived as a terminal type of a + highly-restricted device. + + 3.2.6 Telnet Command Structure: RFC-854, p. 13 + + Since options may appear at any point in the data stream, a + Telnet escape character (known as IAC, with the value 255) to + be sent as data MUST be doubled. + + 3.2.7 Telnet Binary Option: RFC-856 + + When the Binary option has been successfully negotiated, + arbitrary 8-bit characters are allowed. However, the data + stream MUST still be scanned for IAC characters, any embedded + Telnet commands MUST be obeyed, and data bytes equal to IAC + MUST be doubled. Other character processing (e.g., replacing + CR by CR NUL or by CR LF) MUST NOT be done. In particular, + there is no end-of-line convention (see Section 3.3.1) in + binary mode. + + DISCUSSION: + The Binary option is normally negotiated in both + directions, to change the Telnet connection from NVT mode + to "binary mode". + + The sequence IAC EOR can be used to delimit blocks of data + within a binary-mode Telnet stream. + + 3.2.8 Telnet Terminal-Type Option: RFC-1091 + + The Terminal-Type option MUST use the terminal type names + officially defined in the Assigned Numbers RFC [INTRO:5], when + they are available for the particular terminal. However, the + receiver of a Terminal-Type option MUST accept any name. + + DISCUSSION: + RFC-1091 [TELNET:10] updates an earlier version of the + Terminal-Type option defined in RFC-930. The earlier + version allowed a server host capable of supporting + multiple terminal types to learn the type of a particular + client's terminal, assuming that each physical terminal + had an intrinsic type. However, today a "terminal" is + often really a terminal emulator program running in a PC, + perhaps capable of emulating a range of terminal types. + Therefore, RFC-1091 extends the specification to allow a + + + +Internet Engineering Task Force [Page 20] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + more general terminal-type negotiation between User and + Server Telnets. + + 3.3 SPECIFIC ISSUES + + 3.3.1 Telnet End-of-Line Convention + + The Telnet protocol defines the sequence CR LF to mean "end- + of-line". For terminal input, this corresponds to a command- + completion or "end-of-line" key being pressed on a user + terminal; on an ASCII terminal, this is the CR key, but it may + also be labelled "Return" or "Enter". + + When a Server Telnet receives the Telnet end-of-line sequence + CR LF as input from a remote terminal, the effect MUST be the + same as if the user had pressed the "end-of-line" key on a + local terminal. On server hosts that use ASCII, in particular, + receipt of the Telnet sequence CR LF must cause the same effect + as a local user pressing the CR key on a local terminal. Thus, + CR LF and CR NUL MUST have the same effect on an ASCII server + host when received as input over a Telnet connection. + + A User Telnet MUST be able to send any of the forms: CR LF, CR + NUL, and LF. A User Telnet on an ASCII host SHOULD have a + user-controllable mode to send either CR LF or CR NUL when the + user presses the "end-of-line" key, and CR LF SHOULD be the + default. + + The Telnet end-of-line sequence CR LF MUST be used to send + Telnet data that is not terminal-to-computer (e.g., for Server + Telnet sending output, or the Telnet protocol incorporated + another application protocol). + + DISCUSSION: + To allow interoperability between arbitrary Telnet clients + and servers, the Telnet protocol defined a standard + representation for a line terminator. Since the ASCII + character set includes no explicit end-of-line character, + systems have chosen various representations, e.g., CR, LF, + and the sequence CR LF. The Telnet protocol chose the CR + LF sequence as the standard for network transmission. + + Unfortunately, the Telnet protocol specification in RFC- + 854 [TELNET:1] has turned out to be somewhat ambiguous on + what character(s) should be sent from client to server for + the "end-of-line" key. The result has been a massive and + continuing interoperability headache, made worse by + various faulty implementations of both User and Server + + + +Internet Engineering Task Force [Page 21] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Telnets. + + Although the Telnet protocol is based on a perfectly + symmetric model, in a remote login session the role of the + user at a terminal differs from the role of the server + host. For example, RFC-854 defines the meaning of CR, LF, + and CR LF as output from the server, but does not specify + what the User Telnet should send when the user presses the + "end-of-line" key on the terminal; this turns out to be + the point at issue. + + When a user presses the "end-of-line" key, some User + Telnet implementations send CR LF, while others send CR + NUL (based on a different interpretation of the same + sentence in RFC-854). These will be equivalent for a + correctly-implemented ASCII server host, as discussed + above. For other servers, a mode in the User Telnet is + needed. + + The existence of User Telnets that send only CR NUL when + CR is pressed creates a dilemma for non-ASCII hosts: they + can either treat CR NUL as equivalent to CR LF in input, + thus precluding the possibility of entering a "bare" CR, + or else lose complete interworking. + + Suppose a user on host A uses Telnet to log into a server + host B, and then execute B's User Telnet program to log + into server host C. It is desirable for the Server/User + Telnet combination on B to be as transparent as possible, + i.e., to appear as if A were connected directly to C. In + particular, correct implementation will make B transparent + to Telnet end-of-line sequences, except that CR LF may be + translated to CR NUL or vice versa. + + IMPLEMENTATION: + To understand Telnet end-of-line issues, one must have at + least a general model of the relationship of Telnet to the + local operating system. The Server Telnet process is + typically coupled into the terminal driver software of the + operating system as a pseudo-terminal. A Telnet end-of- + line sequence received by the Server Telnet must have the + same effect as pressing the end-of-line key on a real + locally-connected terminal. + + Operating systems that support interactive character-at- + a-time applications (e.g., editors) typically have two + internal modes for their terminal I/O: a formatted mode, + in which local conventions for end-of-line and other + + + +Internet Engineering Task Force [Page 22] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + formatting rules have been applied to the data stream, and + a "raw" mode, in which the application has direct access + to every character as it was entered. A Server Telnet + must be implemented in such a way that these modes have + the same effect for remote as for local terminals. For + example, suppose a CR LF or CR NUL is received by the + Server Telnet on an ASCII host. In raw mode, a CR + character is passed to the application; in formatted mode, + the local system's end-of-line convention is used. + + 3.3.2 Data Entry Terminals + + DISCUSSION: + In addition to the line-oriented and character-oriented + ASCII terminals for which Telnet was designed, there are + several families of video display terminals that are + sometimes known as "data entry terminals" or DETs. The + IBM 3270 family is a well-known example. + + Two Internet protocols have been designed to support + generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET + option [TELNET:18, TELNET:19]. The DET option drives a + data entry terminal over a Telnet connection using (sub-) + negotiation. SUPDUP is a completely separate terminal + protocol, which can be entered from Telnet by negotiation. + Although both SUPDUP and the DET option have been used + successfully in particular environments, neither has + gained general acceptance or wide implementation. + + A different approach to DET interaction has been developed + for supporting the IBM 3270 family through Telnet, + although the same approach would be applicable to any DET. + The idea is to enter a "native DET" mode, in which the + native DET input/output stream is sent as binary data. + The Telnet EOR command is used to delimit logical records + (e.g., "screens") within this binary stream. + + IMPLEMENTATION: + The rules for entering and leaving native DET mode are as + follows: + + o The Server uses the Terminal-Type option [TELNET:10] + to learn that the client is a DET. + + o It is conventional, but not required, that both ends + negotiate the EOR option [TELNET:9]. + + o Both ends negotiate the Binary option [TELNET:3] to + + + +Internet Engineering Task Force [Page 23] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + enter native DET mode. + + o When either end negotiates out of binary mode, the + other end does too, and the mode then reverts to + normal NVT. + + + 3.3.3 Option Requirements + + Every Telnet implementation MUST support the Binary option + [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and + SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of- + Record [TELNET:9], and Extended Options List [TELNET:8] + options. + + A User or Server Telnet SHOULD support the Window Size Option + [TELNET:12] if the local operating system provides the + corresponding capability. + + DISCUSSION: + Note that the End-of-Record option only signifies that a + Telnet can receive a Telnet EOR without crashing; + therefore, every Telnet ought to be willing to accept + negotiation of the End-of-Record option. See also the + discussion in Section 3.2.3. + + 3.3.4 Option Initiation + + When the Telnet protocol is used in a client/server situation, + the server SHOULD initiate negotiation of the terminal + interaction mode it expects. + + DISCUSSION: + The Telnet protocol was defined to be perfectly + symmetrical, but its application is generally asymmetric. + Remote login has been known to fail because NEITHER side + initiated negotiation of the required non-default terminal + modes. It is generally the server that determines the + preferred mode, so the server needs to initiate the + negotiation; since the negotiation is symmetric, the user + can also initiate it. + + A client (User Telnet) SHOULD provide a means for users to + enable and disable the initiation of option negotiation. + + DISCUSSION: + A user sometimes needs to connect to an application + service (e.g., FTP or SMTP) that uses Telnet for its + + + +Internet Engineering Task Force [Page 24] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + control stream but does not support Telnet options. User + Telnet may be used for this purpose if initiation of + option negotiation is disabled. + + 3.3.5 Telnet Linemode Option + + DISCUSSION: + An important new Telnet option, LINEMODE [TELNET:12], has + been proposed. The LINEMODE option provides a standard + way for a User Telnet and a Server Telnet to agree that + the client rather than the server will perform terminal + character processing. When the client has prepared a + complete line of text, it will send it to the server in + (usually) one TCP packet. This option will greatly + decrease the packet cost of Telnet sessions and will also + give much better user response over congested or long- + delay networks. + + The LINEMODE option allows dynamic switching between local + and remote character processing. For example, the Telnet + connection will automatically negotiate into single- + character mode while a full screen editor is running, and + then return to linemode when the editor is finished. + + We expect that when this RFC is released, hosts should + implement the client side of this option, and may + implement the server side of this option. To properly + implement the server side, the server needs to be able to + tell the local system not to do any input character + processing, but to remember its current terminal state and + notify the Server Telnet process whenever the state + changes. This will allow password echoing and full screen + editors to be handled properly, for example. + + 3.4 TELNET/USER INTERFACE + + 3.4.1 Character Set Transparency + + User Telnet implementations SHOULD be able to send or receive + any 7-bit ASCII character. Where possible, any special + character interpretations by the user host's operating system + SHOULD be bypassed so that these characters can conveniently be + sent and received on the connection. + + Some character value MUST be reserved as "escape to command + mode"; conventionally, doubling this character allows it to be + entered as data. The specific character used SHOULD be user + selectable. + + + +Internet Engineering Task Force [Page 25] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + On binary-mode connections, a User Telnet program MAY provide + an escape mechanism for entering arbitrary 8-bit values, if the + host operating system doesn't allow them to be entered directly + from the keyboard. + + IMPLEMENTATION: + The transparency issues are less pressing on servers, but + implementors should take care in dealing with issues like: + masking off parity bits (sent by an older, non-conforming + client) before they reach programs that expect only NVT + ASCII, and properly handling programs that request 8-bit + data streams. + + 3.4.2 Telnet Commands + + A User Telnet program MUST provide a user the capability of + entering any of the Telnet control functions IP, AO, or AYT, + and SHOULD provide the capability of entering EC, EL, and + Break. + + 3.4.3 TCP Connection Errors + + A User Telnet program SHOULD report to the user any TCP errors + that are reported by the transport layer (see "TCP/Application + Layer Interface" section in [INTRO:1]). + + 3.4.4 Non-Default Telnet Contact Port + + A User Telnet program SHOULD allow the user to optionally + specify a non-standard contact port number at the Server Telnet + host. + + 3.4.5 Flushing Output + + A User Telnet program SHOULD provide the user the ability to + specify whether or not output should be flushed when an IP is + sent; see Section 3.2.4. + + For any output flushing scheme that causes the User Telnet to + flush output locally until a Telnet signal is received from the + Server, there SHOULD be a way for the user to manually restore + normal output, in case the Server fails to send the expected + signal. + + + + + + + + +Internet Engineering Task Force [Page 26] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + 3.5. TELNET REQUIREMENTS SUMMARY + + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------------|--------|-|-|-|-|-|-- + | | | | | | | +Option Negotiation |3.2.1 |x| | | | | + Avoid negotiation loops |3.2.1 |x| | | | | + Refuse unsupported options |3.2.1 |x| | | | | + Negotiation OK anytime on connection |3.2.1 | |x| | | | + Default to NVT |3.2.1 |x| | | | | + Send official name in Term-Type option |3.2.8 |x| | | | | + Accept any name in Term-Type option |3.2.8 |x| | | | | + Implement Binary, Suppress-GA options |3.3.3 |x| | | | | + Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | | + Implement Window-Size option if appropriate |3.3.3 | |x| | | | + Server initiate mode negotiations |3.3.4 | |x| | | | + User can enable/disable init negotiations |3.3.4 | |x| | | | + | | | | | | | +Go-Aheads | | | | | | | + Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | | + User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | | + User Telnet ignore GA's |3.2.2 | | |x| | | + | | | | | | | +Control Functions | | | | | | | + Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | | + Support EOR EC EL Break |3.2.3 | | |x| | | + Ignore unsupported control functions |3.2.3 |x| | | | | + User, Server discard urgent data up to DM |3.2.4 |x| | | | | + User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | | + Server Telnet reply Synch to IP |3.2.4 | | |x| | | + Server Telnet reply Synch to AO |3.2.4 |x| | | | | + User Telnet can flush output when send IP |3.2.4 | |x| | | | + | | | | | | | +Encoding | | | | | | | + Send high-order bit in NVT mode |3.2.5 | | | |x| | + Send high-order bit as parity bit |3.2.5 | | | | |x| + Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | | + Always double IAC data byte |3.2.6 |x| | | | | + + + +Internet Engineering Task Force [Page 27] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Double IAC data byte in binary mode |3.2.7 |x| | | | | + Obey Telnet cmds in binary mode |3.2.7 |x| | | | | + End-of-line, CR NUL in binary mode |3.2.7 | | | | |x| + | | | | | | | +End-of-Line | | | | | | | + EOL at Server same as local end-of-line |3.3.1 |x| | | | | + ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | | + User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | | + ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | | + User Telnet default mode is CR LF |3.3.1 | |x| | | | + Non-interactive uses CR LF for EOL |3.3.1 |x| | | | | + | | | | | | | +User Telnet interface | | | | | | | + Input & output all 7-bit characters |3.4.1 | |x| | | | + Bypass local op sys interpretation |3.4.1 | |x| | | | + Escape character |3.4.1 |x| | | | | + User-settable escape character |3.4.1 | |x| | | | + Escape to enter 8-bit values |3.4.1 | | |x| | | + Can input IP, AO, AYT |3.4.2 |x| | | | | + Can input EC, EL, Break |3.4.2 | |x| | | | + Report TCP connection errors to user |3.4.3 | |x| | | | + Optional non-default contact port |3.4.4 | |x| | | | + Can spec: output flushed when IP sent |3.4.5 | |x| | | | + Can manually restore output mode |3.4.5 | |x| | | | + | | | | | | | + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 28] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + +4. FILE TRANSFER + + 4.1 FILE TRANSFER PROTOCOL -- FTP + + 4.1.1 INTRODUCTION + + The File Transfer Protocol FTP is the primary Internet standard + for file transfer. The current specification is contained in + RFC-959 [FTP:1]. + + FTP uses separate simultaneous TCP connections for control and + for data transfer. The FTP protocol includes many features, + some of which are not commonly implemented. However, for every + feature in FTP, there exists at least one implementation. The + minimum implementation defined in RFC-959 was too small, so a + somewhat larger minimum implementation is defined here. + + Internet users have been unnecessarily burdened for years by + deficient FTP implementations. Protocol implementors have + suffered from the erroneous opinion that implementing FTP ought + to be a small and trivial task. This is wrong, because FTP has + a user interface, because it has to deal (correctly) with the + whole variety of communication and operating system errors that + may occur, and because it has to handle the great diversity of + real file systems in the world. + + 4.1.2. PROTOCOL WALK-THROUGH + + 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4 + + An FTP program MUST support TYPE I ("IMAGE" or binary type) + as well as TYPE L 8 ("LOCAL" type with logical byte size 8). + A machine whose memory is organized into m-bit words, where + m is not a multiple of 8, MAY also support TYPE L m. + + DISCUSSION: + The command "TYPE L 8" is often required to transfer + binary data between a machine whose memory is organized + into (e.g.) 36-bit words and a machine with an 8-bit + byte organization. For an 8-bit byte machine, TYPE L 8 + is equivalent to IMAGE. + + "TYPE L m" is sometimes specified to the FTP programs + on two m-bit word machines to ensure the correct + transfer of a native-mode binary file from one machine + to the other. However, this command should have the + same effect on these machines as "TYPE I". + + + + +Internet Engineering Task Force [Page 29] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2 + + A host that makes no distinction between TYPE N and TYPE T + SHOULD implement TYPE T to be identical to TYPE N. + + DISCUSSION: + This provision should ease interoperation with hosts + that do make this distinction. + + Many hosts represent text files internally as strings + of ASCII characters, using the embedded ASCII format + effector characters (LF, BS, FF, ...) to control the + format when a file is printed. For such hosts, there + is no distinction between "print" files and other + files. However, systems that use record structured + files typically need a special format for printable + files (e.g., ASA carriage control). For the latter + hosts, FTP allows a choice of TYPE N or TYPE T. + + 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I + + Implementation of page structure is NOT RECOMMENDED in + general. However, if a host system does need to implement + FTP for "random access" or "holey" files, it MUST use the + defined page structure format rather than define a new + private FTP format. + + 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2 + + An FTP transformation between record-structure and file- + structure SHOULD be invertible, to the extent possible while + making the result useful on the target host. + + DISCUSSION: + RFC-959 required strict invertibility between record- + structure and file-structure, but in practice, + efficiency and convenience often preclude it. + Therefore, the requirement is being relaxed. There are + two different objectives for transferring a file: + processing it on the target host, or just storage. For + storage, strict invertibility is important. For + processing, the file created on the target host needs + to be in the format expected by application programs on + that host. + + As an example of the conflict, imagine a record- + oriented operating system that requires some data files + to have exactly 80 bytes in each record. While STORing + + + +Internet Engineering Task Force [Page 30] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + a file on such a host, an FTP Server must be able to + pad each line or record to 80 bytes; a later retrieval + of such a file cannot be strictly invertible. + + 4.1.2.5 Data Connection Management: RFC-959 Section 3.3 + + A User-FTP that uses STREAM mode SHOULD send a PORT command + to assign a non-default data port before each transfer + command is issued. + + DISCUSSION: + This is required because of the long delay after a TCP + connection is closed until its socket pair can be + reused, to allow multiple transfers during a single FTP + session. Sending a port command can avoided if a + transfer mode other than stream is used, by leaving the + data transfer connection open between transfers. + + 4.1.2.6 PASV Command: RFC-959 Section 4.1.2 + + A server-FTP MUST implement the PASV command. + + If multiple third-party transfers are to be executed during + the same session, a new PASV command MUST be issued before + each transfer command, to obtain a unique port pair. + + IMPLEMENTATION: + The format of the 227 reply to a PASV command is not + well standardized. In particular, an FTP client cannot + assume that the parentheses shown on page 40 of RFC-959 + will be present (and in fact, Figure 3 on page 43 omits + them). Therefore, a User-FTP program that interprets + the PASV reply must scan the reply for the first digit + of the host and port numbers. + + Note that the host number h1,h2,h3,h4 is the IP address + of the server host that is sending the reply, and that + p1,p2 is a non-default data transfer port that PASV has + assigned. + + 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3 + + The data returned by an NLST command MUST contain only a + simple list of legal pathnames, such that the server can use + them directly as the arguments of subsequent data transfer + commands for the individual files. + + The data returned by a LIST or NLST command SHOULD use an + + + +Internet Engineering Task Force [Page 31] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + implied TYPE AN, unless the current type is EBCDIC, in which + case an implied TYPE EN SHOULD be used. + + DISCUSSION: + Many FTP clients support macro-commands that will get + or put files matching a wildcard specification, using + NLST to obtain a list of pathnames. The expansion of + "multiple-put" is local to the client, but "multiple- + get" requires cooperation by the server. + + The implied type for LIST and NLST is designed to + provide compatibility with existing User-FTPs, and in + particular with multiple-get commands. + + 4.1.2.8 SITE Command: RFC-959 Section 4.1.3 + + A Server-FTP SHOULD use the SITE command for non-standard + features, rather than invent new private commands or + unstandardized extensions to existing commands. + + 4.1.2.9 STOU Command: RFC-959 Section 4.1.3 + + The STOU command stores into a uniquely named file. When it + receives an STOU command, a Server-FTP MUST return the + actual file name in the "125 Transfer Starting" or the "150 + Opening Data Connection" message that precedes the transfer + (the 250 reply code mentioned in RFC-959 is incorrect). The + exact format of these messages is hereby defined to be as + follows: + + 125 FILE: pppp + 150 FILE: pppp + + where pppp represents the unique pathname of the file that + will be written. + + 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34 + + Implementors MUST NOT assume any correspondence between READ + boundaries on the control connection and the Telnet EOL + sequences (CR LF). + + DISCUSSION: + Thus, a server-FTP (or User-FTP) must continue reading + characters from the control connection until a complete + Telnet EOL sequence is encountered, before processing + the command (or response, respectively). Conversely, a + single READ from the control connection may include + + + +Internet Engineering Task Force [Page 32] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + more than one FTP command. + + 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35 + + A Server-FTP MUST send only correctly formatted replies on + the control connection. Note that RFC-959 (unlike earlier + versions of the FTP spec) contains no provision for a + "spontaneous" reply message. + + A Server-FTP SHOULD use the reply codes defined in RFC-959 + whenever they apply. However, a server-FTP MAY use a + different reply code when needed, as long as the general + rules of Section 4.2 are followed. When the implementor has + a choice between a 4xx and 5xx reply code, a Server-FTP + SHOULD send a 4xx (temporary failure) code when there is any + reasonable possibility that a failed FTP will succeed a few + hours later. + + A User-FTP SHOULD generally use only the highest-order digit + of a 3-digit reply code for making a procedural decision, to + prevent difficulties when a Server-FTP uses non-standard + reply codes. + + A User-FTP MUST be able to handle multi-line replies. If + the implementation imposes a limit on the number of lines + and if this limit is exceeded, the User-FTP MUST recover, + e.g., by ignoring the excess lines until the end of the + multi-line reply is reached. + + A User-FTP SHOULD NOT interpret a 421 reply code ("Service + not available, closing control connection") specially, but + SHOULD detect closing of the control connection by the + server. + + DISCUSSION: + Server implementations that fail to strictly follow the + reply rules often cause FTP user programs to hang. + Note that RFC-959 resolved ambiguities in the reply + rules found in earlier FTP specifications and must be + followed. + + It is important to choose FTP reply codes that properly + distinguish between temporary and permanent failures, + to allow the successful use of file transfer client + daemons. These programs depend on the reply codes to + decide whether or not to retry a failed transfer; using + a permanent failure code (5xx) for a temporary error + will cause these programs to give up unnecessarily. + + + +Internet Engineering Task Force [Page 33] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + When the meaning of a reply matches exactly the text + shown in RFC-959, uniformity will be enhanced by using + the RFC-959 text verbatim. However, a Server-FTP + implementor is encouraged to choose reply text that + conveys specific system-dependent information, when + appropriate. + + 4.1.2.12 Connections: RFC-959 Section 5.2 + + The words "and the port used" in the second paragraph of + this section of RFC-959 are erroneous (historical), and they + should be ignored. + + On a multihomed server host, the default data transfer port + (L-1) MUST be associated with the same local IP address as + the corresponding control connection to port L. + + A user-FTP MUST NOT send any Telnet controls other than + SYNCH and IP on an FTP control connection. In particular, it + MUST NOT attempt to negotiate Telnet options on the control + connection. However, a server-FTP MUST be capable of + accepting and refusing Telnet negotiations (i.e., sending + DONT/WONT). + + DISCUSSION: + Although the RFC says: "Server- and User- processes + should follow the conventions for the Telnet + protocol...[on the control connection]", it is not the + intent that Telnet option negotiation is to be + employed. + + 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1 + + The following commands and options MUST be supported by + every server-FTP and user-FTP, except in cases where the + underlying file system or operating system does not allow or + support a particular command. + + Type: ASCII Non-print, IMAGE, LOCAL 8 + Mode: Stream + Structure: File, Record* + Commands: + USER, PASS, ACCT, + PORT, PASV, + TYPE, MODE, STRU, + RETR, STOR, APPE, + RNFR, RNTO, DELE, + CWD, CDUP, RMD, MKD, PWD, + + + +Internet Engineering Task Force [Page 34] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + LIST, NLST, + SYST, STAT, + HELP, NOOP, QUIT. + + *Record structure is REQUIRED only for hosts whose file + systems support record structure. + + DISCUSSION: + Vendors are encouraged to implement a larger subset of + the protocol. For example, there are important + robustness features in the protocol (e.g., Restart, + ABOR, block mode) that would be an aid to some Internet + users but are not widely implemented. + + A host that does not have record structures in its file + system may still accept files with STRU R, recording + the byte stream literally. + + 4.1.3 SPECIFIC ISSUES + + 4.1.3.1 Non-standard Command Verbs + + FTP allows "experimental" commands, whose names begin with + "X". If these commands are subsequently adopted as + standards, there may still be existing implementations using + the "X" form. At present, this is true for the directory + commands: + + RFC-959 "Experimental" + + MKD XMKD + RMD XRMD + PWD XPWD + CDUP XCUP + CWD XCWD + + All FTP implementations SHOULD recognize both forms of these + commands, by simply equating them with extra entries in the + command lookup table. + + IMPLEMENTATION: + A User-FTP can access a server that supports only the + "X" forms by implementing a mode switch, or + automatically using the following procedure: if the + RFC-959 form of one of the above commands is rejected + with a 500 or 502 response code, then try the + experimental form; any other response would be passed + to the user. + + + +Internet Engineering Task Force [Page 35] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.3.2 Idle Timeout + + A Server-FTP process SHOULD have an idle timeout, which will + terminate the process and close the control connection if + the server is inactive (i.e., no command or data transfer in + progress) for a long period of time. The idle timeout time + SHOULD be configurable, and the default should be at least 5 + minutes. + + A client FTP process ("User-PI" in RFC-959) will need + timeouts on responses only if it is invoked from a program. + + DISCUSSION: + Without a timeout, a Server-FTP process may be left + pending indefinitely if the corresponding client + crashes without closing the control connection. + + 4.1.3.3 Concurrency of Data and Control + + DISCUSSION: + The intent of the designers of FTP was that a user + should be able to send a STAT command at any time while + data transfer was in progress and that the server-FTP + would reply immediately with status -- e.g., the number + of bytes transferred so far. Similarly, an ABOR + command should be possible at any time during a data + transfer. + + Unfortunately, some small-machine operating systems + make such concurrent programming difficult, and some + other implementers seek minimal solutions, so some FTP + implementations do not allow concurrent use of the data + and control connections. Even such a minimal server + must be prepared to accept and defer a STAT or ABOR + command that arrives during data transfer. + + 4.1.3.4 FTP Restart Mechanism + + The description of the 110 reply on pp. 40-41 of RFC-959 is + incorrect; the correct description is as follows. A restart + reply message, sent over the control connection from the + receiving FTP to the User-FTP, has the format: + + 110 MARK ssss = rrrr + + Here: + + * ssss is a text string that appeared in a Restart Marker + + + +Internet Engineering Task Force [Page 36] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + in the data stream and encodes a position in the + sender's file system; + + * rrrr encodes the corresponding position in the + receiver's file system. + + The encoding, which is specific to a particular file system + and network implementation, is always generated and + interpreted by the same system, either sender or receiver. + + When an FTP that implements restart receives a Restart + Marker in the data stream, it SHOULD force the data to that + point to be written to stable storage before encoding the + corresponding position rrrr. An FTP sending Restart Markers + MUST NOT assume that 110 replies will be returned + synchronously with the data, i.e., it must not await a 110 + reply before sending more data. + + Two new reply codes are hereby defined for errors + encountered in restarting a transfer: + + 554 Requested action not taken: invalid REST parameter. + + A 554 reply may result from a FTP service command that + follows a REST command. The reply indicates that the + existing file at the Server-FTP cannot be repositioned + as specified in the REST. + + 555 Requested action not taken: type or stru mismatch. + + A 555 reply may result from an APPE command or from any + FTP service command following a REST command. The + reply indicates that there is some mismatch between the + current transfer parameters (type and stru) and the + attributes of the existing file. + + DISCUSSION: + Note that the FTP Restart mechanism requires that Block + or Compressed mode be used for data transfer, to allow + the Restart Markers to be included within the data + stream. The frequency of Restart Markers can be low. + + Restart Markers mark a place in the data stream, but + the receiver may be performing some transformation on + the data as it is stored into stable storage. In + general, the receiver's encoding must include any state + information necessary to restart this transformation at + any point of the FTP data stream. For example, in TYPE + + + +Internet Engineering Task Force [Page 37] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + A transfers, some receiver hosts transform CR LF + sequences into a single LF character on disk. If a + Restart Marker happens to fall between CR and LF, the + receiver must encode in rrrr that the transfer must be + restarted in a "CR has been seen and discarded" state. + + Note that the Restart Marker is required to be encoded + as a string of printable ASCII characters, regardless + of the type of the data. + + RFC-959 says that restart information is to be returned + "to the user". This should not be taken literally. In + general, the User-FTP should save the restart + information (ssss,rrrr) in stable storage, e.g., append + it to a restart control file. An empty restart control + file should be created when the transfer first starts + and deleted automatically when the transfer completes + successfully. It is suggested that this file have a + name derived in an easily-identifiable manner from the + name of the file being transferred and the remote host + name; this is analogous to the means used by many text + editors for naming "backup" files. + + There are three cases for FTP restart. + + (1) User-to-Server Transfer + + The User-FTP puts Restart Markers at + convenient places in the data stream. When the + Server-FTP receives a Marker, it writes all prior + data to disk, encodes its file system position and + transformation state as rrrr, and returns a "110 + MARK ssss = rrrr" reply over the control + connection. The User-FTP appends the pair + (ssss,rrrr) to its restart control file. + + To restart the transfer, the User-FTP fetches the + last (ssss,rrrr) pair from the restart control + file, repositions its local file system and + transformation state using ssss, and sends the + command "REST rrrr" to the Server-FTP. + + (2) Server-to-User Transfer + + The Server-FTP puts Restart Markers at + convenient places in the data stream. When the + User-FTP receives a Marker, it writes all prior + data to disk, encodes its file system position and + + + +Internet Engineering Task Force [Page 38] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + transformation state as rrrr, and appends the pair + (rrrr,ssss) to its restart control file. + + To restart the transfer, the User-FTP fetches the + last (rrrr,ssss) pair from the restart control + file, repositions its local file system and + transformation state using rrrr, and sends the + command "REST ssss" to the Server-FTP. + + (3) Server-to-Server ("Third-Party") Transfer + + The sending Server-FTP puts Restart Markers + at convenient places in the data stream. When it + receives a Marker, the receiving Server-FTP writes + all prior data to disk, encodes its file system + position and transformation state as rrrr, and + sends a "110 MARK ssss = rrrr" reply over the + control connection to the User. The User-FTP + appends the pair (ssss,rrrr) to its restart + control file. + + To restart the transfer, the User-FTP fetches the + last (ssss,rrrr) pair from the restart control + file, sends "REST ssss" to the sending Server-FTP, + and sends "REST rrrr" to the receiving Server-FTP. + + + 4.1.4 FTP/USER INTERFACE + + This section discusses the user interface for a User-FTP + program. + + 4.1.4.1 Pathname Specification + + Since FTP is intended for use in a heterogeneous + environment, User-FTP implementations MUST support remote + pathnames as arbitrary character strings, so that their form + and content are not limited by the conventions of the local + operating system. + + DISCUSSION: + In particular, remote pathnames can be of arbitrary + length, and all the printing ASCII characters as well + as space (0x20) must be allowed. RFC-959 allows a + pathname to contain any 7-bit ASCII character except CR + or LF. + + + + + +Internet Engineering Task Force [Page 39] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.4.2 "QUOTE" Command + + A User-FTP program MUST implement a "QUOTE" command that + will pass an arbitrary character string to the server and + display all resulting response messages to the user. + + To make the "QUOTE" command useful, a User-FTP SHOULD send + transfer control commands to the server as the user enters + them, rather than saving all the commands and sending them + to the server only when a data transfer is started. + + DISCUSSION: + The "QUOTE" command is essential to allow the user to + access servers that require system-specific commands + (e.g., SITE or ALLO), or to invoke new or optional + features that are not implemented by the User-FTP. For + example, "QUOTE" may be used to specify "TYPE A T" to + send a print file to hosts that require the + distinction, even if the User-FTP does not recognize + that TYPE. + + 4.1.4.3 Displaying Replies to User + + A User-FTP SHOULD display to the user the full text of all + error reply messages it receives. It SHOULD have a + "verbose" mode in which all commands it sends and the full + text and reply codes it receives are displayed, for + diagnosis of problems. + + 4.1.4.4 Maintaining Synchronization + + The state machine in a User-FTP SHOULD be forgiving of + missing and unexpected reply messages, in order to maintain + command synchronization with the server. + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 40] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.5 FTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------|---------------|-|-|-|-|-|-- +Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | | +File/Record transform invertible if poss. |4.1.2.4 | |x| | | | +User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | | +Server-FTP implement PASV |4.1.2.6 |x| | | | | + PASV is per-transfer |4.1.2.6 |x| | | | | +NLST reply usable in RETR cmds |4.1.2.7 |x| | | | | +Implied type for LIST and NLST |4.1.2.7 | |x| | | | +SITE cmd for non-standard features |4.1.2.8 | |x| | | | +STOU cmd return pathname as specified |4.1.2.9 |x| | | | | +Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x| + | | | | | | | +Server-FTP send only correct reply format |4.1.2.11 |x| | | | | +Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | | + New reply code following Section 4.2 |4.1.2.11 | | |x| | | +User-FTP use only high digit of reply |4.1.2.11 | |x| | | | +User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | | +User-FTP handle 421 reply specially |4.1.2.11 | | | |x| | + | | | | | | | +Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | | +User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x| +User-FTP negotiate Telnet options |4.1.2.12 | | | | |x| +Server-FTP handle Telnet options |4.1.2.12 |x| | | | | +Handle "Experimental" directory cmds |4.1.3.1 | |x| | | | +Idle timeout in server-FTP |4.1.3.2 | |x| | | | + Configurable idle timeout |4.1.3.2 | |x| | | | +Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | | +Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x| + | | | | | | | +Support TYPE: | | | | | | | + ASCII - Non-Print (AN) |4.1.2.13 |x| | | | | + ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | | + ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | | + EBCDIC - (any form) |959 3.1.1.2 | | |x| | | + IMAGE |4.1.2.1 |x| | | | | + LOCAL 8 |4.1.2.1 |x| | | | | + + + +Internet Engineering Task Force [Page 41] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + LOCAL m |4.1.2.1 | | |x| | |2 + | | | | | | | +Support MODE: | | | | | | | + Stream |4.1.2.13 |x| | | | | + Block |959 3.4.2 | | |x| | | + | | | | | | | +Support STRUCTURE: | | | | | | | + File |4.1.2.13 |x| | | | | + Record |4.1.2.13 |x| | | | |3 + Page |4.1.2.3 | | | |x| | + | | | | | | | +Support commands: | | | | | | | + USER |4.1.2.13 |x| | | | | + PASS |4.1.2.13 |x| | | | | + ACCT |4.1.2.13 |x| | | | | + CWD |4.1.2.13 |x| | | | | + CDUP |4.1.2.13 |x| | | | | + SMNT |959 5.3.1 | | |x| | | + REIN |959 5.3.1 | | |x| | | + QUIT |4.1.2.13 |x| | | | | + | | | | | | | + PORT |4.1.2.13 |x| | | | | + PASV |4.1.2.6 |x| | | | | + TYPE |4.1.2.13 |x| | | | |1 + STRU |4.1.2.13 |x| | | | |1 + MODE |4.1.2.13 |x| | | | |1 + | | | | | | | + RETR |4.1.2.13 |x| | | | | + STOR |4.1.2.13 |x| | | | | + STOU |959 5.3.1 | | |x| | | + APPE |4.1.2.13 |x| | | | | + ALLO |959 5.3.1 | | |x| | | + REST |959 5.3.1 | | |x| | | + RNFR |4.1.2.13 |x| | | | | + RNTO |4.1.2.13 |x| | | | | + ABOR |959 5.3.1 | | |x| | | + DELE |4.1.2.13 |x| | | | | + RMD |4.1.2.13 |x| | | | | + MKD |4.1.2.13 |x| | | | | + PWD |4.1.2.13 |x| | | | | + LIST |4.1.2.13 |x| | | | | + NLST |4.1.2.13 |x| | | | | + SITE |4.1.2.8 | | |x| | | + STAT |4.1.2.13 |x| | | | | + SYST |4.1.2.13 |x| | | | | + HELP |4.1.2.13 |x| | | | | + NOOP |4.1.2.13 |x| | | | | + | | | | | | | + + + +Internet Engineering Task Force [Page 42] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + +User Interface: | | | | | | | + Arbitrary pathnames |4.1.4.1 |x| | | | | + Implement "QUOTE" command |4.1.4.2 |x| | | | | + Transfer control commands immediately |4.1.4.2 | |x| | | | + Display error messages to user |4.1.4.3 | |x| | | | + Verbose mode |4.1.4.3 | |x| | | | + Maintain synchronization with server |4.1.4.4 | |x| | | | + +Footnotes: + +(1) For the values shown earlier. + +(2) Here m is number of bits in a memory word. + +(3) Required for host with record-structured file system, optional + otherwise. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 43] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP + + 4.2.1 INTRODUCTION + + The Trivial File Transfer Protocol TFTP is defined in RFC-783 + [TFTP:1]. + + TFTP provides its own reliable delivery with UDP as its + transport protocol, using a simple stop-and-wait acknowledgment + system. Since TFTP has an effective window of only one 512 + octet segment, it can provide good performance only over paths + that have a small delay*bandwidth product. The TFTP file + interface is very simple, providing no access control or + security. + + TFTP's most important application is bootstrapping a host over + a local network, since it is simple and small enough to be + easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are + urged to support TFTP for booting. + + 4.2.2 PROTOCOL WALK-THROUGH + + The TFTP specification [TFTP:1] is written in an open style, + and does not fully specify many parts of the protocol. + + 4.2.2.1 Transfer Modes: RFC-783, Page 3 + + The transfer mode "mail" SHOULD NOT be supported. + + 4.2.2.2 UDP Header: RFC-783, Page 17 + + The Length field of a UDP header is incorrectly defined; it + includes the UDP header length (8). + + 4.2.3 SPECIFIC ISSUES + + 4.2.3.1 Sorcerer's Apprentice Syndrome + + There is a serious bug, known as the "Sorcerer's Apprentice + Syndrome," in the protocol specification. While it does not + cause incorrect operation of the transfer (the file will + always be transferred correctly if the transfer completes), + this bug may cause excessive retransmission, which may cause + the transfer to time out. + + Implementations MUST contain the fix for this problem: the + sender (i.e., the side originating the DATA packets) must + never resend the current DATA packet on receipt of a + + + +Internet Engineering Task Force [Page 44] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + duplicate ACK. + + DISCUSSION: + The bug is caused by the protocol rule that either + side, on receiving an old duplicate datagram, may + resend the current datagram. If a packet is delayed in + the network but later successfully delivered after + either side has timed out and retransmitted a packet, a + duplicate copy of the response may be generated. If + the other side responds to this duplicate with a + duplicate of its own, then every datagram will be sent + in duplicate for the remainder of the transfer (unless + a datagram is lost, breaking the repetition). Worse + yet, since the delay is often caused by congestion, + this duplicate transmission will usually causes more + congestion, leading to more delayed packets, etc. + + The following example may help to clarify this problem. + + TFTP A TFTP B + + (1) Receive ACK X-1 + Send DATA X + (2) Receive DATA X + Send ACK X + (ACK X is delayed in network, + and A times out): + (3) Retransmit DATA X + + (4) Receive DATA X again + Send ACK X again + (5) Receive (delayed) ACK X + Send DATA X+1 + (6) Receive DATA X+1 + Send ACK X+1 + (7) Receive ACK X again + Send DATA X+1 again + (8) Receive DATA X+1 again + Send ACK X+1 again + (9) Receive ACK X+1 + Send DATA X+2 + (10) Receive DATA X+2 + Send ACK X+3 + (11) Receive ACK X+1 again + Send DATA X+2 again + (12) Receive DATA X+2 again + Send ACK X+3 again + + + + +Internet Engineering Task Force [Page 45] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + Notice that once the delayed ACK arrives, the protocol + settles down to duplicate all further packets + (sequences 5-8 and 9-12). The problem is caused not by + either side timing out, but by both sides + retransmitting the current packet when they receive a + duplicate. + + The fix is to break the retransmission loop, as + indicated above. This is analogous to the behavior of + TCP. It is then possible to remove the retransmission + timer on the receiver, since the resent ACK will never + cause any action; this is a useful simplification where + TFTP is used in a bootstrap program. It is OK to allow + the timer to remain, and it may be helpful if the + retransmitted ACK replaces one that was genuinely lost + in the network. The sender still requires a retransmit + timer, of course. + + 4.2.3.2 Timeout Algorithms + + A TFTP implementation MUST use an adaptive timeout. + + IMPLEMENTATION: + TCP retransmission algorithms provide a useful base to + work from. At least an exponential backoff of + retransmission timeout is necessary. + + 4.2.3.3 Extensions + + A variety of non-standard extensions have been made to TFTP, + including additional transfer modes and a secure operation + mode (with passwords). None of these have been + standardized. + + 4.2.3.4 Access Control + + A server TFTP implementation SHOULD include some + configurable access control over what pathnames are allowed + in TFTP operations. + + 4.2.3.5 Broadcast Request + + A TFTP request directed to a broadcast address SHOULD be + silently ignored. + + DISCUSSION: + Due to the weak access control capability of TFTP, + directed broadcasts of TFTP requests to random networks + + + +Internet Engineering Task Force [Page 46] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + could create a significant security hole. + + 4.2.4 TFTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------------|--------|-|-|-|-|-|-- +Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | | +Transfer modes: | | | | | | | + netascii |RFC-783 |x| | | | | + octet |RFC-783 |x| | | | | + mail |4.2.2.1 | | | |x| | + extensions |4.2.3.3 | | |x| | | +Use adaptive timeout |4.2.3.2 |x| | | | | +Configurable access control |4.2.3.4 | |x| | | | +Silently ignore broadcast request |4.2.3.5 | |x| | | | +-------------------------------------------------|--------|-|-|-|-|-|-- +-------------------------------------------------|--------|-|-|-|-|-|-- + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 47] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + +5. ELECTRONIC MAIL -- SMTP and RFC-822 + + 5.1 INTRODUCTION + + In the TCP/IP protocol suite, electronic mail in a format + specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail + Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1]. + + While SMTP has remained unchanged over the years, the Internet + community has made several changes in the way SMTP is used. In + particular, the conversion to the Domain Name System (DNS) has + caused changes in address formats and in mail routing. In this + section, we assume familiarity with the concepts and terminology + of the DNS, whose requirements are given in Section 6.1. + + RFC-822 specifies the Internet standard format for electronic mail + messages. RFC-822 supercedes an older standard, RFC-733, that may + still be in use in a few places, although it is obsolete. The two + formats are sometimes referred to simply by number ("822" and + "733"). + + RFC-822 is used in some non-Internet mail environments with + different mail transfer protocols than SMTP, and SMTP has also + been adapted for use in some non-Internet environments. Note that + this document presents the rules for the use of SMTP and RFC-822 + for the Internet environment only; other mail environments that + use these protocols may be expected to have their own rules. + + 5.2 PROTOCOL WALK-THROUGH + + This section covers both RFC-821 and RFC-822. + + The SMTP specification in RFC-821 is clear and contains numerous + examples, so implementors should not find it difficult to + understand. This section simply updates or annotates portions of + RFC-821 to conform with current usage. + + RFC-822 is a long and dense document, defining a rich syntax. + Unfortunately, incomplete or defective implementations of RFC-822 + are common. In fact, nearly all of the many formats of RFC-822 + are actually used, so an implementation generally needs to + recognize and correctly interpret all of the RFC-822 syntax. + + 5.2.1 The SMTP Model: RFC-821 Section 2 + + DISCUSSION: + Mail is sent by a series of request/response transactions + between a client, the "sender-SMTP," and a server, the + + + +Internet Engineering Task Force [Page 48] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + "receiver-SMTP". These transactions pass (1) the message + proper, which is composed of header and body, and (2) SMTP + source and destination addresses, referred to as the + "envelope". + + The SMTP programs are analogous to Message Transfer Agents + (MTAs) of X.400. There will be another level of protocol + software, closer to the end user, that is responsible for + composing and analyzing RFC-822 message headers; this + component is known as the "User Agent" in X.400, and we + use that term in this document. There is a clear logical + distinction between the User Agent and the SMTP + implementation, since they operate on different levels of + protocol. Note, however, that this distinction is may not + be exactly reflected the structure of typical + implementations of Internet mail. Often there is a + program known as the "mailer" that implements SMTP and + also some of the User Agent functions; the rest of the + User Agent functions are included in a user interface used + for entering and reading mail. + + The SMTP envelope is constructed at the originating site, + typically by the User Agent when the message is first + queued for the Sender-SMTP program. The envelope + addresses may be derived from information in the message + header, supplied by the user interface (e.g., to implement + a bcc: request), or derived from local configuration + information (e.g., expansion of a mailing list). The SMTP + envelope cannot in general be re-derived from the header + at a later stage in message delivery, so the envelope is + transmitted separately from the message itself using the + MAIL and RCPT commands of SMTP. + + The text of RFC-821 suggests that mail is to be delivered + to an individual user at a host. With the advent of the + domain system and of mail routing using mail-exchange (MX) + resource records, implementors should now think of + delivering mail to a user at a domain, which may or may + not be a particular host. This DOES NOT change the fact + that SMTP is a host-to-host mail exchange protocol. + + 5.2.2 Canonicalization: RFC-821 Section 3.1 + + The domain names that a Sender-SMTP sends in MAIL and RCPT + commands MUST have been "canonicalized," i.e., they must be + fully-qualified principal names or domain literals, not + nicknames or domain abbreviations. A canonicalized name either + identifies a host directly or is an MX name; it cannot be a + + + +Internet Engineering Task Force [Page 49] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + CNAME. + + 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3 + + A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN + (this requirement overrides RFC-821). However, there MAY be + configuration information to disable VRFY and EXPN in a + particular installation; this might even allow EXPN to be + disabled for selected lists. + + A new reply code is defined for the VRFY command: + + 252 Cannot VRFY user (e.g., info is not local), but will + take message for this user and attempt delivery. + + DISCUSSION: + SMTP users and administrators make regular use of these + commands for diagnosing mail delivery problems. With the + increasing use of multi-level mailing list expansion + (sometimes more than two levels), EXPN has been + increasingly important for diagnosing inadvertent mail + loops. On the other hand, some feel that EXPN represents + a significant privacy, and perhaps even a security, + exposure. + + 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4 + + An SMTP MAY implement the commands to send a message to a + user's terminal: SEND, SOML, and SAML. + + DISCUSSION: + It has been suggested that the use of mail relaying + through an MX record is inconsistent with the intent of + SEND to deliver a message immediately and directly to a + user's terminal. However, an SMTP receiver that is unable + to write directly to the user terminal can return a "251 + User Not Local" reply to the RCPT following a SEND, to + inform the originator of possibly deferred delivery. + + 5.2.5 HELO Command: RFC-821 Section 3.5 + + The sender-SMTP MUST ensure that the parameter in a + HELO command is a valid principal host domain name for the + client host. As a result, the receiver-SMTP will not have to + perform MX resolution on this name in order to validate the + HELO parameter. + + The HELO receiver MAY verify that the HELO parameter really + + + +Internet Engineering Task Force [Page 50] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + corresponds to the IP address of the sender. However, the + receiver MUST NOT refuse to accept a message, even if the + sender's HELO command fails verification. + + DISCUSSION: + Verifying the HELO parameter requires a domain name lookup + and may therefore take considerable time. An alternative + tool for tracking bogus mail sources is suggested below + (see "DATA Command"). + + Note also that the HELO argument is still required to have + valid syntax, since it will appear in a Received: + line; otherwise, a 501 error is to be sent. + + IMPLEMENTATION: + When HELO parameter validation fails, a suggested + procedure is to insert a note about the unknown + authenticity of the sender into the message header (e.g., + in the "Received:" line). + + 5.2.6 Mail Relay: RFC-821 Section 3.6 + + We distinguish three types of mail (store-and-) forwarding: + + (1) A simple forwarder or "mail exchanger" forwards a message + using private knowledge about the recipient; see section + 3.2 of RFC-821. + + (2) An SMTP mail "relay" forwards a message within an SMTP + mail environment as the result of an explicit source route + (as defined in section 3.6 of RFC-821). The SMTP relay + function uses the "@...:" form of source route from RFC- + 822 (see Section 5.2.19 below). + + (3) A mail "gateway" passes a message between different + environments. The rules for mail gateways are discussed + below in Section 5.3.7. + + An Internet host that is forwarding a message but is not a + gateway to a different mail environment (i.e., it falls under + (1) or (2)) SHOULD NOT alter any existing header fields, + although the host will add an appropriate Received: line as + required in Section 5.2.8. + + A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an + explicit source route using the "@...:" address form. Thus, + the relay function defined in section 3.6 of RFC-821 should + not be used. + + + +Internet Engineering Task Force [Page 51] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + The intent is to discourage all source routing and to + abolish explicit source routing for mail delivery within + the Internet environment. Source-routing is unnecessary; + the simple target address "user@domain" should always + suffice. This is the result of an explicit architectural + decision to use universal naming rather than source + routing for mail. Thus, SMTP provides end-to-end + connectivity, and the DNS provides globally-unique, + location-independent names. MX records handle the major + case where source routing might otherwise be needed. + + A receiver-SMTP MUST accept the explicit source route syntax in + the envelope, but it MAY implement the relay function as + defined in section 3.6 of RFC-821. If it does not implement + the relay function, it SHOULD attempt to deliver the message + directly to the host to the right of the right-most "@" sign. + + DISCUSSION: + For example, suppose a host that does not implement the + relay function receives a message with the SMTP command: + "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and + GAMMA represent domain names. Rather than immediately + refusing the message with a 550 error reply as suggested + on page 20 of RFC-821, the host should try to forward the + message to GAMMA directly, using: "RCPT TO:". + Since this host does not support relaying, it is not + required to update the reverse path. + + Some have suggested that source routing may be needed + occasionally for manually routing mail around failures; + however, the reality and importance of this need is + controversial. The use of explicit SMTP mail relaying for + this purpose is discouraged, and in fact it may not be + successful, as many host systems do not support it. Some + have used the "%-hack" (see Section 5.2.16) for this + purpose. + + 5.2.7 RCPT Command: RFC-821 Section 4.1.1 + + A host that supports a receiver-SMTP MUST support the reserved + mailbox "Postmaster". + + The receiver-SMTP MAY verify RCPT parameters as they arrive; + however, RCPT responses MUST NOT be delayed beyond a reasonable + time (see Section 5.3.2). + + Therefore, a "250 OK" response to a RCPT does not necessarily + + + +Internet Engineering Task Force [Page 52] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + imply that the delivery address(es) are valid. Errors found + after message acceptance will be reported by mailing a + notification message to an appropriate address (see Section + 5.3.3). + + DISCUSSION: + The set of conditions under which a RCPT parameter can be + validated immediately is an engineering design choice. + Reporting destination mailbox errors to the Sender-SMTP + before mail is transferred is generally desirable to save + time and network bandwidth, but this advantage is lost if + RCPT verification is lengthy. + + For example, the receiver can verify immediately any + simple local reference, such as a single locally- + registered mailbox. On the other hand, the "reasonable + time" limitation generally implies deferring verification + of a mailing list until after the message has been + transferred and accepted, since verifying a large mailing + list can take a very long time. An implementation might + or might not choose to defer validation of addresses that + are non-local and therefore require a DNS lookup. If a + DNS lookup is performed but a soft domain system error + (e.g., timeout) occurs, validity must be assumed. + + 5.2.8 DATA Command: RFC-821 Section 4.1.1 + + Every receiver-SMTP (not just one that "accepts a message for + relaying or for final delivery" [SMTP:1]) MUST insert a + "Received:" line at the beginning of a message. In this line, + called a "time stamp line" in RFC-821: + + * The FROM field SHOULD contain both (1) the name of the + source host as presented in the HELO command and (2) a + domain literal containing the IP address of the source, + determined from the TCP connection. + + * The ID field MAY contain an "@" as suggested in RFC-822, + but this is not required. + + * The FOR field MAY contain a list of entries when + multiple RCPT commands have been given. + + + An Internet mail program MUST NOT change a Received: line that + was previously added to the message header. + + + + + +Internet Engineering Task Force [Page 53] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + Including both the source host and the IP source address + in the Received: line may provide enough information for + tracking illicit mail sources and eliminate a need to + explicitly verify the HELO parameter. + + Received: lines are primarily intended for humans tracing + mail routes, primarily of diagnosis of faults. See also + the discussion under 5.3.7. + + When the receiver-SMTP makes "final delivery" of a message, + then it MUST pass the MAIL FROM: address from the SMTP envelope + with the message, for use if an error notification message must + be sent later (see Section 5.3.3). There is an analogous + requirement when gatewaying from the Internet into a different + mail environment; see Section 5.3.7. + + DISCUSSION: + Note that the final reply to the DATA command depends only + upon the successful transfer and storage of the message. + Any problem with the destination address(es) must either + (1) have been reported in an SMTP error reply to the RCPT + command(s), or (2) be reported in a later error message + mailed to the originator. + + IMPLEMENTATION: + The MAIL FROM: information may be passed as a parameter or + in a Return-Path: line inserted at the beginning of the + message. + + 5.2.9 Command Syntax: RFC-821 Section 4.1.2 + + The syntax shown in RFC-821 for the MAIL FROM: command omits + the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page + 15). An empty reverse path MUST be supported. + + 5.2.10 SMTP Replies: RFC-821 Section 4.2 + + A receiver-SMTP SHOULD send only the reply codes listed in + section 4.2.2 of RFC-821 or in this document. A receiver-SMTP + SHOULD use the text shown in examples in RFC-821 whenever + appropriate. + + A sender-SMTP MUST determine its actions only by the reply + code, not by the text (except for 251 and 551 replies); any + text, including no text at all, must be acceptable. The space + (blank) following the reply code is considered part of the + text. Whenever possible, a sender-SMTP SHOULD test only the + + + +Internet Engineering Task Force [Page 54] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + first digit of the reply code, as specified in Appendix E of + RFC-821. + + DISCUSSION: + Interoperability problems have arisen with SMTP systems + using reply codes that are not listed explicitly in RFC- + 821 Section 4.3 but are legal according to the theory of + reply codes explained in Appendix E. + + 5.2.11 Transparency: RFC-821 Section 4.5.2 + + Implementors MUST be sure that their mail systems always add + and delete periods to ensure message transparency. + + 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 + + RFC-974 [SMTP:3] recommended that the domain system be queried + for WKS ("Well-Known Service") records, to verify that each + proposed mail target does support SMTP. Later experience has + shown that WKS is not widely supported, so the WKS step in MX + processing SHOULD NOT be used. + + The following are notes on RFC-822, organized by section of that + document. + + 5.2.13 RFC-822 Message Specification: RFC-822 Section 4 + + The syntax shown for the Return-path line omits the possibility + of a null return path, which is used to prevent looping of + error notifications (see Section 5.3.3). The complete syntax + is: + + return = "Return-path" ":" route-addr + / "Return-path" ":" "<" ">" + + The set of optional header fields is hereby expanded to include + the Content-Type field defined in RFC-1049 [SMTP:7]. This + field "allows mail reading systems to automatically identify + the type of a structured message body and to process it for + display accordingly". [SMTP:7] A User Agent MAY support this + field. + + 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 + + The syntax for the date is hereby changed to: + + date = 1*2DIGIT month 2*4DIGIT + + + + +Internet Engineering Task Force [Page 55] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + All mail software SHOULD use 4-digit years in dates, to ease + the transition to the next century. + + There is a strong trend towards the use of numeric timezone + indicators, and implementations SHOULD use numeric timezones + instead of timezone names. However, all implementations MUST + accept either notation. If timezone names are used, they MUST + be exactly as defined in RFC-822. + + The military time zones are specified incorrectly in RFC-822: + they count the wrong way from UT (the signs are reversed). As + a result, military time zones in RFC-822 headers carry no + information. + + Finally, note that there is a typo in the definition of "zone" + in the syntax summary of appendix D; the correct definition + occurs in Section 3 of RFC-822. + + 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1 + + The syntactic definition of "mailbox" in RFC-822 is hereby + changed to: + + mailbox = addr-spec ; simple address + / [phrase] route-addr ; name & addr-spec + + That is, the phrase preceding a route address is now OPTIONAL. + This change makes the following header field legal, for + example: + + From: + + 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2 + + The basic mailbox address specification has the form: "local- + part@domain". Here "local-part", sometimes called the "left- + hand side" of the address, is domain-dependent. + + A host that is forwarding the message but is not the + destination host implied by the right-hand side "domain" MUST + NOT interpret or modify the "local-part" of the address. + + When mail is to be gatewayed from the Internet mail environment + into a foreign mail environment (see Section 5.3.7), routing + information for that foreign environment MAY be embedded within + the "local-part" of the address. The gateway will then + interpret this local part appropriately for the foreign mail + environment. + + + +Internet Engineering Task Force [Page 56] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + Although source routes are discouraged within the Internet + (see Section 5.2.6), there are non-Internet mail + environments whose delivery mechanisms do depend upon + source routes. Source routes for extra-Internet + environments can generally be buried in the "local-part" + of the address (see Section 5.2.16) while mail traverses + the Internet. When the mail reaches the appropriate + Internet mail gateway, the gateway will interpret the + local-part and build the necessary address or route for + the target mail environment. + + For example, an Internet host might send mail to: + "a!b!c!user@gateway-domain". The complex local part + "a!b!c!user" would be uninterpreted within the Internet + domain, but could be parsed and understood by the + specified mail gateway. + + An embedded source route is sometimes encoded in the + "local-part" using "%" as a right-binding routing + operator. For example, in: + + user%domain%relay3%relay2@relay1 + + the "%" convention implies that the mail is to be routed + from "relay1" through "relay2", "relay3", and finally to + "user" at "domain". This is commonly known as the "%- + hack". It is suggested that "%" have lower precedence + than any other routing operator (e.g., "!") hidden in the + local-part; for example, "a!b%c" would be interpreted as + "(a!b)%c". + + Only the target host (in this case, "relay1") is permitted + to analyze the local-part "user%domain%relay3%relay2". + + 5.2.17 Domain Literals: RFC-822 Section 6.2.3 + + A mailer MUST be able to accept and parse an Internet domain + literal whose content ("dtext"; see RFC-822) is a dotted- + decimal host address. This satisfies the requirement of + Section 2.1 for the case of mail. + + An SMTP MUST accept and recognize a domain literal for any of + its own IP addresses. + + + + + + + +Internet Engineering Task Force [Page 57] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 + + Errors in formatting or parsing 822 addresses are unfortunately + common. This section mentions only the most common errors. A + User Agent MUST accept all valid RFC-822 address formats, and + MUST NOT generate illegal address syntax. + + o A common error is to leave out the semicolon after a group + identifier. + + o Some systems fail to fully-qualify domain names in + messages they generate. The right-hand side of an "@" + sign in a header address field MUST be a fully-qualified + domain name. + + For example, some systems fail to fully-qualify the From: + address; this prevents a "reply" command in the user + interface from automatically constructing a return + address. + + DISCUSSION: + Although RFC-822 allows the local use of abbreviated + domain names within a domain, the application of + RFC-822 in Internet mail does not allow this. The + intent is that an Internet host must not send an SMTP + message header containing an abbreviated domain name + in an address field. This allows the address fields + of the header to be passed without alteration across + the Internet, as required in Section 5.2.6. + + o Some systems mis-parse multiple-hop explicit source routes + such as: + + @relay1,@relay2,@relay3:user@domain. + + + o Some systems over-qualify domain names by adding a + trailing dot to some or all domain names in addresses or + message-ids. This violates RFC-822 syntax. + + + 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7 + + Internet host software SHOULD NOT create an RFC-822 header + containing an address with an explicit source route, but MUST + accept such headers for compatibility with earlier systems. + + DISCUSSION: + + + +Internet Engineering Task Force [Page 58] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + In an understatement, RFC-822 says "The use of explicit + source routing is discouraged". Many hosts implemented + RFC-822 source routes incorrectly, so the syntax cannot be + used unambiguously in practice. Many users feel the + syntax is ugly. Explicit source routes are not needed in + the mail envelope for delivery; see Section 5.2.6. For + all these reasons, explicit source routes using the RFC- + 822 notations are not to be used in Internet mail headers. + + As stated in Section 5.2.16, it is necessary to allow an + explicit source route to be buried in the local-part of an + address, e.g., using the "%-hack", in order to allow mail + to be gatewayed into another environment in which explicit + source routing is necessary. The vigilant will observe + that there is no way for a User Agent to detect and + prevent the use of such implicit source routing when the + destination is within the Internet. We can only + discourage source routing of any kind within the Internet, + as unnecessary and undesirable. + + 5.3 SPECIFIC ISSUES + + 5.3.1 SMTP Queueing Strategies + + The common structure of a host SMTP implementation includes + user mailboxes, one or more areas for queueing messages in + transit, and one or more daemon processes for sending and + receiving mail. The exact structure will vary depending on the + needs of the users on the host and the number and size of + mailing lists supported by the host. We describe several + optimizations that have proved helpful, particularly for + mailers supporting high traffic levels. + + Any queueing strategy MUST include: + + o Timeouts on all activities. See Section 5.3.2. + + o Never sending error messages in response to error + messages. + + + 5.3.1.1 Sending Strategy + + The general model of a sender-SMTP is one or more processes + that periodically attempt to transmit outgoing mail. In a + typical system, the program that composes a message has some + method for requesting immediate attention for a new piece of + outgoing mail, while mail that cannot be transmitted + + + +Internet Engineering Task Force [Page 59] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + immediately MUST be queued and periodically retried by the + sender. A mail queue entry will include not only the + message itself but also the envelope information. + + The sender MUST delay retrying a particular destination + after one attempt has failed. In general, the retry + interval SHOULD be at least 30 minutes; however, more + sophisticated and variable strategies will be beneficial + when the sender-SMTP can determine the reason for non- + delivery. + + Retries continue until the message is transmitted or the + sender gives up; the give-up time generally needs to be at + least 4-5 days. The parameters to the retry algorithm MUST + be configurable. + + A sender SHOULD keep a list of hosts it cannot reach and + corresponding timeouts, rather than just retrying queued + mail items. + + DISCUSSION: + Experience suggests that failures are typically + transient (the target system has crashed), favoring a + policy of two connection attempts in the first hour the + message is in the queue, and then backing off to once + every two or three hours. + + The sender-SMTP can shorten the queueing delay by + cooperation with the receiver-SMTP. In particular, if + mail is received from a particular address, it is good + evidence that any mail queued for that host can now be + sent. + + The strategy may be further modified as a result of + multiple addresses per host (see Section 5.3.4), to + optimize delivery time vs. resource usage. + + A sender-SMTP may have a large queue of messages for + each unavailable destination host, and if it retried + all these messages in every retry cycle, there would be + excessive Internet overhead and the daemon would be + blocked for a long period. Note that an SMTP can + generally determine that a delivery attempt has failed + only after a timeout of a minute or more; a one minute + timeout per connection will result in a very large + delay if it is repeated for dozens or even hundreds of + queued messages. + + + + +Internet Engineering Task Force [Page 60] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + When the same message is to be delivered to several users on + the same host, only one copy of the message SHOULD be + transmitted. That is, the sender-SMTP should use the + command sequence: RCPT, RCPT,... RCPT, DATA instead of the + sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA. + Implementation of this efficiency feature is strongly urged. + + Similarly, the sender-SMTP MAY support multiple concurrent + outgoing mail transactions to achieve timely delivery. + However, some limit SHOULD be imposed to protect the host + from devoting all its resources to mail. + + The use of the different addresses of a multihomed host is + discussed below. + + 5.3.1.2 Receiving strategy + + The receiver-SMTP SHOULD attempt to keep a pending listen on + the SMTP port at all times. This will require the support + of multiple incoming TCP connections for SMTP. Some limit + MAY be imposed. + + IMPLEMENTATION: + When the receiver-SMTP receives mail from a particular + host address, it could notify the sender-SMTP to retry + any mail pending for that host address. + + 5.3.2 Timeouts in SMTP + + There are two approaches to timeouts in the sender-SMTP: (a) + limit the time for each SMTP command separately, or (b) limit + the time for the entire SMTP dialogue for a single mail + message. A sender-SMTP SHOULD use option (a), per-command + timeouts. Timeouts SHOULD be easily reconfigurable, preferably + without recompiling the SMTP code. + + DISCUSSION: + Timeouts are an essential feature of an SMTP + implementation. If the timeouts are too long (or worse, + there are no timeouts), Internet communication failures or + software bugs in receiver-SMTP programs can tie up SMTP + processes indefinitely. If the timeouts are too short, + resources will be wasted with attempts that time out part + way through message delivery. + + If option (b) is used, the timeout has to be very large, + e.g., an hour, to allow time to expand very large mailing + lists. The timeout may also need to increase linearly + + + +Internet Engineering Task Force [Page 61] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + with the size of the message, to account for the time to + transmit a very large message. A large fixed timeout + leads to two problems: a failure can still tie up the + sender for a very long time, and very large messages may + still spuriously time out (which is a wasteful failure!). + + Using the recommended option (a), a timer is set for each + SMTP command and for each buffer of the data transfer. + The latter means that the overall timeout is inherently + proportional to the size of the message. + + Based on extensive experience with busy mail-relay hosts, the + minimum per-command timeout values SHOULD be as follows: + + o Initial 220 Message: 5 minutes + + A Sender-SMTP process needs to distinguish between a + failed TCP connection and a delay in receiving the initial + 220 greeting message. Many receiver-SMTPs will accept a + TCP connection but delay delivery of the 220 message until + their system load will permit more mail to be processed. + + o MAIL Command: 5 minutes + + + o RCPT Command: 5 minutes + + A longer timeout would be required if processing of + mailing lists and aliases were not deferred until after + the message was accepted. + + o DATA Initiation: 2 minutes + + This is while awaiting the "354 Start Input" reply to a + DATA command. + + o Data Block: 3 minutes + + This is while awaiting the completion of each TCP SEND + call transmitting a chunk of data. + + o DATA Termination: 10 minutes. + + This is while awaiting the "250 OK" reply. When the + receiver gets the final period terminating the message + data, it typically performs processing to deliver the + message to a user mailbox. A spurious timeout at this + point would be very wasteful, since the message has been + + + +Internet Engineering Task Force [Page 62] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + successfully sent. + + A receiver-SMTP SHOULD have a timeout of at least 5 minutes + while it is awaiting the next command from the sender. + + 5.3.3 Reliable Mail Receipt + + When the receiver-SMTP accepts a piece of mail (by sending a + "250 OK" message in response to DATA), it is accepting + responsibility for delivering or relaying the message. It must + take this responsibility seriously, i.e., it MUST NOT lose the + message for frivolous reasons, e.g., because the host later + crashes or because of a predictable resource shortage. + + If there is a delivery failure after acceptance of a message, + the receiver-SMTP MUST formulate and mail a notification + message. This notification MUST be sent using a null ("<>") + reverse path in the envelope; see Section 3.6 of RFC-821. The + recipient of this notification SHOULD be the address from the + envelope return path (or the Return-Path: line). However, if + this address is null ("<>"), the receiver-SMTP MUST NOT send a + notification. If the address is an explicit source route, it + SHOULD be stripped down to its final hop. + + DISCUSSION: + For example, suppose that an error notification must be + sent for a message that arrived with: + "MAIL FROM:<@a,@b:user@d>". The notification message + should be sent to: "RCPT TO:". + + Some delivery failures after the message is accepted by + SMTP will be unavoidable. For example, it may be + impossible for the receiver-SMTP to validate all the + delivery addresses in RCPT command(s) due to a "soft" + domain system error or because the target is a mailing + list (see earlier discussion of RCPT). + + To avoid receiving duplicate messages as the result of + timeouts, a receiver-SMTP MUST seek to minimize the time + required to respond to the final "." that ends a message + transfer. See RFC-1047 [SMTP:4] for a discussion of this + problem. + + 5.3.4 Reliable Mail Transmission + + To transmit a message, a sender-SMTP determines the IP address + of the target host from the destination address in the + envelope. Specifically, it maps the string to the right of the + + + +Internet Engineering Task Force [Page 63] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + "@" sign into an IP address. This mapping or the transfer + itself may fail with a soft error, in which case the sender- + SMTP will requeue the outgoing mail for a later retry, as + required in Section 5.3.1.1. + + When it succeeds, the mapping can result in a list of + alternative delivery addresses rather than a single address, + because of (a) multiple MX records, (b) multihoming, or both. + To provide reliable mail transmission, the sender-SMTP MUST be + able to try (and retry) each of the addresses in this list in + order, until a delivery attempt succeeds. However, there MAY + also be a configurable limit on the number of alternate + addresses that can be tried. In any case, a host SHOULD try at + least two addresses. + + The following information is to be used to rank the host + addresses: + + (1) Multiple MX Records -- these contain a preference + indication that should be used in sorting. If there are + multiple destinations with the same preference and there + is no clear reason to favor one (e.g., by address + preference), then the sender-SMTP SHOULD pick one at + random to spread the load across multiple mail exchanges + for a specific organization; note that this is a + refinement of the procedure in [DNS:3]. + + (2) Multihomed host -- The destination host (perhaps taken + from the preferred MX record) may be multihomed, in which + case the domain name resolver will return a list of + alternative IP addresses. It is the responsibility of the + domain name resolver interface (see Section 6.1.3.4 below) + to have ordered this list by decreasing preference, and + SMTP MUST try them in the order presented. + + DISCUSSION: + Although the capability to try multiple alternative + addresses is required, there may be circumstances where + specific installations want to limit or disable the use of + alternative addresses. The question of whether a sender + should attempt retries using the different addresses of a + multihomed host has been controversial. The main argument + for using the multiple addresses is that it maximizes the + probability of timely delivery, and indeed sometimes the + probability of any delivery; the counter argument is that + it may result in unnecessary resource use. + + Note that resource use is also strongly determined by the + + + +Internet Engineering Task Force [Page 64] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + sending strategy discussed in Section 5.3.1. + + 5.3.5 Domain Name Support + + SMTP implementations MUST use the mechanism defined in Section + 6.1 for mapping between domain names and IP addresses. This + means that every Internet SMTP MUST include support for the + Internet DNS. + + In particular, a sender-SMTP MUST support the MX record scheme + [SMTP:3]. See also Section 7.4 of [DNS:2] for information on + domain name support for SMTP. + + 5.3.6 Mailing Lists and Aliases + + An SMTP-capable host SHOULD support both the alias and the list + form of address expansion for multiple delivery. When a + message is delivered or forwarded to each address of an + expanded list form, the return address in the envelope + ("MAIL FROM:") MUST be changed to be the address of a person + who administers the list, but the message header MUST be left + unchanged; in particular, the "From" field of the message is + unaffected. + + DISCUSSION: + An important mail facility is a mechanism for multi- + destination delivery of a single message, by transforming + or "expanding" a pseudo-mailbox address into a list of + destination mailbox addresses. When a message is sent to + such a pseudo-mailbox (sometimes called an "exploder"), + copies are forwarded or redistributed to each mailbox in + the expanded list. We classify such a pseudo-mailbox as + an "alias" or a "list", depending upon the expansion + rules: + + (a) Alias + + To expand an alias, the recipient mailer simply + replaces the pseudo-mailbox address in the envelope + with each of the expanded addresses in turn; the rest + of the envelope and the message body are left + unchanged. The message is then delivered or + forwarded to each expanded address. + + (b) List + + A mailing list may be said to operate by + "redistribution" rather than by "forwarding". To + + + +Internet Engineering Task Force [Page 65] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + expand a list, the recipient mailer replaces the + pseudo-mailbox address in the envelope with each of + the expanded addresses in turn. The return address in + the envelope is changed so that all error messages + generated by the final deliveries will be returned to + a list administrator, not to the message originator, + who generally has no control over the contents of the + list and will typically find error messages annoying. + + + 5.3.7 Mail Gatewaying + + Gatewaying mail between different mail environments, i.e., + different mail formats and protocols, is complex and does not + easily yield to standardization. See for example [SMTP:5a], + [SMTP:5b]. However, some general requirements may be given for + a gateway between the Internet and another mail environment. + + (A) Header fields MAY be rewritten when necessary as messages + are gatewayed across mail environment boundaries. + + DISCUSSION: + This may involve interpreting the local-part of the + destination address, as suggested in Section 5.2.16. + + The other mail systems gatewayed to the Internet + generally use a subset of RFC-822 headers, but some + of them do not have an equivalent to the SMTP + envelope. Therefore, when a message leaves the + Internet environment, it may be necessary to fold the + SMTP envelope information into the message header. A + possible solution would be to create new header + fields to carry the envelope information (e.g., "X- + SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would + require changes in mail programs in the foreign + environment. + + (B) When forwarding a message into or out of the Internet + environment, a gateway MUST prepend a Received: line, but + it MUST NOT alter in any way a Received: line that is + already in the header. + + DISCUSSION: + This requirement is a subset of the general + "Received:" line requirement of Section 5.2.8; it is + restated here for emphasis. + + Received: fields of messages originating from other + + + +Internet Engineering Task Force [Page 66] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + environments may not conform exactly to RFC822. + However, the most important use of Received: lines is + for debugging mail faults, and this debugging can be + severely hampered by well-meaning gateways that try + to "fix" a Received: line. + + The gateway is strongly encouraged to indicate the + environment and protocol in the "via" clauses of + Received field(s) that it supplies. + + (C) From the Internet side, the gateway SHOULD accept all + valid address formats in SMTP commands and in RFC-822 + headers, and all valid RFC-822 messages. Although a + gateway must accept an RFC-822 explicit source route + ("@...:" format) in either the RFC-822 header or in the + envelope, it MAY or may not act on the source route; see + Sections 5.2.6 and 5.2.19. + + DISCUSSION: + It is often tempting to restrict the range of + addresses accepted at the mail gateway to simplify + the translation into addresses for the remote + environment. This practice is based on the + assumption that mail users have control over the + addresses their mailers send to the mail gateway. In + practice, however, users have little control over the + addresses that are finally sent; their mailers are + free to change addresses into any legal RFC-822 + format. + + (D) The gateway MUST ensure that all header fields of a + message that it forwards into the Internet meet the + requirements for Internet mail. In particular, all + addresses in "From:", "To:", "Cc:", etc., fields must be + transformed (if necessary) to satisfy RFC-822 syntax, and + they must be effective and useful for sending replies. + + + (E) The translation algorithm used to convert mail from the + Internet protocols to another environment's protocol + SHOULD try to ensure that error messages from the foreign + mail environment are delivered to the return path from the + SMTP envelope, not to the sender listed in the "From:" + field of the RFC-822 message. + + DISCUSSION: + Internet mail lists usually place the address of the + mail list maintainer in the envelope but leave the + + + +Internet Engineering Task Force [Page 67] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + original message header intact (with the "From:" + field containing the original sender). This yields + the behavior the average recipient expects: a reply + to the header gets sent to the original sender, not + to a mail list maintainer; however, errors get sent + to the maintainer (who can fix the problem) and not + the sender (who probably cannot). + + (F) Similarly, when forwarding a message from another + environment into the Internet, the gateway SHOULD set the + envelope return path in accordance with an error message + return address, if any, supplied by the foreign + environment. + + + 5.3.8 Maximum Message Size + + Mailer software MUST be able to send and receive messages of at + least 64K bytes in length (including header), and a much larger + maximum size is highly desirable. + + DISCUSSION: + Although SMTP does not define the maximum size of a + message, many systems impose implementation limits. + + The current de facto minimum limit in the Internet is 64K + bytes. However, electronic mail is used for a variety of + purposes that create much larger messages. For example, + mail is often used instead of FTP for transmitting ASCII + files, and in particular to transmit entire documents. As + a result, messages can be 1 megabyte or even larger. We + note that the present document together with its lower- + layer companion contains 0.5 megabytes. + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 68] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + 5.4 SMTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +RECEIVER-SMTP: | | | | | | | + Implement VRFY |5.2.3 |x| | | | | + Implement EXPN |5.2.3 | |x| | | | + EXPN, VRFY configurable |5.2.3 | | |x| | | + Implement SEND, SOML, SAML |5.2.4 | | |x| | | + Verify HELO parameter |5.2.5 | | |x| | | + Refuse message with bad HELO |5.2.5 | | | | |x| + Accept explicit src-route syntax in env. |5.2.6 |x| | | | | + Support "postmaster" |5.2.7 |x| | | | | + Process RCPT when received (except lists) |5.2.7 | | |x| | | + Long delay of RCPT responses |5.2.7 | | | | |x| + | | | | | | | + Add Received: line |5.2.8 |x| | | | | + Received: line include domain literal |5.2.8 | |x| | | | + Change previous Received: line |5.2.8 | | | | |x| + Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | | + Support empty reverse path |5.2.9 |x| | | | | + Send only official reply codes |5.2.10 | |x| | | | + Send text from RFC-821 when appropriate |5.2.10 | |x| | | | + Delete "." for transparency |5.2.11 |x| | | | | + Accept and recognize self domain literal(s) |5.2.17 |x| | | | | + | | | | | | | + Error message about error message |5.3.1 | | | | |x| + Keep pending listen on SMTP port |5.3.1.2 | |x| | | | + Provide limit on recv concurrency |5.3.1.2 | | |x| | | + Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | | + Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x| + Send error notification msg after accept |5.3.3 |x| | | | | + Send using null return path |5.3.3 |x| | | | | + Send to envelope return path |5.3.3 | |x| | | | + Send to null address |5.3.3 | | | | |x| + Strip off explicit src route |5.3.3 | |x| | | | + Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | | +-----------------------------------------------|----------|-|-|-|-|-|-- + + + +Internet Engineering Task Force [Page 69] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + | | | | | | | +SENDER-SMTP: | | | | | | | + Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | | + Implement SEND, SOML, SAML |5.2.4 | | |x| | | + Send valid principal host name in HELO |5.2.5 |x| | | | | + Send explicit source route in RCPT TO: |5.2.6 | | | |x| | + Use only reply code to determine action |5.2.10 |x| | | | | + Use only high digit of reply code when poss. |5.2.10 | |x| | | | + Add "." for transparency |5.2.11 |x| | | | | + | | | | | | | + Retry messages after soft failure |5.3.1.1 |x| | | | | + Delay before retry |5.3.1.1 |x| | | | | + Configurable retry parameters |5.3.1.1 |x| | | | | + Retry once per each queued dest host |5.3.1.1 | |x| | | | + Multiple RCPT's for same DATA |5.3.1.1 | |x| | | | + Support multiple concurrent transactions |5.3.1.1 | | |x| | | + Provide limit on concurrency |5.3.1.1 | |x| | | | + | | | | | | | + Timeouts on all activities |5.3.1 |x| | | | | + Per-command timeouts |5.3.2 | |x| | | | + Timeouts easily reconfigurable |5.3.2 | |x| | | | + Recommended times |5.3.2 | |x| | | | + Try alternate addr's in order |5.3.4 |x| | | | | + Configurable limit on alternate tries |5.3.4 | | |x| | | + Try at least two alternates |5.3.4 | |x| | | | + Load-split across equal MX alternates |5.3.4 | |x| | | | + Use the Domain Name System |5.3.5 |x| | | | | + Support MX records |5.3.5 |x| | | | | + Use WKS records in MX processing |5.2.12 | | | |x| | +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +MAIL FORWARDING: | | | | | | | + Alter existing header field(s) |5.2.6 | | | |x| | + Implement relay function: 821/section 3.6 |5.2.6 | | |x| | | + If not, deliver to RHS domain |5.2.6 | |x| | | | + Interpret 'local-part' of addr |5.2.16 | | | | |x| + | | | | | | | +MAILING LISTS AND ALIASES | | | | | | | + Support both |5.3.6 | |x| | | | + Report mail list error to local admin. |5.3.6 |x| | | | | + | | | | | | | +MAIL GATEWAYS: | | | | | | | + Embed foreign mail route in local-part |5.2.16 | | |x| | | + Rewrite header fields when necessary |5.3.7 | | |x| | | + Prepend Received: line |5.3.7 |x| | | | | + Change existing Received: line |5.3.7 | | | | |x| + Accept full RFC-822 on Internet side |5.3.7 | |x| | | | + Act on RFC-822 explicit source route |5.3.7 | | |x| | | + + + +Internet Engineering Task Force [Page 70] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + Send only valid RFC-822 on Internet side |5.3.7 |x| | | | | + Deliver error msgs to envelope addr |5.3.7 | |x| | | | + Set env return path from err return addr |5.3.7 | |x| | | | + | | | | | | | +USER AGENT -- RFC-822 | | | | | | | + Allow user to enter address |5.2.6 | | | |x| | + Support RFC-1049 Content Type field |5.2.13 | | |x| | | + Use 4-digit years |5.2.14 | |x| | | | + Generate numeric timezones |5.2.14 | |x| | | | + Accept all timezones |5.2.14 |x| | | | | + Use non-num timezones from RFC-822 |5.2.14 |x| | | | | + Omit phrase before route-addr |5.2.15 | | |x| | | + Accept and parse dot.dec. domain literals |5.2.17 |x| | | | | + Accept all RFC-822 address formats |5.2.18 |x| | | | | + Generate invalid RFC-822 address format |5.2.18 | | | | |x| + Fully-qualified domain names in header |5.2.18 |x| | | | | + Create explicit src route in header |5.2.19 | | | |x| | + Accept explicit src route in header |5.2.19 |x| | | | | + | | | | | | | +Send/recv at least 64KB messages |5.3.8 |x| | | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 71] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + +6. SUPPORT SERVICES + + 6.1 DOMAIN NAME TRANSLATION + + 6.1.1 INTRODUCTION + + Every host MUST implement a resolver for the Domain Name System + (DNS), and it MUST implement a mechanism using this DNS + resolver to convert host names to IP addresses and vice-versa + [DNS:1, DNS:2]. + + In addition to the DNS, a host MAY also implement a host name + translation mechanism that searches a local Internet host + table. See Section 6.1.3.8 for more information on this + option. + + DISCUSSION: + Internet host name translation was originally performed by + searching local copies of a table of all hosts. This + table became too large to update and distribute in a + timely manner and too large to fit into many hosts, so the + DNS was invented. + + The DNS creates a distributed database used primarily for + the translation between host names and host addresses. + Implementation of DNS software is required. The DNS + consists of two logically distinct parts: name servers and + resolvers (although implementations often combine these + two logical parts in the interest of efficiency) [DNS:2]. + + Domain name servers store authoritative data about certain + sections of the database and answer queries about the + data. Domain resolvers query domain name servers for data + on behalf of user processes. Every host therefore needs a + DNS resolver; some host machines will also need to run + domain name servers. Since no name server has complete + information, in general it is necessary to obtain + information from more than one name server to resolve a + query. + + 6.1.2 PROTOCOL WALK-THROUGH + + An implementor must study references [DNS:1] and [DNS:2] + carefully. They provide a thorough description of the theory, + protocol, and implementation of the domain name system, and + reflect several years of experience. + + + + + +Internet Engineering Task Force [Page 72] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1 + + All DNS name servers and resolvers MUST properly handle RRs + with a zero TTL: return the RR to the client but do not + cache it. + + DISCUSSION: + Zero TTL values are interpreted to mean that the RR can + only be used for the transaction in progress, and + should not be cached; they are useful for extremely + volatile data. + + 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5 + + A query with "QCLASS=*" SHOULD NOT be used unless the + requestor is seeking data from more than one class. In + particular, if the requestor is only interested in Internet + data types, QCLASS=IN MUST be used. + + 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1 + + Unused fields in a query or response message MUST be zero. + + 6.1.2.4 Compression: RFC-1035 Section 4.1.4 + + Name servers MUST use compression in responses. + + DISCUSSION: + Compression is essential to avoid overflowing UDP + datagrams; see Section 6.1.3.2. + + 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2 + + Recursive name servers and full-service resolvers generally + have some configuration information containing hints about + the location of root or local name servers. An + implementation MUST NOT include any of these hints in a + response. + + DISCUSSION: + Many implementors have found it convenient to store + these hints as if they were cached data, but some + neglected to ensure that this "cached data" was not + included in responses. This has caused serious + problems in the Internet when the hints were obsolete + or incorrect. + + + + + +Internet Engineering Task Force [Page 73] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3 SPECIFIC ISSUES + + 6.1.3.1 Resolver Implementation + + A name resolver SHOULD be able to multiplex concurrent + requests if the host supports concurrent processes. + + In implementing a DNS resolver, one of two different models + MAY optionally be chosen: a full-service resolver, or a stub + resolver. + + + (A) Full-Service Resolver + + A full-service resolver is a complete implementation of + the resolver service, and is capable of dealing with + communication failures, failure of individual name + servers, location of the proper name server for a given + name, etc. It must satisfy the following requirements: + + o The resolver MUST implement a local caching + function to avoid repeated remote access for + identical requests, and MUST time out information + in the cache. + + o The resolver SHOULD be configurable with start-up + information pointing to multiple root name servers + and multiple name servers for the local domain. + This insures that the resolver will be able to + access the whole name space in normal cases, and + will be able to access local domain information + should the local network become disconnected from + the rest of the Internet. + + + (B) Stub Resolver + + A "stub resolver" relies on the services of a recursive + name server on the connected network or a "nearby" + network. This scheme allows the host to pass on the + burden of the resolver function to a name server on + another host. This model is often essential for less + capable hosts, such as PCs, and is also recommended + when the host is one of several workstations on a local + network, because it allows all of the workstations to + share the cache of the recursive name server and hence + reduce the number of domain requests exported by the + local network. + + + +Internet Engineering Task Force [Page 74] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + At a minimum, the stub resolver MUST be capable of + directing its requests to redundant recursive name + servers. Note that recursive name servers are allowed + to restrict the sources of requests that they will + honor, so the host administrator must verify that the + service will be provided. Stub resolvers MAY implement + caching if they choose, but if so, MUST timeout cached + information. + + + 6.1.3.2 Transport Protocols + + DNS resolvers and recursive servers MUST support UDP, and + SHOULD support TCP, for sending (non-zone-transfer) queries. + Specifically, a DNS resolver or server that is sending a + non-zone-transfer query MUST send a UDP query first. If the + Answer section of the response is truncated and if the + requester supports TCP, it SHOULD try the query again using + TCP. + + DNS servers MUST be able to service UDP queries and SHOULD + be able to service TCP queries. A name server MAY limit the + resources it devotes to TCP queries, but it SHOULD NOT + refuse to service a TCP query just because it would have + succeeded with UDP. + + Truncated responses MUST NOT be saved (cached) and later + used in such a way that the fact that they are truncated is + lost. + + DISCUSSION: + UDP is preferred over TCP for queries because UDP + queries have much lower overhead, both in packet count + and in connection state. The use of UDP is essential + for heavily-loaded servers, especially the root + servers. UDP also offers additional robustness, since + a resolver can attempt several UDP queries to different + servers for the cost of a single TCP query. + + It is possible for a DNS response to be truncated, + although this is a very rare occurrence in the present + Internet DNS. Practically speaking, truncation cannot + be predicted, since it is data-dependent. The + dependencies include the number of RRs in the answer, + the size of each RR, and the savings in space realized + by the name compression algorithm. As a rule of thumb, + truncation in NS and MX lists should not occur for + answers containing 15 or fewer RRs. + + + +Internet Engineering Task Force [Page 75] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Whether it is possible to use a truncated answer + depends on the application. A mailer must not use a + truncated MX response, since this could lead to mail + loops. + + Responsible practices can make UDP suffice in the vast + majority of cases. Name servers must use compression + in responses. Resolvers must differentiate truncation + of the Additional section of a response (which only + loses extra information) from truncation of the Answer + section (which for MX records renders the response + unusable by mailers). Database administrators should + list only a reasonable number of primary names in lists + of name servers, MX alternatives, etc. + + However, it is also clear that some new DNS record + types defined in the future will contain information + exceeding the 512 byte limit that applies to UDP, and + hence will require TCP. Thus, resolvers and name + servers should implement TCP services as a backup to + UDP today, with the knowledge that they will require + the TCP service in the future. + + By private agreement, name servers and resolvers MAY arrange + to use TCP for all traffic between themselves. TCP MUST be + used for zone transfers. + + A DNS server MUST have sufficient internal concurrency that + it can continue to process UDP queries while awaiting a + response or performing a zone transfer on an open TCP + connection [DNS:2]. + + A server MAY support a UDP query that is delivered using an + IP broadcast or multicast address. However, the Recursion + Desired bit MUST NOT be set in a query that is multicast, + and MUST be ignored by name servers receiving queries via a + broadcast or multicast address. A host that sends broadcast + or multicast DNS queries SHOULD send them only as occasional + probes, caching the IP address(es) it obtains from the + response(s) so it can normally send unicast queries. + + DISCUSSION: + Broadcast or (especially) IP multicast can provide a + way to locate nearby name servers without knowing their + IP addresses in advance. However, general broadcasting + of recursive queries can result in excessive and + unnecessary load on both network and servers. + + + + +Internet Engineering Task Force [Page 76] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3.3 Efficient Resource Usage + + The following requirements on servers and resolvers are very + important to the health of the Internet as a whole, + particularly when DNS services are invoked repeatedly by + higher level automatic servers, such as mailers. + + (1) The resolver MUST implement retransmission controls to + insure that it does not waste communication bandwidth, + and MUST impose finite bounds on the resources consumed + to respond to a single request. See [DNS:2] pages 43- + 44 for specific recommendations. + + (2) After a query has been retransmitted several times + without a response, an implementation MUST give up and + return a soft error to the application. + + (3) All DNS name servers and resolvers SHOULD cache + temporary failures, with a timeout period of the order + of minutes. + + DISCUSSION: + This will prevent applications that immediately + retry soft failures (in violation of Section 2.2 + of this document) from generating excessive DNS + traffic. + + (4) All DNS name servers and resolvers SHOULD cache + negative responses that indicate the specified name, or + data of the specified type, does not exist, as + described in [DNS:2]. + + (5) When a DNS server or resolver retries a UDP query, the + retry interval SHOULD be constrained by an exponential + backoff algorithm, and SHOULD also have upper and lower + bounds. + + IMPLEMENTATION: + A measured RTT and variance (if available) should + be used to calculate an initial retransmission + interval. If this information is not available, a + default of no less than 5 seconds should be used. + Implementations may limit the retransmission + interval, but this limit must exceed twice the + Internet maximum segment lifetime plus service + delay at the name server. + + (6) When a resolver or server receives a Source Quench for + + + +Internet Engineering Task Force [Page 77] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + a query it has issued, it SHOULD take steps to reduce + the rate of querying that server in the near future. A + server MAY ignore a Source Quench that it receives as + the result of sending a response datagram. + + IMPLEMENTATION: + One recommended action to reduce the rate is to + send the next query attempt to an alternate + server, if there is one available. Another is to + backoff the retry interval for the same server. + + + 6.1.3.4 Multihomed Hosts + + When the host name-to-address function encounters a host + with multiple addresses, it SHOULD rank or sort the + addresses using knowledge of the immediately connected + network number(s) and any other applicable performance or + history information. + + DISCUSSION: + The different addresses of a multihomed host generally + imply different Internet paths, and some paths may be + preferable to others in performance, reliability, or + administrative restrictions. There is no general way + for the domain system to determine the best path. A + recommended approach is to base this decision on local + configuration information set by the system + administrator. + + IMPLEMENTATION: + The following scheme has been used successfully: + + (a) Incorporate into the host configuration data a + Network-Preference List, that is simply a list of + networks in preferred order. This list may be + empty if there is no preference. + + (b) When a host name is mapped into a list of IP + addresses, these addresses should be sorted by + network number, into the same order as the + corresponding networks in the Network-Preference + List. IP addresses whose networks do not appear + in the Network-Preference List should be placed at + the end of the list. + + + + + + +Internet Engineering Task Force [Page 78] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3.5 Extensibility + + DNS software MUST support all well-known, class-independent + formats [DNS:2], and SHOULD be written to minimize the + trauma associated with the introduction of new well-known + types and local experimentation with non-standard types. + + DISCUSSION: + The data types and classes used by the DNS are + extensible, and thus new types will be added and old + types deleted or redefined. Introduction of new data + types ought to be dependent only upon the rules for + compression of domain names inside DNS messages, and + the translation between printable (i.e., master file) + and internal formats for Resource Records (RRs). + + Compression relies on knowledge of the format of data + inside a particular RR. Hence compression must only be + used for the contents of well-known, class-independent + RRs, and must never be used for class-specific RRs or + RR types that are not well-known. The owner name of an + RR is always eligible for compression. + + A name server may acquire, via zone transfer, RRs that + the server doesn't know how to convert to printable + format. A resolver can receive similar information as + the result of queries. For proper operation, this data + must be preserved, and hence the implication is that + DNS software cannot use textual formats for internal + storage. + + The DNS defines domain name syntax very generally -- a + string of labels each containing up to 63 8-bit octets, + separated by dots, and with a maximum total of 255 + octets. Particular applications of the DNS are + permitted to further constrain the syntax of the domain + names they use, although the DNS deployment has led to + some applications allowing more general names. In + particular, Section 2.1 of this document liberalizes + slightly the syntax of a legal Internet host name that + was defined in RFC-952 [DNS:4]. + + 6.1.3.6 Status of RR Types + + Name servers MUST be able to load all RR types except MD and + MF from configuration files. The MD and MF types are + obsolete and MUST NOT be implemented; in particular, name + servers MUST NOT load these types from configuration files. + + + +Internet Engineering Task Force [Page 79] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + DISCUSSION: + The RR types MB, MG, MR, NULL, MINFO and RP are + considered experimental, and applications that use the + DNS cannot expect these RR types to be supported by + most domains. Furthermore these types are subject to + redefinition. + + The TXT and WKS RR types have not been widely used by + Internet sites; as a result, an application cannot rely + on the the existence of a TXT or WKS RR in most + domains. + + 6.1.3.7 Robustness + + DNS software may need to operate in environments where the + root servers or other servers are unavailable due to network + connectivity or other problems. In this situation, DNS name + servers and resolvers MUST continue to provide service for + the reachable part of the name space, while giving temporary + failures for the rest. + + DISCUSSION: + Although the DNS is meant to be used primarily in the + connected Internet, it should be possible to use the + system in networks which are unconnected to the + Internet. Hence implementations must not depend on + access to root servers before providing service for + local names. + + 6.1.3.8 Local Host Table + + DISCUSSION: + A host may use a local host table as a backup or + supplement to the DNS. This raises the question of + which takes precedence, the DNS or the host table; the + most flexible approach would make this a configuration + option. + + Typically, the contents of such a supplementary host + table will be determined locally by the site. However, + a publically-available table of Internet hosts is + maintained by the DDN Network Information Center (DDN + NIC), with a format documented in [DNS:4]. This table + can be retrieved from the DDN NIC using a protocol + described in [DNS:5]. It must be noted that this table + contains only a small fraction of all Internet hosts. + Hosts using this protocol to retrieve the DDN NIC host + table should use the VERSION command to check if the + + + +Internet Engineering Task Force [Page 80] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + table has changed before requesting the entire table + with the ALL command. The VERSION identifier should be + treated as an arbitrary string and tested only for + equality; no numerical sequence may be assumed. + + The DDN NIC host table includes administrative + information that is not needed for host operation and + is therefore not currently included in the DNS + database; examples include network and gateway entries. + However, much of this additional information will be + added to the DNS in the future. Conversely, the DNS + provides essential services (in particular, MX records) + that are not available from the DDN NIC host table. + + 6.1.4 DNS USER INTERFACE + + 6.1.4.1 DNS Administration + + This document is concerned with design and implementation + issues in host software, not with administrative or + operational issues. However, administrative issues are of + particular importance in the DNS, since errors in particular + segments of this large distributed database can cause poor + or erroneous performance for many sites. These issues are + discussed in [DNS:6] and [DNS:7]. + + 6.1.4.2 DNS User Interface + + Hosts MUST provide an interface to the DNS for all + application programs running on the host. This interface + will typically direct requests to a system process to + perform the resolver function [DNS:1, 6.1:2]. + + At a minimum, the basic interface MUST support a request for + all information of a specific type and class associated with + a specific name, and it MUST return either all of the + requested information, a hard error code, or a soft error + indication. When there is no error, the basic interface + returns the complete response information without + modification, deletion, or ordering, so that the basic + interface will not need to be changed to accommodate new + data types. + + DISCUSSION: + The soft error indication is an essential part of the + interface, since it may not always be possible to + access particular information from the DNS; see Section + 6.1.3.3. + + + +Internet Engineering Task Force [Page 81] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + A host MAY provide other DNS interfaces tailored to + particular functions, transforming the raw domain data into + formats more suited to these functions. In particular, a + host MUST provide a DNS interface to facilitate translation + between host addresses and host names. + + 6.1.4.3 Interface Abbreviation Facilities + + User interfaces MAY provide a method for users to enter + abbreviations for commonly-used names. Although the + definition of such methods is outside of the scope of the + DNS specification, certain rules are necessary to insure + that these methods allow access to the entire DNS name space + and to prevent excessive use of Internet resources. + + If an abbreviation method is provided, then: + + (a) There MUST be some convention for denoting that a name + is already complete, so that the abbreviation method(s) + are suppressed. A trailing dot is the usual method. + + (b) Abbreviation expansion MUST be done exactly once, and + MUST be done in the context in which the name was + entered. + + + DISCUSSION: + For example, if an abbreviation is used in a mail + program for a destination, the abbreviation should be + expanded into a full domain name and stored in the + queued message with an indication that it is already + complete. Otherwise, the abbreviation might be + expanded with a mail system search list, not the + user's, or a name could grow due to repeated + canonicalizations attempts interacting with wildcards. + + The two most common abbreviation methods are: + + (1) Interface-level aliases + + Interface-level aliases are conceptually implemented as + a list of alias/domain name pairs. The list can be + per-user or per-host, and separate lists can be + associated with different functions, e.g. one list for + host name-to-address translation, and a different list + for mail domains. When the user enters a name, the + interface attempts to match the name to the alias + component of a list entry, and if a matching entry can + + + +Internet Engineering Task Force [Page 82] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + be found, the name is replaced by the domain name found + in the pair. + + Note that interface-level aliases and CNAMEs are + completely separate mechanisms; interface-level aliases + are a local matter while CNAMEs are an Internet-wide + aliasing mechanism which is a required part of any DNS + implementation. + + (2) Search Lists + + A search list is conceptually implemented as an ordered + list of domain names. When the user enters a name, the + domain names in the search list are used as suffixes to + the user-supplied name, one by one, until a domain name + with the desired associated data is found, or the + search list is exhausted. Search lists often contain + the name of the local host's parent domain or other + ancestor domains. Search lists are often per-user or + per-process. + + It SHOULD be possible for an administrator to disable a + DNS search-list facility. Administrative denial may be + warranted in some cases, to prevent abuse of the DNS. + + There is danger that a search-list mechanism will + generate excessive queries to the root servers while + testing whether user input is a complete domain name, + lacking a final period to mark it as complete. A + search-list mechanism MUST have one of, and SHOULD have + both of, the following two provisions to prevent this: + + (a) The local resolver/name server can implement + caching of negative responses (see Section + 6.1.3.3). + + (b) The search list expander can require two or more + interior dots in a generated domain name before it + tries using the name in a query to non-local + domain servers, such as the root. + + DISCUSSION: + The intent of this requirement is to avoid + excessive delay for the user as the search list is + tested, and more importantly to prevent excessive + traffic to the root and other high-level servers. + For example, if the user supplied a name "X" and + the search list contained the root as a component, + + + +Internet Engineering Task Force [Page 83] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + a query would have to consult a root server before + the next search list alternative could be tried. + The resulting load seen by the root servers and + gateways near the root would be multiplied by the + number of hosts in the Internet. + + The negative caching alternative limits the effect + to the first time a name is used. The interior + dot rule is simpler to implement but can prevent + easy use of some top-level names. + + + 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|-----------|-|-|-|-|-|-- +GENERAL ISSUES | | | | | | | + | | | | | | | +Implement DNS name-to-address conversion |6.1.1 |x| | | | | +Implement DNS address-to-name conversion |6.1.1 |x| | | | | +Support conversions using host table |6.1.1 | | |x| | | +Properly handle RR with zero TTL |6.1.2.1 |x| | | | | +Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | | + Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | | +Unused fields zero |6.1.2.3 |x| | | | | +Use compression in responses |6.1.2.4 |x| | | | | + | | | | | | | +Include config info in responses |6.1.2.5 | | | | |x| +Support all well-known, class-indep. types |6.1.3.5 |x| | | | | +Easily expand type list |6.1.3.5 | |x| | | | +Load all RR types (except MD and MF) |6.1.3.6 |x| | | | | +Load MD or MF type |6.1.3.6 | | | | |x| +Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +RESOLVER ISSUES: | | | | | | | + | | | | | | | +Resolver support multiple concurrent requests |6.1.3.1 | |x| | | | +Full-service resolver: |6.1.3.1 | | |x| | | + Local caching |6.1.3.1 |x| | | | | + + + +Internet Engineering Task Force [Page 84] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Information in local cache times out |6.1.3.1 |x| | | | | + Configurable with starting info |6.1.3.1 | |x| | | | +Stub resolver: |6.1.3.1 | | |x| | | + Use redundant recursive name servers |6.1.3.1 |x| | | | | + Local caching |6.1.3.1 | | |x| | | + Information in local cache times out |6.1.3.1 |x| | | | | +Support for remote multi-homed hosts: | | | | | | | + Sort multiple addresses by preference list |6.1.3.4 | |x| | | | + | | | | | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +TRANSPORT PROTOCOLS: | | | | | | | + | | | | | | | +Support UDP queries |6.1.3.2 |x| | | | | +Support TCP queries |6.1.3.2 | |x| | | | + Send query using UDP first |6.1.3.2 |x| | | | |1 + Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | | +Name server limit TCP query resources |6.1.3.2 | | |x| | | + Punish unnecessary TCP query |6.1.3.2 | | | |x| | +Use truncated data as if it were not |6.1.3.2 | | | | |x| +Private agreement to use only TCP |6.1.3.2 | | |x| | | +Use TCP for zone transfers |6.1.3.2 |x| | | | | +TCP usage not block UDP queries |6.1.3.2 |x| | | | | +Support broadcast or multicast queries |6.1.3.2 | | |x| | | + RD bit set in query |6.1.3.2 | | | | |x| + RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | | + Send only as occasional probe for addr's |6.1.3.2 | |x| | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +RESOURCE USAGE: | | | | | | | + | | | | | | | +Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | | + Finite bounds per request |6.1.3.3 |x| | | | | +Failure after retries => soft error |6.1.3.3 |x| | | | | +Cache temporary failures |6.1.3.3 | |x| | | | +Cache negative responses |6.1.3.3 | |x| | | | +Retries use exponential backoff |6.1.3.3 | |x| | | | + Upper, lower bounds |6.1.3.3 | |x| | | | +Client handle Source Quench |6.1.3.3 | |x| | | | +Server ignore Source Quench |6.1.3.3 | | |x| | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +USER INTERFACE: | | | | | | | + | | | | | | | +All programs have access to DNS interface |6.1.4.2 |x| | | | | +Able to request all info for given name |6.1.4.2 |x| | | | | +Returns complete info or error |6.1.4.2 |x| | | | | +Special interfaces |6.1.4.2 | | |x| | | + Name<->Address translation |6.1.4.2 |x| | | | | + | | | | | | | +Abbreviation Facilities: |6.1.4.3 | | |x| | | + + + +Internet Engineering Task Force [Page 85] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Convention for complete names |6.1.4.3 |x| | | | | + Conversion exactly once |6.1.4.3 |x| | | | | + Conversion in proper context |6.1.4.3 |x| | | | | + Search list: |6.1.4.3 | | |x| | | + Administrator can disable |6.1.4.3 | |x| | | | + Prevention of excessive root queries |6.1.4.3 |x| | | | | + Both methods |6.1.4.3 | |x| | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +-----------------------------------------------|-----------|-|-|-|-|-|-- + +1. Unless there is private agreement between particular resolver and + particular server. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 86] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + 6.2 HOST INITIALIZATION + + 6.2.1 INTRODUCTION + + This section discusses the initialization of host software + across a connected network, or more generally across an + Internet path. This is necessary for a diskless host, and may + optionally be used for a host with disk drives. For a diskless + host, the initialization process is called "network booting" + and is controlled by a bootstrap program located in a boot ROM. + + To initialize a diskless host across the network, there are two + distinct phases: + + (1) Configure the IP layer. + + Diskless machines often have no permanent storage in which + to store network configuration information, so that + sufficient configuration information must be obtained + dynamically to support the loading phase that follows. + This information must include at least the IP addresses of + the host and of the boot server. To support booting + across a gateway, the address mask and a list of default + gateways are also required. + + (2) Load the host system code. + + During the loading phase, an appropriate file transfer + protocol is used to copy the system code across the + network from the boot server. + + A host with a disk may perform the first step, dynamic + configuration. This is important for microcomputers, whose + floppy disks allow network configuration information to be + mistakenly duplicated on more than one host. Also, + installation of new hosts is much simpler if they automatically + obtain their configuration information from a central server, + saving administrator time and decreasing the probability of + mistakes. + + 6.2.2 REQUIREMENTS + + 6.2.2.1 Dynamic Configuration + + A number of protocol provisions have been made for dynamic + configuration. + + o ICMP Information Request/Reply messages + + + +Internet Engineering Task Force [Page 87] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + This obsolete message pair was designed to allow a host + to find the number of the network it is on. + Unfortunately, it was useful only if the host already + knew the host number part of its IP address, + information that hosts requiring dynamic configuration + seldom had. + + o Reverse Address Resolution Protocol (RARP) [BOOT:4] + + RARP is a link-layer protocol for a broadcast medium + that allows a host to find its IP address given its + link layer address. Unfortunately, RARP does not work + across IP gateways and therefore requires a RARP server + on every network. In addition, RARP does not provide + any other configuration information. + + o ICMP Address Mask Request/Reply messages + + These ICMP messages allow a host to learn the address + mask for a particular network interface. + + o BOOTP Protocol [BOOT:2] + + This protocol allows a host to determine the IP + addresses of the local host and the boot server, the + name of an appropriate boot file, and optionally the + address mask and list of default gateways. To locate a + BOOTP server, the host broadcasts a BOOTP request using + UDP. Ad hoc gateway extensions have been used to + transmit the BOOTP broadcast through gateways, and in + the future the IP Multicasting facility will provide a + standard mechanism for this purpose. + + + The suggested approach to dynamic configuration is to use + the BOOTP protocol with the extensions defined in "BOOTP + Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 + defines some important general (not vendor-specific) + extensions. In particular, these extensions allow the + address mask to be supplied in BOOTP; we RECOMMEND that the + address mask be supplied in this manner. + + DISCUSSION: + Historically, subnetting was defined long after IP, and + so a separate mechanism (ICMP Address Mask messages) + was designed to supply the address mask to a host. + However, the IP address mask and the corresponding IP + address conceptually form a pair, and for operational + + + +Internet Engineering Task Force [Page 88] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + simplicity they ought to be defined at the same time + and by the same mechanism, whether a configuration file + or a dynamic mechanism like BOOTP. + + Note that BOOTP is not sufficiently general to specify + the configurations of all interfaces of a multihomed + host. A multihomed host must either use BOOTP + separately for each interface, or configure one + interface using BOOTP to perform the loading, and + perform the complete initialization from a file later. + + Application layer configuration information is expected + to be obtained from files after loading of the system + code. + + 6.2.2.2 Loading Phase + + A suggested approach for the loading phase is to use TFTP + [BOOT:1] between the IP addresses established by BOOTP. + + TFTP to a broadcast address SHOULD NOT be used, for reasons + explained in Section 4.2.3.4. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 89] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + 6.3 REMOTE MANAGEMENT + + 6.3.1 INTRODUCTION + + The Internet community has recently put considerable effort + into the development of network management protocols. The + result has been a two-pronged approach [MGT:1, MGT:6]: the + Simple Network Management Protocol (SNMP) [MGT:4] and the + Common Management Information Protocol over TCP (CMOT) [MGT:5]. + + In order to be managed using SNMP or CMOT, a host will need to + implement an appropriate management agent. An Internet host + SHOULD include an agent for either SNMP or CMOT. + + Both SNMP and CMOT operate on a Management Information Base + (MIB) that defines a collection of management values. By + reading and setting these values, a remote application may + query and change the state of the managed system. + + A standard MIB [MGT:3] has been defined for use by both + management protocols, using data types defined by the Structure + of Management Information (SMI) defined in [MGT:2]. Additional + MIB variables can be introduced under the "enterprises" and + "experimental" subtrees of the MIB naming space [MGT:2]. + + Every protocol module in the host SHOULD implement the relevant + MIB variables. A host SHOULD implement the MIB variables as + defined in the most recent standard MIB, and MAY implement + other MIB variables when appropriate and useful. + + 6.3.2 PROTOCOL WALK-THROUGH + + The MIB is intended to cover both hosts and gateways, although + there may be detailed differences in MIB application to the two + cases. This section contains the appropriate interpretation of + the MIB for hosts. It is likely that later versions of the MIB + will include more entries for host management. + + A managed host must implement the following groups of MIB + object definitions: System, Interfaces, Address Translation, + IP, ICMP, TCP, and UDP. + + The following specific interpretations apply to hosts: + + o ipInHdrErrors + + Note that the error "time-to-live exceeded" can occur in a + host only when it is forwarding a source-routed datagram. + + + +Internet Engineering Task Force [Page 90] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + o ipOutNoRoutes + + This object counts datagrams discarded because no route + can be found. This may happen in a host if all the + default gateways in the host's configuration are down. + + o ipFragOKs, ipFragFails, ipFragCreates + + A host that does not implement intentional fragmentation + (see "Fragmentation" section of [INTRO:1]) MUST return the + value zero for these three objects. + + o icmpOutRedirects + + For a host, this object MUST always be zero, since hosts + do not send Redirects. + + o icmpOutAddrMaskReps + + For a host, this object MUST always be zero, unless the + host is an authoritative source of address mask + information. + + o ipAddrTable + + For a host, the "IP Address Table" object is effectively a + table of logical interfaces. + + o ipRoutingTable + + For a host, the "IP Routing Table" object is effectively a + combination of the host's Routing Cache and the static + route table described in "Routing Outbound Datagrams" + section of [INTRO:1]. + + Within each ipRouteEntry, ipRouteMetric1...4 normally will + have no meaning for a host and SHOULD always be -1, while + ipRouteType will normally have the value "remote". + + If destinations on the connected network do not appear in + the Route Cache (see "Routing Outbound Datagrams section + of [INTRO:1]), there will be no entries with ipRouteType + of "direct". + + + DISCUSSION: + The current MIB does not include Type-of-Service in an + ipRouteEntry, but a future revision is expected to make + + + +Internet Engineering Task Force [Page 91] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + this addition. + + We also expect the MIB to be expanded to allow the remote + management of applications (e.g., the ability to partially + reconfigure mail systems). Network service applications + such as mail systems should therefore be written with the + "hooks" for remote management. + + 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|-----------|-|-|-|-|-|-- +Support SNMP or CMOT agent |6.3.1 | |x| | | | +Implement specified objects in standard MIB |6.3.1 | |x| | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 92] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + +7. REFERENCES + + This section lists the primary references with which every + implementer must be thoroughly familiar. It also lists some + secondary references that are suggested additional reading. + + INTRODUCTORY REFERENCES: + + + [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," + IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, + October 1989. + + [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, + (three volumes), SRI International, December 1985. + + [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, + RFC-1011, May 1987. + + This document is republished periodically with new RFC numbers; + the latest version must be used. + + [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. + Postel, RFC-980, March 1986. + + [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, + May 1987. + + This document is republished periodically with new RFC numbers; + the latest version must be used. + + + TELNET REFERENCES: + + + [TELNET:1] "Telnet Protocol Specification," J. Postel and J. + Reynolds, RFC-854, May 1983. + + [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, + RFC-855, May 1983. + + [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, + RFC-856, May 1983. + + [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, + May 1983. + + [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. + + + +Internet Engineering Task Force [Page 93] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + Reynolds, RFC-858, May 1983. + + [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC- + 859, May 1983. + + [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, + RFC-860, May 1983. + + [TELNET:8] "Telnet Extended Options List," J. Postel and J. + Reynolds, RFC-861, May 1983. + + [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, + December 1983. + + [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, + February 1989. + + This document supercedes RFC-930. + + [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, + October 1988. + + [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August + 1989. + + [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, + December 1988. + + [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC- + 1080, November 1988. + + + SECONDARY TELNET REFERENCES: + + + [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of + Defense, May 1984. + + This document is intended to describe the same protocol as RFC- + 854. In case of conflict, RFC-854 takes precedence, and the + present document takes precedence over both. + + [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977. + + [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October + 1977. + + [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977. + + + +Internet Engineering Task Force [Page 94] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS + Implementation," A. Yasuda and T. Thompson, RFC-1043, February + 1988. + + + FTP REFERENCES: + + + [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC- + 959, October 1985. + + [FTP:2] "Document File Format Standards," J. Postel, RFC-678, + December 1974. + + [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of + Defense, May 1984. + + This document is based on an earlier version of the FTP + specification (RFC-765) and is obsolete. + + + TFTP REFERENCES: + + + [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June + 1981. + + + MAIL REFERENCES: + + + [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August + 1982. + + [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," + D. Crocker, RFC-822, August 1982. + + This document obsoleted an earlier specification, RFC-733. + + [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC- + 974, January 1986. + + This RFC describes the use of MX records, a mandatory extension + to the mail delivery process. + + [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, + February 1988. + + + + +Internet Engineering Task Force [Page 95] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, + June 1986. + + [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. + + The two preceding RFC's define a proposed standard for + gatewaying mail between the Internet and the X.400 environments. + + [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. + Department of Defense, May 1984. + + This specification is intended to describe the same protocol as + does RFC-821. However, MIL-STD-1781 is incomplete; in + particular, it does not include MX records [SMTP:3]. + + [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, + RFC-1049, March 1988. + + + DOMAIN NAME SYSTEM REFERENCES: + + + [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, + RFC-1034, November 1987. + + This document and the following one obsolete RFC-882, RFC-883, + and RFC-973. + + [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, + P. Mockapetris, November 1987. + + + [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, + January 1986. + + + [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, + RFC-952, M. Stahl, E. Feinler, October 1985. + + SECONDARY DNS REFERENCES: + + + [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, + RFC-953, October 1985. + + [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November + 1987. + + + + +Internet Engineering Task Force [Page 96] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC- + 1033, November 1987. + + [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet + Protocol Handbook, NIC 50007, SRI Network Information Center, + August 1989. + + + SYSTEM INITIALIZATION REFERENCES: + + + [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June + 1984. + + [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC- + 951, September 1985. + + [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC- + 1084, December 1988. + + Note: this RFC revised and obsoleted RFC-1048. + + [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. + Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. + + + MANAGEMENT REFERENCES: + + + [MGT:1] "IAB Recommendations for the Development of Internet Network + Management Standards," V. Cerf, RFC-1052, April 1988. + + [MGT:2] "Structure and Identification of Management Information for + TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, + August 1988. + + [MGT:3] "Management Information Base for Network Management of + TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, + August 1988. + + [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, + M. Schoffstall, and C. Davin, RFC-1098, April 1989. + + [MGT:5] "The Common Management Information Services and Protocol + over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. + + [MGT:6] "Report of the Second Ad Hoc Network Management Review + Group," V. Cerf, RFC-1109, August 1989. + + + +Internet Engineering Task Force [Page 97] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + +Security Considerations + + There are many security issues in the application and support + programs of host software, but a full discussion is beyond the scope + of this RFC. Security-related issues are mentioned in sections + concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and + EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the + SMTP DATA command (Section 5.2.8). + +Author's Address + + Robert Braden + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + + Phone: (213) 822 1511 + + EMail: Braden@ISI.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 98] + diff --git a/server/src/site/resources/rfclist/basic/rfc2045.txt b/server/src/site/resources/rfclist/basic/rfc2045.txt new file mode 100644 index 00000000000..0179984eae5 --- /dev/null +++ b/server/src/site/resources/rfclist/basic/rfc2045.txt @@ -0,0 +1,1740 @@ + + + + + +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 := + + x-token := + + subtype := extension-token / iana-token + + iana-token := + + parameter := attribute "=" value + + attribute := token + ; Matching of attributes + ; is ALWAYS case-insensitive. + + value := token / quoted-string + + token := 1* + + 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 := + ; 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 := + +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 := + + + + +Freed & Borenstein Standards Track [Page 29] + +RFC 2045 Internet Message Bodies November 1996 + + + ietf-token := + + id := "Content-ID" ":" msg-id + + mechanism := "7bit" / "8bit" / "binary" / + "quoted-printable" / "base64" / + ietf-token / x-token + + MIME-extension-field := + + 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 := + ; Characters not listed as "mail-safe" in + ; RFC 2049 are also not recommended. + + subtype := extension-token / iana-token + + token := 1* + + 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 := + + + + + + + + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 31] + + + diff --git a/server/src/site/resources/rfclist/basic/rfc2046.txt b/server/src/site/resources/rfclist/basic/rfc2046.txt new file mode 100644 index 00000000000..ee204a53722 --- /dev/null +++ b/server/src/site/resources/rfclist/basic/rfc2046.txt @@ -0,0 +1,2468 @@ + + + + + +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 + To: Ned Freed + 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 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 := + + 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 + To: Ned Freed + 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: + 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: + 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: + 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: + 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: + 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: + Content-Type: multipart/alternative; boundary=42 + Content-ID: + + --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: + + --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: + + --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: + + 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 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/server/src/site/resources/rfclist/basic/rfc2822.txt b/server/src/site/resources/rfclist/basic/rfc2822.txt new file mode 100644 index 00000000000..92b3ec28ba7 --- /dev/null +++ b/server/src/site/resources/rfclist/basic/rfc2822.txt @@ -0,0 +1,2858 @@ + + + + + +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 +To: Mary Smith +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 +Sender: Michael Jones +To: Mary Smith +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" +To: Mary Smith , jdoe@example.org, Who? +Cc: , "Giant; \"Big\" Box" +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 +To: A Group:Chris Jones ,joe@where.test,John ; +Cc: Undisclosed recipients:; +Date: Thu, 13 Feb 1969 23:32:54 -0330 +Message-ID: + +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 +To: Mary Smith +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 +To: John Doe +Reply-To: "Mary Smith: Personal Account" +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" +From: John Doe +Subject: Re: Saying Hello +Date: Fri, 21 Nov 1997 11:00:00 -0600 +Message-ID: +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 +To: Mary Smith +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 +Resent-To: Jane Brown +Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 +Resent-Message-ID: <78910@example.net> +From: John Doe +To: Mary Smith +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 ; 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 +To: Mary Smith +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) +To:A Group(Some people) + :Chris Jones , + joe@example.org, + John (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: + +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 +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 +To: Mary Smith +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 +To : Mary Smith +__ + +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/server/src/site/resources/rfclist/imap4/rfc1731.txt b/server/src/site/resources/rfclist/imap4/rfc1731.txt new file mode 100644 index 00000000000..7c3f9535163 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc1731.txt @@ -0,0 +1,340 @@ + + + + + +Network Working Group J. Myers +Request for Comments: 1731 Carnegie Mellon +Category: Standards Track December 1994 + + + IMAP4 Authentication Mechanisms + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + + +1. Introduction + + The Internet Message Access Protocol, Version 4 [IMAP4] contains the + AUTHENTICATE command, for identifying and authenticating a user to an + IMAP4 server and for optionally negotiating a protection mechanism + for subsequent protocol interactions. This document describes + several authentication mechanisms for use by the IMAP4 AUTHENTICATE + command. + + +2. Kerberos version 4 authentication mechanism + + The authentication type associated with Kerberos version 4 is + "KERBEROS_V4". + + The data encoded in the first ready response contains a random 32-bit + number in network byte order. The client should respond with a + Kerberos ticket and an authenticator for the principal + "imap.hostname@realm", where "hostname" is the first component of the + host name of the server with all letters in lower case and where + "realm" is the Kerberos realm of the server. The encrypted checksum + field included within the Kerberos authenticator should contain the + server provided 32-bit number in network byte order. + + Upon decrypting and verifying the ticket and authenticator, the + server should verify that the contained checksum field equals the + original server provided random 32-bit number. Should the + verification be successful, the server must add one to the checksum + and construct 8 octets of data, with the first four octets containing + the incremented checksum in network byte order, the fifth octet + containing a bit-mask specifying the protection mechanisms supported + by the server, and the sixth through eighth octets containing, in + + + +Myers [Page 1] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + network byte order, the maximum cipher-text buffer size the server is + able to receive. The server must encrypt the 8 octets of data in the + session key and issue that encrypted data in a second ready response. + The client should consider the server authenticated if the first four + octets the un-encrypted data is equal to one plus the checksum it + previously sent. + + The client must construct data with the first four octets containing + the original server-issued checksum in network byte order, the fifth + octet containing the bit-mask specifying the selected protection + mechanism, the sixth through eighth octets containing in network byte + order the maximum cipher-text buffer size the client is able to + receive, and the following octets containing a user name string. The + client must then append from one to eight octets so that the length + of the data is a multiple of eight octets. The client must then PCBC + encrypt the data with the session key and respond to the second ready + response with the encrypted data. The server decrypts the data and + verifies the contained checksum. The username field identifies the + user for whom subsequent IMAP operations are to be performed; the + server must verify that the principal identified in the Kerberos + ticket is authorized to connect as that user. After these + verifications, the authentication process is complete. + + The protection mechanisms and their corresponding bit-masks are as + follows: + + 1 No protection mechanism + 2 Integrity (krb_mk_safe) protection + 4 Privacy (krb_mk_priv) protection + + + EXAMPLE: The following are two Kerberos version 4 login scenarios + (note that the line breaks in the sample authenticators are for + editorial clarity and are not in real authenticators) + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + AmFYig== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: + or//EoAADZI= + C: DiAF5A4gA+oOIALuBkAAmw== + S: A001 OK Kerberos V4 authentication successful + + + + + + + +Myers [Page 2] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + gcfgCA== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: A001 NO Kerberos V4 authentication failed + + +3. GSSAPI authentication mechanism + + The authentication type associated with all mechanisms employing the + GSSAPI [RFC1508] is "GSSAPI". + + The first ready response issued by the server contains no data. The + client should call GSS_Init_sec_context, passing in 0 for + input_context_handle (initially) and a targ_name equal to output_name + from GSS_Import_Name called with input_name_type of NULL and + input_name_string of "SERVICE:imap@hostname" where "hostname" is the + fully qualified host name of the server with all letters in lower + case. The client must then respond with the resulting output_token. + If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client + should expect the server to issue a token in a subsequent ready + response. The client must pass the token to another call to + GSS_Init_sec_context. + + If GSS_Init_sec_context returns GSS_COMPLETE, then the client should + respond with any resulting output_token. If there is no + output_token, the client should respond with no data. The client + should then expect the server to issue a token in a subsequent ready + response. The client should pass this token to GSS_Unseal and + interpret the first octet of resulting cleartext as a bit-mask + specifying the protection mechanisms supported by the server and the + second through fourth octets as the maximum size output_message to + send to the server. The client should construct data, with the first + octet containing the bit-mask specifying the selected protection + mechanism, the second through fourth octets containing in network + byte order the maximum size output_message the client is able to + receive, and the remaining octets containing a user name string. The + client must pass the data to GSS_Seal with conf_flag set to FALSE, + and respond with the generated output_message. The client can then + consider the server authenticated. + + The server must issue a ready response with no data and pass the + resulting client supplied token to GSS_Accept_sec_context as + input_token, setting acceptor_cred_handle to NULL (for "use default + credentials"), and 0 for input_context_handle (initially). If + GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should + + + +Myers [Page 3] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + return the generated output_token to the client in a ready response + and pass the resulting client supplied token to another call to + GSS_Accept_sec_context. + + If GSS_Accept_sec_context returns GSS_COMPLETE, then if an + output_token is returned, the server should return it to the client + in a ready response and expect a reply from the client with no data. + Whether or not an output_token was returned, the server then should + then construct 4 octets of data, with the first octet containing a + bit-mask specifying the protection mechanisms supported by the server + and the second through fourth octets containing in network byte order + the maximum size output_token the server is able to receive. The + server must then pass the plaintext to GSS_Seal with conf_flag set to + FALSE and issue the generated output_message to the client in a ready + response. The server must then pass the resulting client supplied + token to GSS_Unseal and interpret the first octet of resulting + cleartext as the bit-mask for the selected protection mechanism, the + second through fourth octets as the maximum size output_message to + send to the client, and the remaining octets as the user name. Upon + verifying the src_name is authorized to authenticate as the user + name, The server should then consider the client authenticated. + + The protection mechanisms and their corresponding bit-masks are as + follows: + + 1 No protection mechanism + 2 Integrity protection. + Sender calls GSS_Seal with conf_flag set to FALSE + 4 Privacy protection. + Sender calls GSS_Seal with conf_flag set to TRUE + + +4. S/Key authentication mechanism + + The authentication type associated with S/Key [SKEY] is "SKEY". + + The first ready response issued by the server contains no data. The + client responds with the user name string. + + The data encoded in the second ready response contains the decimal + sequence number followed by a single space and the seed string for + the indicated user. The client responds with the one-time-password, + as either a 64-bit value in network byte order or encoded in the "six + English words" format. + + Upon successful verification of the one-time-password, the server + should consider the client authenticated. + + + + +Myers [Page 4] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + + S/Key authentication does not provide for any protection mechanisms. + + + EXAMPLE: The following are two S/Key login scenarios. + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE SKEY + S: + + C: bW9yZ2Fu + S: + OTUgUWE1ODMwOA== + C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== + S: A001 OK S/Key authentication successful + + + S: * OK IMAP4 Server + C: A001 AUTHENTICATE SKEY + S: + + C: c21pdGg= + S: + OTUgUWE1ODMwOA== + C: BsAY3g4gBNo= + S: A001 NO S/Key authentication failed + + +5. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", + RFC 1730, University of Washington, December 1994. + + [RFC1508] Linn, J., "Generic Security Service Application Program + Interface", RFC 1508, Geer Zolot Associates, September 1993. + + [SKEY] Haller, Neil M. "The S/Key One-Time Password System", + Bellcore, Morristown, New Jersey, October 1993, + thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps + + + + + + + + + + + + + + + + + +Myers [Page 5] + +RFC 1731 IMAP4 Authentication Mechanisms December 1994 + + +6. Security Considerations + + Security issues are discussed throughout this memo. + + +7. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + EMail: jgm+@cmu.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers [Page 6] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2060.txt b/server/src/site/resources/rfclist/imap4/rfc2060.txt new file mode 100644 index 00000000000..5c31eb99642 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2060.txt @@ -0,0 +1,4596 @@ + + + + + +Network Working Group M. Crispin +Request for Comments: 2060 University of Washington +Obsoletes: 1730 December 1996 +Category: Standards Track + + + INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) + allows a client to access and manipulate electronic mail messages on + a server. IMAP4rev1 permits manipulation of remote message folders, + called "mailboxes", in a way that is functionally equivalent to local + mailboxes. IMAP4rev1 also provides the capability for an offline + client to resynchronize with the server (see also [IMAP-DISC]). + + IMAP4rev1 includes operations for creating, deleting, and renaming + mailboxes; checking for new messages; permanently removing messages; + setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; + searching; and selective fetching of message attributes, texts, and + portions thereof. Messages in IMAP4rev1 are accessed by the use of + numbers. These numbers are either message sequence numbers or unique + identifiers. + + IMAP4rev1 supports a single server. A mechanism for accessing + configuration information to support multiple IMAP4rev1 servers is + discussed in [ACAP]. + + IMAP4rev1 does not specify a means of posting mail; this function is + handled by a mail transfer protocol such as [SMTP]. + + IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and + unpublished IMAP2bis protocols. In the course of the evolution of + IMAP4rev1, some aspects in the earlier protocol have become obsolete. + Obsolete commands, responses, and data formats which an IMAP4rev1 + implementation may encounter when used with an earlier implementation + are described in [IMAP-OBSOLETE]. + + + + + +Crispin Standards Track [Page 1] + +RFC 2060 IMAP4rev1 December 1996 + + + Other compatibility issues with IMAP2bis, the most common variant of + the earlier protocol, are discussed in [IMAP-COMPAT]. A full + discussion of compatibility issues with rare (and presumed extinct) + variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is + primarily of historical interest. + +Table of Contents + +IMAP4rev1 Protocol Specification .................................. 4 +1. How to Read This Document ................................. 4 +1.1. Organization of This Document ............................. 4 +1.2. Conventions Used in This Document ......................... 4 +2. Protocol Overview ......................................... 5 +2.1. Link Level ................................................ 5 +2.2. Commands and Responses .................................... 6 +2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 6 +2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 7 +2.3. Message Attributes ........................................ 7 +2.3.1. Message Numbers ........................................... 7 +2.3.1.1. Unique Identifier (UID) Message Attribute ......... 7 +2.3.1.2. Message Sequence Number Message Attribute ......... 9 +2.3.2. Flags Message Attribute .................................... 9 +2.3.3. Internal Date Message Attribute ........................... 10 +2.3.4. [RFC-822] Size Message Attribute .......................... 11 +2.3.5. Envelope Structure Message Attribute ...................... 11 +2.3.6. Body Structure Message Attribute .......................... 11 +2.4. Message Texts ............................................. 11 +3. State and Flow Diagram .................................... 11 +3.1. Non-Authenticated State ................................... 11 +3.2. Authenticated State ....................................... 11 +3.3. Selected State ............................................ 12 +3.4. Logout State .............................................. 12 +4. Data Formats .............................................. 12 +4.1. Atom ...................................................... 13 +4.2. Number .................................................... 13 +4.3. String ..................................................... 13 +4.3.1. 8-bit and Binary Strings .................................. 13 +4.4. Parenthesized List ........................................ 14 +4.5. NIL ....................................................... 14 +5. Operational Considerations ................................ 14 +5.1. Mailbox Naming ............................................ 14 +5.1.1. Mailbox Hierarchy Naming .................................. 14 +5.1.2. Mailbox Namespace Naming Convention ....................... 14 +5.1.3. Mailbox International Naming Convention ................... 15 +5.2. Mailbox Size and Message Status Updates ................... 16 +5.3. Response when no Command in Progress ...................... 16 +5.4. Autologout Timer .......................................... 16 +5.5. Multiple Commands in Progress ............................. 17 + + + +Crispin Standards Track [Page 2] + +RFC 2060 IMAP4rev1 December 1996 + + +6. Client Commands ........................................... 17 +6.1. Client Commands - Any State ............................... 18 +6.1.1. CAPABILITY Command ........................................ 18 +6.1.2. NOOP Command .............................................. 19 +6.1.3. LOGOUT Command ............................................ 20 +6.2. Client Commands - Non-Authenticated State ................. 20 +6.2.1. AUTHENTICATE Command ...................................... 21 +6.2.2. LOGIN Command ............................................. 22 +6.3. Client Commands - Authenticated State ..................... 22 +6.3.1. SELECT Command ............................................ 23 +6.3.2. EXAMINE Command ........................................... 24 +6.3.3. CREATE Command ............................................ 25 +6.3.4. DELETE Command ............................................ 26 +6.3.5. RENAME Command ............................................ 27 +6.3.6. SUBSCRIBE Command ......................................... 29 +6.3.7. UNSUBSCRIBE Command ....................................... 30 +6.3.8. LIST Command .............................................. 30 +6.3.9. LSUB Command .............................................. 32 +6.3.10. STATUS Command ............................................ 33 +6.3.11. APPEND Command ............................................ 34 +6.4. Client Commands - Selected State .......................... 35 +6.4.1. CHECK Command ............................................. 36 +6.4.2. CLOSE Command ............................................. 36 +6.4.3. EXPUNGE Command ........................................... 37 +6.4.4. SEARCH Command ............................................ 37 +6.4.5. FETCH Command ............................................. 41 +6.4.6. STORE Command ............................................. 45 +6.4.7. COPY Command .............................................. 46 +6.4.8. UID Command ............................................... 47 +6.5. Client Commands - Experimental/Expansion .................. 48 +6.5.1. X Command ........................................... 48 +7. Server Responses .......................................... 48 +7.1. Server Responses - Status Responses ....................... 49 +7.1.1. OK Response ............................................... 51 +7.1.2. NO Response ............................................... 51 +7.1.3. BAD Response .............................................. 52 +7.1.4. PREAUTH Response .......................................... 52 +7.1.5. BYE Response .............................................. 52 +7.2. Server Responses - Server and Mailbox Status .............. 53 +7.2.1. CAPABILITY Response ....................................... 53 +7.2.2. LIST Response .............................................. 54 +7.2.3. LSUB Response ............................................. 55 +7.2.4 STATUS Response ........................................... 55 +7.2.5. SEARCH Response ........................................... 55 +7.2.6. FLAGS Response ............................................ 56 +7.3. Server Responses - Mailbox Size ........................... 56 +7.3.1. EXISTS Response ........................................... 56 +7.3.2. RECENT Response ........................................... 57 + + + +Crispin Standards Track [Page 3] + +RFC 2060 IMAP4rev1 December 1996 + + +7.4. Server Responses - Message Status ......................... 57 +7.4.1. EXPUNGE Response .......................................... 57 +7.4.2. FETCH Response ............................................ 58 +7.5. Server Responses - Command Continuation Request ........... 63 +8. Sample IMAP4rev1 connection ............................... 63 +9. Formal Syntax ............................................. 64 +10. Author's Note ............................................. 74 +11. Security Considerations ................................... 74 +12. Author's Address .......................................... 75 +Appendices ........................................................ 76 +A. References ................................................ 76 +B. Changes from RFC 1730 ..................................... 77 +C. Key Word Index ............................................ 79 + + +IMAP4rev1 Protocol Specification + +1. How to Read This Document + +1.1. Organization of This Document + + This document is written from the point of view of the implementor of + an IMAP4rev1 client or server. Beyond the protocol overview in + section 2, it is not optimized for someone trying to understand the + operation of the protocol. The material in sections 3 through 5 + provides the general context and definitions with which IMAP4rev1 + operates. + + Sections 6, 7, and 9 describe the IMAP commands, responses, and + syntax, respectively. The relationships among these are such that it + is almost impossible to understand any of them separately. In + particular, do not attempt to deduce command syntax from the command + section alone; instead refer to the Formal Syntax section. + +1.2. Conventions Used in This Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + The following terms are used in this document to signify the + requirements of this specification. + + 1) MUST, or the adjective REQUIRED, means that the definition is + an absolute requirement of the specification. + + 2) MUST NOT that the definition is an absolute prohibition of the + specification. + + + + +Crispin Standards Track [Page 4] + +RFC 2060 IMAP4rev1 December 1996 + + + 3) SHOULD means that there may exist valid reasons in particular + circumstances to ignore a particular item, but the full + implications MUST be understood and carefully weighed before + choosing a different course. + + 4) SHOULD NOT means that there may exist valid reasons in + particular circumstances when the particular behavior is + acceptable or even useful, but the full implications SHOULD be + understood and the case carefully weighed before implementing + any behavior described with this label. + + 5) MAY, or the adjective OPTIONAL, means that an item is truly + optional. One vendor may choose to include the item because a + particular marketplace requires it or because the vendor feels + that it enhances the product while another vendor may omit the + same item. An implementation which does not include a + particular option MUST be prepared to interoperate with another + implementation which does include the option. + + "Can" is used instead of "may" when referring to a possible + circumstance or situation, as opposed to an optional facility of + the protocol. + + "User" is used to refer to a human user, whereas "client" refers + to the software being run by the user. + + "Connection" refers to the entire sequence of client/server + interaction from the initial establishment of the network + connection until its termination. "Session" refers to the + sequence of client/server interaction from the time that a mailbox + is selected (SELECT or EXAMINE command) until the time that + selection ends (SELECT or EXAMINE of another mailbox, CLOSE + command, or connection termination). + + Characters are 7-bit US-ASCII unless otherwise specified. Other + character sets are indicated using a "CHARSET", as described in + [MIME-IMT] and defined in [CHARSET]. CHARSETs have important + additional semantics in addition to defining character set; refer + to these documents for more detail. + +2. Protocol Overview + +2.1. Link Level + + The IMAP4rev1 protocol assumes a reliable data stream such as + provided by TCP. When TCP is used, an IMAP4rev1 server listens on + port 143. + + + + +Crispin Standards Track [Page 5] + +RFC 2060 IMAP4rev1 December 1996 + + +2.2. Commands and Responses + + An IMAP4rev1 connection consists of the establishment of a + client/server network connection, an initial greeting from the + server, and client/server interactions. These client/server + interactions consist of a client command, server data, and a server + completion result response. + + All interactions transmitted by client and server are in the form of + lines; that is, strings that end with a CRLF. The protocol receiver + of an IMAP4rev1 client or server is either reading a line, or is + reading a sequence of octets with a known count followed by a line. + +2.2.1. Client Protocol Sender and Server Protocol Receiver + + The client command begins an operation. Each client command is + prefixed with an identifier (typically a short alphanumeric string, + e.g. A0001, A0002, etc.) called a "tag". A different tag is + generated by the client for each command. + + There are two cases in which a line from the client does not + represent a complete command. In one case, a command argument is + quoted with an octet count (see the description of literal in String + under Data Formats); in the other case, the command arguments require + server feedback (see the AUTHENTICATE command). In either case, the + server sends a command continuation request response if it is ready + for the octets (if appropriate) and the remainder of the command. + This response is prefixed with the token "+". + + Note: If, instead, the server detected an error in the command, it + sends a BAD completion response with tag matching the command (as + described below) to reject the command and prevent the client from + sending any more of the command. + + It is also possible for the server to send a completion response + for some other command (if multiple commands are in progress), or + untagged data. In either case, the command continuation request + is still pending; the client takes the appropriate action for the + response, and reads another response from the server. In all + cases, the client MUST send a complete command (including + receiving all command continuation request responses and command + continuations for the command) before initiating a new command. + + The protocol receiver of an IMAP4rev1 server reads a command line + from the client, parses the command and its arguments, and transmits + server data and a server command completion result response. + + + + + +Crispin Standards Track [Page 6] + +RFC 2060 IMAP4rev1 December 1996 + + +2.2.2. Server Protocol Sender and Client Protocol Receiver + + Data transmitted by the server to the client and status responses + that do not indicate command completion are prefixed with the token + "*", and are called untagged responses. + + Server data MAY be sent as a result of a client command, or MAY be + sent unilaterally by the server. There is no syntactic difference + between server data that resulted from a specific command and server + data that were sent unilaterally. + + The server completion result response indicates the success or + failure of the operation. It is tagged with the same tag as the + client command which began the operation. Thus, if more than one + command is in progress, the tag in a server completion response + identifies the command to which the response applies. There are + three possible server completion responses: OK (indicating success), + NO (indicating failure), or BAD (indicating protocol error such as + unrecognized command or command syntax error). + + The protocol receiver of an IMAP4rev1 client reads a response line + from the server. It then takes action on the response based upon the + first token of the response, which can be a tag, a "*", or a "+". + + A client MUST be prepared to accept any server response at all times. + This includes server data that was not requested. Server data SHOULD + be recorded, so that the client can reference its recorded copy + rather than sending a command to the server to request the data. In + the case of certain server data, the data MUST be recorded. + + This topic is discussed in greater detail in the Server Responses + section. + +2.3. Message Attributes + + In addition to message text, each message has several attributes + associated with it. These attributes may be retrieved individually + or in conjunction with other attributes or message texts. + +2.3.1. Message Numbers + + Messages in IMAP4rev1 are accessed by one of two numbers; the unique + identifier and the message sequence number. + +2.3.1.1. Unique Identifier (UID) Message Attribute + + A 32-bit value assigned to each message, which when used with the + unique identifier validity value (see below) forms a 64-bit value + + + +Crispin Standards Track [Page 7] + +RFC 2060 IMAP4rev1 December 1996 + + + that is permanently guaranteed not to refer to any other message in + the mailbox. Unique identifiers are assigned in a strictly ascending + fashion in the mailbox; as each message is added to the mailbox it is + assigned a higher UID than the message(s) which were added + previously. + + Unlike message sequence numbers, unique identifiers are not + necessarily contiguous. Unique identifiers also persist across + sessions. This permits a client to resynchronize its state from a + previous session with the server (e.g. disconnected or offline access + clients); this is discussed further in [IMAP-DISC]. + + Associated with every mailbox is a unique identifier validity value, + which is sent in an UIDVALIDITY response code in an OK untagged + response at mailbox selection time. If unique identifiers from an + earlier session fail to persist to this session, the unique + identifier validity value MUST be greater than the one used in the + earlier session. + + Note: Unique identifiers MUST be strictly ascending in the mailbox + at all times. If the physical message store is re-ordered by a + non-IMAP agent, this requires that the unique identifiers in the + mailbox be regenerated, since the former unique identifers are no + longer strictly ascending as a result of the re-ordering. Another + instance in which unique identifiers are regenerated is if the + message store has no mechanism to store unique identifiers. + Although this specification recognizes that this may be + unavoidable in certain server environments, it STRONGLY ENCOURAGES + message store implementation techniques that avoid this problem. + + Another cause of non-persistance is if the mailbox is deleted and + a new mailbox with the same name is created at a later date, Since + the name is the same, a client may not know that this is a new + mailbox unless the unique identifier validity is different. A + good value to use for the unique identifier validity value is a + 32-bit representation of the creation date/time of the mailbox. + It is alright to use a constant such as 1, but only if it + guaranteed that unique identifiers will never be reused, even in + the case of a mailbox being deleted (or renamed) and a new mailbox + by the same name created at some future time. + + The unique identifier of a message MUST NOT change during the + session, and SHOULD NOT change between sessions. However, if it is + not possible to preserve the unique identifier of a message in a + subsequent session, each subsequent session MUST have a new unique + identifier validity value that is larger than any that was used + previously. + + + + +Crispin Standards Track [Page 8] + +RFC 2060 IMAP4rev1 December 1996 + + +2.3.1.2. Message Sequence Number Message Attribute + + A relative position from 1 to the number of messages in the mailbox. + This position MUST be ordered by ascending unique identifier. As + each new message is added, it is assigned a message sequence number + that is 1 higher than the number of messages in the mailbox before + that new message was added. + + Message sequence numbers can be reassigned during the session. For + example, when a message is permanently removed (expunged) from the + mailbox, the message sequence number for all subsequent messages is + decremented. Similarly, a new message can be assigned a message + sequence number that was once held by some other message prior to an + expunge. + + In addition to accessing messages by relative position in the + mailbox, message sequence numbers can be used in mathematical + calculations. For example, if an untagged "EXISTS 11" is received, + and previously an untagged "8 EXISTS" was received, three new + messages have arrived with message sequence numbers of 9, 10, and 11. + Another example; if message 287 in a 523 message mailbox has UID + 12345, there are exactly 286 messages which have lesser UIDs and 236 + messages which have greater UIDs. + +2.3.2. Flags Message Attribute + + A list of zero or more named tokens associated with the message. A + flag is set by its addition to this list, and is cleared by its + removal. There are two types of flags in IMAP4rev1. A flag of + either type may be permanent or session-only. + + A system flag is a flag name that is pre-defined in this + specification. All system flags begin with "\". Certain system + flags (\Deleted and \Seen) have special semantics described + elsewhere. The currently-defined system flags are: + + \Seen Message has been read + + \Answered Message has been answered + + \Flagged Message is "flagged" for urgent/special attention + + \Deleted Message is "deleted" for removal by later EXPUNGE + + \Draft Message has not completed composition (marked as a + draft). + + + + + +Crispin Standards Track [Page 9] + +RFC 2060 IMAP4rev1 December 1996 + + + \Recent Message is "recently" arrived in this mailbox. This + session is the first session to have been notified + about this message; subsequent sessions will not see + \Recent set for this message. This flag can not be + altered by the client. + + If it is not possible to determine whether or not + this session is the first session to be notified + about a message, then that message SHOULD be + considered recent. + + If multiple connections have the same mailbox + selected simultaneously, it is undefined which of + these connections will see newly-arrives messages + with \Recent set and which will see it without + \Recent set. + + A keyword is defined by the server implementation. Keywords do + not begin with "\". Servers MAY permit the client to define new + keywords in the mailbox (see the description of the + PERMANENTFLAGS response code for more information). + + A flag may be permanent or session-only on a per-flag basis. + Permanent flags are those which the client can add or remove + from the message flags permanently; that is, subsequent sessions + will see any change in permanent flags. Changes to session + flags are valid only in that session. + + Note: The \Recent system flag is a special case of a + session flag. \Recent can not be used as an argument in a + STORE command, and thus can not be changed at all. + +2.3.3. Internal Date Message Attribute + + The internal date and time of the message on the server. This is not + the date and time in the [RFC-822] header, but rather a date and time + which reflects when the message was received. In the case of + messages delivered via [SMTP], this SHOULD be the date and time of + final delivery of the message as defined by [SMTP]. In the case of + messages delivered by the IMAP4rev1 COPY command, this SHOULD be the + internal date and time of the source message. In the case of + messages delivered by the IMAP4rev1 APPEND command, this SHOULD be + the date and time as specified in the APPEND command description. + All other cases are implementation defined. + + + + + + + +Crispin Standards Track [Page 10] + +RFC 2060 IMAP4rev1 December 1996 + + +2.3.4. [RFC-822] Size Message Attribute + + The number of octets in the message, as expressed in [RFC-822] + format. + +2.3.5. Envelope Structure Message Attribute + + A parsed representation of the [RFC-822] envelope information (not to + be confused with an [SMTP] envelope) of the message. + +2.3.6. Body Structure Message Attribute + + A parsed representation of the [MIME-IMB] body structure information + of the message. + +2.4. Message Texts + + In addition to being able to fetch the full [RFC-822] text of a + message, IMAP4rev1 permits the fetching of portions of the full + message text. Specifically, it is possible to fetch the [RFC-822] + message header, [RFC-822] message body, a [MIME-IMB] body part, or a + [MIME-IMB] header. + +3. State and Flow Diagram + + An IMAP4rev1 server is in one of four states. Most commands are + valid in only certain states. It is a protocol error for the client + to attempt a command while the command is in an inappropriate state. + In this case, a server will respond with a BAD or NO (depending upon + server implementation) command completion result. + +3.1. Non-Authenticated State + + In non-authenticated state, the client MUST supply authentication + credentials before most commands will be permitted. This state is + entered when a connection starts unless the connection has been pre- + authenticated. + +3.2. Authenticated State + + In authenticated state, the client is authenticated and MUST select a + mailbox to access before commands that affect messages will be + permitted. This state is entered when a pre-authenticated connection + starts, when acceptable authentication credentials have been + provided, or after an error in selecting a mailbox. + + + + + + +Crispin Standards Track [Page 11] + +RFC 2060 IMAP4rev1 December 1996 + + +3.3. Selected State + + In selected state, a mailbox has been selected to access. This state + is entered when a mailbox has been successfully selected. + +3.4. Logout State + + In logout state, the connection is being terminated, and the server + will close the connection. This state can be entered as a result of + a client request or by unilateral server decision. + + +--------------------------------------+ + |initial connection and server greeting| + +--------------------------------------+ + || (1) || (2) || (3) + VV || || + +-----------------+ || || + |non-authenticated| || || + +-----------------+ || || + || (7) || (4) || || + || VV VV || + || +----------------+ || + || | authenticated |<=++ || + || +----------------+ || || + || || (7) || (5) || (6) || + || || VV || || + || || +--------+ || || + || || |selected|==++ || + || || +--------+ || + || || || (7) || + VV VV VV VV + +--------------------------------------+ + | logout and close connection | + +--------------------------------------+ + + (1) connection without pre-authentication (OK greeting) + (2) pre-authenticated connection (PREAUTH greeting) + (3) rejected connection (BYE greeting) + (4) successful LOGIN or AUTHENTICATE command + (5) successful SELECT or EXAMINE command + (6) CLOSE command, or failed SELECT or EXAMINE command + (7) LOGOUT command, server shutdown, or connection closed + +4. Data Formats + + IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can + be in one of several forms: atom, number, string, parenthesized list, + or NIL. + + + +Crispin Standards Track [Page 12] + +RFC 2060 IMAP4rev1 December 1996 + + +4.1. Atom + + An atom consists of one or more non-special characters. + +4.2. Number + + A number consists of one or more digit characters, and represents a + numeric value. + +4.3. String + + A string is in one of two forms: literal and quoted string. The + literal form is the general form of string. The quoted string form + is an alternative that avoids the overhead of processing a literal at + the cost of limitations of characters that can be used in a quoted + string. + + A literal is a sequence of zero or more octets (including CR and LF), + prefix-quoted with an octet count in the form of an open brace ("{"), + the number of octets, close brace ("}"), and CRLF. In the case of + literals transmitted from server to client, the CRLF is immediately + followed by the octet data. In the case of literals transmitted from + client to server, the client MUST wait to receive a command + continuation request (described later in this document) before + sending the octet data (and the remainder of the command). + + A quoted string is a sequence of zero or more 7-bit characters, + excluding CR and LF, with double quote (<">) characters at each end. + + The empty string is represented as either "" (a quoted string with + zero characters between double quotes) or as {0} followed by CRLF (a + literal with an octet count of 0). + + Note: Even if the octet count is 0, a client transmitting a + literal MUST wait to receive a command continuation request. + +4.3.1. 8-bit and Binary Strings + + 8-bit textual and binary mail is supported through the use of a + [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY + transmit 8-bit or multi-octet characters in literals, but SHOULD do + so only when the [CHARSET] is identified. + + + + + + + + + +Crispin Standards Track [Page 13] + +RFC 2060 IMAP4rev1 December 1996 + + + Although a BINARY body encoding is defined, unencoded binary strings + are not permitted. A "binary string" is any string with NUL + characters. Implementations MUST encode binary data into a textual + form such as BASE64 before transmitting the data. A string with an + excessive amount of CTL characters MAY also be considered to be + binary. + +4.4. Parenthesized List + + Data structures are represented as a "parenthesized list"; a sequence + of data items, delimited by space, and bounded at each end by + parentheses. A parenthesized list can contain other parenthesized + lists, using multiple levels of parentheses to indicate nesting. + + The empty list is represented as () -- a parenthesized list with no + members. + +4.5. NIL + + The special atom "NIL" represents the non-existence of a particular + data item that is represented as a string or parenthesized list, as + distinct from the empty string "" or the empty parenthesized list (). + +5. Operational Considerations + +5.1. Mailbox Naming + + The interpretation of mailbox names is implementation-dependent. + However, the case-insensitive mailbox name INBOX is a special name + reserved to mean "the primary mailbox for this user on this server". + +5.1.1. Mailbox Hierarchy Naming + + If it is desired to export hierarchical mailbox names, mailbox names + MUST be left-to-right hierarchical using a single character to + separate levels of hierarchy. The same hierarchy separator character + is used for all levels of hierarchy within a single name. + +5.1.2. Mailbox Namespace Naming Convention + + By convention, the first hierarchical element of any mailbox name + which begins with "#" identifies the "namespace" of the remainder of + the name. This makes it possible to disambiguate between different + types of mailbox stores, each of which have their own namespaces. + + + + + + + +Crispin Standards Track [Page 14] + +RFC 2060 IMAP4rev1 December 1996 + + + For example, implementations which offer access to USENET + newsgroups MAY use the "#news" namespace to partition the USENET + newsgroup namespace from that of other mailboxes. Thus, the + comp.mail.misc newsgroup would have an mailbox name of + "#news.comp.mail.misc", and the name "comp.mail.misc" could refer + to a different object (e.g. a user's private mailbox). + +5.1.3. Mailbox International Naming Convention + + By convention, international mailbox names are specified using a + modified version of the UTF-7 encoding described in [UTF-7]. The + purpose of these modifications is to correct the following problems + with UTF-7: + + 1) UTF-7 uses the "+" character for shifting; this conflicts with + the common use of "+" in mailbox names, in particular USENET + newsgroup names. + + 2) UTF-7's encoding is BASE64 which uses the "/" character; this + conflicts with the use of "/" as a popular hierarchy delimiter. + + 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with + the use of "\" as a popular hierarchy delimiter. + + 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with + the use of "~" in some servers as a home directory indicator. + + 5) UTF-7 permits multiple alternate forms to represent the same + string; in particular, printable US-ASCII chararacters can be + represented in encoded form. + + In modified UTF-7, printable US-ASCII characters except for "&" + represent themselves; that is, characters with octet values 0x20-0x25 + and 0x27-0x7e. The character "&" (0x26) is represented by the two- + octet sequence "&-". + + All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all + Unicode 16-bit octets) are represented in modified BASE64, with a + further modification from [UTF-7] that "," is used instead of "/". + Modified BASE64 MUST NOT be used to represent any printing US-ASCII + character which can represent itself. + + "&" is used to shift to modified BASE64 and "-" to shift back to US- + ASCII. All names start in US-ASCII, and MUST end in US-ASCII (that + is, a name that ends with a Unicode 16-bit octet MUST end with a "- + "). + + + + + +Crispin Standards Track [Page 15] + +RFC 2060 IMAP4rev1 December 1996 + + + For example, here is a mailbox name which mixes English, Japanese, + and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw- + +5.2. Mailbox Size and Message Status Updates + + At any time, a server can send data that the client did not request. + Sometimes, such behavior is REQUIRED. For example, agents other than + the server MAY add messages to the mailbox (e.g. new mail delivery), + change the flags of message in the mailbox (e.g. simultaneous access + to the same mailbox by multiple agents), or even remove messages from + the mailbox. A server MUST send mailbox size updates automatically + if a mailbox size change is observed during the processing of a + command. A server SHOULD send message flag updates automatically, + without requiring the client to request such updates explicitly. + Special rules exist for server notification of a client about the + removal of messages to prevent synchronization errors; see the + description of the EXPUNGE response for more detail. + + Regardless of what implementation decisions a client makes on + remembering data from the server, a client implementation MUST record + mailbox size updates. It MUST NOT assume that any command after + initial mailbox selection will return the size of the mailbox. + +5.3. Response when no Command in Progress + + Server implementations are permitted to send an untagged response + (except for EXPUNGE) while there is no command in progress. Server + implementations that send such responses MUST deal with flow control + considerations. Specifically, they MUST either (1) verify that the + size of the data does not exceed the underlying transport's available + window size, or (2) use non-blocking writes. + +5.4. Autologout Timer + + If a server has an inactivity autologout timer, that timer MUST be of + at least 30 minutes' duration. The receipt of ANY command from the + client during that interval SHOULD suffice to reset the autologout + timer. + + + + + + + + + + + + + +Crispin Standards Track [Page 16] + +RFC 2060 IMAP4rev1 December 1996 + + +5.5. Multiple Commands in Progress + + The client MAY send another command without waiting for the + completion result response of a command, subject to ambiguity rules + (see below) and flow control constraints on the underlying data + stream. Similarly, a server MAY begin processing another command + before processing the current command to completion, subject to + ambiguity rules. However, any command continuation request responses + and command continuations MUST be negotiated before any subsequent + command is initiated. + + The exception is if an ambiguity would result because of a command + that would affect the results of other commands. Clients MUST NOT + send multiple commands without waiting if an ambiguity would result. + If the server detects a possible ambiguity, it MUST execute commands + to completion in the order given by the client. + + The most obvious example of ambiguity is when a command would affect + the results of another command; for example, a FETCH of a message's + flags and a STORE of that same message's flags. + + A non-obvious ambiguity occurs with commands that permit an untagged + EXPUNGE response (commands other than FETCH, STORE, and SEARCH), + since an untagged EXPUNGE response can invalidate sequence numbers in + a subsequent command. This is not a problem for FETCH, STORE, or + SEARCH commands because servers are prohibited from sending EXPUNGE + responses while any of those commands are in progress. Therefore, if + the client sends any command other than FETCH, STORE, or SEARCH, it + MUST wait for a response before sending a command with message + sequence numbers. + + For example, the following non-waiting command sequences are invalid: + + FETCH + NOOP + STORE + STORE + COPY + FETCH + COPY + COPY + CHECK + FETCH + + The following are examples of valid non-waiting command sequences: + + FETCH + STORE + SEARCH + CHECK + STORE + COPY + EXPUNGE + +6. Client Commands + + IMAP4rev1 commands are described in this section. Commands are + organized by the state in which the command is permitted. Commands + which are permitted in multiple states are listed in the minimum + + + +Crispin Standards Track [Page 17] + +RFC 2060 IMAP4rev1 December 1996 + + + permitted state (for example, commands valid in authenticated and + selected state are listed in the authenticated state commands). + + Command arguments, identified by "Arguments:" in the command + descriptions below, are described by function, not by syntax. The + precise syntax of command arguments is described in the Formal Syntax + section. + + Some commands cause specific server responses to be returned; these + are identified by "Responses:" in the command descriptions below. + See the response descriptions in the Responses section for + information on these responses, and the Formal Syntax section for the + precise syntax of these responses. It is possible for server data to + be transmitted as a result of any command; thus, commands that do not + specifically require server data specify "no specific responses for + this command" instead of "none". + + The "Result:" in the command description refers to the possible + tagged status responses to a command, and any special interpretation + of these status responses. + +6.1. Client Commands - Any State + + The following commands are valid in any state: CAPABILITY, NOOP, and + LOGOUT. + +6.1.1. CAPABILITY Command + + Arguments: none + + Responses: REQUIRED untagged response: CAPABILITY + + Result: OK - capability completed + BAD - command unknown or arguments invalid + + The CAPABILITY command requests a listing of capabilities that the + server supports. The server MUST send a single untagged + CAPABILITY response with "IMAP4rev1" as one of the listed + capabilities before the (tagged) OK response. This listing of + capabilities is not dependent upon connection state or user. It + is therefore not necessary to issue a CAPABILITY command more than + once in a connection. + + + + + + + + + +Crispin Standards Track [Page 18] + +RFC 2060 IMAP4rev1 December 1996 + + + A capability name which begins with "AUTH=" indicates that the + server supports that particular authentication mechanism. All + such names are, by definition, part of this specification. For + example, the authorization capability for an experimental + "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not + "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP". + + Other capability names refer to extensions, revisions, or + amendments to this specification. See the documentation of the + CAPABILITY response for additional information. No capabilities, + beyond the base IMAP4rev1 set defined in this specification, are + enabled without explicit client action to invoke the capability. + + See the section entitled "Client Commands - + Experimental/Expansion" for information about the form of site or + implementation-specific capabilities. + + Example: C: abcd CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 + S: abcd OK CAPABILITY completed + +6.1.2. NOOP Command + + Arguments: none + + Responses: no specific responses for this command (but see below) + + Result: OK - noop completed + BAD - command unknown or arguments invalid + + The NOOP command always succeeds. It does nothing. + + Since any command can return a status update as untagged data, the + NOOP command can be used as a periodic poll for new messages or + message status updates during a period of inactivity. The NOOP + command can also be used to reset any inactivity autologout timer + on the server. + + Example: C: a002 NOOP + S: a002 OK NOOP completed + . . . + C: a047 NOOP + S: * 22 EXPUNGE + S: * 23 EXISTS + S: * 3 RECENT + S: * 14 FETCH (FLAGS (\Seen \Deleted)) + S: a047 OK NOOP completed + + + + +Crispin Standards Track [Page 19] + +RFC 2060 IMAP4rev1 December 1996 + + +6.1.3. LOGOUT Command + + Arguments: none + + Responses: REQUIRED untagged response: BYE + + Result: OK - logout completed + BAD - command unknown or arguments invalid + + The LOGOUT command informs the server that the client is done with + the connection. The server MUST send a BYE untagged response + before the (tagged) OK response, and then close the network + connection. + + Example: C: A023 LOGOUT + S: * BYE IMAP4rev1 Server logging out + S: A023 OK LOGOUT completed + (Server and client then close the connection) + +6.2. Client Commands - Non-Authenticated State + + In non-authenticated state, the AUTHENTICATE or LOGIN command + establishes authentication and enter authenticated state. The + AUTHENTICATE command provides a general mechanism for a variety of + authentication techniques, whereas the LOGIN command uses the + traditional user name and plaintext password pair. + + Server implementations MAY allow non-authenticated access to certain + mailboxes. The convention is to use a LOGIN command with the userid + "anonymous". A password is REQUIRED. It is implementation-dependent + what requirements, if any, are placed on the password and what access + restrictions are placed on anonymous users. + + Once authenticated (including as anonymous), it is not possible to + re-enter non-authenticated state. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in non-authenticated state: + AUTHENTICATE and LOGIN. + + + + + + + + + + + + +Crispin Standards Track [Page 20] + +RFC 2060 IMAP4rev1 December 1996 + + +6.2.1. AUTHENTICATE Command + + Arguments: authentication mechanism name + + Responses: continuation data can be requested + + Result: OK - authenticate completed, now in authenticated state + NO - authenticate failure: unsupported authentication + mechanism, credentials rejected + BAD - command unknown or arguments invalid, + authentication exchange cancelled + + The AUTHENTICATE command indicates an authentication mechanism, + such as described in [IMAP-AUTH], to the server. If the server + supports the requested authentication mechanism, it performs an + authentication protocol exchange to authenticate and identify the + client. It MAY also negotiate an OPTIONAL protection mechanism + for subsequent protocol interactions. If the requested + authentication mechanism is not supported, the server SHOULD + reject the AUTHENTICATE command by sending a tagged NO response. + + The authentication protocol exchange consists of a series of + server challenges and client answers that are specific to the + authentication mechanism. A server challenge consists of a + command continuation request response with the "+" token followed + by a BASE64 encoded string. The client answer consists of a line + consisting of a BASE64 encoded string. If the client wishes to + cancel an authentication exchange, it issues a line with a single + "*". If the server receives such an answer, it MUST reject the + AUTHENTICATE command by sending a tagged BAD response. + + A protection mechanism provides integrity and privacy protection + to the connection. If a protection mechanism is negotiated, it is + applied to all subsequent data sent over the connection. The + protection mechanism takes effect immediately following the CRLF + that concludes the authentication exchange for the client, and the + CRLF of the tagged OK response for the server. Once the + protection mechanism is in effect, the stream of command and + response octets is processed into buffers of ciphertext. Each + buffer is transferred over the connection as a stream of octets + prepended with a four octet field in network byte order that + represents the length of the following data. The maximum + ciphertext buffer length is defined by the protection mechanism. + + Authentication mechanisms are OPTIONAL. Protection mechanisms are + also OPTIONAL; an authentication mechanism MAY be implemented + without any protection mechanism. If an AUTHENTICATE command + fails with a NO response, the client MAY try another + + + +Crispin Standards Track [Page 21] + +RFC 2060 IMAP4rev1 December 1996 + + + authentication mechanism by issuing another AUTHENTICATE command, + or MAY attempt to authenticate by using the LOGIN command. In + other words, the client MAY request authentication types in + decreasing order of preference, with the LOGIN command as a last + resort. + + Example: S: * OK KerberosV4 IMAP4rev1 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + AmFYig== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: + or//EoAADZI= + C: DiAF5A4gA+oOIALuBkAAmw== + S: A001 OK Kerberos V4 authentication successful + + Note: the line breaks in the first client answer are for editorial + clarity and are not in real authenticators. + +6.2.2. LOGIN Command + + Arguments: user name + password + + Responses: no specific responses for this command + + Result: OK - login completed, now in authenticated state + NO - login failure: user name or password rejected + BAD - command unknown or arguments invalid + + The LOGIN command identifies the client to the server and carries + the plaintext password authenticating this user. + + Example: C: a001 LOGIN SMITH SESAME + S: a001 OK LOGIN completed + +6.3. Client Commands - Authenticated State + + In authenticated state, commands that manipulate mailboxes as atomic + entities are permitted. Of these commands, the SELECT and EXAMINE + commands will select a mailbox for access and enter selected state. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in authenticated state: SELECT, + EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, + STATUS, and APPEND. + + + + + +Crispin Standards Track [Page 22] + +RFC 2060 IMAP4rev1 December 1996 + + +6.3.1. SELECT Command + + Arguments: mailbox name + + Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT + OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS + + Result: OK - select completed, now in selected state + NO - select failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The SELECT command selects a mailbox so that messages in the + mailbox can be accessed. Before returning an OK to the client, + the server MUST send the following untagged data to the client: + + FLAGS Defined flags in the mailbox. See the description + of the FLAGS response for more detail. + + EXISTS The number of messages in the mailbox. See the + description of the EXISTS response for more detail. + + RECENT The number of messages with the \Recent flag set. + See the description of the RECENT response for more + detail. + + OK [UIDVALIDITY ] + The unique identifier validity value. See the + description of the UID command for more detail. + + to define the initial state of the mailbox at the client. + + The server SHOULD also send an UNSEEN response code in an OK + untagged response, indicating the message sequence number of the + first unseen message in the mailbox. + + If the client can not change the permanent state of one or more of + the flags listed in the FLAGS untagged response, the server SHOULD + send a PERMANENTFLAGS response code in an OK untagged response, + listing the flags that the client can change permanently. + + Only one mailbox can be selected at a time in a connection; + simultaneous access to multiple mailboxes requires multiple + connections. The SELECT command automatically deselects any + currently selected mailbox before attempting the new selection. + Consequently, if a mailbox is selected and a SELECT command that + fails is attempted, no mailbox is selected. + + + + +Crispin Standards Track [Page 23] + +RFC 2060 IMAP4rev1 December 1996 + + + If the client is permitted to modify the mailbox, the server + SHOULD prefix the text of the tagged OK response with the + "[READ-WRITE]" response code. + + If the client is not permitted to modify the mailbox but is + permitted read access, the mailbox is selected as read-only, and + the server MUST prefix the text of the tagged OK response to + SELECT with the "[READ-ONLY]" response code. Read-only access + through SELECT differs from the EXAMINE command in that certain + read-only mailboxes MAY permit the change of permanent state on a + per-user (as opposed to global) basis. Netnews messages marked in + a server-based .newsrc file are an example of such per-user + permanent state that can be modified with read-only mailboxes. + + Example: C: A142 SELECT INBOX + S: * 172 EXISTS + S: * 1 RECENT + S: * OK [UNSEEN 12] Message 12 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited + S: A142 OK [READ-WRITE] SELECT completed + +6.3.2. EXAMINE Command + + Arguments: mailbox name + + Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT + OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS + + Result: OK - examine completed, now in selected state + NO - examine failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The EXAMINE command is identical to SELECT and returns the same + output; however, the selected mailbox is identified as read-only. + No changes to the permanent state of the mailbox, including + per-user state, are permitted. + + + + + + + + + + + + +Crispin Standards Track [Page 24] + +RFC 2060 IMAP4rev1 December 1996 + + + The text of the tagged OK response to the EXAMINE command MUST + begin with the "[READ-ONLY]" response code. + + Example: C: A932 EXAMINE blurdybloop + S: * 17 EXISTS + S: * 2 RECENT + S: * OK [UNSEEN 8] Message 8 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS ()] No permanent flags permitted + S: A932 OK [READ-ONLY] EXAMINE completed + +6.3.3. CREATE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - create completed + NO - create failure: can't create mailbox with that name + BAD - command unknown or arguments invalid + + The CREATE command creates a mailbox with the given name. An OK + response is returned only if a new mailbox with that name has been + created. It is an error to attempt to create INBOX or a mailbox + with a name that refers to an extant mailbox. Any error in + creation will return a tagged NO response. + + If the mailbox name is suffixed with the server's hierarchy + separator character (as returned from the server by a LIST + command), this is a declaration that the client intends to create + mailbox names under this name in the hierarchy. Server + implementations that do not require this declaration MUST ignore + it. + + If the server's hierarchy separator character appears elsewhere in + the name, the server SHOULD create any superior hierarchical names + that are needed for the CREATE command to complete successfully. + In other words, an attempt to create "foo/bar/zap" on a server in + which "/" is the hierarchy separator character SHOULD create foo/ + and foo/bar/ if they do not already exist. + + If a new mailbox is created with the same name as a mailbox which + was deleted, its unique identifiers MUST be greater than any + unique identifiers used in the previous incarnation of the mailbox + UNLESS the new incarnation has a different unique identifier + validity value. See the description of the UID command for more + detail. + + + +Crispin Standards Track [Page 25] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A003 CREATE owatagusiam/ + S: A003 OK CREATE completed + C: A004 CREATE owatagusiam/blurdybloop + S: A004 OK CREATE completed + + Note: the interpretation of this example depends on whether "/" + was returned as the hierarchy separator from LIST. If "/" is the + hierarchy separator, a new level of hierarchy named "owatagusiam" + with a member called "blurdybloop" is created. Otherwise, two + mailboxes at the same hierarchy level are created. + +6.3.4. DELETE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - delete completed + NO - delete failure: can't delete mailbox with that name + BAD - command unknown or arguments invalid + + The DELETE command permanently removes the mailbox with the given + name. A tagged OK response is returned only if the mailbox has + been deleted. It is an error to attempt to delete INBOX or a + mailbox name that does not exist. + + The DELETE command MUST NOT remove inferior hierarchical names. + For example, if a mailbox "foo" has an inferior "foo.bar" + (assuming "." is the hierarchy delimiter character), removing + "foo" MUST NOT remove "foo.bar". It is an error to attempt to + delete a name that has inferior hierarchical names and also has + the \Noselect mailbox name attribute (see the description of the + LIST response for more details). + + It is permitted to delete a name that has inferior hierarchical + names and does not have the \Noselect mailbox name attribute. In + this case, all messages in that mailbox are removed, and the name + will acquire the \Noselect mailbox name attribute. + + The value of the highest-used unique identifier of the deleted + mailbox MUST be preserved so that a new mailbox created with the + same name will not reuse the identifiers of the former + incarnation, UNLESS the new incarnation has a different unique + identifier validity value. See the description of the UID command + for more detail. + + + + + + +Crispin Standards Track [Page 26] + +RFC 2060 IMAP4rev1 December 1996 + + + Examples: C: A682 LIST "" * + S: * LIST () "/" blurdybloop + S: * LIST (\Noselect) "/" foo + S: * LIST () "/" foo/bar + S: A682 OK LIST completed + C: A683 DELETE blurdybloop + S: A683 OK DELETE completed + C: A684 DELETE foo + S: A684 NO Name "foo" has inferior hierarchical names + C: A685 DELETE foo/bar + S: A685 OK DELETE Completed + C: A686 LIST "" * + S: * LIST (\Noselect) "/" foo + S: A686 OK LIST completed + C: A687 DELETE foo + S: A687 OK DELETE Completed + + + C: A82 LIST "" * + S: * LIST () "." blurdybloop + S: * LIST () "." foo + S: * LIST () "." foo.bar + S: A82 OK LIST completed + C: A83 DELETE blurdybloop + S: A83 OK DELETE completed + C: A84 DELETE foo + S: A84 OK DELETE Completed + C: A85 LIST "" * + S: * LIST () "." foo.bar + S: A85 OK LIST completed + C: A86 LIST "" % + S: * LIST (\Noselect) "." foo + S: A86 OK LIST completed + +6.3.5. RENAME Command + + Arguments: existing mailbox name + new mailbox name + + Responses: no specific responses for this command + + Result: OK - rename completed + NO - rename failure: can't rename mailbox with that name, + can't rename to mailbox with that name + BAD - command unknown or arguments invalid + + The RENAME command changes the name of a mailbox. A tagged OK + response is returned only if the mailbox has been renamed. It is + + + +Crispin Standards Track [Page 27] + +RFC 2060 IMAP4rev1 December 1996 + + + an error to attempt to rename from a mailbox name that does not + exist or to a mailbox name that already exists. Any error in + renaming will return a tagged NO response. + + If the name has inferior hierarchical names, then the inferior + hierarchical names MUST also be renamed. For example, a rename of + "foo" to "zap" will rename "foo/bar" (assuming "/" is the + hierarchy delimiter character) to "zap/bar". + + The value of the highest-used unique identifier of the old mailbox + name MUST be preserved so that a new mailbox created with the same + name will not reuse the identifiers of the former incarnation, + UNLESS the new incarnation has a different unique identifier + validity value. See the description of the UID command for more + detail. + + Renaming INBOX is permitted, and has special behavior. It moves + all messages in INBOX to a new mailbox with the given name, + leaving INBOX empty. If the server implementation supports + inferior hierarchical names of INBOX, these are unaffected by a + rename of INBOX. + + Examples: C: A682 LIST "" * + S: * LIST () "/" blurdybloop + S: * LIST (\Noselect) "/" foo + S: * LIST () "/" foo/bar + S: A682 OK LIST completed + C: A683 RENAME blurdybloop sarasoop + S: A683 OK RENAME completed + C: A684 RENAME foo zowie + S: A684 OK RENAME Completed + C: A685 LIST "" * + S: * LIST () "/" sarasoop + S: * LIST (\Noselect) "/" zowie + S: * LIST () "/" zowie/bar + S: A685 OK LIST completed + + + + + + + + + + + + + + + +Crispin Standards Track [Page 28] + +RFC 2060 IMAP4rev1 December 1996 + + + C: Z432 LIST "" * + S: * LIST () "." INBOX + S: * LIST () "." INBOX.bar + S: Z432 OK LIST completed + C: Z433 RENAME INBOX old-mail + S: Z433 OK RENAME completed + C: Z434 LIST "" * + S: * LIST () "." INBOX + S: * LIST () "." INBOX.bar + S: * LIST () "." old-mail + S: Z434 OK LIST completed + +6.3.6. SUBSCRIBE Command + + Arguments: mailbox + + Responses: no specific responses for this command + + Result: OK - subscribe completed + NO - subscribe failure: can't subscribe to that name + BAD - command unknown or arguments invalid + + The SUBSCRIBE command adds the specified mailbox name to the + server's set of "active" or "subscribed" mailboxes as returned by + the LSUB command. This command returns a tagged OK response only + if the subscription is successful. + + A server MAY validate the mailbox argument to SUBSCRIBE to verify + that it exists. However, it MUST NOT unilaterally remove an + existing mailbox name from the subscription list even if a mailbox + by that name no longer exists. + + Note: this requirement is because some server sites may routinely + remove a mailbox with a well-known name (e.g. "system-alerts") + after its contents expire, with the intention of recreating it + when new contents are appropriate. + + Example: C: A002 SUBSCRIBE #news.comp.mail.mime + S: A002 OK SUBSCRIBE completed + + + + + + + + + + + + +Crispin Standards Track [Page 29] + +RFC 2060 IMAP4rev1 December 1996 + + +6.3.7. UNSUBSCRIBE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - unsubscribe completed + NO - unsubscribe failure: can't unsubscribe that name + BAD - command unknown or arguments invalid + + The UNSUBSCRIBE command removes the specified mailbox name from + the server's set of "active" or "subscribed" mailboxes as returned + by the LSUB command. This command returns a tagged OK response + only if the unsubscription is successful. + + Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime + S: A002 OK UNSUBSCRIBE completed + +6.3..8. LIST Command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LIST + + Result: OK - list completed + NO - list failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LIST command returns a subset of names from the complete set + of all names available to the client. Zero or more untagged LIST + replies are returned, containing the name attributes, hierarchy + delimiter, and name; see the description of the LIST reply for + more detail. + + The LIST command SHOULD return its data quickly, without undue + delay. For example, it SHOULD NOT go to excess trouble to + calculate \Marked or \Unmarked status or perform other processing; + if each name requires 1 second of processing, then a list of 1200 + names would take 20 minutes! + + An empty ("" string) reference name argument indicates that the + mailbox name is interpreted as by SELECT. The returned mailbox + names MUST match the supplied mailbox name pattern. A non-empty + reference name argument is the name of a mailbox or a level of + mailbox hierarchy, and indicates a context in which the mailbox + name is interpreted in an implementation-defined manner. + + + + +Crispin Standards Track [Page 30] + +RFC 2060 IMAP4rev1 December 1996 + + + An empty ("" string) mailbox name argument is a special request to + return the hierarchy delimiter and the root name of the name given + in the reference. The value returned as the root MAY be null if + the reference is non-rooted or is null. In all cases, the + hierarchy delimiter is returned. This permits a client to get the + hierarchy delimiter even when no mailboxes by that name currently + exist. + + The reference and mailbox name arguments are interpreted, in an + implementation-dependent fashion, into a canonical form that + represents an unambiguous left-to-right hierarchy. The returned + mailbox names will be in the interpreted form. + + Any part of the reference argument that is included in the + interpreted form SHOULD prefix the interpreted form. It SHOULD + also be in the same form as the reference name argument. This + rule permits the client to determine if the returned mailbox name + is in the context of the reference argument, or if something about + the mailbox argument overrode the reference argument. Without + this rule, the client would have to have knowledge of the server's + naming semantics including what characters are "breakouts" that + override a naming context. + + For example, here are some examples of how references and mailbox + names might be interpreted on a UNIX-based server: + + Reference Mailbox Name Interpretation + ------------ ------------ -------------- + ~smith/Mail/ foo.* ~smith/Mail/foo.* + archive/ % archive/% + #news. comp.mail.* #news.comp.mail.* + ~smith/Mail/ /usr/doc/foo /usr/doc/foo + archive/ ~fred/Mail/* ~fred/Mail/* + + The first three examples demonstrate interpretations in the + context of the reference argument. Note that "~smith/Mail" SHOULD + NOT be transformed into something like "/u2/users/smith/Mail", or + it would be impossible for the client to determine that the + interpretation was in the context of the reference. + + The character "*" is a wildcard, and matches zero or more + characters at this position. The character "%" is similar to "*", + but it does not match a hierarchy delimiter. If the "%" wildcard + is the last character of a mailbox name argument, matching levels + of hierarchy are also returned. If these levels of hierarchy are + not also selectable mailboxes, they are returned with the + \Noselect mailbox name attribute (see the description of the LIST + response for more details). + + + +Crispin Standards Track [Page 31] + +RFC 2060 IMAP4rev1 December 1996 + + + Server implementations are permitted to "hide" otherwise + accessible mailboxes from the wildcard characters, by preventing + certain characters or names from matching a wildcard in certain + situations. For example, a UNIX-based server might restrict the + interpretation of "*" so that an initial "/" character does not + match. + + The special name INBOX is included in the output from LIST, if + INBOX is supported by this server for this user and if the + uppercase string "INBOX" matches the interpreted reference and + mailbox name arguments with wildcards as described above. The + criteria for omitting INBOX is whether SELECT INBOX will return + failure; it is not relevant whether the user's real INBOX resides + on this or some other server. + + Example: C: A101 LIST "" "" + S: * LIST (\Noselect) "/" "" + S: A101 OK LIST Completed + C: A102 LIST #news.comp.mail.misc "" + S: * LIST (\Noselect) "." #news. + S: A102 OK LIST Completed + C: A103 LIST /usr/staff/jones "" + S: * LIST (\Noselect) "/" / + S: A103 OK LIST Completed + C: A202 LIST ~/Mail/ % + S: * LIST (\Noselect) "/" ~/Mail/foo + S: * LIST () "/" ~/Mail/meetings + S: A202 OK LIST completed + +6.3.9. LSUB Command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LSUB + + Result: OK - lsub completed + NO - lsub failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LSUB command returns a subset of names from the set of names + that the user has declared as being "active" or "subscribed". + Zero or more untagged LSUB replies are returned. The arguments to + LSUB are in the same form as those for LIST. + + A server MAY validate the subscribed names to see if they still + exist. If a name does not exist, it SHOULD be flagged with the + \Noselect attribute in the LSUB response. The server MUST NOT + + + +Crispin Standards Track [Page 32] + +RFC 2060 IMAP4rev1 December 1996 + + + unilaterally remove an existing mailbox name from the subscription + list even if a mailbox by that name no longer exists. + + Example: C: A002 LSUB "#news." "comp.mail.*" + S: * LSUB () "." #news.comp.mail.mime + S: * LSUB () "." #news.comp.mail.misc + S: A002 OK LSUB completed + +6.3.10. STATUS Command + + Arguments: mailbox name + status data item names + + Responses: untagged responses: STATUS + + Result: OK - status completed + NO - status failure: no status for that name + BAD - command unknown or arguments invalid + + The STATUS command requests the status of the indicated mailbox. + It does not change the currently selected mailbox, nor does it + affect the state of any messages in the queried mailbox (in + particular, STATUS MUST NOT cause messages to lose the \Recent + flag). + + The STATUS command provides an alternative to opening a second + IMAP4rev1 connection and doing an EXAMINE command on a mailbox to + query that mailbox's status without deselecting the current + mailbox in the first IMAP4rev1 connection. + + Unlike the LIST command, the STATUS command is not guaranteed to + be fast in its response. In some implementations, the server is + obliged to open the mailbox read-only internally to obtain certain + status information. Also unlike the LIST command, the STATUS + command does not accept wildcards. + + The currently defined status data items that can be requested are: + + MESSAGES The number of messages in the mailbox. + + RECENT The number of messages with the \Recent flag set. + + UIDNEXT The next UID value that will be assigned to a new + message in the mailbox. It is guaranteed that this + value will not change unless new messages are added + to the mailbox; and that it will change when new + messages are added even if those new messages are + subsequently expunged. + + + +Crispin Standards Track [Page 33] + +RFC 2060 IMAP4rev1 December 1996 + + + UIDVALIDITY The unique identifier validity value of the + mailbox. + + UNSEEN The number of messages which do not have the \Seen + flag set. + + + Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) + S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) + S: A042 OK STATUS completed + +6.3.11. APPEND Command + + Arguments: mailbox name + OPTIONAL flag parenthesized list + OPTIONAL date/time string + message literal + + Responses: no specific responses for this command + + Result: OK - append completed + NO - append error: can't append to that mailbox, error + in flags or date/time or message text + BAD - command unknown or arguments invalid + + The APPEND command appends the literal argument as a new message + to the end of the specified destination mailbox. This argument + SHOULD be in the format of an [RFC-822] message. 8-bit characters + are permitted in the message. A server implementation that is + unable to preserve 8-bit data properly MUST be able to reversibly + convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content + transfer encoding. + + Note: There MAY be exceptions, e.g. draft messages, in which + required [RFC-822] header lines are omitted in the message literal + argument to APPEND. The full implications of doing so MUST be + understood and carefully weighed. + + If a flag parenthesized list is specified, the flags SHOULD be set in + the resulting message; otherwise, the flag list of the resulting + message is set empty by default. + + If a date_time is specified, the internal date SHOULD be set in the + resulting message; otherwise, the internal date of the resulting + message is set to the current date and time by default. + + + + + + +Crispin Standards Track [Page 34] + +RFC 2060 IMAP4rev1 December 1996 + + + If the append is unsuccessful for any reason, the mailbox MUST be + restored to its state before the APPEND attempt; no partial appending + is permitted. + + If the destination mailbox does not exist, a server MUST return an + error, and MUST NOT automatically create the mailbox. Unless it is + certain that the destination mailbox can not be created, the server + MUST send the response code "[TRYCREATE]" as the prefix of the text + of the tagged NO response. This gives a hint to the client that it + can attempt a CREATE command and retry the APPEND if the CREATE is + successful. + + If the mailbox is currently selected, the normal new mail actions + SHOULD occur. Specifically, the server SHOULD notify the client + immediately via an untagged EXISTS response. If the server does not + do so, the client MAY issue a NOOP command (or failing that, a CHECK + command) after one or more APPEND commands. + + Example: C: A003 APPEND saved-messages (\Seen) {310} + C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) + C: From: Fred Foobar + C: Subject: afternoon meeting + C: To: mooch@owatagu.siam.edu + C: Message-Id: + C: MIME-Version: 1.0 + C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + C: + C: Hello Joe, do you think we can meet at 3:30 tomorrow? + C: + S: A003 OK APPEND completed + + Note: the APPEND command is not used for message delivery, because + it does not provide a mechanism to transfer [SMTP] envelope + information. + +6.4. Client Commands - Selected State + + In selected state, commands that manipulate messages in a mailbox are + permitted. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + and the authenticated state commands (SELECT, EXAMINE, CREATE, + DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and + APPEND), the following commands are valid in the selected state: + CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID. + + + + + + +Crispin Standards Track [Page 35] + +RFC 2060 IMAP4rev1 December 1996 + + +6.4.1. CHECK Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - check completed + BAD - command unknown or arguments invalid + + The CHECK command requests a checkpoint of the currently selected + mailbox. A checkpoint refers to any implementation-dependent + housekeeping associated with the mailbox (e.g. resolving the + server's in-memory state of the mailbox with the state on its + disk) that is not normally executed as part of each command. A + checkpoint MAY take a non-instantaneous amount of real time to + complete. If a server implementation has no such housekeeping + considerations, CHECK is equivalent to NOOP. + + There is no guarantee that an EXISTS untagged response will happen + as a result of CHECK. NOOP, not CHECK, SHOULD be used for new + mail polling. + + Example: C: FXXZ CHECK + S: FXXZ OK CHECK Completed + +6.4.2. CLOSE Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - close completed, now in authenticated state + NO - close failure: no mailbox selected + BAD - command unknown or arguments invalid + + The CLOSE command permanently removes from the currently selected + mailbox all messages that have the \Deleted flag set, and returns + to authenticated state from selected state. No untagged EXPUNGE + responses are sent. + + No messages are removed, and no error is given, if the mailbox is + selected by an EXAMINE command or is otherwise selected read-only. + + Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT + command MAY be issued without previously issuing a CLOSE command. + The SELECT, EXAMINE, and LOGOUT commands implicitly close the + currently selected mailbox without doing an expunge. However, + when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT + + + +Crispin Standards Track [Page 36] + +RFC 2060 IMAP4rev1 December 1996 + + + sequence is considerably faster than an EXPUNGE-LOGOUT or + EXPUNGE-SELECT because no untagged EXPUNGE responses (which the + client would probably ignore) are sent. + + Example: C: A341 CLOSE + S: A341 OK CLOSE completed + +6.4.3. EXPUNGE Command + + Arguments: none + + Responses: untagged responses: EXPUNGE + + Result: OK - expunge completed + NO - expunge failure: can't expunge (e.g. permission + denied) + BAD - command unknown or arguments invalid + + The EXPUNGE command permanently removes from the currently + selected mailbox all messages that have the \Deleted flag set. + Before returning an OK to the client, an untagged EXPUNGE response + is sent for each message that is removed. + + Example: C: A202 EXPUNGE + S: * 3 EXPUNGE + S: * 3 EXPUNGE + S: * 5 EXPUNGE + S: * 8 EXPUNGE + S: A202 OK EXPUNGE completed + + Note: in this example, messages 3, 4, 7, and 11 had the + \Deleted flag set. See the description of the EXPUNGE + response for further explanation. + +6.4.4. SEARCH Command + + Arguments: OPTIONAL [CHARSET] specification + searching criteria (one or more) + + Responses: REQUIRED untagged response: SEARCH + + Result: OK - search completed + NO - search error: can't search that [CHARSET] or + criteria + BAD - command unknown or arguments invalid + + + + + + +Crispin Standards Track [Page 37] + +RFC 2060 IMAP4rev1 December 1996 + + + The SEARCH command searches the mailbox for messages that match + the given searching criteria. Searching criteria consist of one + or more search keys. The untagged SEARCH response from the server + contains a listing of message sequence numbers corresponding to + those messages that match the searching criteria. + + When multiple keys are specified, the result is the intersection + (AND function) of all the messages that match those keys. For + example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers + to all deleted messages from Smith that were placed in the mailbox + since February 1, 1994. A search key can also be a parenthesized + list of one or more search keys (e.g. for use with the OR and NOT + keys). + + Server implementations MAY exclude [MIME-IMB] body parts with + terminal content media types other than TEXT and MESSAGE from + consideration in SEARCH matching. + + The OPTIONAL [CHARSET] specification consists of the word + "CHARSET" followed by a registered [CHARSET]. It indicates the + [CHARSET] of the strings that appear in the search criteria. + [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in + [RFC-822]/[MIME-IMB] headers, MUST be decoded before comparing + text in a [CHARSET] other than US-ASCII. US-ASCII MUST be + supported; other [CHARSET]s MAY be supported. If the server does + not support the specified [CHARSET], it MUST return a tagged NO + response (not a BAD). + + In all search keys that use strings, a message matches the key if + the string is a substring of the field. The matching is case- + insensitive. + + The defined search keys are as follows. Refer to the Formal + Syntax section for the precise syntactic definitions of the + arguments. + + Messages with message sequence numbers + corresponding to the specified message sequence + number set + + ALL All messages in the mailbox; the default initial + key for ANDing. + + ANSWERED Messages with the \Answered flag set. + + BCC Messages that contain the specified string in the + envelope structure's BCC field. + + + + +Crispin Standards Track [Page 38] + +RFC 2060 IMAP4rev1 December 1996 + + + BEFORE Messages whose internal date is earlier than the + specified date. + + BODY Messages that contain the specified string in the + body of the message. + + CC Messages that contain the specified string in the + envelope structure's CC field. + + DELETED Messages with the \Deleted flag set. + + DRAFT Messages with the \Draft flag set. + + FLAGGED Messages with the \Flagged flag set. + + FROM Messages that contain the specified string in the + envelope structure's FROM field. + + HEADER + Messages that have a header with the specified + field-name (as defined in [RFC-822]) and that + contains the specified string in the [RFC-822] + field-body. + + KEYWORD Messages with the specified keyword set. + + LARGER Messages with an [RFC-822] size larger than the + specified number of octets. + + NEW Messages that have the \Recent flag set but not the + \Seen flag. This is functionally equivalent to + "(RECENT UNSEEN)". + + NOT + Messages that do not match the specified search + key. + + OLD Messages that do not have the \Recent flag set. + This is functionally equivalent to "NOT RECENT" (as + opposed to "NOT NEW"). + + ON Messages whose internal date is within the + specified date. + + OR + Messages that match either search key. + + RECENT Messages that have the \Recent flag set. + + + +Crispin Standards Track [Page 39] + +RFC 2060 IMAP4rev1 December 1996 + + + SEEN Messages that have the \Seen flag set. + + SENTBEFORE + Messages whose [RFC-822] Date: header is earlier + than the specified date. + + SENTON Messages whose [RFC-822] Date: header is within the + specified date. + + SENTSINCE + Messages whose [RFC-822] Date: header is within or + later than the specified date. + + SINCE Messages whose internal date is within or later + than the specified date. + + SMALLER Messages with an [RFC-822] size smaller than the + specified number of octets. + + SUBJECT + Messages that contain the specified string in the + envelope structure's SUBJECT field. + + TEXT Messages that contain the specified string in the + header or body of the message. + + TO Messages that contain the specified string in the + envelope structure's TO field. + + UID + Messages with unique identifiers corresponding to + the specified unique identifier set. + + UNANSWERED Messages that do not have the \Answered flag set. + + UNDELETED Messages that do not have the \Deleted flag set. + + UNDRAFT Messages that do not have the \Draft flag set. + + UNFLAGGED Messages that do not have the \Flagged flag set. + + UNKEYWORD + Messages that do not have the specified keyword + set. + + UNSEEN Messages that do not have the \Seen flag set. + + + + + +Crispin Standards Track [Page 40] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" + S: * SEARCH 2 84 882 + S: A282 OK SEARCH completed + +6.4.5. FETCH Command + + Arguments: message set + message data item names + + Responses: untagged responses: FETCH + + Result: OK - fetch completed + NO - fetch error: can't fetch that data + BAD - command unknown or arguments invalid + + The FETCH command retrieves data associated with a message in the + mailbox. The data items to be fetched can be either a single atom + or a parenthesized list. + + The currently defined data items that can be fetched are: + + ALL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE) + + BODY Non-extensible form of BODYSTRUCTURE. + + BODY[
]<> + The text of a particular body section. The section + specification is a set of zero or more part + specifiers delimited by periods. A part specifier + is either a part number or one of the following: + HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and + TEXT. An empty section specification refers to the + entire message, including the header. + + Every message has at least one part number. + Non-[MIME-IMB] messages, and non-multipart + [MIME-IMB] messages with no encapsulated message, + only have a part 1. + + Multipart messages are assigned consecutive part + numbers, as they occur in the message. If a + particular part is of type message or multipart, + its parts MUST be indicated by a period followed by + the part number within that nested multipart part. + + + + + + +Crispin Standards Track [Page 41] + +RFC 2060 IMAP4rev1 December 1996 + + + A part of type MESSAGE/RFC822 also has nested part + numbers, referring to parts of the MESSAGE part's + body. + + The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and + TEXT part specifiers can be the sole part specifier + or can be prefixed by one or more numeric part + specifiers, provided that the numeric part + specifier refers to a part of type MESSAGE/RFC822. + The MIME part specifier MUST be prefixed by one or + more numeric part specifiers. + + The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT + part specifiers refer to the [RFC-822] header of + the message or of an encapsulated [MIME-IMT] + MESSAGE/RFC822 message. HEADER.FIELDS and + HEADER.FIELDS.NOT are followed by a list of + field-name (as defined in [RFC-822]) names, and + return a subset of the header. The subset returned + by HEADER.FIELDS contains only those header fields + with a field-name that matches one of the names in + the list; similarly, the subset returned by + HEADER.FIELDS.NOT contains only the header fields + with a non-matching field-name. The field-matching + is case-insensitive but otherwise exact. In all + cases, the delimiting blank line between the header + and the body is always included. + + The MIME part specifier refers to the [MIME-IMB] + header for this part. + + The TEXT part specifier refers to the text body of + the message, omitting the [RFC-822] header. + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 42] + +RFC 2060 IMAP4rev1 December 1996 + + + Here is an example of a complex message + with some of its part specifiers: + + HEADER ([RFC-822] header of the message) + TEXT MULTIPART/MIXED + 1 TEXT/PLAIN + 2 APPLICATION/OCTET-STREAM + 3 MESSAGE/RFC822 + 3.HEADER ([RFC-822] header of the message) + 3.TEXT ([RFC-822] text body of the message) + 3.1 TEXT/PLAIN + 3.2 APPLICATION/OCTET-STREAM + 4 MULTIPART/MIXED + 4.1 IMAGE/GIF + 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) + 4.2 MESSAGE/RFC822 + 4.2.HEADER ([RFC-822] header of the message) + 4.2.TEXT ([RFC-822] text body of the message) + 4.2.1 TEXT/PLAIN + 4.2.2 MULTIPART/ALTERNATIVE + 4.2.2.1 TEXT/PLAIN + 4.2.2.2 TEXT/RICHTEXT + + + It is possible to fetch a substring of the + designated text. This is done by appending an open + angle bracket ("<"), the octet position of the + first desired octet, a period, the maximum number + of octets desired, and a close angle bracket (">") + to the part specifier. If the starting octet is + beyond the end of the text, an empty string is + returned. + + Any partial fetch that attempts to read beyond the + end of the text is truncated as appropriate. A + partial fetch that starts at octet 0 is returned as + a partial fetch, even if this truncation happened. + + Note: this means that BODY[]<0.2048> of a + 1500-octet message will return BODY[]<0> + with a literal of size 1500, not BODY[]. + + Note: a substring fetch of a + HEADER.FIELDS or HEADER.FIELDS.NOT part + specifier is calculated after subsetting + the header. + + + + + +Crispin Standards Track [Page 43] + +RFC 2060 IMAP4rev1 December 1996 + + + The \Seen flag is implicitly set; if this causes + the flags to change they SHOULD be included as part + of the FETCH responses. + + BODY.PEEK[
]<> + An alternate form of BODY[
] that does not + implicitly set the \Seen flag. + + BODYSTRUCTURE The [MIME-IMB] body structure of the message. This + is computed by the server by parsing the [MIME-IMB] + header fields in the [RFC-822] header and + [MIME-IMB] headers. + + ENVELOPE The envelope structure of the message. This is + computed by the server by parsing the [RFC-822] + header into the component parts, defaulting various + fields as necessary. + + FAST Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE) + + FLAGS The flags that are set for this message. + + FULL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE BODY) + + INTERNALDATE The internal date of the message. + + RFC822 Functionally equivalent to BODY[], differing in the + syntax of the resulting untagged FETCH data (RFC822 + is returned). + + RFC822.HEADER Functionally equivalent to BODY.PEEK[HEADER], + differing in the syntax of the resulting untagged + FETCH data (RFC822.HEADER is returned). + + RFC822.SIZE The [RFC-822] size of the message. + + RFC822.TEXT Functionally equivalent to BODY[TEXT], differing in + the syntax of the resulting untagged FETCH data + (RFC822.TEXT is returned). + + UID The unique identifier for the message. + + + + + + + + +Crispin Standards Track [Page 44] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) + S: * 2 FETCH .... + S: * 3 FETCH .... + S: * 4 FETCH .... + S: A654 OK FETCH completed + +6.4.6. STORE Command + + Arguments: message set + message data item name + value for message data item + + Responses: untagged responses: FETCH + + Result: OK - store completed + NO - store error: can't store that data + BAD - command unknown or arguments invalid + + The STORE command alters data associated with a message in the + mailbox. Normally, STORE will return the updated value of the + data with an untagged FETCH response. A suffix of ".SILENT" in + the data item name prevents the untagged FETCH, and the server + SHOULD assume that the client has determined the updated value + itself or does not care about the updated value. + + Note: regardless of whether or not the ".SILENT" suffix was + used, the server SHOULD send an untagged FETCH response if a + change to a message's flags from an external source is + observed. The intent is that the status of the flags is + determinate without a race condition. + + The currently defined data items that can be stored are: + + FLAGS + Replace the flags for the message with the + argument. The new value of the flags are returned + as if a FETCH of those flags was done. + + FLAGS.SILENT + Equivalent to FLAGS, but without returning a new + value. + + +FLAGS + Add the argument to the flags for the message. The + new value of the flags are returned as if a FETCH + of those flags was done. + + + + + +Crispin Standards Track [Page 45] + +RFC 2060 IMAP4rev1 December 1996 + + + +FLAGS.SILENT + Equivalent to +FLAGS, but without returning a new + value. + + -FLAGS + Remove the argument from the flags for the message. + The new value of the flags are returned as if a + FETCH of those flags was done. + + -FLAGS.SILENT + Equivalent to -FLAGS, but without returning a new + value. + + Example: C: A003 STORE 2:4 +FLAGS (\Deleted) + S: * 2 FETCH FLAGS (\Deleted \Seen) + S: * 3 FETCH FLAGS (\Deleted) + S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) + S: A003 OK STORE completed + +6.4.7. COPY Command + + Arguments: message set + mailbox name + + Responses: no specific responses for this command + + Result: OK - copy completed + NO - copy error: can't copy those messages or to that + name + BAD - command unknown or arguments invalid + + The COPY command copies the specified message(s) to the end of the + specified destination mailbox. The flags and internal date of the + message(s) SHOULD be preserved in the copy. + + If the destination mailbox does not exist, a server SHOULD return + an error. It SHOULD NOT automatically create the mailbox. Unless + it is certain that the destination mailbox can not be created, the + server MUST send the response code "[TRYCREATE]" as the prefix of + the text of the tagged NO response. This gives a hint to the + client that it can attempt a CREATE command and retry the COPY if + the CREATE is successful. + + + + + + + + + +Crispin Standards Track [Page 46] + +RFC 2060 IMAP4rev1 December 1996 + + + If the COPY command is unsuccessful for any reason, server + implementations MUST restore the destination mailbox to its state + before the COPY attempt. + + Example: C: A003 COPY 2:4 MEETING + S: A003 OK COPY completed + +6.4.8. UID Command + + Arguments: command name + command arguments + + Responses: untagged responses: FETCH, SEARCH + + Result: OK - UID command completed + NO - UID command error + BAD - command unknown or arguments invalid + + The UID command has two forms. In the first form, it takes as its + arguments a COPY, FETCH, or STORE command with arguments + appropriate for the associated command. However, the numbers in + the message set argument are unique identifiers instead of message + sequence numbers. + + In the second form, the UID command takes a SEARCH command with + SEARCH command arguments. The interpretation of the arguments is + the same as with SEARCH; however, the numbers returned in a SEARCH + response for a UID SEARCH command are unique identifiers instead + of message sequence numbers. For example, the command UID SEARCH + 1:100 UID 443:557 returns the unique identifiers corresponding to + the intersection of the message sequence number set 1:100 and the + UID set 443:557. + + Message set ranges are permitted; however, there is no guarantee + that unique identifiers be contiguous. A non-existent unique + identifier within a message set range is ignored without any error + message generated. + + The number after the "*" in an untagged FETCH response is always a + message sequence number, not a unique identifier, even for a UID + command response. However, server implementations MUST implicitly + include the UID message data item as part of any FETCH response + caused by a UID command, regardless of whether a UID was specified + as a message data item to the FETCH. + + + + + + + +Crispin Standards Track [Page 47] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A999 UID FETCH 4827313:4828442 FLAGS + S: * 23 FETCH (FLAGS (\Seen) UID 4827313) + S: * 24 FETCH (FLAGS (\Seen) UID 4827943) + S: * 25 FETCH (FLAGS (\Seen) UID 4828442) + S: A999 UID FETCH completed + +6.5. Client Commands - Experimental/Expansion + +6.5.1. X Command + + Arguments: implementation defined + + Responses: implementation defined + + Result: OK - command completed + NO - failure + BAD - command unknown or arguments invalid + + Any command prefixed with an X is an experimental command. + Commands which are not part of this specification, a standard or + standards-track revision of this specification, or an IESG- + approved experimental protocol, MUST use the X prefix. + + Any added untagged responses issued by an experimental command + MUST also be prefixed with an X. Server implementations MUST NOT + send any such untagged responses, unless the client requested it + by issuing the associated experimental command. + + Example: C: a441 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN + S: a441 OK CAPABILITY completed + C: A442 XPIG-LATIN + S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay + S: A442 OK XPIG-LATIN ompleted-cay + +7. Server Responses + + Server responses are in three forms: status responses, server data, + and command continuation request. The information contained in a + server response, identified by "Contents:" in the response + descriptions below, is described by function, not by syntax. The + precise syntax of server responses is described in the Formal Syntax + section. + + The client MUST be prepared to accept any response at all times. + + + + + + +Crispin Standards Track [Page 48] + +RFC 2060 IMAP4rev1 December 1996 + + + Status responses can be tagged or untagged. Tagged status responses + indicate the completion result (OK, NO, or BAD status) of a client + command, and have a tag matching the command. + + Some status responses, and all server data, are untagged. An + untagged response is indicated by the token "*" instead of a tag. + Untagged status responses indicate server greeting, or server status + that does not indicate the completion of a command (for example, an + impending system shutdown alert). For historical reasons, untagged + server data responses are also called "unsolicited data", although + strictly speaking only unilateral server data is truly "unsolicited". + + Certain server data MUST be recorded by the client when it is + received; this is noted in the description of that data. Such data + conveys critical information which affects the interpretation of all + subsequent commands and responses (e.g. updates reflecting the + creation or destruction of messages). + + Other server data SHOULD be recorded for later reference; if the + client does not need to record the data, or if recording the data has + no obvious purpose (e.g. a SEARCH response when no SEARCH command is + in progress), the data SHOULD be ignored. + + An example of unilateral untagged server data occurs when the IMAP + connection is in selected state. In selected state, the server + checks the mailbox for new messages as part of command execution. + Normally, this is part of the execution of every command; hence, a + NOOP command suffices to check for new messages. If new messages are + found, the server sends untagged EXISTS and RECENT responses + reflecting the new size of the mailbox. Server implementations that + offer multiple simultaneous access to the same mailbox SHOULD also + send appropriate unilateral untagged FETCH and EXPUNGE responses if + another agent changes the state of any message flags or expunges any + messages. + + Command continuation request responses use the token "+" instead of a + tag. These responses are sent by the server to indicate acceptance + of an incomplete client command and readiness for the remainder of + the command. + +7.1. Server Responses - Status Responses + + Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD + may be tagged or untagged. PREAUTH and BYE are always untagged. + + Status responses MAY include an OPTIONAL "response code". A response + code consists of data inside square brackets in the form of an atom, + possibly followed by a space and arguments. The response code + + + +Crispin Standards Track [Page 49] + +RFC 2060 IMAP4rev1 December 1996 + + + contains additional information or status codes for client software + beyond the OK/NO/BAD condition, and are defined when there is a + specific action that a client can take based upon the additional + information. + + The currently defined response codes are: + + ALERT The human-readable text contains a special alert + that MUST be presented to the user in a fashion + that calls the user's attention to the message. + + NEWNAME Followed by a mailbox name and a new mailbox name. + A SELECT or EXAMINE is failing because the target + mailbox name no longer exists because it was + renamed to the new mailbox name. This is a hint to + the client that the operation can succeed if the + SELECT or EXAMINE is reissued with the new mailbox + name. + + PARSE The human-readable text represents an error in + parsing the [RFC-822] header or [MIME-IMB] headers + of a message in the mailbox. + + PERMANENTFLAGS Followed by a parenthesized list of flags, + indicates which of the known flags that the client + can change permanently. Any flags that are in the + FLAGS untagged response, but not the PERMANENTFLAGS + list, can not be set permanently. If the client + attempts to STORE a flag that is not in the + PERMANENTFLAGS list, the server will either reject + it with a NO reply or store the state for the + remainder of the current session only. The + PERMANENTFLAGS list can also include the special + flag \*, which indicates that it is possible to + create new keywords by attempting to store those + flags in the mailbox. + + READ-ONLY The mailbox is selected read-only, or its access + while selected has changed from read-write to + read-only. + + READ-WRITE The mailbox is selected read-write, or its access + while selected has changed from read-only to + read-write. + + + + + + + +Crispin Standards Track [Page 50] + +RFC 2060 IMAP4rev1 December 1996 + + + TRYCREATE An APPEND or COPY attempt is failing because the + target mailbox does not exist (as opposed to some + other reason). This is a hint to the client that + the operation can succeed if the mailbox is first + created by the CREATE command. + + UIDVALIDITY Followed by a decimal number, indicates the unique + identifier validity value. + + UNSEEN Followed by a decimal number, indicates the number + of the first message without the \Seen flag set. + + Additional response codes defined by particular client or server + implementations SHOULD be prefixed with an "X" until they are + added to a revision of this protocol. Client implementations + SHOULD ignore response codes that they do not recognize. + +7.1.1. OK Response + + Contents: OPTIONAL response code + human-readable text + + The OK response indicates an information message from the server. + When tagged, it indicates successful completion of the associated + command. The human-readable text MAY be presented to the user as + an information message. The untagged form indicates an + information-only message; the nature of the information MAY be + indicated by a response code. + + The untagged form is also used as one of three possible greetings + at connection startup. It indicates that the connection is not + yet authenticated and that a LOGIN command is needed. + + Example: S: * OK IMAP4rev1 server ready + C: A001 LOGIN fred blurdybloop + S: * OK [ALERT] System shutdown in 10 minutes + S: A001 OK LOGIN Completed + +7.1.2. NO Response + + Contents: OPTIONAL response code + human-readable text + + The NO response indicates an operational error message from the + server. When tagged, it indicates unsuccessful completion of the + associated command. The untagged form indicates a warning; the + command can still complete successfully. The human-readable text + describes the condition. + + + +Crispin Standards Track [Page 51] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A222 COPY 1:2 owatagusiam + S: * NO Disk is 98% full, please delete unnecessary data + S: A222 OK COPY completed + C: A223 COPY 3:200 blurdybloop + S: * NO Disk is 98% full, please delete unnecessary data + S: * NO Disk is 99% full, please delete unnecessary data + S: A223 NO COPY failed: disk is full + +7.1.3. BAD Response + + Contents: OPTIONAL response code + human-readable text + + The BAD response indicates an error message from the server. When + tagged, it reports a protocol-level error in the client's command; + the tag indicates the command that caused the error. The untagged + form indicates a protocol-level error for which the associated + command can not be determined; it can also indicate an internal + server failure. The human-readable text describes the condition. + + Example: C: ...very long command line... + S: * BAD Command line too long + C: ...empty line... + S: * BAD Empty command line + C: A443 EXPUNGE + S: * BAD Disk crash, attempting salvage to a new disk! + S: * OK Salvage successful, no data lost + S: A443 OK Expunge completed + +7.1.4. PREAUTH Response + + Contents: OPTIONAL response code + human-readable text + + The PREAUTH response is always untagged, and is one of three + possible greetings at connection startup. It indicates that the + connection has already been authenticated by external means and + thus no LOGIN command is needed. + + Example: S: * PREAUTH IMAP4rev1 server logged in as Smith + +7.1.5. BYE Response + + Contents: OPTIONAL response code + human-readable text + + + + + + +Crispin Standards Track [Page 52] + +RFC 2060 IMAP4rev1 December 1996 + + + The BYE response is always untagged, and indicates that the server + is about to close the connection. The human-readable text MAY be + displayed to the user in a status report by the client. The BYE + response is sent under one of four conditions: + + 1) as part of a normal logout sequence. The server will close + the connection after sending the tagged OK response to the + LOGOUT command. + + 2) as a panic shutdown announcement. The server closes the + connection immediately. + + 3) as an announcement of an inactivity autologout. The server + closes the connection immediately. + + 4) as one of three possible greetings at connection startup, + indicating that the server is not willing to accept a + connection from this client. The server closes the + connection immediately. + + The difference between a BYE that occurs as part of a normal + LOGOUT sequence (the first case) and a BYE that occurs because of + a failure (the other three cases) is that the connection closes + immediately in the failure case. + + Example: S: * BYE Autologout; idle for too long + +7.2. Server Responses - Server and Mailbox Status + + These responses are always untagged. This is how server and mailbox + status data are transmitted from the server to the client. Many of + these responses typically result from a command with the same name. + +7.2.1. CAPABILITY Response + + Contents: capability listing + + The CAPABILITY response occurs as a result of a CAPABILITY + command. The capability listing contains a space-separated + listing of capability names that the server supports. The + capability listing MUST include the atom "IMAP4rev1". + + A capability name which begins with "AUTH=" indicates that the + server supports that particular authentication mechanism. + + + + + + + +Crispin Standards Track [Page 53] + +RFC 2060 IMAP4rev1 December 1996 + + + Other capability names indicate that the server supports an + extension, revision, or amendment to the IMAP4rev1 protocol. + Server responses MUST conform to this document until the client + issues a command that uses the associated capability. + + Capability names MUST either begin with "X" or be standard or + standards-track IMAP4rev1 extensions, revisions, or amendments + registered with IANA. A server MUST NOT offer unregistered or + non-standard capability names, unless such names are prefixed with + an "X". + + Client implementations SHOULD NOT require any capability name + other than "IMAP4rev1", and MUST ignore any unknown capability + names. + + Example: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN + +7.2.2. LIST Response + + Contents: name attributes + hierarchy delimiter + name + + The LIST response occurs as a result of a LIST command. It + returns a single name that matches the LIST specification. There + can be multiple LIST responses for a single LIST command. + + Four name attributes are defined: + + \Noinferiors It is not possible for any child levels of + hierarchy to exist under this name; no child levels + exist now and none can be created in the future. + + \Noselect It is not possible to use this name as a selectable + mailbox. + + \Marked The mailbox has been marked "interesting" by the + server; the mailbox probably contains messages that + have been added since the last time the mailbox was + selected. + + \Unmarked The mailbox does not contain any additional + messages since the last time the mailbox was + selected. + + If it is not feasible for the server to determine whether the + mailbox is "interesting" or not, or if the name is a \Noselect + name, the server SHOULD NOT send either \Marked or \Unmarked. + + + +Crispin Standards Track [Page 54] + +RFC 2060 IMAP4rev1 December 1996 + + + The hierarchy delimiter is a character used to delimit levels of + hierarchy in a mailbox name. A client can use it to create child + mailboxes, and to search higher or lower levels of naming + hierarchy. All children of a top-level hierarchy node MUST use + the same separator character. A NIL hierarchy delimiter means + that no hierarchy exists; the name is a "flat" name. + + The name represents an unambiguous left-to-right hierarchy, and + MUST be valid for use as a reference in LIST and LSUB commands. + Unless \Noselect is indicated, the name MUST also be valid as an + argument for commands, such as SELECT, that accept mailbox + names. + + Example: S: * LIST (\Noselect) "/" ~/Mail/foo + +7.2.3. LSUB Response + + Contents: name attributes + hierarchy delimiter + name + + The LSUB response occurs as a result of an LSUB command. It + returns a single name that matches the LSUB specification. There + can be multiple LSUB responses for a single LSUB command. The + data is identical in format to the LIST response. + + Example: S: * LSUB () "." #news.comp.mail.misc + +7.2.4 STATUS Response + + Contents: name + status parenthesized list + + The STATUS response occurs as a result of an STATUS command. It + returns the mailbox name that matches the STATUS specification and + the requested mailbox status information. + + Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) + +7.2.5. SEARCH Response + + Contents: zero or more numbers + + + + + + + + + +Crispin Standards Track [Page 55] + +RFC 2060 IMAP4rev1 December 1996 + + + The SEARCH response occurs as a result of a SEARCH or UID SEARCH + command. The number(s) refer to those messages that match the + search criteria. For SEARCH, these are message sequence numbers; + for UID SEARCH, these are unique identifiers. Each number is + delimited by a space. + + Example: S: * SEARCH 2 3 6 + +7.2.6. FLAGS Response + + Contents: flag parenthesized list + + The FLAGS response occurs as a result of a SELECT or EXAMINE + command. The flag parenthesized list identifies the flags (at a + minimum, the system-defined flags) that are applicable for this + mailbox. Flags other than the system flags can also exist, + depending on server implementation. + + The update from the FLAGS response MUST be recorded by the client. + + Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + +7.3. Server Responses - Mailbox Size + + These responses are always untagged. This is how changes in the size + of the mailbox are trasnmitted from the server to the client. + Immediately following the "*" token is a number that represents a + message count. + +7.3.1. EXISTS Response + + Contents: none + + The EXISTS response reports the number of messages in the mailbox. + This response occurs as a result of a SELECT or EXAMINE command, + and if the size of the mailbox changes (e.g. new mail). + + The update from the EXISTS response MUST be recorded by the + client. + + Example: S: * 23 EXISTS + + + + + + + + + + +Crispin Standards Track [Page 56] + +RFC 2060 IMAP4rev1 December 1996 + + +7.3.2. RECENT Response + + Contents: none + + The RECENT response reports the number of messages with the + \Recent flag set. This response occurs as a result of a SELECT or + EXAMINE command, and if the size of the mailbox changes (e.g. new + mail). + + Note: It is not guaranteed that the message sequence numbers of + recent messages will be a contiguous range of the highest n + messages in the mailbox (where n is the value reported by the + RECENT response). Examples of situations in which this is not + the case are: multiple clients having the same mailbox open + (the first session to be notified will see it as recent, others + will probably see it as non-recent), and when the mailbox is + re-ordered by a non-IMAP agent. + + The only reliable way to identify recent messages is to look at + message flags to see which have the \Recent flag set, or to do + a SEARCH RECENT. + + The update from the RECENT response MUST be recorded by the + client. + + Example: S: * 5 RECENT + +7.4. Server Responses - Message Status + + These responses are always untagged. This is how message data are + transmitted from the server to the client, often as a result of a + command with the same name. Immediately following the "*" token is a + number that represents a message sequence number. + +7.4.1. EXPUNGE Response + + Contents: none + + The EXPUNGE response reports that the specified message sequence + number has been permanently removed from the mailbox. The message + sequence number for each successive message in the mailbox is + immediately decremented by 1, and this decrement is reflected in + message sequence numbers in subsequent responses (including other + untagged EXPUNGE responses). + + As a result of the immediate decrement rule, message sequence + numbers that appear in a set of successive EXPUNGE responses + depend upon whether the messages are removed starting from lower + + + +Crispin Standards Track [Page 57] + +RFC 2060 IMAP4rev1 December 1996 + + + numbers to higher numbers, or from higher numbers to lower + numbers. For example, if the last 5 messages in a 9-message + mailbox are expunged; a "lower to higher" server will send five + untagged EXPUNGE responses for message sequence number 5, whereas + a "higher to lower server" will send successive untagged EXPUNGE + responses for message sequence numbers 9, 8, 7, 6, and 5. + + An EXPUNGE response MUST NOT be sent when no command is in + progress; nor while responding to a FETCH, STORE, or SEARCH + command. This rule is necessary to prevent a loss of + synchronization of message sequence numbers between client and + server. + + The update from the EXPUNGE response MUST be recorded by the + client. + + Example: S: * 44 EXPUNGE + +7.4.2. FETCH Response + + Contents: message data + + The FETCH response returns data about a message to the client. + The data are pairs of data item names and their values in + parentheses. This response occurs as the result of a FETCH or + STORE command, as well as by unilateral server decision (e.g. flag + updates). + + The current data items are: + + BODY A form of BODYSTRUCTURE without extension data. + + BODY[
]<> + A string expressing the body contents of the + specified section. The string SHOULD be + interpreted by the client according to the content + transfer encoding, body type, and subtype. + + If the origin octet is specified, this string is a + substring of the entire body contents, starting at + that origin octet. This means that BODY[]<0> MAY + be truncated, but BODY[] is NEVER truncated. + + 8-bit textual data is permitted if a [CHARSET] + identifier is part of the body parameter + parenthesized list for this section. Note that + headers (part specifiers HEADER or MIME, or the + header portion of a MESSAGE/RFC822 part), MUST be + + + +Crispin Standards Track [Page 58] + +RFC 2060 IMAP4rev1 December 1996 + + + 7-bit; 8-bit characters are not permitted in + headers. Note also that the blank line at the end + of the header is always included in header data. + + Non-textual data such as binary data MUST be + transfer encoded into a textual form such as BASE64 + prior to being sent to the client. To derive the + original binary data, the client MUST decode the + transfer encoded string. + + BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB] + body structure of a message. This is computed by + the server by parsing the [MIME-IMB] header fields, + defaulting various fields as necessary. + + For example, a simple text message of 48 lines and + 2279 octets can have a body structure of: ("TEXT" + "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 + 48) + + Multiple parts are indicated by parenthesis + nesting. Instead of a body type as the first + element of the parenthesized list there is a nested + body. The second element of the parenthesized list + is the multipart subtype (mixed, digest, parallel, + alternative, etc.). + + For example, a two part message consisting of a + text and a BASE645-encoded text attachment can have + a body structure of: (("TEXT" "PLAIN" ("CHARSET" + "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" + ("CHARSET" "US-ASCII" "NAME" "cc.diff") + "<960723163407.20117h@cac.washington.edu>" + "Compiler diff" "BASE64" 4554 73) "MIXED")) + + Extension data follows the multipart subtype. + Extension data is never returned with the BODY + fetch, but can be returned with a BODYSTRUCTURE + fetch. Extension data, if present, MUST be in the + defined order. + + The extension data of a multipart body part are in + the following order: + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. ("foo" "bar" "baz" "rag") where "bar" is + the value of "foo" and "rag" is the value of + + + +Crispin Standards Track [Page 59] + +RFC 2060 IMAP4rev1 December 1996 + + + "baz"] as defined in [MIME-IMB]. + + body disposition + A parenthesized list, consisting of a + disposition type string followed by a + parenthesized list of disposition + attribute/value pairs. The disposition type and + attribute names will be defined in a future + standards-track revision to [DISPOSITION]. + + body language + A string or parenthesized list giving the body + language value as defined in [LANGUAGE-TAGS]. + + Any following extension data are not yet defined in + this version of the protocol. Such extension data + can consist of zero or more NILs, strings, numbers, + or potentially nested parenthesized lists of such + data. Client implementations that do a + BODYSTRUCTURE fetch MUST be prepared to accept such + extension data. Server implementations MUST NOT + send such extension data until it has been defined + by a revision of this protocol. + + The basic fields of a non-multipart body part are + in the following order: + + body type + A string giving the content media type name as + defined in [MIME-IMB]. + + body subtype + A string giving the content subtype name as + defined in [MIME-IMB]. + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. ("foo" "bar" "baz" "rag") where "bar" is + the value of "foo" and "rag" is the value of + "baz"] as defined in [MIME-IMB]. + + body id + A string giving the content id as defined in + [MIME-IMB]. + + body description + A string giving the content description as + defined in [MIME-IMB]. + + + +Crispin Standards Track [Page 60] + +RFC 2060 IMAP4rev1 December 1996 + + + body encoding + A string giving the content transfer encoding as + defined in [MIME-IMB]. + + body size + A number giving the size of the body in octets. + Note that this size is the size in its transfer + encoding and not the resulting size after any + decoding. + + A body type of type MESSAGE and subtype RFC822 + contains, immediately after the basic fields, the + envelope structure, body structure, and size in + text lines of the encapsulated message. + + A body type of type TEXT contains, immediately + after the basic fields, the size of the body in + text lines. Note that this size is the size in its + content transfer encoding and not the resulting + size after any decoding. + + Extension data follows the basic fields and the + type-specific fields listed above. Extension data + is never returned with the BODY fetch, but can be + returned with a BODYSTRUCTURE fetch. Extension + data, if present, MUST be in the defined order. + + The extension data of a non-multipart body part are + in the following order: + + body MD5 + A string giving the body MD5 value as defined in + [MD5]. + + body disposition + A parenthesized list with the same content and + function as the body disposition for a multipart + body part. + + body language + A string or parenthesized list giving the body + language value as defined in [LANGUAGE-TAGS]. + + Any following extension data are not yet defined in + this version of the protocol, and would be as + described above under multipart extension data. + + + + + +Crispin Standards Track [Page 61] + +RFC 2060 IMAP4rev1 December 1996 + + + ENVELOPE A parenthesized list that describes the envelope + structure of a message. This is computed by the + server by parsing the [RFC-822] header into the + component parts, defaulting various fields as + necessary. + + The fields of the envelope structure are in the + following order: date, subject, from, sender, + reply-to, to, cc, bcc, in-reply-to, and message-id. + The date, subject, in-reply-to, and message-id + fields are strings. The from, sender, reply-to, + to, cc, and bcc fields are parenthesized lists of + address structures. + + An address structure is a parenthesized list that + describes an electronic mail address. The fields + of an address structure are in the following order: + personal name, [SMTP] at-domain-list (source + route), mailbox name, and host name. + + [RFC-822] group syntax is indicated by a special + form of address structure in which the host name + field is NIL. If the mailbox name field is also + NIL, this is an end of group marker (semi-colon in + RFC 822 syntax). If the mailbox name field is + non-NIL, this is a start of group marker, and the + mailbox name field holds the group name phrase. + + Any field of an envelope or address structure that + is not applicable is presented as NIL. Note that + the server MUST default the reply-to and sender + fields from the from field; a client is not + expected to know to do this. + + FLAGS A parenthesized list of flags that are set for this + message. + + INTERNALDATE A string representing the internal date of the + message. + + RFC822 Equivalent to BODY[]. + + RFC822.HEADER Equivalent to BODY.PEEK[HEADER]. + + RFC822.SIZE A number expressing the [RFC-822] size of the + message. + + RFC822.TEXT Equivalent to BODY[TEXT]. + + + +Crispin Standards Track [Page 62] + +RFC 2060 IMAP4rev1 December 1996 + + + UID A number expressing the unique identifier of the + message. + + + Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) + +7.5. Server Responses - Command Continuation Request + + The command continuation request response is indicated by a "+" token + instead of a tag. This form of response indicates that the server is + ready to accept the continuation of a command from the client. The + remainder of this response is a line of text. + + This response is used in the AUTHORIZATION command to transmit server + data to the client, and request additional client data. This + response is also used if an argument to any command is a literal. + + The client is not permitted to send the octets of the literal unless + the server indicates that it expects it. This permits the server to + process commands and reject errors on a line-by-line basis. The + remainder of the command, including the CRLF that terminates a + command, follows the octets of the literal. If there are any + additional command arguments the literal octets are followed by a + space and those arguments. + + Example: C: A001 LOGIN {11} + S: + Ready for additional command text + C: FRED FOOBAR {7} + S: + Ready for additional command text + C: fat man + S: A001 OK LOGIN completed + C: A044 BLURDYBLOOP {102856} + S: A044 BAD No such command as "BLURDYBLOOP" + +8. Sample IMAP4rev1 connection + + The following is a transcript of an IMAP4rev1 connection. A long + line in this sample is broken for editorial clarity. + +S: * OK IMAP4rev1 Service Ready +C: a001 login mrc secret +S: a001 OK LOGIN completed +C: a002 select inbox +S: * 18 EXISTS +S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) +S: * 2 RECENT +S: * OK [UNSEEN 17] Message 17 is the first unseen message +S: * OK [UIDVALIDITY 3857529045] UIDs valid + + + +Crispin Standards Track [Page 63] + +RFC 2060 IMAP4rev1 December 1996 + + +S: a002 OK [READ-WRITE] SELECT completed +C: a003 fetch 12 full +S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" + RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" + "IMAP4rev1 WG mtg summary and minutes" + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + ((NIL NIL "imap" "cac.washington.edu")) + ((NIL NIL "minutes" "CNRI.Reston.VA.US") + ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL + "") + BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) +S: a003 OK FETCH completed +C: a004 fetch 12 body[header] +S: * 12 FETCH (BODY[HEADER] {350} +S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) +S: From: Terry Gray +S: Subject: IMAP4rev1 WG mtg summary and minutes +S: To: imap@cac.washington.edu +S: cc: minutes@CNRI.Reston.VA.US, John Klensin +S: Message-Id: +S: MIME-Version: 1.0 +S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII +S: +S: ) +S: a004 OK FETCH completed +C: a005 store 12 +flags \deleted +S: * 12 FETCH (FLAGS (\Seen \Deleted)) +S: a005 OK +FLAGS completed +C: a006 logout +S: * BYE IMAP4rev1 server terminating connection +S: a006 OK LOGOUT completed + +9. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] with one exception; the + delimiter used with the "#" construct is a single space (SPACE) and + not one or more commas. + + In the case of alternative or optional rules in which a later rule + overlaps an earlier rule, the rule which is listed earlier MUST take + priority. For example, "\Seen" when parsed as a flag is the \Seen + flag name and not a flag_extension, even though "\Seen" could be + parsed as a flag_extension. Some, but not all, instances of this + rule are noted below. + + + + +Crispin Standards Track [Page 64] + +RFC 2060 IMAP4rev1 December 1996 + + + Except as noted otherwise, all alphabetic characters are case- + insensitive. The use of upper or lower case characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + +address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox + SPACE addr_host ")" + +addr_adl ::= nstring + ;; Holds route from [RFC-822] route-addr if + ;; non-NIL + +addr_host ::= nstring + ;; NIL indicates [RFC-822] group syntax. + ;; Otherwise, holds [RFC-822] domain name + +addr_mailbox ::= nstring + ;; NIL indicates end of [RFC-822] group; if + ;; non-NIL and addr_host is NIL, holds + ;; [RFC-822] group name. + ;; Otherwise, holds [RFC-822] local-part + +addr_name ::= nstring + ;; Holds phrase from [RFC-822] mailbox if + ;; non-NIL + +alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / + "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / + "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / + "Y" / "Z" / + "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / + "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / + "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / + "y" / "z" + ;; Case-sensitive + +append ::= "APPEND" SPACE mailbox [SPACE flag_list] + [SPACE date_time] SPACE literal + +astring ::= atom / string + +atom ::= 1*ATOM_CHAR + +ATOM_CHAR ::= + +atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards / + quoted_specials + + + + +Crispin Standards Track [Page 65] + +RFC 2060 IMAP4rev1 December 1996 + + +authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) + +auth_type ::= atom + ;; Defined by [IMAP-AUTH] + +base64 ::= *(4base64_char) [base64_terminal] + +base64_char ::= alpha / digit / "+" / "/" + +base64_terminal ::= (2base64_char "==") / (3base64_char "=") + +body ::= "(" body_type_1part / body_type_mpart ")" + +body_extension ::= nstring / number / "(" 1#body_extension ")" + ;; Future expansion. Client implementations + ;; MUST accept body_extension fields. Server + ;; implementations MUST NOT generate + ;; body_extension fields except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + +body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp + [SPACE body_fld_lang + [SPACE 1#body_extension]]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + +body_ext_mpart ::= body_fld_param + [SPACE body_fld_dsp SPACE body_fld_lang + [SPACE 1#body_extension]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + +body_fields ::= body_fld_param SPACE body_fld_id SPACE + body_fld_desc SPACE body_fld_enc SPACE + body_fld_octets + +body_fld_desc ::= nstring + +body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil + +body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ + "QUOTED-PRINTABLE") <">) / string + +body_fld_id ::= nstring + +body_fld_lang ::= nstring / "(" 1#string ")" + + + + +Crispin Standards Track [Page 66] + +RFC 2060 IMAP4rev1 December 1996 + + +body_fld_lines ::= number + +body_fld_md5 ::= nstring + +body_fld_octets ::= number + +body_fld_param ::= "(" 1#(string SPACE string) ")" / nil + +body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) + [SPACE body_ext_1part] + +body_type_basic ::= media_basic SPACE body_fields + ;; MESSAGE subtype MUST NOT be "RFC822" + +body_type_mpart ::= 1*body SPACE media_subtype + [SPACE body_ext_mpart] + +body_type_msg ::= media_message SPACE body_fields SPACE envelope + SPACE body SPACE body_fld_lines + +body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines + +capability ::= "AUTH=" auth_type / atom + ;; New capabilities MUST begin with "X" or be + ;; registered with IANA as standard or + ;; standards-track + +capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1" + [SPACE 1#capability] + ;; IMAP4rev1 servers which offer RFC 1730 + ;; compatibility MUST list "IMAP4" as the first + ;; capability. + +CHAR ::= + +CHAR8 ::= + +command ::= tag SPACE (command_any / command_auth / + command_nonauth / command_select) CRLF + ;; Modal based on state + +command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command + ;; Valid in all states + +command_auth ::= append / create / delete / examine / list / lsub / + rename / select / status / subscribe / unsubscribe + ;; Valid only in Authenticated or Selected state + + + +Crispin Standards Track [Page 67] + +RFC 2060 IMAP4rev1 December 1996 + + +command_nonauth ::= login / authenticate + ;; Valid only when in Non-Authenticated state + +command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / + copy / fetch / store / uid / search + ;; Valid only when in Selected state + +continue_req ::= "+" SPACE (resp_text / base64) + +copy ::= "COPY" SPACE set SPACE mailbox + +CR ::= + +create ::= "CREATE" SPACE mailbox + ;; Use of INBOX gives a NO error + +CRLF ::= CR LF + +CTL ::= + +date ::= date_text / <"> date_text <"> + +date_day ::= 1*2digit + ;; Day of month + +date_day_fixed ::= (SPACE digit) / 2digit + ;; Fixed-format version of date_day + +date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / + "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" + +date_text ::= date_day "-" date_month "-" date_year + +date_year ::= 4digit + +date_time ::= <"> date_day_fixed "-" date_month "-" date_year + SPACE time SPACE zone <"> + +delete ::= "DELETE" SPACE mailbox + ;; Use of INBOX gives a NO error + +digit ::= "0" / digit_nz + +digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / + "9" + + + + + +Crispin Standards Track [Page 68] + +RFC 2060 IMAP4rev1 December 1996 + + +envelope ::= "(" env_date SPACE env_subject SPACE env_from + SPACE env_sender SPACE env_reply_to SPACE env_to + SPACE env_cc SPACE env_bcc SPACE env_in_reply_to + SPACE env_message_id ")" + +env_bcc ::= "(" 1*address ")" / nil + +env_cc ::= "(" 1*address ")" / nil + +env_date ::= nstring + +env_from ::= "(" 1*address ")" / nil + +env_in_reply_to ::= nstring + +env_message_id ::= nstring + +env_reply_to ::= "(" 1*address ")" / nil + +env_sender ::= "(" 1*address ")" / nil + +env_subject ::= nstring + +env_to ::= "(" 1*address ")" / nil + +examine ::= "EXAMINE" SPACE mailbox + +fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / + "FAST" / fetch_att / "(" 1#fetch_att ")") + +fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] / + "BODY" ["STRUCTURE"] / "UID" / + "BODY" [".PEEK"] section + ["<" number "." nz_number ">"] + +flag ::= "\Answered" / "\Flagged" / "\Deleted" / + "\Seen" / "\Draft" / flag_keyword / flag_extension + +flag_extension ::= "\" atom + ;; Future expansion. Client implementations + ;; MUST accept flag_extension flags. Server + ;; implementations MUST NOT generate + ;; flag_extension flags except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + +flag_keyword ::= atom + + + +Crispin Standards Track [Page 69] + +RFC 2060 IMAP4rev1 December 1996 + + +flag_list ::= "(" #flag ")" + +greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF + +header_fld_name ::= astring + +header_list ::= "(" 1#header_fld_name ")" + +LF ::= + +list ::= "LIST" SPACE mailbox SPACE list_mailbox + +list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string + +list_wildcards ::= "%" / "*" + +literal ::= "{" number "}" CRLF *CHAR8 + ;; Number represents the number of CHAR8 octets + +login ::= "LOGIN" SPACE userid SPACE password + +lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox + +mailbox ::= "INBOX" / astring + ;; INBOX is case-insensitive. All case variants of + ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX + ;; not as an astring. Refer to section 5.1 for + ;; further semantic details of mailbox names. + +mailbox_data ::= "FLAGS" SPACE flag_list / + "LIST" SPACE mailbox_list / + "LSUB" SPACE mailbox_list / + "MAILBOX" SPACE text / + "SEARCH" [SPACE 1#nz_number] / + "STATUS" SPACE mailbox SPACE + "(" # QUOTED_CHAR <"> / nil) SPACE mailbox + +media_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / + "MESSAGE" / "VIDEO") <">) / string) + SPACE media_subtype + ;; Defined in [MIME-IMT] + +media_message ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> + + + +Crispin Standards Track [Page 70] + +RFC 2060 IMAP4rev1 December 1996 + + + ;; Defined in [MIME-IMT] + +media_subtype ::= string + ;; Defined in [MIME-IMT] + +media_text ::= <"> "TEXT" <"> SPACE media_subtype + ;; Defined in [MIME-IMT] + +message_data ::= nz_number SPACE ("EXPUNGE" / + ("FETCH" SPACE msg_att)) + +msg_att ::= "(" 1#("ENVELOPE" SPACE envelope / + "FLAGS" SPACE "(" #(flag / "\Recent") ")" / + "INTERNALDATE" SPACE date_time / + "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / + "RFC822.SIZE" SPACE number / + "BODY" ["STRUCTURE"] SPACE body / + "BODY" section ["<" number ">"] SPACE nstring / + "UID" SPACE uniqueid) ")" + +nil ::= "NIL" + +nstring ::= string / nil + +number ::= 1*digit + ;; Unsigned 32-bit integer + ;; (0 <= n < 4,294,967,296) + +nz_number ::= digit_nz *digit + ;; Non-zero unsigned 32-bit integer + ;; (0 < n < 4,294,967,296) + +password ::= astring + +quoted ::= <"> *QUOTED_CHAR <"> + +QUOTED_CHAR ::= / + "\" quoted_specials + +quoted_specials ::= <"> / "\" + +rename ::= "RENAME" SPACE mailbox SPACE mailbox + ;; Use of INBOX as a destination gives a NO error + +response ::= *(continue_req / response_data) response_done + +response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / + mailbox_data / message_data / capability_data) + + + +Crispin Standards Track [Page 71] + +RFC 2060 IMAP4rev1 December 1996 + + + CRLF + +response_done ::= response_tagged / response_fatal + +response_fatal ::= "*" SPACE resp_cond_bye CRLF + ;; Server closes connection immediately + +response_tagged ::= tag SPACE resp_cond_state CRLF + +resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text + ;; Authentication condition + +resp_cond_bye ::= "BYE" SPACE resp_text + +resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text + ;; Status condition + +resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) + ;; text SHOULD NOT begin with "[" or "=" + +resp_text_code ::= "ALERT" / "PARSE" / + "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / + "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / + "UIDVALIDITY" SPACE nz_number / + "UNSEEN" SPACE nz_number / + atom [SPACE 1*] + +search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] + 1#search_key + ;; [CHARSET] MUST be registered with IANA + +search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / + "BEFORE" SPACE date / "BODY" SPACE astring / + "CC" SPACE astring / "DELETED" / "FLAGGED" / + "FROM" SPACE astring / + "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / + "ON" SPACE date / "RECENT" / "SEEN" / + "SINCE" SPACE date / "SUBJECT" SPACE astring / + "TEXT" SPACE astring / "TO" SPACE astring / + "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / + "UNKEYWORD" SPACE flag_keyword / "UNSEEN" / + ;; Above this line were in [IMAP2] + "DRAFT" / + "HEADER" SPACE header_fld_name SPACE astring / + "LARGER" SPACE number / "NOT" SPACE search_key / + "OR" SPACE search_key SPACE search_key / + "SENTBEFORE" SPACE date / "SENTON" SPACE date / + "SENTSINCE" SPACE date / "SMALLER" SPACE number / + + + +Crispin Standards Track [Page 72] + +RFC 2060 IMAP4rev1 December 1996 + + + "UID" SPACE set / "UNDRAFT" / set / + "(" 1#search_key ")" + +section ::= "[" [section_text / (nz_number *["." nz_number] + ["." (section_text / "MIME")])] "]" + +section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"] + SPACE header_list / "TEXT" + +select ::= "SELECT" SPACE mailbox + +sequence_num ::= nz_number / "*" + ;; * is the largest number in use. For message + ;; sequence numbers, it is the number of messages + ;; in the mailbox. For unique identifiers, it is + ;; the unique identifier of the last message in + ;; the mailbox. + +set ::= sequence_num / (sequence_num ":" sequence_num) / + (set "," set) + ;; Identifies a set of messages. For message + ;; sequence numbers, these are consecutive + ;; numbers from 1 to the number of messages in + ;; the mailbox + ;; Comma delimits individual numbers, colon + ;; delimits between two numbers inclusive. + ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, + ;; 14,15 for a mailbox with 15 messages. + +SPACE ::= + +status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")" + +status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / + "UNSEEN" + +store ::= "STORE" SPACE set SPACE store_att_flags + +store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE + (flag_list / #flag) + +string ::= quoted / literal + +subscribe ::= "SUBSCRIBE" SPACE mailbox + +tag ::= 1* + +text ::= 1*TEXT_CHAR + + + +Crispin Standards Track [Page 73] + +RFC 2060 IMAP4rev1 December 1996 + + +text_mime2 ::= "=?" "?" "?" + "?=" + ;; Syntax defined in [MIME-HDRS] + +TEXT_CHAR ::= + +time ::= 2digit ":" 2digit ":" 2digit + ;; Hours minutes seconds + +uid ::= "UID" SPACE (copy / fetch / search / store) + ;; Unique identifiers used instead of message + ;; sequence numbers + +uniqueid ::= nz_number + ;; Strictly ascending + +unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox + +userid ::= astring + +x_command ::= "X" atom + +zone ::= ("+" / "-") 4digit + ;; Signed four-digit value of hhmm representing + ;; hours and minutes west of Greenwich (that is, + ;; (the amount that the given time differs from + ;; Universal Time). Subtracting the timezone + ;; from the given time will give the UT form. + ;; The Universal Time zone is "+0000". + +10. Author's Note + + This document is a revision or rewrite of earlier documents, and + supercedes the protocol specification in those documents: RFC 1730, + unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064. + +11. Security Considerations + + IMAP4rev1 protocol transactions, including electronic mail data, are + sent in the clear over the network unless privacy protection is + negotiated in the AUTHENTICATE command. + + A server error message for an AUTHENTICATE command which fails due to + invalid credentials SHOULD NOT detail why the credentials are + invalid. + + Use of the LOGIN command sends passwords in the clear. This can be + avoided by using the AUTHENTICATE command instead. + + + +Crispin Standards Track [Page 74] + +RFC 2060 IMAP4rev1 December 1996 + + + A server error message for a failing LOGIN command SHOULD NOT specify + that the user name, as opposed to the password, is invalid. + + Additional security considerations are discussed in the section + discussing the AUTHENTICATE and LOGIN commands. + +12. Author's Address + + Mark R. Crispin + Networks and Distributed Computing + University of Washington + 4545 15th Aveneue NE + Seattle, WA 98105-4527 + + Phone: (206) 543-5762 + + EMail: MRC@CAC.Washington.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 75] + +RFC 2060 IMAP4rev1 December 1996 + + +Appendices + +A. References + +[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol", +Work in Progress. + +[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, +RFC 1700, USC/Information Sciences Institute, October 1994. + +[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation +Information in Internet Messages: The Content-Disposition Header", +RFC 1806, June 1995. + +[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. +Carnegie-Mellon University, December 1994. + +[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC +2061, University of Washington, November 1996. + +[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected +IMAP4 Clients", Work in Progress. + +[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and +IMAP2bis", RFC 1732, University of Washington, December 1994. + +[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in +IMAP4", RFC 1733, University of Washington, December 1994. + +[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - +Obsolete Syntax", RFC 2062, University of Washington, November 1996. + +[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", +RFC 1176, University of Washington, August 1990. + +[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of +Languages", RFC 1766, March 1995. + +[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC +1864, October 1995. + +[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet +Mail Extensions) Part One: Format of Internet Message Bodies", RFC +2045, November 1996. + +[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose +Internet Mail Extensions) Part Two: Media Types", RFC 2046, +November 1996. + + + +Crispin Standards Track [Page 76] + +RFC 2060 IMAP4rev1 December 1996 + + +[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) +Part Three: Message Header Extensions for Non-ASCII Text", RFC +2047, November 1996. + +[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text +Messages", STD 11, RFC 822, University of Delaware, August 1982. + +[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, +RFC 821, USC/Information Sciences Institute, August 1982. + +[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe +Transformation Format of Unicode", RFC 1642, July 1994. + +B. Changes from RFC 1730 + +1) The STATUS command has been added. + +2) Clarify in the formal syntax that the "#" construct can never +refer to multiple spaces. + +3) Obsolete syntax has been moved to a separate document. + +4) The PARTIAL command has been obsoleted. + +5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and +RFC822.TEXT.PEEK fetch attributes have been obsoleted. + +6) The "<" origin "." size ">" suffix for BODY text attributes has +been added. + +7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part +specifiers have been added. + +8) Support for Content-Disposition and Content-Language has been +added. + +9) The restriction on fetching nested MULTIPART parts has been +removed. + +10) Body part number 0 has been obsoleted. + +11) Server-supported authenticators are now identified by +capabilities. + + + + + + + + +Crispin Standards Track [Page 77] + +RFC 2060 IMAP4rev1 December 1996 + + +12) The capability that identifies this protocol is now called +"IMAP4rev1". A server that provides backwards support for RFC 1730 +SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its +CAPABILITY response. Because RFC-1730 required "IMAP4" to appear as +the first capability, it MUST listed first in the response. + +13) A description of the mailbox name namespace convention has been +added. + +14) A description of the international mailbox name convention has +been added. + +15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT +and UIDVALIDITY. This is a change from the IMAP STATUS +Work in Progress and not from RFC-1730 + +16) Add a clarification that a null mailbox name argument to the LIST +command returns an untagged LIST response with the hierarchy +delimiter and root of the reference argument. + +17) Define terms such as "MUST", "SHOULD", and "MUST NOT". + +18) Add a section which defines message attributes and more +thoroughly details the semantics of message sequence numbers, UIDs, +and flags. + +19) Add a clarification detailing the circumstances when a client may +send multiple commands without waiting for a response, and the +circumstances in which ambiguities may result. + +20) Add a recommendation on server behavior for DELETE and RENAME +when inferior hierarchical names of the given name exist. + +21) Add a clarification that a mailbox name may not be unilaterally +unsubscribed by the server, even if that mailbox name no longer +exists. + +22) Add a clarification that LIST should return its results quickly +without undue delay. + +23) Add a clarification that the date_time argument to APPEND sets +the internal date of the message. + +24) Add a clarification on APPEND behavior when the target mailbox is +the currently selected mailbox. + + + + + + +Crispin Standards Track [Page 78] + +RFC 2060 IMAP4rev1 December 1996 + + +25) Add a clarification that external changes to flags should be +always announced via an untagged FETCH even if the current command is +a STORE with the ".SILENT" suffix. + +26) Add a clarification that COPY appends to the target mailbox. + +27) Add the NEWNAME response code. + +28) Rewrite the description of the untagged BYE response to clarify +its semantics. + +29) Change the reference for the body MD5 to refer to the proper RFC. + +30) Clarify that the formal syntax contains rules which may overlap, +and that in the event of such an overlap the rule which occurs first +takes precedence. + +31) Correct the definition of body_fld_param. + +32) More formal syntax for capability_data. + +33) Clarify that any case variant of "INBOX" must be interpreted as +INBOX. + +34) Clarify that the human-readable text in resp_text should not +begin with "[" or "=". + +35) Change MIME references to Draft Standard documents. + +36) Clarify \Recent semantics. + +37) Additional examples. + +C. Key Word Index + + +FLAGS (store command data item) ............... 45 + +FLAGS.SILENT (store command data item) ........ 46 + -FLAGS (store command data item) ............... 46 + -FLAGS.SILENT (store command data item) ........ 46 + ALERT (response code) ...................................... 50 + ALL (fetch item) ........................................... 41 + ALL (search key) ........................................... 38 + ANSWERED (search key) ...................................... 38 + APPEND (command) ........................................... 34 + AUTHENTICATE (command) ..................................... 20 + BAD (response) ............................................. 52 + BCC (search key) .................................. 38 + BEFORE (search key) ................................. 39 + + + +Crispin Standards Track [Page 79] + +RFC 2060 IMAP4rev1 December 1996 + + + BODY (fetch item) .......................................... 41 + BODY (fetch result) ........................................ 58 + BODY (search key) ................................. 39 + BODY.PEEK[
]<> (fetch item) ............... 44 + BODYSTRUCTURE (fetch item) ................................. 44 + BODYSTRUCTURE (fetch result) ............................... 59 + BODY[
]<> (fetch result) ............. 58 + BODY[
]<> (fetch item) .................... 41 + BYE (response) ............................................. 52 + Body Structure (message attribute) ......................... 11 + CAPABILITY (command) ....................................... 18 + CAPABILITY (response) ...................................... 53 + CC (search key) ................................... 39 + CHECK (command) ............................................ 36 + CLOSE (command) ............................................ 36 + COPY (command) ............................................. 46 + CREATE (command) ........................................... 25 + DELETE (command) ........................................... 26 + DELETED (search key) ....................................... 39 + DRAFT (search key) ......................................... 39 + ENVELOPE (fetch item) ...................................... 44 + ENVELOPE (fetch result) .................................... 62 + EXAMINE (command) .......................................... 24 + EXISTS (response) .......................................... 56 + EXPUNGE (command) .......................................... 37 + EXPUNGE (response) ......................................... 57 + Envelope Structure (message attribute) ..................... 11 + FAST (fetch item) .......................................... 44 + FETCH (command) ............................................ 41 + FETCH (response) ........................................... 58 + FLAGGED (search key) ....................................... 39 + FLAGS (fetch item) ......................................... 44 + FLAGS (fetch result) ....................................... 62 + FLAGS (response) ........................................... 56 + FLAGS (store command data item) ................ 45 + FLAGS.SILENT (store command data item) ......... 45 + FROM (search key) ................................. 39 + FULL (fetch item) .......................................... 44 + Flags (message attribute) .................................. 9 + HEADER (part specifier) .................................... 41 + HEADER (search key) .................. 39 + HEADER.FIELDS (part specifier) ............... 41 + HEADER.FIELDS.NOT (part specifier) ........... 41 + INTERNALDATE (fetch item) .................................. 44 + INTERNALDATE (fetch result) ................................ 62 + Internal Date (message attribute) .......................... 10 + KEYWORD (search key) ................................ 39 + Keyword (type of flag) ..................................... 10 + + + +Crispin Standards Track [Page 80] + +RFC 2060 IMAP4rev1 December 1996 + + + LARGER (search key) .................................... 39 + LIST (command) ............................................. 30 + LIST (response) ............................................ 54 + LOGIN (command) ............................................ 22 + LOGOUT (command) ........................................... 20 + LSUB (command) ............................................. 32 + LSUB (response) ............................................ 55 + MAY (specification requirement term) ....................... 5 + MESSAGES (status item) ..................................... 33 + MIME (part specifier) ...................................... 42 + MUST (specification requirement term) ...................... 4 + MUST NOT (specification requirement term) .................. 4 + Message Sequence Number (message attribute) ................ 9 + NEW (search key) ........................................... 39 + NEWNAME (response code) .................................... 50 + NO (response) .............................................. 51 + NOOP (command) ............................................. 19 + NOT (search key) .............................. 39 + OK (response) .............................................. 51 + OLD (search key) ........................................... 39 + ON (search key) ..................................... 39 + OPTIONAL (specification requirement term) .................. 5 + OR (search key) ................ 39 + PARSE (response code) ...................................... 50 + PERMANENTFLAGS (response code) ............................. 50 + PREAUTH (response) ......................................... 52 + Permanent Flag (class of flag) ............................. 10 + READ-ONLY (response code) .................................. 50 + READ-WRITE (response code) ................................. 50 + RECENT (response) .......................................... 57 + RECENT (search key) ........................................ 39 + RECENT (status item) ....................................... 33 + RENAME (command) ........................................... 27 + REQUIRED (specification requirement term) .................. 4 + RFC822 (fetch item) ........................................ 44 + RFC822 (fetch result) ...................................... 63 + RFC822.HEADER (fetch item) ................................. 44 + RFC822.HEADER (fetch result) ............................... 62 + RFC822.SIZE (fetch item) ................................... 44 + RFC822.SIZE (fetch result) ................................. 62 + RFC822.TEXT (fetch item) ................................... 44 + RFC822.TEXT (fetch result) ................................. 62 + SEARCH (command) ........................................... 37 + SEARCH (response) .......................................... 55 + SEEN (search key) .......................................... 40 + SELECT (command) ........................................... 23 + SENTBEFORE (search key) ............................. 40 + SENTON (search key) ................................. 40 + + + +Crispin Standards Track [Page 81] + +RFC 2060 IMAP4rev1 December 1996 + + + SENTSINCE (search key) .............................. 40 + SHOULD (specification requirement term) .................... 5 + SHOULD NOT (specification requirement term) ................ 5 + SINCE (search key) .................................. 40 + SMALLER (search key) ................................... 40 + STATUS (command) ........................................... 33 + STATUS (response) .......................................... 55 + STORE (command) ............................................ 45 + SUBJECT (search key) .............................. 40 + SUBSCRIBE (command) ........................................ 29 + Session Flag (class of flag) ............................... 10 + System Flag (type of flag) ................................. 9 + TEXT (part specifier) ...................................... 42 + TEXT (search key) ................................. 40 + TO (search key) ................................... 40 + TRYCREATE (response code) .................................. 51 + UID (command) .............................................. 47 + UID (fetch item) ........................................... 44 + UID (fetch result) ......................................... 63 + UID (search key) ............................. 40 + UIDNEXT (status item) ...................................... 33 + UIDVALIDITY (response code) ................................ 51 + UIDVALIDITY (status item) .................................. 34 + UNANSWERED (search key) .................................... 40 + UNDELETED (search key) ..................................... 40 + UNDRAFT (search key) ....................................... 40 + UNFLAGGED (search key) ..................................... 40 + UNKEYWORD (search key) .............................. 40 + UNSEEN (response code) ..................................... 51 + UNSEEN (search key) ........................................ 40 + UNSEEN (status item) ....................................... 34 + UNSUBSCRIBE (command) ...................................... 30 + Unique Identifier (UID) (message attribute) ................ 7 + X (command) .......................................... 48 + [RFC-822] Size (message attribute) ......................... 11 + \Answered (system flag) .................................... 9 + \Deleted (system flag) ..................................... 9 + \Draft (system flag) ....................................... 9 + \Flagged (system flag) ..................................... 9 + \Marked (mailbox name attribute) ........................... 54 + \Noinferiors (mailbox name attribute) ...................... 54 + \Noselect (mailbox name attribute) ......................... 54 + \Recent (system flag) ...................................... 10 + \Seen (system flag) ........................................ 9 + \Unmarked (mailbox name attribute) ......................... 54 + + + + + + +Crispin Standards Track [Page 82] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2086.txt b/server/src/site/resources/rfclist/imap4/rfc2086.txt new file mode 100644 index 00000000000..7a58f0b06c1 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2086.txt @@ -0,0 +1,452 @@ + + + + + +Network Working Group J. Myers +Request for Comments: 2086 Carnegie Mellon +Category: Standards Track January 1997 + + + IMAP4 ACL extension + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The ACL extension of the Internet Message Access Protocol [IMAP4] + permits access control lists to be manipulated through the IMAP + protocol. + +Table of Contents + + 1. Abstract............................................... 1 + 2. Conventions Used in this Document...................... 1 + 3. Introduction and Overview.............................. 2 + 4. Commands............................................... 3 + 4.1. SETACL................................................. 3 + 4.2. DELETEACL.............................................. 4 + 4.3. GETACL................................................. 4 + 4.4. LISTRIGHTS............................................. 4 + 4.5. MYRIGHTS............................................... 5 + 5. Responses.............................................. 5 + 5.1. ACL.................................................... 5 + 5.2. LISTRIGHTS............................................. 6 + 5.3. MYRIGHTS............................................... 6 + 6. Formal Syntax.......................................... 6 + 7. References............................................. 7 + 8. Security Considerations................................ 7 + 9. Author's Address....................................... 8 + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + + + + + +Myers Standards Track [Page 1] + +RFC 2086 ACL extension January 1997 + + +3. Introduction and Overview + + The ACL extension is present in any IMAP4 implementation which + returns "ACL" as one of the supported capabilities to the CAPABILITY + command. + + An access control list is a set of pairs. + + Identifier is a US-ASCII string. The identifier anyone is reserved + to refer to the universal identity (all authentications, including + anonymous). All user name strings accepted by the LOGIN or + AUTHENTICATE commands to authenticate to the IMAP server are reserved + as identifiers for the corresponding user. Identifiers starting with + a dash ("-") are reserved for "negative rights", described below. + All other identifier strings are interpreted in an implementation- + defined manner. + + Rights is a string listing a (possibly empty) set of alphanumeric + characters, each character listing a set of operations which is being + controlled. Letters are reserved for ``standard'' rights, listed + below. The set of standard rights may only be extended by a + standards-track document. Digits are reserved for implementation or + site defined rights. The currently defined standard rights are: + + l - lookup (mailbox is visible to LIST/LSUB commands) + r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, + SEARCH, COPY from mailbox) + s - keep seen/unseen information across sessions (STORE SEEN flag) + w - write (STORE flags other than SEEN and DELETED) + i - insert (perform APPEND, COPY into mailbox) + p - post (send mail to submission address for mailbox, + not enforced by IMAP4 itself) + c - create (CREATE new sub-mailboxes in any implementation-defined + hierarchy) + d - delete (STORE DELETED flag, perform EXPUNGE) + a - administer (perform SETACL) + + An implementation may tie rights together or may force rights to + always or never be granted to particular identifiers. For example, + in an implementation that uses unix mode bits, the rights "wisd" are + tied, the "a" right is always granted to the owner of a mailbox and + is never granted to another user. If rights are tied in an + implementation, the implementation must be conservative in granting + rights in response to SETACL commands--unless all rights in a tied + set are specified, none of that set should be included in the ACL + entry for that identifier. A client may discover the set of rights + which may be granted to a given identifier in the ACL for a given + mailbox by using the LISTRIGHTS command. + + + +Myers Standards Track [Page 2] + +RFC 2086 ACL extension January 1997 + + + It is possible for multiple identifiers in an access control list to + apply to a given user (or other authentication identity). For + example, an ACL may include rights to be granted to the identifier + matching the user, one or more implementation-defined identifiers + matching groups which include the user, and/or the identifier + "anyone". How these rights are combined to determine the user's + access is implementation-defined. An implementation may choose, for + example, to use the union of the rights granted to the applicable + identifiers. An implementation may instead choose, for example, to + only use those rights granted to the most specific identifier present + in the ACL. A client may determine the set of rights granted to the + logged-in user for a given mailbox by using the MYRIGHTS command. + + When an identifier in an ACL starts with a dash ("-"), that indicates + that associated rights are to be removed from the identifier that is + prefixed by the dash. For example, if the identifier "-fred" is + granted the "w" right, that indicates that the "w" right is to be + removed from users matching the identifier "fred". Implementations + need not support having identifiers which start with a dash in ACLs. + +4. Commands + +4.1. SETACL + + Arguments: mailbox name + authentication identifier + access right modification + + Data: no specific data for this command + + Result: OK - setacl completed + NO - setacl failure: can't set acl + BAD - command unknown or arguments invalid + + The SETACL command changes the access control list on the + specified mailbox so that the specified identifier is granted + permissions as specified in the third argument. + + The third argument is a string containing an optional plus ("+") + or minus ("-") prefix, followed by zero or more rights characters. + If the string starts with a plus, the following rights are added + to any existing rights for the identifier. If the string starts + with a minus, the following rights are removed from any existing + rights for the identifier. If the string does not start with a + plus or minus, the rights replace any existing rights for the + identifier. + + + + + +Myers Standards Track [Page 3] + +RFC 2086 ACL extension January 1997 + + +4.2. DELETEACL + + Arguments: mailbox name + authentication identifier + + Data: no specific data for this command + + Result: OK - deleteacl completed + NO - deleteacl failure: can't delete acl + BAD - command unknown or arguments invalid + + The DELETEACL command removes any pair for the + specified identifier from the access control list for the specified + mailbox. + +4.3. GETACL + + Arguments: mailbox name + + Data: untagged responses: ACL + + Result: OK - getacl completed + NO - getacl failure: can't get acl + BAD - command unknown or arguments invalid + + The GETACL command returns the access control list for mailbox in + an untagged ACL reply. + + Example: C: A002 GETACL INBOX + S: * ACL INBOX Fred rwipslda + S: A002 OK Getacl complete + +4.4. LISTRIGHTS + + Arguments: mailbox name + authentication identifier + + Data: untagged responses: LISTRIGHTS + + Result: OK - listrights completed + NO - listrights failure: can't get rights list + BAD - command unknown or arguments invalid + + The LISTRIGHTS command takes a mailbox name and an identifier and + returns information about what rights may be granted to the identifier + in the ACL for the mailbox. + + + + + +Myers Standards Track [Page 4] + +RFC 2086 ACL extension January 1997 + + + Example: C: a001 LISTRIGHTS ~/Mail/saved smith + S: * LISTRIGHTS ~/Mail/saved smith la r swicd + S: a001 OK Listrights completed + + + C: a005 LISTRIGHTS archive.imap anyone + S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a + 0 1 2 3 4 5 6 7 8 9 + +4.5. MYRIGHTS + + Arguments: mailbox name + + Data: untagged responses: MYRIGHTS + + Result: OK - myrights completed + NO - myrights failure: can't get rights + BAD - command unknown or arguments invalid + + The MYRIGHTS command returns the set of rights that the user has + to mailbox in an untagged MYRIGHTS reply. + + Example: C: A003 MYRIGHTS INBOX + S: * MYRIGHTS INBOX rwipslda + S: A003 OK Myrights complete + +5. Responses + +5.1. ACL + + Data: mailbox name + zero or more identifier rights pairs + + The ACL response occurs as a result of a GETACL command. The first + string is the mailbox name for which this ACL applies. This is + followed by zero or more pairs of strings, each pair contains the + identifier for which the entry applies followed by the set of + rights that the identifier has. + + + + + + + + + + + + + +Myers Standards Track [Page 5] + +RFC 2086 ACL extension January 1997 + + +5.2. LISTRIGHTS + + Data: mailbox name + identifier + required rights + list of optional rights + + The LISTRIGHTS response occurs as a result of a LISTRIGHTS + command. The first two strings are the mailbox name and identifier + for which this rights list applies. Following the identifier is a + string containing the (possibly empty) set of rights the + identifier will always be granted in the mailbox. + + Following this are zero or more strings each containing a set of + rights the identifier may be granted in the mailbox. Rights + mentioned in the same string are tied together--either all must be + granted to the identifier in the mailbox or none may be granted. + + The same right may not be listed more than once in the LISTRIGHTS + command. + +5.3. MYRIGHTS + + Data: mailbox name + rights + + The MYRIGHTS response occurs as a result of a MYRIGHTS command. + The first string is the mailbox name for which these rights apply. + The second string is the set of rights that the client has. + +6. 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. + + + + + + + + + + +Myers Standards Track [Page 6] + +RFC 2086 ACL extension January 1997 + + + acl_data ::= "ACL" SPACE mailbox *(SPACE identifier SPACE + rights) + + deleteacl ::= "DELETEACL" SPACE mailbox SPACE identifier + + getacl ::= "GETACL" SPACE mailbox + + identifier ::= astring + + listrights ::= "LISTRIGHTS" SPACE mailbox SPACE identifier + + listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier + SPACE rights *(SPACE rights) + + mod_rights ::= astring + ;; +rights to add, -rights to remove + ;; rights to replace + + myrights ::= "MYRIGHTS" SPACE mailbox + + myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE rights + + rights ::= astring + + setacl ::= "SETACL" SPACE mailbox SPACE identifier + SPACE mod_rights + +7. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", + RFC 1730, University of Washington, December 1994. + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822. + +8. Security Considerations + + An implementation must make sure the ACL commands themselves do not + give information about mailboxes with appropriately restricted ACL's. + For example, a GETACL command on a mailbox for which the user has + insufficient rights should not admit the mailbox exists, much less + return the mailbox's ACL. + + + + + + + + + +Myers Standards Track [Page 7] + +RFC 2086 ACL extension January 1997 + + +9. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + Email: jgm+@cmu.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers Standards Track [Page 8] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2087.txt b/server/src/site/resources/rfclist/imap4/rfc2087.txt new file mode 100644 index 00000000000..979c8ecec87 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2087.txt @@ -0,0 +1,284 @@ + + + + + +Network Working Group J. Myers +Request for Comments: 2087 Carnegie Mellon +Category: Standards Track January 1997 + + + IMAP4 QUOTA extension + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The QUOTA extension of the Internet Message Access Protocol [IMAP4] + permits administrative limits on resource usage (quotas) to be + manipulated through the IMAP protocol. + +Table of Contents + + 1. Abstract........................................... 1 + 2. Conventions Used in this Document.................. 1 + 3. Introduction and Overview.......................... 2 + 4. Commands........................................... 2 + 4.1. SETQUOTA Command................................... 2 + 4.2. GETQUOTA Command................................... 2 + 4.3. GETQUOTAROOT Command............................... 3 + 5. Responses.......................................... 3 + 5.1. QUOTA Response..................................... 3 + 5.2. QUOTAROOT Response................................. 4 + 6. Formal syntax...................................... 4 + 7. References......................................... 5 + 8. Security Considerations............................ 5 + 9. Author's Address................................... 5 + + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + + + + + + + +Myers Standards Track [Page 1] + +RFC 2087 QUOTA January 1997 + + +3. Introduction and Overview + + The QUOTA extension is present in any IMAP4 implementation which + returns "QUOTA" as one of the supported capabilities to the + CAPABILITY command. + + An IMAP4 server which supports the QUOTA capability may support + limits on any number of resources. Each resource has an atom name + and an implementation-defined interpretation which evaluates to an + integer. Examples of such resources are: + + Name Interpretation + + STORAGE Sum of messages' RFC822.SIZE, in units of 1024 octets + MESSAGE Number of messages + + + Each mailbox has zero or more implementation-defined named "quota + roots". Each quota root has zero or more resource limits. All + mailboxes that share the same named quota root share the resource + limits of the quota root. + + Quota root names do not necessarily have to match the names of + existing mailboxes. + +4. Commands + +4.1. SETQUOTA Command + + Arguments: quota root + list of resource limits + + Data: untagged responses: QUOTA + + Result: OK - setquota completed + NO - setquota error: can't set that data + BAD - command unknown or arguments invalid + + The SETQUOTA command takes the name of a mailbox quota root and a + list of resource limits. The resource limits for the named quota root + are changed to be the specified limits. Any previous resource limits + for the named quota root are discarded. + + If the named quota root did not previously exist, an implementation + may optionally create it and change the quota roots for any number of + existing mailboxes in an implementation-defined manner. + + + + + +Myers Standards Track [Page 2] + +RFC 2087 QUOTA January 1997 + + + Example: C: A001 SETQUOTA "" (STORAGE 512) + S: * QUOTA "" (STORAGE 10 512) + S: A001 OK Setquota completed + +4.2. GETQUOTA Command + + Arguments: quota root + + Data: untagged responses: QUOTA + + Result: OK - getquota completed + NO - getquota error: no such quota root, permission + denied + BAD - command unknown or arguments invalid + + The GETQUOTA command takes the name of a quota root and returns the + quota root's resource usage and limits in an untagged QUOTA response. + + Example: C: A003 GETQUOTA "" + S: * QUOTA "" (STORAGE 10 512) + S: A003 OK Getquota completed + +4.3. GETQUOTAROOT Command + + Arguments: mailbox name + + Data: untagged responses: QUOTAROOT, QUOTA + + Result: OK - getquota completed + NO - getquota error: no such mailbox, permission denied + BAD - command unknown or arguments invalid + + The GETQUOTAROOT command takes the name of a mailbox and returns the + list of quota roots for the mailbox in an untagged QUOTAROOT + response. For each listed quota root, it also returns the quota + root's resource usage and limits in an untagged QUOTA response. + + Example: C: A003 GETQUOTAROOT INBOX + S: * QUOTAROOT INBOX "" + S: * QUOTA "" (STORAGE 10 512) + S: A003 OK Getquota completed + + + + + + + + + + +Myers Standards Track [Page 3] + +RFC 2087 QUOTA January 1997 + + +5. Responses + +5.1. QUOTA Response + + Data: quota root name + list of resource names, usages, and limits + + This response occurs as a result of a GETQUOTA or GETQUOTAROOT + command. The first string is the name of the quota root for which + this quota applies. + + The name is followed by a S-expression format list of the resource + usage and limits of the quota root. The list contains zero or + more triplets. Each triplet conatins a resource name, the current + usage of the resource, and the resource limit. + + Resources not named in the list are not limited in the quota root. + Thus, an empty list means there are no administrative resource + limits in the quota root. + + Example: S: * QUOTA "" (STORAGE 10 512) + +5.2. QUOTAROOT Response + + Data: mailbox name + zero or more quota root names + + This response occurs as a result of a GETQUOTAROOT command. The + first string is the mailbox and the remaining strings are the + names of the quota roots for the mailbox. + + Example: S: * QUOTAROOT INBOX "" + S: * QUOTAROOT comp.mail.mime + +6. Formal syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in RFC 822 with one exception; the + delimiter used with the "#" construct is a single space (SP) and not + one or more commas. + + Except as noted otherwise, all alphabetic characters are case- + insensitive. The use of upper or lower case characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + + + + + + +Myers Standards Track [Page 4] + +RFC 2087 QUOTA January 1997 + + + getquota ::= "GETQUOTA" SP astring + + getquotaroot ::= "GETQUOTAROOT" SP astring + + quota_list ::= "(" #quota_resource ")" + + quota_resource ::= atom SP number SP number + + quota_response ::= "QUOTA" SP astring SP quota_list + + quotaroot_response + ::= "QUOTAROOT" SP astring *(SP astring) + + setquota ::= "SETQUOTA" SP astring SP setquota_list + + setquota_list ::= "(" 0#setquota_resource ")" + + setquota_resource ::= atom SP number + +7. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", + RFC 1730, University of Washington, December 1994. + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822. + +8. Security Considerations + + Implementors should be careful to make sure the implementation of + these commands does not violate the site's security policy. The + resource usage of other users is likely to be considered confidential + information and should not be divulged to unauthorized persons. + +9. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + EMail: jgm+@cmu.edu + + + + + + + + + +Myers Standards Track [Page 5] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2088.txt b/server/src/site/resources/rfclist/imap4/rfc2088.txt new file mode 100644 index 00000000000..2cd02f561fe --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2088.txt @@ -0,0 +1,116 @@ + + + + + +Network Working Group J. Myers +Request for Comments: 2088 Carnegie Mellon +Cateogry: Standards Track January 1997 + + + IMAP4 non-synchronizing literals + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The Internet Message Access Protocol [IMAP4] contains the "literal" + syntactic construct for communicating strings. When sending a + literal from client to server, IMAP4 requires the client to wait for + the server to send a command continuation request between sending the + octet count and the string data. This document specifies an + alternate form of literal which does not require this network round + trip. + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + +3. Specification + + The non-synchronizing literal is added an alternate form of literal, + and may appear in communication from client to server instead of the + IMAP4 form of literal. The IMAP4 form of literal, used in + communication from client to server, is referred to as a + synchronizing literal. + + Non-synchronizing literals may be used with any IMAP4 server + implementation which returns "LITERAL+" as one of the supported + capabilities to the CAPABILITY command. If the server does not + advertise the LITERAL+ capability, the client must use synchronizing + literals instead. + + The non-synchronizing literal is distinguished from the original + synchronizing literal by having a plus ('+') between the octet count + and the closing brace ('}'). The server does not generate a command + continuation request in response to a non-synchronizing literal, and + + + +Myers Standards Track [Page 1] + +RFC 2088 LITERAL January 1997 + + + clients are not required to wait before sending the octets of a non- + synchronizing literal. + + The protocol receiver of an IMAP4 server must check the end of every + received line for an open brace ('{') followed by an octet count, a + plus ('+'), and a close brace ('}') immediately preceeding the CRLF. + If it finds this sequence, it is the octet count of a non- + synchronizing literal and the server MUST treat the specified number + of following octets and the following line as part of the same + command. A server MAY still process commands and reject errors on a + line-by-line basis, as long as it checks for non-synchronizing + literals at the end of each line. + + Example: C: A001 LOGIN {11+} + C: FRED FOOBAR {7+} + C: fat man + S: A001 OK LOGIN completed + +4. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. + Non-terminals referenced but not defined below are as defined by + [IMAP4]. + + literal ::= "{" number ["+"] "}" CRLF *CHAR8 + ;; Number represents the number of CHAR8 octets + +6. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", + draft-crispin-imap-base-XX.txt, University of Washington, April 1996. + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822. + +7. Security Considerations + + There are no known security issues with this extension. + +8. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + Email: jgm+@cmu.edu + + + +Myers Standards Track [Page 2] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2177.txt b/server/src/site/resources/rfclist/imap4/rfc2177.txt new file mode 100644 index 00000000000..80393f6f4e6 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2177.txt @@ -0,0 +1,228 @@ + + + + + +Network Working Group B. Leiba +Request for Comments: 2177 IBM T.J. Watson Research Center +Category: Standards Track June 1997 + + + IMAP4 IDLE command + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + The Internet Message Access Protocol [IMAP4] requires a client to + poll the server for changes to the selected mailbox (new mail, + deletions). It's often more desirable to have the server transmit + updates to the client in real time. This allows a user to see new + mail immediately. It also helps some real-time applications based on + IMAP, which might otherwise need to poll extremely often (such as + every few seconds). (While the spec actually does allow a server to + push EXISTS responses aysynchronously, a client can't expect this + behaviour and must poll.) + + This document specifies the syntax of an IDLE command, which will + allow a client to tell the server that it's ready to accept such + real-time updates. + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as described in RFC 2060 + [IMAP4]. + +3. Specification + + IDLE Command + + Arguments: none + + Responses: continuation data will be requested; the client sends + the continuation data "DONE" to end the command + + + +Leiba Standards Track [Page 1] + +RFC 2177 IMAP4 IDLE command June 1997 + + + + Result: OK - IDLE completed after client sent "DONE" + NO - failure: the server will not allow the IDLE + command at this time + BAD - command unknown or arguments invalid + + The IDLE command may be used with any IMAP4 server implementation + that returns "IDLE" as one of the supported capabilities to the + CAPABILITY command. If the server does not advertise the IDLE + capability, the client MUST NOT use the IDLE command and must poll + for mailbox updates. In particular, the client MUST continue to be + able to accept unsolicited untagged responses to ANY command, as + specified in the base IMAP specification. + + The IDLE command is sent from the client to the server when the + client is ready to accept unsolicited mailbox update messages. The + server requests a response to the IDLE command using the continuation + ("+") response. The IDLE command remains active until the client + responds to the continuation, and as long as an IDLE command is + active, the server is now free to send untagged EXISTS, EXPUNGE, and + other messages at any time. + + The IDLE command is terminated by the receipt of a "DONE" + continuation from the client; such response satisfies the server's + continuation request. At that point, the server MAY send any + remaining queued untagged responses and then MUST immediately send + the tagged response to the IDLE command and prepare to process other + commands. As in the base specification, the processing of any new + command may cause the sending of unsolicited untagged responses, + subject to the ambiguity limitations. The client MUST NOT send a + command while the server is waiting for the DONE, since the server + will not be able to distinguish a command from a continuation. + + The server MAY consider a client inactive if it has an IDLE command + running, and if such a server has an inactivity timeout it MAY log + the client off implicitly at the end of its timeout period. Because + of that, clients using IDLE are advised to terminate the IDLE and + re-issue it at least every 29 minutes to avoid being logged off. + This still allows a client to receive immediate mailbox updates even + though it need only "poll" at half hour intervals. + + + + + + + + + + + +Leiba Standards Track [Page 2] + +RFC 2177 IMAP4 IDLE command June 1997 + + + Example: C: A001 SELECT INBOX + S: * FLAGS (Deleted Seen) + S: * 3 EXISTS + S: * 0 RECENT + S: * OK [UIDVALIDITY 1] + S: A001 OK SELECT completed + C: A002 IDLE + S: + idling + ...time passes; new mail arrives... + S: * 4 EXISTS + C: DONE + S: A002 OK IDLE terminated + ...another client expunges message 2 now... + C: A003 FETCH 4 ALL + S: * 4 FETCH (...) + S: A003 OK FETCH completed + C: A004 IDLE + S: * 2 EXPUNGE + S: * 3 EXISTS + S: + idling + ...time passes; another client expunges message 3... + S: * 3 EXPUNGE + S: * 2 EXISTS + ...time passes; new mail arrives... + S: * 3 EXISTS + C: DONE + S: A004 OK IDLE terminated + C: A005 FETCH 3 ALL + S: * 3 FETCH (...) + S: A005 OK FETCH completed + C: A006 IDLE + +4. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. + Non-terminals referenced but not defined below are as defined by + [IMAP4]. + + command_auth ::= append / create / delete / examine / list / lsub / + rename / select / status / subscribe / unsubscribe + / idle + ;; Valid only in Authenticated or Selected state + + idle ::= "IDLE" CRLF "DONE" + + + + + + +Leiba Standards Track [Page 3] + +RFC 2177 IMAP4 IDLE command June 1997 + + +5. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + +6. Security Considerations + + There are no known security issues with this extension. + +7. Author's Address + + Barry Leiba + IBM T.J. Watson Research Center + 30 Saw Mill River Road + Hawthorne, NY 10532 + + Email: leiba@watson.ibm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Leiba Standards Track [Page 4] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2180.txt b/server/src/site/resources/rfclist/imap4/rfc2180.txt new file mode 100644 index 00000000000..57607002fa3 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2180.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group M. Gahrns +Request for Comments: 2180 Microsoft +Category: Informational July 1997 + + + IMAP4 Multi-Accessed Mailbox Practice + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +1. Abstract + + IMAP4[RFC-2060] is rich client/server protocol that allows a client + to access and manipulate electronic mail messages on a server. + Within the protocol framework, it is possible to have differing + results for particular client/server interactions. If a protocol does + not allow for this, it is often unduly restrictive. + + For example, when multiple clients are accessing a mailbox and one + attempts to delete the mailbox, an IMAP4 server may choose to + implement a solution based upon server architectural constraints or + individual preference. + + With this flexibility comes greater client responsibility. It is not + sufficient for a client to be written based upon the behavior of a + particular IMAP server. Rather the client must be based upon the + behavior allowed by the protocol. + + By documenting common IMAP4 server practice for the case of + simultaneous client access to a mailbox, we hope to ensure the widest + amount of inter-operation between IMAP4 clients and servers. + + The behavior described in this document reflects the practice of some + existing servers or behavior that the consensus of the IMAP mailing + list has deemed to be reasonable. The behavior described within this + document is believed to be [RFC-2060] compliant. However, this + document is not meant to define IMAP4 compliance, nor is it an + exhaustive list of valid IMAP4 behavior. [RFC-2060] must always be + consulted to determine IMAP4 compliance, especially for server + behavior not described within this document. + + + + + + + + +Gahrns Informational [Page 1] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +2. Conventions used in this document + + In examples,"C1:", "C2:" and "C3:" indicate lines sent by 3 different + clients (client #1, client #2 and client #3) that are connected to a + server. "S1:", "S2:" and "S3:" indicated lines sent by the server to + client #1, client #2 and client #3 respectively. + + A shared mailbox, is a mailbox that can be used by multiple users. + + A multi-accessed mailbox, is a mailbox that has multiple clients + simultaneously accessing it. + + A client is said to have accessed a mailbox after a successful SELECT + or EXAMINE command. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + + +3. Deletion/Renaming of a multi-accessed mailbox + + If an external agent or multiple clients are accessing a mailbox, + care must be taken when handling the deletion or renaming of the + mailbox. Following are some strategies an IMAP server may choose to + use when dealing with this situation. + + +3.1. The server MAY fail the DELETE/RENAME command of a multi-accessed + mailbox + + In some cases, this behavior may not be practical. For example, if a + large number of clients are accessing a shared mailbox, the window in + which no clients have the mailbox accessed may be small or non- + existent, effectively rendering the mailbox undeletable or + unrenamable. + + Example: + + + + C1: A001 DELETE FOO + S1: A001 NO Mailbox FOO is in use by another user. + + + + + + + +Gahrns Informational [Page 2] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +3.2. The server MAY allow the DELETE command of a multi-accessed + mailbox, but keep the information in the mailbox available for + those clients that currently have access to the mailbox. + + When all clients have finished accessing the mailbox, it is + permanently removed. For clients that do not already have access to + the mailbox, the 'ghosted' mailbox would not be available. For + example, it would not be returned to these clients in a subsequent + LIST or LSUB command and would not be a valid mailbox argument to any + other IMAP command until the reference count of clients accessing the + mailbox reached 0. + + In some cases, this behavior may not be desirable. For example if + someone created a mailbox with offensive or sensitive information, + one might prefer to have the mailbox deleted and all access to the + information contained within removed immediately, rather than + continuing to allow access until the client closes the mailbox. + + Furthermore, this behavior, may prevent 'recycling' of the same + mailbox name until all clients have finished accessing the original + mailbox. + + Example: + + + + C1: A001 DELETE FOO + S1: A001 OK Mailbox FOO is deleted. + + + + C2: B001 STORE 1 +FLAGS (\Seen) + S2: * 1 FETCH FLAGS (\Seen) + S2: B001 OK STORE completed + + + + C3: C001 STATUS FOO (MESSAGES) + S3: C001 NO Mailbox does not exist + + + + C3: C002 CREATE FOO + S3: C002 NO Mailbox FOO is still in use. Try again later. + + + + +Gahrns Informational [Page 3] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + + + + C2: B002 CLOSE + S2: B002 OK CLOSE Completed + + + + C3: C003 CREATE FOO + S3: C003 OK CREATE Completed + + +3.3. The server MAY allow the DELETE/RENAME of a multi-accessed + mailbox, but disconnect all other clients who have the mailbox + accessed by sending a untagged BYE response. + + A server may often choose to disconnect clients in the DELETE case, + but may choose to implement a "friendlier" method for the RENAME + case. + + Example: + + + + C1: A002 DELETE FOO + S1: A002 OK DELETE completed. + + + S2: * BYE Mailbox FOO has been deleted. + + +3.4. The server MAY allow the RENAME of a multi-accessed mailbox by + simply changing the name attribute on the mailbox. + + Other clients that have access to the mailbox can continue issuing + commands such as FETCH that do not reference the mailbox name. + Clients would discover the renaming the next time they referred to + the old mailbox name. Some servers MAY choose to include the + [NEWNAME] response code in their tagged NO response to a command that + contained the old mailbox name, as a hint to the client that the + operation can succeed if the command is issued with the new mailbox + name. + + + + + + + +Gahrns Informational [Page 4] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + + Example: + + + + C1: A001 RENAME FOO BAR + S1: A001 OK RENAME completed. + + + + C2: B001 FETCH 2:4 (FLAGS) + S2: * 2 FETCH . . . + S2: * 3 FETCH . . . + S2: * 4 FETCH . . . + S2: B001 OK FETCH completed + + + + C2: B002 APPEND FOO {300} C2: Date: Mon, 7 Feb 1994 + 21:52:25 0800 (PST) C2: . . . S2: B002 NO [NEWNAME FOO + BAR] Mailbox has been renamed + + +4. Expunging of messages on a multi-accessed mailbox + + If an external agent or multiple clients are accessing a mailbox, + care must be taken when handling the EXPUNGE of messages. Other + clients accessing the mailbox may be in the midst of issuing a + command that depends upon message sequence numbers. Because an + EXPUNGE response can not be sent while responding to a FETCH, STORE + or SEARCH command, it is not possible to immediately notify the + client of the EXPUNGE. This can result in ambiguity if the client + issues a FETCH, STORE or SEARCH operation on a message that has been + EXPUNGED. + + +4.1. Fetching of expunged messages + + Following are some strategies an IMAP server may choose to use when + dealing with a FETCH command on expunged messages. + + + + + + + + + +Gahrns Informational [Page 5] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + + Consider the following scenario: + + - Client #1 and Client #2 have mailbox FOO selected. + - There are 7 messages in the mailbox. + - Messages 4:7 are marked for deletion. + - Client #1 issues an EXPUNGE, to expunge messages 4:7 + + +4.1.1. The server MAY allow the EXPUNGE of a multi-accessed mailbox but + keep the messages available to satisfy subsequent FETCH commands + until it is able to send an EXPUNGE response to each client. + + In some cases, the behavior of keeping "ghosted" messages may not be + desirable. For example if a message contained offensive or sensitive + information, one might prefer to instantaneously remove all access to + the information, regardless of whether another client is in the midst + of accessing it. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 FETCH 4:7 RFC822 + S2: * 4 FETCH RFC822 . . . (RFC822 info returned) + S2: * 5 FETCH RFC822 . . . (RFC822 info returned) + S2: * 6 FETCH RFC822 . . . (RFC822 info returned) + S2: * 7 FETCH RFC822 . . . (RFC822 info returned) + S2: B001 OK FETCH Completed + + + + C2: B002 NOOP + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 3 EXISTS + S2: B002 OK NOOP Complete + + + + C2: B003 FETCH 4:7 RFC822 + S2: B003 NO Messages 4:7 are no longer available. + + + + + + +Gahrns Informational [Page 6] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +4.1.2 The server MAY allow the EXPUNGE of a multi-accessed mailbox, + and on subsequent FETCH commands return FETCH responses only for + non-expunged messages and a tagged NO. + + After receiving a tagged NO FETCH response, the client SHOULD issue a + NOOP command so that it will be informed of any pending EXPUNGE + responses. The client may then either reissue the failed FETCH + command, or by examining the EXPUNGE response from the NOOP and the + FETCH response from the FETCH, determine that the FETCH failed + because of pending expunges. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 FETCH 3:5 ENVELOPE + S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) + S2: B001 NO Some of the requested messages no longer exist + + + + C2: B002 NOOP + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 3 EXISTS + S2: B002 OK NOOP Completed. + + + + + + + + + + + + + + + + + + +Gahrns Informational [Page 7] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +4.1.3 The server MAY allow the EXPUNGE of a multi-accessed mailbox, and + on subsequent FETCH commands return the usual FETCH responses for + non-expunged messages, "NIL FETCH Responses" for expunged + messages, and a tagged OK response. + + If all of the messages in the subsequent FETCH command have been + expunged, the server SHOULD return only a tagged NO. In this case, + the client SHOULD issue a NOOP command so that it will be informed of + any pending EXPUNGE responses. The client may then either reissue + the failed FETCH command, or by examining the EXPUNGE response from + the NOOP, determine that the FETCH failed because of pending + expunges. + + "NIL FETCH responses" are a representation of empty data as + appropriate for the FETCH argument specified. + + Example: + + * 1 FETCH (ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL)) + * 1 FETCH (FLAGS ()) + * 1 FETCH (INTERNALDATE "00-Jan-0000 00:00:00 +0000") + * 1 FETCH (RFC822 "") + * 1 FETCH (RFC822.HEADER "") + * 1 FETCH (RFC822.TEXT "") + * 1 FETCH (RFC822.SIZE 0) + * 1 FETCH (BODY ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) + * 1 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" NIL NIL NIL "7BIT" 0 0) + * 1 FETCH (BODY[
] "") + * 1 FETCH (BODY[
] "") + + In some cases, a client may not be able to distinguish between "NIL + FETCH responses" received because a message was expunged and those + received because the data actually was NIL. For example, a * 5 + FETCH (FLAGS ()) response could be received if no flags were set on + message 5, or because message 5 was expunged. In a case of potential + ambiguity, the client SHOULD issue a command such as NOOP to force + the sending of the EXPUNGE responses to resolve any ambiguity. + + Example: (Building upon the scenario outlined in 4.1.) + + + + + + + + + + +Gahrns Informational [Page 8] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + + C2: B002 FETCH 3:5 ENVELOPE + S2: * 3 FETCH ENVELOPE . . . (ENVELOPE info returned) + S2: * 4 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL + NIL NIL) + S2: * 5 FETCH ENVELOPE (NIL NIL NIL NIL NIL NIL NIL NIL + NIL NIL) + S2: B002 OK FETCH Completed + + + + C2: B002 FETCH 4:7 ENVELOPE + S2: B002 NO Messages 4:7 have been expunged. + + +4.1.4 To avoid the situation altogether, the server MAY fail the + EXPUNGE of a multi-accessed mailbox + + In some cases, this behavior may not be practical. For example, if a + large number of clients are accessing a shared mailbox, the window in + which no clients have the mailbox accessed may be small or non- + existent, effectively rendering the message unexpungeable. + + +4.2. Storing of expunged messages + + Following are some strategies an IMAP server may choose to use when + dealing with a STORE command on expunged messages. + + +4.2.1 If the ".SILENT" suffix is used, and the STORE completed + successfully for all the non-expunged messages, the server SHOULD + return a tagged OK. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 STORE 1:7 +FLAGS.SILENT (\SEEN) + S2: B001 OK + + + + + + + + + +Gahrns Informational [Page 9] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +4.2.2. If the ".SILENT" suffix is not used, and only expunged messages + are referenced, the server SHOULD return only a tagged NO. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 STORE 5:7 +FLAGS (\SEEN) + S2: B001 NO Messages have been expunged + + +4.2.3. If the ".SILENT" suffix is not used, and a mixture of expunged + and non-expunged messages are referenced, the server MAY set the + flags and return a FETCH response for the non-expunged messages + along with a tagged NO. + + After receiving a tagged NO STORE response, the client SHOULD issue a + NOOP command so that it will be informed of any pending EXPUNGE + responses. The client may then either reissue the failed STORE + command, or by examining the EXPUNGE responses from the NOOP and + FETCH responses from the STORE, determine that the STORE failed + because of pending expunges. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 STORE 1:7 +FLAGS (\SEEN) + S2: * FETCH 1 FLAGS (\SEEN) + S2: * FETCH 2 FLAGS (\SEEN) + S2: * FETCH 3 FLAGS (\SEEN) + S2: B001 NO Some of the messages no longer exist. + + C2: B002 NOOP + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 3 EXISTS + S2: B002 OK NOOP Completed. + + + + + + + + +Gahrns Informational [Page 10] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +4.2.4. If the ".SILENT" suffix is not used, and a mixture of expunged + and non-expunged messages are referenced, the server MAY return + an untagged NO and not set any flags. + + After receiving a tagged NO STORE response, the client SHOULD issue a + NOOP command so that it will be informed of any pending EXPUNGE + responses. The client would then re-issue the STORE command after + updating its message list per any EXPUNGE response. + + If a large number of clients are accessing a shared mailbox, the + window in which there are no pending expunges may be small or non- + existent, effectively disallowing a client from setting the flags on + all messages at once. + + Example: (Building upon the scenario outlined in 4.1.) + + + + C2: B001 STORE 1:7 +FLAGS (\SEEN) + S2: B001 NO Some of the messages no longer exist. + + + + C2: B002 NOOP + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 4 EXPUNGE + S2: * 3 EXISTS + S2: B002 OK NOOP Completed. + + + + C2: B003 STORE 1:3 +FLAGS (\SEEN) S2: * FETCH 1 FLAGS + (\SEEN) S2: * FETCH 2 FLAGS (\SEEN) S2: * FETCH 3 FLAGS + (\SEEN) S2: B003 OK STORE Completed + + +4.3. Searching of expunged messages + + A server MAY simply not return a search response for messages that + have been expunged and it has not been able to inform the client + about. If a client was expecting a particular message to be returned + in a search result, and it was not, the client SHOULD issue a NOOP + command to see if the message was expunged by another client. + + + + +Gahrns Informational [Page 11] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +4.4 Copying of expunged messages + + COPY is the only IMAP4 sequence number command that is safe to allow + an EXPUNGE response on. This is because a client is not permitted to + cascade several COPY commands together. A client is required to wait + and confirm that the copy worked before issuing another one. + +4.4.1 The server MAY disallow the COPY of messages in a multi-access + mailbox that contains expunged messages. + + Pending EXPUNGE response(s) MUST be returned to the COPY command. + + Example: + + C: A001 COPY 2,4,6,8 FRED + S: * 4 EXPUNGE + S: A001 NO COPY rejected, because some of the requested + messages were expunged + + Note: Non of the above messages are copied because if a COPY command + is unsuccessful, the server MUST restore the destination mailbox to + its state before the COPY attempt. + + +4.4.2 The server MAY allow the COPY of messages in a multi-access + mailbox that contains expunged messages. + + Pending EXPUNGE response(s) MUST be returned to the COPY command. + Messages that are copied are messages corresponding to sequence + numbers before any EXPUNGE response. + + Example: + + C: A001 COPY 2,4,6,8 FRED + S: * 3 EXPUNGE + S: A001 OK COPY completed + + In the above example, the messages that are copied to FRED are + messages 2,4,6,8 at the start of the COPY command. These are + equivalent to messages 2,3,5,7 at the end of the COPY command. The + EXPUNGE response can't take place until after the messages from the + COPY command are identified (because of the "no expunge while no + commands in progress" rule). + + + + + + + + +Gahrns Informational [Page 12] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + + Example: + + C: A001 COPY 2,4,6,8 FRED + S: * 4 EXPUNGE + S: A001 OK COPY completed + + In the above example, message 4 was copied before it was expunged, + and MUST appear in the destination mailbox FRED. + + +5. Security Considerations + + This document describes behavior of servers that use the IMAP4 + protocol, and as such, has the same security considerations as + described in [RFC-2060]. + + In particular, some described server behavior does not allow for the + immediate deletion of information when a mailbox is accessed by + multiple clients. This may be a consideration when dealing with + sensitive information where immediate deletion would be preferred. + + +6. References + + [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, Harvard University, March 1997. + + +7. Acknowledgments + + This document is the result of discussions on the IMAP4 mailing list + and is meant to reflect consensus of this group. In particular, + Raymond Cheng, Mark Crispin, Jim Evans, Erik Forsberg, Steve Hole, + Mark Keasling, Barry Leiba, Syd Logan, John Mani, Pat Moran, Larry + Osterman, Chris Newman, Bart Schaefer, Vladimir Vulovic, and Jack De + Winter were active participants in this discussion or made + suggestions to this document. + + + + + + + + + + + +Gahrns Informational [Page 13] + +RFC 2180 IMAP4 Multi-Accessed Mailbox Practice July 1997 + + +8. Author's Address + + Mike Gahrns + Microsoft + One Microsoft Way + Redmond, WA, 98072 + + Phone: (206) 936-9833 + EMail: mikega@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gahrns Informational [Page 14] + diff --git a/server/src/site/resources/rfclist/imap4/rfc2192.txt b/server/src/site/resources/rfclist/imap4/rfc2192.txt new file mode 100644 index 00000000000..a8ac12d04a4 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2192.txt @@ -0,0 +1,900 @@ + + + + + +Network Working Group C. Newman +Request for Comments: 2192 Innosoft +Category: Standards Track September 1997 + + + IMAP URL Scheme + + +Status of this memo + + This document specifies an Internet standards track protocol for + the Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is + unlimited. + + +Abstract + + IMAP [IMAP4] is a rich protocol for accessing remote message + stores. It provides an ideal mechanism for accessing public + mailing list archives as well as private and shared message stores. + This document defines a URL scheme for referencing objects on an + IMAP server. + + +1. Conventions used in this document + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as defined in "Key words for + use in RFCs to Indicate Requirement Levels" [KEYWORDS]. + + +2. IMAP scheme + + The IMAP URL scheme is used to designate IMAP servers, mailboxes, + messages, MIME bodies [MIME], and search programs on Internet hosts + accessible using the IMAP protocol. + + The IMAP URL follows the common Internet scheme syntax as defined + in RFC 1738 [BASIC-URL] except that clear text passwords are not + permitted. If : is omitted, the port defaults to 143. + + + + + + + + +Newman Standards Track [Page 1] + +RFC 2192 IMAP URL Scheme September 1997 + + + An IMAP URL takes one of the following forms: + + imap:/// + imap:///;TYPE= + imap:///[uidvalidity][?] + imap:///[uidvalidity][isection] + + The first form is used to refer to an IMAP server, the second form + refers to a list of mailboxes, the third form refers to the + contents of a mailbox or a set of messages resulting from a search, + and the final form refers to a specific message or message part. + Note that the syntax here is informal. The authoritative formal + syntax for IMAP URLs is defined in section 11. + + +3. IMAP User Name and Authentication Mechanism + + A user name and/or authentication mechanism may be supplied. They + are used in the "LOGIN" or "AUTHENTICATE" commands after making the + connection to the IMAP server. If no user name or authentication + mechanism is supplied, the user name "anonymous" is used with the + "LOGIN" command and the password is supplied as the Internet e-mail + address of the end user accessing the resource. If the URL doesn't + supply a user name, the program interpreting the IMAP URL SHOULD + request one from the user if necessary. + + An authentication mechanism can be expressed by adding + ";AUTH=" to the end of the user name. When such an + is indicated, the client SHOULD request appropriate + credentials from that mechanism and use the "AUTHENTICATE" command + instead of the "LOGIN" command. If no user name is specified, one + SHOULD be obtained from the mechanism or requested from the user as + appropriate. + + The string ";AUTH=*" indicates that the client SHOULD select an + appropriate authentication mechanism. It MAY use any mechanism + listed in the CAPABILITY command or use an out of band security + service resulting in a PREAUTH connection. If no user name is + specified and no appropriate authentication mechanisms are + available, the client SHOULD fall back to anonymous login as + described above. This allows a URL which grants read-write access + to authorized users, and read-only anonymous access to other users. + + If a user name is included with no authentication mechanism, then + ";AUTH=*" is assumed. + + + + + + +Newman Standards Track [Page 2] + +RFC 2192 IMAP URL Scheme September 1997 + + + Since URLs can easily come from untrusted sources, care must be + taken when resolving a URL which requires or requests any sort of + authentication. If authentication credentials are supplied to the + wrong server, it may compromise the security of the user's account. + The program resolving the URL should make sure it meets at least + one of the following criteria in this case: + + (1) The URL comes from a trusted source, such as a referral server + which the client has validated and trusts according to site policy. + Note that user entry of the URL may or may not count as a trusted + source, depending on the experience level of the user and site + policy. + (2) Explicit local site policy permits the client to connect to the + server in the URL. For example, if the client knows the site + domain name, site policy may dictate that any hostname ending in + that domain is trusted. + (3) The user confirms that connecting to that domain name with the + specified credentials and/or mechanism is permitted. + (4) A mechanism is used which validates the server before passing + potentially compromising client credentials. + (5) An authentication mechanism is used which will not reveal + information to the server which could be used to compromise future + connections. + + URLs which do not include a user name must be treated with extra + care, since they are more likely to compromise the user's primary + account. A URL containing ";AUTH=*" must also be treated with + extra care since it might fall back on a weaker security mechanism. + Finally, clients are discouraged from using a plain text password + as a fallback with ";AUTH=*" unless the connection has strong + encryption (e.g. a key length of greater than 56 bits). + + A program interpreting IMAP URLs MAY cache open connections to an + IMAP server for later re-use. If a URL contains a user name, only + connections authenticated as that user may be re-used. If a URL + does not contain a user name or authentication mechanism, then only + an anonymous connection may be re-used. If a URL contains an + authentication mechanism without a user name, then any non- + anonymous connection may be re-used. + + Note that if unsafe or reserved characters such as " " or ";" are + present in the user name or authentication mechanism, they MUST be + encoded as described in RFC 1738 [BASIC-URL]. + + + + + + + + +Newman Standards Track [Page 3] + +RFC 2192 IMAP URL Scheme September 1997 + + +4. IMAP server + + An IMAP URL referring to an IMAP server has the following form: + + imap:/// + + A program interpreting this URL would issue the standard set of + commands it uses to present a view of the contents of an IMAP + server. This is likely to be semanticly equivalent to one of the + following URLs: + + imap:///;TYPE=LIST + imap:///;TYPE=LSUB + + The program interpreting this URL SHOULD use the LSUB form if it + supports mailbox subscriptions. + + +5. Lists of mailboxes + + An IMAP URL referring to a list of mailboxes has the following + form: + + imap:///;TYPE= + + The may be either "LIST" or "LSUB", and is case + insensitive. The field ";TYPE=" MUST be included. + + The is any argument suitable for the + list_mailbox field of the IMAP [IMAP4] LIST or LSUB commands. The + field may be omitted, in which case the program + interpreting the IMAP URL may use "*" or "%" as the + . The program SHOULD use "%" if it supports a + hierarchical view, otherwise it SHOULD use "*". + + Note that if unsafe or reserved characters such as " " or "%" are + present in they MUST be encoded as described in + RFC 1738 [BASIC-URL]. If the character "/" is present in + enc_list_mailbox, it SHOULD NOT be encoded. + + +6. Lists of messages + + An IMAP URL referring to a list of messages has the following form: + + imap:///[uidvalidity][?] + + + + + +Newman Standards Track [Page 4] + +RFC 2192 IMAP URL Scheme September 1997 + + + The field is used as the argument to the IMAP4 + "SELECT" command. Note that if unsafe or reserved characters such + as " ", ";", or "?" are present in they MUST be + encoded as described in RFC 1738 [BASIC-URL]. If the character "/" + is present in enc_mailbox, it SHOULD NOT be encoded. + + The [uidvalidity] field is optional. If it is present, it MUST be + the argument to the IMAP4 UIDVALIDITY status response at the time + the URL was created. This SHOULD be used by the program + interpreting the IMAP URL to determine if the URL is stale. + + The [?] field is optional. If it is not present, the + contents of the mailbox SHOULD be presented by the program + interpreting the URL. If it is present, it SHOULD be used as the + arguments following an IMAP4 SEARCH command with unsafe characters + such as " " (which are likely to be present in the ) + encoded as described in RFC 1738 [BASIC-URL]. + + +7. A specific message or message part + + An IMAP URL referring to a specific message or message part has the + following form: + + imap:///[uidvalidity][isection] + + The and [uidvalidity] are as defined above. + + If [uidvalidity] is present in this form, it SHOULD be used by the + program interpreting the URL to determine if the URL is stale. + + The refers to an IMAP4 message UID, and SHOULD be used as + the argument to the IMAP4 "UID FETCH" command. + + The [isection] field is optional. If not present, the URL refers + to the entire Internet message as returned by the IMAP command "UID + FETCH BODY.PEEK[]". If present, the URL refers to the object + returned by a "UID FETCH BODY.PEEK[
]" command. The + type of the object may be determined with a "UID FETCH + BODYSTRUCTURE" command and locating the appropriate part in the + resulting BODYSTRUCTURE. Note that unsafe characters in [isection] + MUST be encoded as described in [BASIC-URL]. + + + + + + + + + +Newman Standards Track [Page 5] + +RFC 2192 IMAP URL Scheme September 1997 + + +8. Relative IMAP URLs + + Relative IMAP URLs are permitted and are resolved according to the + rules defined in RFC 1808 [REL-URL] with one exception. In IMAP + URLs, parameters are treated as part of the normal path with + respect to relative URL resolution. This is believed to be the + behavior of the installed base and is likely to be documented in a + future revision of the relative URL specification. + + The following observations are also important: + + The grammar element is considered part of the user name for + purposes of resolving relative IMAP URLs. This means that unless a + new login/server specification is included in the relative URL, the + authentication mechanism is inherited from a base IMAP URL. + + URLs always use "/" as the hierarchy delimiter for the purpose of + resolving paths in relative URLs. IMAP4 permits the use of any + hierarchy delimiter in mailbox names. For this reason, relative + mailbox paths will only work if the mailbox uses "/" as the + hierarchy delimiter. Relative URLs may be used on mailboxes which + use other delimiters, but in that case, the entire mailbox name + MUST be specified in the relative URL or inherited as a whole from + the base URL. + + The base URL for a list of mailboxes or messages which was referred + to by an IMAP URL is always the referring IMAP URL itself. The + base URL for a message or message part which was referred to by an + IMAP URL may be more complicated to determine. The program + interpreting the relative URL will have to check the headers of the + MIME entity and any enclosing MIME entities in order to locate the + "Content-Base" and "Content-Location" headers. These headers are + used to determine the base URL as defined in [HTTP]. For example, + if the referring IMAP URL contains a "/;SECTION=1.2" parameter, + then the MIME headers for section 1.2, for section 1, and for the + enclosing message itself SHOULD be checked in that order for + "Content-Base" or "Content-Location" headers. + + +9. Multinational Considerations + + IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding + non-US-ASCII characters in IMAP mailbox names. Because this + convention is private to IMAP, it is necessary to convert IMAP's + encoding to one that can be more easily interpreted by a URL + display program. For this reason, IMAP's modified UTF-7 encoding + for mailboxes MUST be converted to UTF-8 [UTF8]. Since 8-bit + characters are not permitted in URLs, the UTF-8 characters are + + + +Newman Standards Track [Page 6] + +RFC 2192 IMAP URL Scheme September 1997 + + + encoded as required by the URL specification [BASIC-URL]. Sample + code is included in Appendix A to demonstrate this conversion. + + +10. Examples + + The following examples demonstrate how an IMAP4 client program + might translate various IMAP4 URLs into a series of IMAP4 commands. + Commands sent from the client to the server are prefixed with "C:", + and responses sent from the server to the client are prefixed with + "S:". + + The URL: + + + + Results in the following client commands: + + + C: A001 LOGIN ANONYMOUS sheridan@babylon5.org + C: A002 SELECT gray-council + + C: A003 UID FETCH 20 BODY.PEEK[] + + The URL: + + + + Results in the following client commands: + + + + C: A001 LOGIN MICHAEL zipper + C: A002 LIST "" users.* + + The URL: + + + + Results in the following client commands: + + + C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.org + C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw- + + + + + + +Newman Standards Track [Page 7] + +RFC 2192 IMAP URL Scheme September 1997 + + + The URL: + + + + Results in the following client commands: + + + C: A001 AUTHENTICATE KERBEROS_V4 + + C: A002 SELECT gray-council + C: A003 UID FETCH 20 BODY.PEEK[1.2] + + If the following relative URL is located in that body part: + + <;section=1.4> + + This could result in the following client commands: + + C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME] + BODY.PEEK[1.MIME] + BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)]) + + C: A005 UID FETCH 20 BODY.PEEK[1.4] + + The URL: + + + + Could result in the following: + + + C: A001 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI + S: A001 OK + C: A002 AUTHENTICATE GSSAPI + + S: A002 OK user lennier authenticated + C: A003 SELECT "gray council" + ... + C: A004 SEARCH SUBJECT shadows + S: * SEARCH 8 10 13 14 15 16 + S: A004 OK SEARCH completed + C: A005 FETCH 8,10,13:16 ALL + ... + + + + + +Newman Standards Track [Page 8] + +RFC 2192 IMAP URL Scheme September 1997 + + + NOTE: In this final example, the client has implementation + dependent choices. The authentication mechanism could be anything, + including PREAUTH. And the final FETCH command could fetch more or + less information about the messages, depending on what it wishes to + display to the user. + + +11. Security Considerations + + Security considerations discussed in the IMAP specification [IMAP4] + and the URL specification [BASIC-URL] are relevant. Security + considerations related to authenticated URLs are discussed in + section 3 of this document. + + Many email clients store the plain text password for later use + after logging into an IMAP server. Such clients MUST NOT use a + stored password in response to an IMAP URL without explicit + permission from the user to supply that password to the specified + host name. + + +12. ABNF for IMAP URL scheme + + This uses ABNF as defined in RFC 822 [IMAIL]. Terminals from the + BNF for IMAP [IMAP4] and URLs [BASIC-URL] are also used. Strings + are not case sensitive and free insertion of linear-white-space is + not permitted. + + achar = uchar / "&" / "=" / "~" + ; see [BASIC-URL] for "uchar" definition + + bchar = achar / ":" / "@" / "/" + + enc_auth_type = 1*achar + ; encoded version of [IMAP-AUTH] "auth_type" + + enc_list_mailbox = 1*bchar + ; encoded version of [IMAP4] "list_mailbox" + + enc_mailbox = 1*bchar + ; encoded version of [IMAP4] "mailbox" + + enc_search = 1*bchar + ; encoded version of search_program below + + enc_section = 1*bchar + ; encoded version of section below + + + + +Newman Standards Track [Page 9] + +RFC 2192 IMAP URL Scheme September 1997 + + + enc_user = 1*achar + ; encoded version of [IMAP4] "userid" + + imapurl = "imap://" iserver "/" [ icommand ] + + iauth = ";AUTH=" ( "*" / enc_auth_type ) + + icommand = imailboxlist / imessagelist / imessagepart + + imailboxlist = [enc_list_mailbox] ";TYPE=" list_type + + imessagelist = enc_mailbox [ "?" enc_search ] [uidvalidity] + + imessagepart = enc_mailbox [uidvalidity] iuid [isection] + + isection = "/;SECTION=" enc_section + + iserver = [iuserauth "@"] hostport + ; See [BASIC-URL] for "hostport" definition + + iuid = "/;UID=" nz_number + ; See [IMAP4] for "nz_number" definition + + iuserauth = enc_user [iauth] / [enc_user] iauth + + list_type = "LIST" / "LSUB" + + search_program = ["CHARSET" SPACE astring SPACE] + search_key *(SPACE search_key) + ; IMAP4 literals may not be used + ; See [IMAP4] for "astring" and "search_key" + + section = section_text / (nz_number *["." nz_number] + ["." (section_text / "MIME")]) + ; See [IMAP4] for "section_text" and "nz_number" + + uidvalidity = ";UIDVALIDITY=" nz_number + ; See [IMAP4] for "nz_number" definition + +13. References + + [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource + Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of + Minnesota, December 1994. + + + + + + + +Newman Standards Track [Page 10] + +RFC 2192 IMAP URL Scheme September 1997 + + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + + + [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, + Carnegie-Mellon University, December 1994. + + + + [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS, + January 1997. + + + + [IMAIL] Crocker, "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, University of Delaware, August 1982. + + + + [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, Harvard University, March 1997. + + + + [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail + Extensions", RFC 2045, Innosoft, First Virtual, November 1996. + + + + [REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808, + UC Irvine, June 1995. + + + + [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and + ISO 10646", RFC 2044, Alis Technologies, October 1996. + + + +14. Author's Address + + Chris Newman + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 USA + EMail: chris.newman@innosoft.com + + + +Newman Standards Track [Page 11] + +RFC 2192 IMAP URL Scheme September 1997 + + +Appendix A. Sample code + +Here is sample C source code to convert between URL paths and IMAP +mailbox names, taking into account mapping between IMAP's modified UTF-7 +[IMAP4] and hex-encoded UTF-8 which is more appropriate for URLs. This +code has not been rigorously tested nor does it necessarily behave +reasonably with invalid input, but it should serve as a useful example. +This code just converts the mailbox portion of the URL and does not deal +with parameters, query or server components of the URL. + +#include +#include + +/* hexadecimal lookup table */ +static char hex[] = "0123456789ABCDEF"; + +/* URL unsafe printable characters */ +static char urlunsafe[] = " \"#%&+:;<=>?@[\\]^`{|}"; + +/* UTF7 modified base64 alphabet */ +static char base64chars[] = + "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,"; +#define UNDEFINED 64 + +/* UTF16 definitions */ +#define UTF16MASK 0x03FFUL +#define UTF16SHIFT 10 +#define UTF16BASE 0x10000UL +#define UTF16HIGHSTART 0xD800UL +#define UTF16HIGHEND 0xDBFFUL +#define UTF16LOSTART 0xDC00UL +#define UTF16LOEND 0xDFFFUL + +/* Convert an IMAP mailbox to a URL path + * dst needs to have roughly 4 times the storage space of src + * Hex encoding can triple the size of the input + * UTF-7 can be slightly denser than UTF-8 + * (worst case: 8 octets UTF-7 becomes 9 octets UTF-8) + */ +void MailboxToURL(char *dst, char *src) +{ + unsigned char c, i, bitcount; + unsigned long ucs4, utf16, bitbuf; + unsigned char base64[256], utf8[6]; + + + + + + + +Newman Standards Track [Page 12] + +RFC 2192 IMAP URL Scheme September 1997 + + + /* initialize modified base64 decoding table */ + memset(base64, UNDEFINED, sizeof (base64)); + for (i = 0; i < sizeof (base64chars); ++i) { + base64[base64chars[i]] = i; + } + + /* loop until end of string */ + while (*src != '\0') { + c = *src++; + /* deal with literal characters and &- */ + if (c != '&' || *src == '-') { + if (c < ' ' || c > '~' || strchr(urlunsafe, c) != NULL) { + /* hex encode if necessary */ + dst[0] = '%'; + dst[1] = hex[c >> 4]; + dst[2] = hex[c & 0x0f]; + dst += 3; + } else { + /* encode literally */ + *dst++ = c; + } + /* skip over the '-' if this is an &- sequence */ + if (c == '&') ++src; + } else { + /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */ + bitbuf = 0; + bitcount = 0; + ucs4 = 0; + while ((c = base64[(unsigned char) *src]) != UNDEFINED) { + ++src; + bitbuf = (bitbuf << 6) | c; + bitcount += 6; + /* enough bits for a UTF-16 character? */ + if (bitcount >= 16) { + bitcount -= 16; + utf16 = (bitcount ? bitbuf >> bitcount + : bitbuf) & 0xffff; + /* convert UTF16 to UCS4 */ + if + (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) { + ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT; + continue; + } else if + (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) { + ucs4 += utf16 - UTF16LOSTART + UTF16BASE; + } else { + ucs4 = utf16; + } + + + +Newman Standards Track [Page 13] + +RFC 2192 IMAP URL Scheme September 1997 + + + /* convert UTF-16 range of UCS4 to UTF-8 */ + if (ucs4 <= 0x7fUL) { + utf8[0] = ucs4; + i = 1; + } else if (ucs4 <= 0x7ffUL) { + utf8[0] = 0xc0 | (ucs4 >> 6); + utf8[1] = 0x80 | (ucs4 & 0x3f); + i = 2; + } else if (ucs4 <= 0xffffUL) { + utf8[0] = 0xe0 | (ucs4 >> 12); + utf8[1] = 0x80 | ((ucs4 >> 6) & 0x3f); + utf8[2] = 0x80 | (ucs4 & 0x3f); + i = 3; + } else { + utf8[0] = 0xf0 | (ucs4 >> 18); + utf8[1] = 0x80 | ((ucs4 >> 12) & 0x3f); + utf8[2] = 0x80 | ((ucs4 >> 6) & 0x3f); + utf8[3] = 0x80 | (ucs4 & 0x3f); + i = 4; + } + /* convert utf8 to hex */ + for (c = 0; c < i; ++c) { + dst[0] = '%'; + dst[1] = hex[utf8[c] >> 4]; + dst[2] = hex[utf8[c] & 0x0f]; + dst += 3; + } + } + } + /* skip over trailing '-' in modified UTF-7 encoding */ + if (*src == '-') ++src; + } + } + /* terminate destination string */ + *dst = '\0'; +} + +/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox + * dst should be about twice the length of src to deal with non-hex + * coded URLs + */ +void URLtoMailbox(char *dst, char *src) +{ + unsigned int utf8pos, utf8total, i, c, utf7mode, bitstogo, utf16flag; + unsigned long ucs4, bitbuf; + unsigned char hextab[256]; + + /* initialize hex lookup table */ + + + +Newman Standards Track [Page 14] + +RFC 2192 IMAP URL Scheme September 1997 + + + memset(hextab, 0, sizeof (hextab)); + for (i = 0; i < sizeof (hex); ++i) { + hextab[hex[i]] = i; + if (isupper(hex[i])) hextab[tolower(hex[i])] = i; + } + + utf7mode = 0; + utf8total = 0; + bitstogo = 0; + while ((c = *src) != '\0') { + ++src; + /* undo hex-encoding */ + if (c == '%' && src[0] != '\0' && src[1] != '\0') { + c = (hextab[src[0]] << 4) | hextab[src[1]]; + src += 2; + } + /* normal character? */ + if (c >= ' ' && c <= '~') { + /* switch out of UTF-7 mode */ + if (utf7mode) { + if (bitstogo) { + *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; + } + *dst++ = '-'; + utf7mode = 0; + } + *dst++ = c; + /* encode '&' as '&-' */ + if (c == '&') { + *dst++ = '-'; + } + continue; + } + /* switch to UTF-7 mode */ + if (!utf7mode) { + *dst++ = '&'; + utf7mode = 1; + } + /* Encode US-ASCII characters as themselves */ + if (c < 0x80) { + ucs4 = c; + utf8total = 1; + } else if (utf8total) { + /* save UTF8 bits into UCS4 */ + ucs4 = (ucs4 << 6) | (c & 0x3FUL); + if (++utf8pos < utf8total) { + continue; + } + + + +Newman Standards Track [Page 15] + +RFC 2192 IMAP URL Scheme September 1997 + + + } else { + utf8pos = 1; + if (c < 0xE0) { + utf8total = 2; + ucs4 = c & 0x1F; + } else if (c < 0xF0) { + utf8total = 3; + ucs4 = c & 0x0F; + } else { + /* NOTE: can't convert UTF8 sequences longer than 4 */ + utf8total = 4; + ucs4 = c & 0x03; + } + continue; + } + /* loop to split ucs4 into two utf16 chars if necessary */ + utf8total = 0; + do { + if (ucs4 >= UTF16BASE) { + ucs4 -= UTF16BASE; + bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT) + + UTF16HIGHSTART); + ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART; + utf16flag = 1; + } else { + bitbuf = (bitbuf << 16) | ucs4; + utf16flag = 0; + } + bitstogo += 16; + /* spew out base64 */ + while (bitstogo >= 6) { + bitstogo -= 6; + *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo) + : bitbuf) + & 0x3F]; + } + } while (utf16flag); + } + /* if in UTF-7 mode, finish in ASCII */ + if (utf7mode) { + if (bitstogo) { + *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; + } + *dst++ = '-'; + } + /* tie off string */ + *dst = '\0'; +} + + + +Newman Standards Track [Page 16] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2193.txt b/server/src/site/resources/rfclist/imap4/rfc2193.txt new file mode 100644 index 00000000000..09dd90f79f1 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2193.txt @@ -0,0 +1,508 @@ + + + + + +Network Working Group M. Gahrns +Request for Comments: 2193 Microsoft +Category: Standards Track September 1997 + + + IMAP4 Mailbox Referrals + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + When dealing with large amounts of users, messages and geographically + dispersed IMAP4 [RFC-2060] servers, it is often desirable to + distribute messages amongst different servers within an organization. + For example an administrator may choose to store user's personal + mailboxes on a local IMAP4 server, while storing shared mailboxes + remotely on another server. This type of configuration is common + when it is uneconomical to store all data centrally due to limited + bandwidth or disk resources. + + Mailbox referrals allow clients to seamlessly access mailboxes that + are distributed across several IMAP4 servers. + + A referral mechanism can provide efficiencies over the alternative + "proxy method", in which the local IMAP4 server contacts the remote + server on behalf of the client, and then transfers the data from the + remote server to itself, and then on to the client. The referral + mechanism's direct client connection to the remote server is often a + more efficient use of bandwidth, and does not require the local + server to impersonate the client when authenticating to the remote + server. + +2. Conventions used in this document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + A home server, is an IMAP4 server that contains the user's inbox. + + A remote mailbox is a mailbox that is not hosted on the user's home + server. + + + + +Gahrns Standards Track [Page 1] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + A remote server is a server that contains remote mailboxes. + + A shared mailbox, is a mailbox that multiple users have access to. + + An IMAP mailbox referral is when the server directs the client to + another IMAP mailbox. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + +3. Introduction and Overview + + IMAP4 servers that support this extension MUST list the keyword + MAILBOX-REFERRALS in their CAPABILITY response. No client action is + needed to invoke the MAILBOX-REFERRALS capability in a server. + + A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals + that result in a referrals loop. + + A referral response consists of a tagged NO response and a REFERRAL + response code. The REFERRAL response code MUST contain as an + argument a one or more valid URLs separated by a space as defined in + [RFC-1738]. If a server replies with multiple URLs for a particular + object, they MUST all be of the same type. In this case, the URL MUST + be an IMAP URL as defined in [RFC-2192]. A client that supports the + REFERRALS extension MUST be prepared for a URL of any type, but it + need only be able to process IMAP URLs. + + A server MAY respond with multiple IMAP mailbox referrals if there is + more than one replica of the mailbox. This allows the implementation + of a load balancing or failover scheme. How a server keeps multiple + replicas of a mailbox in sync is not addressed by this document. + + If the server has a preferred order in which the client should + attempt to access the URLs, the preferred URL SHOULD be listed in the + first, with the remaining URLs presented in descending order of + preference. If multiple referrals are given for a mailbox, a server + should be aware that there are synchronization issues for a client if + the UIDVALIDITY of the referred mailboxes are different. + + An IMAP mailbox referral may be given in response to an IMAP command + that specifies a mailbox as an argument. + + + + + + + + +Gahrns Standards Track [Page 2] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + Example: + + A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox + + NOTE: user;AUTH=* is specified as required by [RFC-2192] to avoid a + client falling back to anonymous login. + + Remote mailboxes and their inferiors, that are accessible only via + referrals SHOULD NOT appear in LIST and LSUB responses issued against + the user's home server. They MUST appear in RLIST and RLSUB + responses issued against the user's home server. Hierarchy referrals, + in which a client would be required to connect to the remote server + to issue a LIST to discover the inferiors of a mailbox are not + addressed in this document. + + For example, if shared mailboxes were only accessible via referrals + on a remote server, a RLIST "" "#SHARED/%" command would return the + same response if issued against the user's home server or the remote + server. + + Note: Mailboxes that are available on the user's home server do not + need to be available on the remote server. In addition, there may be + additional mailboxes available on the remote server, but they will + not accessible to the client via referrals unless they appear in the + LIST response to the RLIST command against the user's home server. + + A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB + commands in lieu of LIST and LSUB. The RLIST and RLSUB commands + behave identically to their LIST and LSUB counterparts, except remote + mailboxes are returned in addition to local mailboxes in the LIST and + LSUB responses. This avoids displaying to a non MAILBOX-REFERRALS + enabled client inaccessible remote mailboxes. + +4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND + Referrals + + An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE, + SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more + IMAP mailbox referrals to indicate to the client that the mailbox is + hosted on a remote server. + + When a client processes an IMAP mailbox referral, it will open a new + connection or use an existing connection to the remote server so that + it is able to issue the commands necessary to process the remote + mailbox. + + + + + + +Gahrns Standards Track [Page 3] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + Example: + + C: A001 DELETE "SHARED/FOO" + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] + Remote mailbox. Try SERVER2. + + + + S: * OK IMAP4rev1 server ready + C: B001 AUTHENTICATE KERBEROS_V4 + + S: B001 OK user is authenticated + + C: B002 DELETE "SHARED/FOO" + S: B002 OK DELETE completed + + Example: + + C: A001 SELECT REMOTE + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE + IMAP://user;AUTH=*@SERVER3/REMOTE] Remote mailbox. + Try SERVER2 or SERVER3. + + + + S: * OK IMAP4rev1 server ready + C: B001 AUTHENTICATE KERBEROS_V4 + + S: B001 OK user is authenticated + + C: B002 SELECT REMOTE + S: * 12 EXISTS + S: * 1 RECENT + S: * OK [UNSEEN 10] Message 10 is first unseen + S: * OK [UIDVALIDITY 123456789] + S: * FLAGS (Answered Flagged Deleted Seen Draft) + S: * OK [PERMANENTFLAGS (Answered Deleted Seen ] + S: B002 OK [READ-WRITE] Selected completed + + C: B003 FETCH 10:12 RFC822 + S: * 10 FETCH . . . + S: * 11 FETCH . . . + S: * 12 FETCH . . . + S: B003 OK FETCH Completed + + + + +Gahrns Standards Track [Page 4] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + + + C: B004 LOGOUT + S: * BYE IMAP4rev1 server logging out + S: B004 OK LOGOUT Completed + + + + C: A002 SELECT INBOX + S: * 16 EXISTS + S: * 2 RECENT + S: * OK [UNSEEN 10] Message 10 is first unseen + S: * OK [UIDVALIDITY 123456789] + S: * FLAGS (Answered Flagged Deleted Seen Draft) + S: * OK [PERMANENTFLAGS (Answered Deleted Seen ] + S: A002 OK [READ-WRITE] Selected completed + +4.2. CREATE Referrals + + An IMAP4 server MAY respond to the CREATE command with one or more + IMAP mailbox referrals, if it wishes to direct the client to issue + the CREATE against another server. The server can employ any means, + such as examining the hierarchy of the specified mailbox name, in + determining which server the mailbox should be created on. + + Example: + + C: A001 CREATE "SHARED/FOO" + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] + Mailbox should be created on remote server + + Alternatively, because a home server is required to maintain a + listing of referred remote mailboxes, a server MAY allow the creation + of a mailbox that will ultimately reside on a remote server against + the home server, and provide referrals on subsequent commands that + manipulate the mailbox. + + Example: + + C: A001 CREATE "SHARED/FOO" + S: A001 OK CREATE succeeded + + C: A002 SELECT "SHARED/FOO" + S: A002 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO] + Remote mailbox. Try SERVER2 + + + + + +Gahrns Standards Track [Page 5] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + +4.3. RENAME Referrals + + An IMAP4 server MAY respond to the RENAME command with one or more + pairs of IMAP mailbox referrals. In each pair of IMAP mailbox + referrals, the first one is an URL to the existing mailbox name and + the second is an URL to the requested new mailbox name. + + If within an IMAP mailbox referral pair, the existing and new mailbox + URLs are on different servers, the remote servers are unable to + perform the RENAME operation. To achieve the same behavior of + server RENAME, the client MAY issue the constituent CREATE, FETCH, + APPEND, and DELETE commands against both servers. + + If within an IMAP mailbox referral pair, the existing and new mailbox + URLs are on the same server it is an indication that the currently + connected server is unable to perform the operation. The client can + simply re-issue the RENAME command on the remote server. + + Example: + + C: A001 RENAME FOO BAR + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER1/FOO + IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox + across servers + + Since the existing and new mailbox names are on different servers, + the client would be required to make a connection to both servers and + issue the constituent commands require to achieve the RENAME. + + Example: + + C: A001 RENAME FOO BAR + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/FOO + IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox + located on SERVER2 + + Since both the existing and new mailbox are on the same remote + server, the client can simply make a connection to the remote server + and re-issue the RENAME command. + +4.4. COPY Referrals + + An IMAP4 server MAY respond to the COPY command with one or more IMAP + mailbox referrals. This indicates that the destination mailbox is on + a remote server. To achieve the same behavior of a server COPY, the + client MAY issue the constituent FETCH and APPEND commands against + both servers. + + + + +Gahrns Standards Track [Page 6] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + Example: + + C: A001 COPY 1 "SHARED/STUFF" + S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/STUFF] + Unable to copy message(s) to SERVER2. + +5.1 RLIST command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LIST + + Result: OK - RLIST Completed + NO - RLIST Failure + BAD - command unknown or arguments invalid + + The RLIST command behaves identically to its LIST counterpart, except + remote mailboxes are returned in addition to local mailboxes in the + LIST responses. + +5.2 RLSUB Command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LSUB + + Result: OK - RLSUB Completed + NO - RLSUB Failure + BAD - command unknown or arguments invalid + + The RLSUB command behaves identically to its LSUB counterpart, except + remote mailboxes are returned in addition to local mailboxes in the + LSUB responses. + +6. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) as described in [ABNF]. + + list_mailbox = as defined in [RFC-2060] + + mailbox = as defined in [RFC-2060] + + mailbox_referral = SPACE "NO" SPACE + (text / text_mime2) + ; See [RFC-2060] for , text and text_mime2 definition + + + +Gahrns Standards Track [Page 7] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + + referral_response_code = "[" "REFERRAL" 1*(SPACE ) "]" + ; See [RFC-1738] for definition + + rlist = "RLIST" SPACE mailbox SPACE list_mailbox + + rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox + +6. Security Considerations + + The IMAP4 referral mechanism makes use of IMAP URLs, and as such, + have the same security considerations as general internet URLs [RFC- + 1738], and in particular IMAP URLs [RFC-2192]. + + With the MAILBOX-REFERRALS capability, it is potentially easier to + write a rogue server that injects a bogus referral response that + directs a user to an incorrect mailbox. Although referrals reduce + the effort to write such a server, the referral response makes + detection of the intrusion easier. + +7. References + + [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + [RFC-2192], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, + September 1997. + + [RFC-1738], Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform + Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, + University of Minnesota, December 1994. + + [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, Harvard University, March 1997. + + [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for + Syntax Specifications: ABNF", Work in Progress, Internet Mail + Consortium, April 1997. + +8. Acknowledgments + + Many valuable suggestions were received from private discussions and + the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin, + Mark Keasling, Chris Newman and Larry Osterman made significant + contributions to this document. + + + + + + + +Gahrns Standards Track [Page 8] + +RFC 2193 IMAP4 Mailbox Referrals September 1997 + + +9. Author's Address + + Mike Gahrns + Microsoft + One Microsoft Way + Redmond, WA, 98072 + + Phone: (206) 936-9833 + EMail: mikega@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gahrns Standards Track [Page 9] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2195.txt b/server/src/site/resources/rfclist/imap4/rfc2195.txt new file mode 100644 index 00000000000..479fa28f674 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2195.txt @@ -0,0 +1,284 @@ + + + + + +Network Working Group J. Klensin +Request for Comments: 2195 R. Catoe +Category: Standards Track P. Krumviede +Obsoletes: 2095 MCI + September 1997 + + + IMAP/POP AUTHorize Extension for Simple Challenge/Response + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + While IMAP4 supports a number of strong authentication mechanisms as + described in RFC 1731, it lacks any mechanism that neither passes + cleartext, reusable passwords across the network nor requires either + a significant security infrastructure or that the mail server update + a mail-system-wide user authentication file on each mail access. + This specification provides a simple challenge-response + authentication protocol that is suitable for use with IMAP4. Since + it utilizes Keyed-MD5 digests and does not require that the secret be + stored in the clear on the server, it may also constitute an + improvement on APOP for POP3 use as specified in RFC 1734. + +1. Introduction + + Existing Proposed Standards specify an AUTHENTICATE mechanism for the + IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for + the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is + intended to be extensible; the four methods specified in [IMAP-AUTH] + are all fairly powerful and require some security infrastructure to + support. The base POP3 specification [POP3] also contains a + lightweight challenge-response mechanism called APOP. APOP is + associated with most of the risks associated with such protocols: in + particular, it requires that both the client and server machines have + access to the shared secret in cleartext form. CRAM offers a method + for avoiding such cleartext storage while retaining the algorithmic + simplicity of APOP in using only MD5, though in a "keyed" method. + + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 1] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + + At present, IMAP [IMAP] lacks any facility corresponding to APOP. + The only alternative to the strong mechanisms identified in [IMAP- + AUTH] is a presumably cleartext username and password, supported + through the LOGIN command in [IMAP]. This document describes a + simple challenge-response mechanism, similar to APOP and PPP CHAP + [PPP], that can be used with IMAP (and, in principle, with POP3). + + This mechanism also has the advantage over some possible alternatives + of not requiring that the server maintain information about email + "logins" on a per-login basis. While mechanisms that do require such + per-login history records may offer enhanced security, protocols such + as IMAP, which may have several connections between a given client + and server open more or less simultaneous, may make their + implementation particularly challenging. + +2. Challenge-Response Authentication Mechanism (CRAM) + + The authentication type associated with CRAM is "CRAM-MD5". + + The data encoded in the first ready response contains an + presumptively arbitrary string of random digits, a timestamp, and the + fully-qualified primary host name of the server. The syntax of the + unencoded form must correspond to that of an RFC 822 'msg-id' + [RFC822] as described in [POP3]. + + The client makes note of the data and then responds with a string + consisting of the user name, a space, and a 'digest'. The latter is + computed by applying the keyed MD5 algorithm from [KEYED-MD5] where + the key is a shared secret and the digested text is the timestamp + (including angle-brackets). + + This shared secret is a string known only to the client and server. + The `digest' parameter itself is a 16-octet value which is sent in + hexadecimal format, using lower-case ASCII characters. + + When the server receives this client response, it verifies the digest + provided. If the digest is correct, the server should consider the + client authenticated and respond appropriately. + + Keyed MD5 is chosen for this application because of the greater + security imparted to authentication of short messages. In addition, + the use of the techniques described in [KEYED-MD5] for precomputation + of intermediate results make it possible to avoid explicit cleartext + storage of the shared secret on the server system by instead storing + the intermediate results which are known as "contexts". + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 2] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + + CRAM does not support a protection mechanism. + + Example: + + The examples in this document show the use of the CRAM mechanism with + the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of + the challenges and responses is part of the IMAP4 AUTHENTICATE + command, not part of the CRAM specification itself. + + S: * OK IMAP4 Server + C: A0001 AUTHENTICATE CRAM-MD5 + S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ + C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw + S: A0001 OK CRAM authentication successful + + In this example, the shared secret is the string + 'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by + calculating + + MD5((tanstaaftanstaaf XOR opad), + MD5((tanstaaftanstaaf XOR ipad), + <1896.697170952@postoffice.reston.mci.net>)) + + where ipad and opad are as defined in the keyed-MD5 Work in + Progress [KEYED-MD5] and the string shown in the challenge is the + base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The + shared secret is null-padded to a length of 64 bytes. If the + shared secret is longer than 64 bytes, the MD5 digest of the + shared secret is used as a 16 byte input to the keyed MD5 + calculation. + + This produces a digest value (in hexadecimal) of + + b913a602c7eda7a495b4e6e7334d3890 + + The user name is then prepended to it, forming + + tim b913a602c7eda7a495b4e6e7334d3890 + + Which is then base64 encoded to meet the requirements of the IMAP4 + AUTHENTICATE command (or the similar POP3 AUTH command), yielding + + dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw + + + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 3] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + +3. References + + [CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", + RFC 1334, October 1992. + + [IMAP] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", + RFC 1731, Carnegie Mellon, December 1994. + + [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for + Message Authentication", RFC 2104, February 1997. + + [MD5] Rivest, R., "The MD5 Message Digest Algorithm", + RFC 1321, MIT Laboratory for Computer Science, April 1992. + + [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, Carnegie Mellon, May 1996. + + [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, + Carnegie Mellon, December, 1994. + +4. Security Considerations + + It is conjectured that use of the CRAM authentication mechanism + provides origin identification and replay protection for a session. + Accordingly, a server that implements both a cleartext password + command and this authentication type should not allow both methods of + access for a given user. + + While the saving, on the server, of "contexts" (see section 2) is + marginally better than saving the shared secrets in cleartext as is + required by CHAP [CHAP] and APOP [POP3], it is not sufficient to + protect the secrets if the server itself is compromised. + Consequently, servers that store the secrets or contexts must both be + protected to a level appropriate to the potential information value + in user mailboxes and identities. + + As the length of the shared secret increases, so does the difficulty + of deriving it. + + While there are now suggestions in the literature that the use of MD5 + and keyed MD5 in authentication procedures probably has a limited + effective lifetime, the technique is now widely deployed and widely + understood. It is believed that this general understanding may + assist with the rapid replacement, by CRAM-MD5, of the current uses + of permanent cleartext passwords in IMAP. This document has been + + + +Klensin, Catoe & Krumviede Standards Track [Page 4] + +RFC 2195 IMAP/POP AUTHorize Extension September 1997 + + + deliberately written to permit easy upgrading to use SHA (or whatever + alternatives emerge) when they are considered to be widely available + and adequately safe. + + Even with the use of CRAM, users are still vulnerable to active + attacks. An example of an increasingly common active attack is 'TCP + Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95]. + + See section 1 above for additional discussion. + +5. Acknowledgements + + This memo borrows ideas and some text liberally from [POP3] and + [RFC-1731] and thanks are due the authors of those documents. Ran + Atkinson made a number of valuable technical and editorial + contributions to the document. + +6. Authors' Addresses + + John C. Klensin + MCI Telecommunications + 800 Boylston St, 7th floor + Boston, MA 02199 + USA + + EMail: klensin@mci.net + Phone: +1 617 960 1011 + + Randy Catoe + MCI Telecommunications + 2100 Reston Parkway + Reston, VA 22091 + USA + + EMail: randy@mci.net + Phone: +1 703 715 7366 + + Paul Krumviede + MCI Telecommunications + 2100 Reston Parkway + Reston, VA 22091 + USA + + EMail: paul@mci.net + Phone: +1 703 715 7251 + + + + + + +Klensin, Catoe & Krumviede Standards Track [Page 5] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2221.txt b/server/src/site/resources/rfclist/imap4/rfc2221.txt new file mode 100644 index 00000000000..78f73c90289 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2221.txt @@ -0,0 +1,284 @@ + + + + + +Network Working Group M. Gahrns +Request for Comments: 2221 Microsoft +Category: Standards Track October 1997 + + + IMAP4 Login Referrals + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1997). All Rights Reserved. + +1. Abstract + + When dealing with large amounts of users and many IMAP4 [RFC-2060] + servers, it is often necessary to move users from one IMAP4 server to + another. For example, hardware failures or organizational changes + may dictate such a move. + + Login referrals allow clients to transparently connect to an + alternate IMAP4 server, if their home IMAP4 server has changed. + + A referral mechanism can provide efficiencies over the alternative + 'proxy method', in which the local IMAP4 server contacts the remote + server on behalf of the client, and then transfers the data from the + remote server to itself, and then on to the client. The referral + mechanism's direct client connection to the remote server is often a + more efficient use of bandwidth, and does not require the local + server to impersonate the client when authenticating to the remote + server. + +2. Conventions used in this document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + A home server, is an IMAP4 server that contains the user's inbox. + + A remote server is a server that contains remote mailboxes. + + + + + +Gahrns Standards Track [Page 1] + +RFC 2221 IMAP4 Login Referrals October 1997 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + +3. Introduction and Overview + + IMAP4 servers that support this extension MUST list the keyword + LOGIN-REFERRALS in their CAPABILITY response. No client action is + needed to invoke the LOGIN-REFERRALS capability in a server. + + A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral + to a server that will return a referral. A client MUST NOT follow + more than 10 levels of referral without consulting the user. + + A LOGIN-REFERRALS response code MUST contain as an argument a valid + IMAP server URL as defined in [IMAP-URL]. + + A home server referral consists of either a tagged NO or OK, or an + untagged BYE response that contains a LOGIN-REFERRALS response code. + + Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server + + NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a + client falling back to anonymous login. + +4. Home Server Referrals + + A home server referral may be returned in response to an AUTHENTICATE + or LOGIN command, or it may appear in the connection startup banner. + If a server returns a home server referral in a tagged NO response, + that server does not contain any mailboxes that are accessible to the + user. If a server returns a home server referral in a tagged OK + response, it indicates that the user's personal mailboxes are + elsewhere, but the server contains public mailboxes which are + readable by the user. After receiving a home server referral, the + client can not make any assumptions as to whether this was a + permanent or temporary move of the user. + +4.1. LOGIN and AUTHENTICATE Referrals + + An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a + home server referral if it wishes to direct the user to another IMAP4 + server. + + Example: C: A001 LOGIN MIKE PASSWORD + S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user + is invalid on this server. Try SERVER2. + + + + +Gahrns Standards Track [Page 2] + +RFC 2221 IMAP4 Login Referrals October 1997 + + + Example: C: A001 LOGIN MATTHEW PASSWORD + S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified + user's personal mailboxes located on Server2, but + public mailboxes are available. + + Example: C: A001 AUTHENTICATE GSSAPI + + S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/] + Specified user is invalid on this server. Try + SERVER2. + +4.2. BYE at connection startup referral + + An IMAP4 server MAY respond with an untagged BYE and a REFERRAL + response code that contains an IMAP URL to a home server if it is not + willing to accept connections and wishes to direct the client to + another IMAP4 server. + + Example: S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not + accepting connections. Try SERVER2 + +5. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) as described in [ABNF]. + + This amends the "resp_text_code" element of the IMAP4 grammar + described in [RFC-2060] + + resp_text_code =/ "REFERRAL" SPACE + ; See [IMAP-URL] for definition of + ; See [RFC-2060] for base definition of resp_text_code + +6. Security Considerations + + The IMAP4 login referral mechanism makes use of IMAP URLs, and as + such, have the same security considerations as general internet URLs + [RFC-1738], and in particular IMAP URLs [IMAP-URL]. + + A server MUST NOT give a login referral if authentication for that + user fails. This is to avoid revealing information about the user's + account to an unauthorized user. + + With the LOGIN-REFERRALS capability, it is potentially easier to + write a rogue 'password catching' server that collects login data and + then refers the client to their actual IMAP4 server. Although + referrals reduce the effort to write such a server, the referral + response makes detection of the intrusion easier. + + + +Gahrns Standards Track [Page 3] + +RFC 2221 IMAP4 Login Referrals October 1997 + + +7. References + + [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, + September 1997. + + [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform + Resource Locators (URL)", RFC 1738, December 1994. + + [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for + Syntax Specifications: ABNF", Work in Progress. + +8. Acknowledgments + + Many valuable suggestions were received from private discussions and + the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin, + Mark Keasling Chris Newman and Larry Osterman made significant + contributions to this document. + +9. Author's Address + + Mike Gahrns + Microsoft + One Microsoft Way + Redmond, WA, 98072 + + Phone: (206) 936-9833 + EMail: mikega@microsoft.com + + + + + + + + + + + + + + + + + + +Gahrns Standards Track [Page 4] + +RFC 2221 IMAP4 Login Referrals October 1997 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (1997). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implmentation may be prepared, copied, published + andand distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + + + + + + + + + + + + + + + + + + + + + + + + +Gahrns Standards Track [Page 5] + + + diff --git a/server/src/site/resources/rfclist/imap4/rfc2342.txt b/server/src/site/resources/rfclist/imap4/rfc2342.txt new file mode 100644 index 00000000000..f1c8c409412 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2342.txt @@ -0,0 +1,564 @@ + + + + + +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 , where 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 , + where 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 = + ; 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 = + ; as defined in [RFC-2060] + + QUOTED_CHAR = + ; as defined in [RFC-2060] + + 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/server/src/site/resources/rfclist/imap4/rfc2359.txt b/server/src/site/resources/rfclist/imap4/rfc2359.txt new file mode 100644 index 00000000000..ad938a42c5a --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2359.txt @@ -0,0 +1,340 @@ + + + + + +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 + C: Subject: afternoon meeting + C: To: mooch@owatagu.siam.edu + C: Message-Id: + C: MIME-Version: 1.0 + C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + C: + C: Hello Joe, do you think we can meet at 3:30 tomorrow? + C: + S: A003 OK [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/server/src/site/resources/rfclist/imap4/rfc2595.txt b/server/src/site/resources/rfclist/imap4/rfc2595.txt new file mode 100644 index 00000000000..66897cd6c97 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2595.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group C. Newman +Request for Comments: 2595 Innosoft +Category: Standards Track June 1999 + + + Using TLS with IMAP, POP3 and ACAP + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Motivation + + The TLS protocol (formerly known as SSL) provides a way to secure an + application protocol from tampering and eavesdropping. The option of + using such security is desirable for IMAP, POP and ACAP due to common + connection eavesdropping and hijacking attacks [AUTH]. Although + advanced SASL authentication mechanisms can provide a lightweight + version of this service, TLS is complimentary to simple + authentication-only SASL mechanisms or deployed clear-text password + login commands. + + Many sites have a high investment in authentication infrastructure + (e.g., a large database of a one-way-function applied to user + passwords), so a privacy layer which is not tightly bound to user + authentication can protect against network eavesdropping attacks + without requiring a new authentication infrastructure and/or forcing + all users to change their password. Recognizing that such sites will + desire simple password authentication in combination with TLS + encryption, this specification defines the PLAIN SASL mechanism for + use with protocols which lack a simple password authentication + command such as ACAP and SMTP. (Note there is a separate RFC for the + STARTTLS command in SMTP [SMTPTLS].) + + There is a strong desire in the IETF to eliminate the transmission of + clear-text passwords over unencrypted channels. While SASL can be + used for this purpose, TLS provides an additional tool with different + deployability characteristics. A server supporting both TLS with + + + + +Newman Standards Track [Page 1] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + simple passwords and a challenge/response SASL mechanism is likely to + interoperate with a wide variety of clients without resorting to + unencrypted clear-text passwords. + + The STARTTLS command rectifies a number of the problems with using a + separate port for a "secure" protocol variant. Some of these are + mentioned in section 7. + +1.1. Conventions Used in this Document + + The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", + "MAY", and "OPTIONAL" in this document are to be interpreted as + described in "Key words for use in RFCs to Indicate Requirement + Levels" [KEYWORDS]. + + Terms related to authentication are defined in "On Internet + Authentication" [AUTH]. + + Formal syntax is defined using ABNF [ABNF]. + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + +2. Basic Interoperability and Security Requirements + + The following requirements apply to all implementations of the + STARTTLS extension for IMAP, POP3 and ACAP. + +2.1. Cipher Suite Requirements + + Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher + suite is REQUIRED. This is important as it assures that any two + compliant implementations can be configured to interoperate. + + All other cipher suites are OPTIONAL. + +2.2. Privacy Operational Mode Security Requirements + + Both clients and servers SHOULD have a privacy operational mode which + refuses authentication unless successful activation of an encryption + layer (such as that provided by TLS) occurs prior to or at the time + of authentication and which will terminate the connection if that + encryption layer is deactivated. Implementations are encouraged to + have flexability with respect to the minimal encryption strength or + cipher suites permitted. A minimalist approach to this + recommendation would be an operational mode where the + TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to + permitting authentication. + + + +Newman Standards Track [Page 2] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + Clients MAY have an operational mode which uses encryption only when + it is advertised by the server, but authentication continues + regardless. For backwards compatibility, servers SHOULD have an + operational mode where only the authentication mechanisms required by + the relevant base protocol specification are needed to successfully + authenticate. + +2.3. Clear-Text Password Requirements + + Clients and servers which implement STARTTLS MUST be configurable to + refuse all clear-text login commands or mechanisms (including both + standards-track and nonstandard mechanisms) unless an encryption + layer of adequate strength is active. Servers which allow + unencrypted clear-text logins SHOULD be configurable to refuse + clear-text logins both for the entire server, and on a per-user + basis. + +2.4. Server Identity Check + + During the TLS negotiation, the client MUST check its understanding + of the server hostname against the server's identity as presented in + the server Certificate message, in order to prevent man-in-the-middle + attacks. Matching is performed according to these rules: + + - The client MUST use the server hostname it used to open the + connection as the value to compare against the server name as + expressed in the server certificate. The client MUST NOT use any + form of the server hostname derived from an insecure remote source + (e.g., insecure DNS lookup). CNAME canonicalization is not done. + + - If a subjectAltName extension of type dNSName is present in the + certificate, it SHOULD be used as the source of the server's + identity. + + - Matching is case-insensitive. + + - A "*" wildcard character MAY be used as the left-most name + component in the certificate. For example, *.example.com would + match a.example.com, foo.example.com, etc. but would not match + example.com. + + - If the certificate contains multiple names (e.g. more than one + dNSName field), then a match with any one of the fields is + considered acceptable. + + If the match fails, the client SHOULD either ask for explicit user + confirmation, or terminate the connection and indicate the server's + identity is suspect. + + + +Newman Standards Track [Page 3] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +2.5. TLS Security Policy Check + + Both the client and server MUST check the result of the STARTTLS + command and subsequent TLS negotiation to see whether acceptable + authentication or privacy was achieved. Ignoring this step + completely invalidates using TLS for security. The decision about + whether acceptable authentication or privacy was achieved is made + locally, is implementation-dependent, and is beyond the scope of this + document. + +3. IMAP STARTTLS extension + + When the TLS extension is present in IMAP, "STARTTLS" is listed as a + capability in response to the CAPABILITY command. This extension + adds a single command, "STARTTLS" to the IMAP protocol which is used + to begin a TLS negotiation. + +3.1. STARTTLS Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - begin TLS negotiation + BAD - command unknown or arguments invalid + + A TLS negotiation begins immediately after the CRLF at the end of + the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. + The server remains in non-authenticated state, even if client + credentials are supplied during the TLS negotiation. The SASL + [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS + client credentials are successfully exchanged, but servers + supporting the STARTTLS command are not required to support the + EXTERNAL mechanism. + + Once TLS has been started, the client MUST discard cached + information about server capabilities and SHOULD re-issue the + CAPABILITY command. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list prior + to STARTTLS. The server MAY advertise different capabilities + after STARTTLS. + + The formal syntax for IMAP is amended as follows: + + + + +Newman Standards Track [Page 4] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + command_any =/ "STARTTLS" + + Example: C: a001 CAPABILITY + S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED + S: a001 OK CAPABILITY completed + C: a002 STARTTLS + S: a002 OK Begin TLS negotiation now + + C: a003 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL + S: a003 OK CAPABILITY completed + C: a004 LOGIN joe password + S: a004 OK LOGIN completed + +3.2. IMAP LOGINDISABLED capability + + The current IMAP protocol specification (RFC 2060) requires the + implementation of the LOGIN command which uses clear-text passwords. + Many sites may choose to disable this command unless encryption is + active for security reasons. An IMAP server MAY advertise that the + LOGIN command is disabled by including the LOGINDISABLED capability + in the capability response. Such a server will respond with a tagged + "NO" response to any attempt to use the LOGIN command. + + An IMAP server which implements STARTTLS MUST implement support for + the LOGINDISABLED capability on unencrypted connections. + + An IMAP client which complies with this specification MUST NOT issue + the LOGIN command if this capability is present. + + This capability is useful to prevent clients compliant with this + specification from sending an unencrypted password in an environment + subject to passive attacks. It has no impact on an environment + subject to active attacks as a man-in-the-middle attacker can remove + this capability. Therefore this does not relieve clients of the need + to follow the privacy mode recommendation in section 2.2. + + Servers advertising this capability will fail to interoperate with + many existing compliant IMAP clients and will be unable to prevent + those clients from disclosing the user's password. + +4. POP3 STARTTLS extension + + The POP3 STARTTLS extension adds the STLS command to POP3 servers. + If this is implemented, the POP3 extension mechanism [POP3EXT] MUST + also be implemented to avoid the need for client probing of multiple + commands. The capability name "STLS" indicates this command is + present and permitted in the current state. + + + +Newman Standards Track [Page 5] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + STLS + + Arguments: none + + Restrictions: + Only permitted in AUTHORIZATION state. + + Discussion: + A TLS negotiation begins immediately after the CRLF at the + end of the +OK response from the server. A -ERR response + MAY result if a security layer is already active. Once a + client issues a STLS command, it MUST NOT issue further + commands until a server response is seen and the TLS + negotiation is complete. + + The STLS command is only permitted in AUTHORIZATION state + and the server remains in AUTHORIZATION state, even if + client credentials are supplied during the TLS negotiation. + The AUTH command [POP-AUTH] with the EXTERNAL mechanism + [SASL] MAY be used to authenticate once TLS client + credentials are successfully exchanged, but servers + supporting the STLS command are not required to support the + EXTERNAL mechanism. + + Once TLS has been started, the client MUST discard cached + information about server capabilities and SHOULD re-issue + the CAPA command. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list + prior to STLS. The server MAY advertise different + capabilities after STLS. + + Possible Responses: + +OK -ERR + + Examples: + C: STLS + S: +OK Begin TLS negotiation + + ... + C: STLS + S: -ERR Command not permitted when TLS active + + + + + + + + + + +Newman Standards Track [Page 6] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +5. ACAP STARTTLS extension + + When the TLS extension is present in ACAP, "STARTTLS" is listed as a + capability in the ACAP greeting. No arguments to this capability are + defined at this time. This extension adds a single command, + "STARTTLS" to the ACAP protocol which is used to begin a TLS + negotiation. + +5.1. STARTTLS Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - begin TLS negotiation + BAD - command unknown or arguments invalid + + A TLS negotiation begins immediately after the CRLF at the end of + the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. + The server remains in non-authenticated state, even if client + credentials are supplied during the TLS negotiation. The SASL + [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS + client credentials are successfully exchanged, but servers + supporting the STARTTLS command are not required to support the + EXTERNAL mechanism. + + After the TLS layer is established, the server MUST re-issue an + untagged ACAP greeting. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list prior + to STARTTLS. The client MUST discard cached capability + information and replace it with the information from the new ACAP + greeting. The server MAY advertise different capabilities after + STARTTLS. + + The formal syntax for ACAP is amended as follows: + + command_any =/ "STARTTLS" + + Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) + C: a002 STARTTLS + S: a002 OK "Begin TLS negotiation now" + + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + + + + +Newman Standards Track [Page 7] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +6. PLAIN SASL mechanism + + Clear-text passwords are simple, interoperate with almost all + existing operating system authentication databases, and are useful + for a smooth transition to a more secure password-based + authentication mechanism. The drawback is that they are unacceptable + for use over an unencrypted network connection. + + This defines the "PLAIN" SASL mechanism for use with ACAP and other + protocols with no clear-text login command. The PLAIN SASL mechanism + MUST NOT be advertised or used unless a strong encryption layer (such + as the provided by TLS) is active or backwards compatibility dictates + otherwise. + + The mechanism consists of a single message from the client to the + server. The client sends the authorization identity (identity to + login as), followed by a US-ASCII NUL character, followed by the + authentication identity (identity whose password will be used), + followed by a US-ASCII NUL character, followed by the clear-text + password. The client may leave the authorization identity empty to + indicate that it is the same as the authentication identity. + + The server will verify the authentication identity and password with + the system authentication database and verify that the authentication + credentials permit the client to login as the authorization identity. + If both steps succeed, the user is logged in. + + The server MAY also use the password to initialize any new + authentication database, such as one suitable for CRAM-MD5 + [CRAM-MD5]. + + Non-US-ASCII characters are permitted as long as they are represented + in UTF-8 [UTF-8]. Use of non-visible characters or characters which + a user may be unable to enter on some keyboards is discouraged. + + The formal grammar for the client message using Augmented BNF [ABNF] + follows. + + message = [authorize-id] NUL authenticate-id NUL password + authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets + authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets + password = 1*UTF8-SAFE ; MUST accept up to 255 octets + NUL = %x00 + UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / + UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 + UTF8-1 = %x80-BF + UTF8-2 = %xC0-DF UTF8-1 + UTF8-3 = %xE0-EF 2UTF8-1 + + + +Newman Standards Track [Page 8] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + UTF8-4 = %xF0-F7 3UTF8-1 + UTF8-5 = %xF8-FB 4UTF8-1 + UTF8-6 = %xFC-FD 5UTF8-1 + + Here is an example of how this might be used to initialize a CRAM-MD5 + authentication database for ACAP: + + Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) + C: a001 AUTHENTICATE "CRAM-MD5" + S: + "<1896.697170952@postoffice.reston.mci.net>" + C: "tim b913a602c7eda7a495b4e6e7334d3890" + S: a001 NO (TRANSITION-NEEDED) + "Please change your password, or use TLS to login" + C: a002 STARTTLS + S: a002 OK "Begin TLS negotiation now" + + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + C: a003 AUTHENTICATE "PLAIN" {21+} + C: timtanstaaftanstaaf + S: a003 OK CRAM-MD5 password initialized + + Note: In this example, represents a single ASCII NUL octet. + +7. imaps and pop3s ports + + Separate "imaps" and "pop3s" ports were registered for use with SSL. + Use of these ports is discouraged in favor of the STARTTLS or STLS + commands. + + A number of problems have been observed with separate ports for + "secure" variants of protocols. This is an attempt to enumerate some + of those problems. + + - Separate ports lead to a separate URL scheme which intrudes into + the user interface in inappropriate ways. For example, many web + pages use language like "click here if your browser supports SSL." + This is a decision the browser is often more capable of making than + the user. + + - Separate ports imply a model of either "secure" or "not secure." + This can be misleading in a number of ways. First, the "secure" + port may not in fact be acceptably secure as an export-crippled + cipher suite might be in use. This can mislead users into a false + sense of security. Second, the normal port might in fact be + secured by using a SASL mechanism which includes a security layer. + Thus the separate port distinction makes the complex topic of + security policy even more confusing. One common result of this + confusion is that firewall administrators are often misled into + + + +Newman Standards Track [Page 9] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + permitting the "secure" port and blocking the standard port. This + could be a poor choice given the common use of SSL with a 40-bit + key encryption layer and plain-text password authentication is less + secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. + + - Use of separate ports for SSL has caused clients to implement only + two security policies: use SSL or don't use SSL. The desirable + security policy "use TLS when available" would be cumbersome with + the separate port model, but is simple with STARTTLS. + + - Port numbers are a limited resource. While they are not yet in + short supply, it is unwise to set a precedent that could double (or + worse) the speed of their consumption. + + +8. IANA Considerations + + This constitutes registration of the "STARTTLS" and "LOGINDISABLED" + IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP]. + + The registration for the POP3 "STLS" capability follows: + + CAPA tag: STLS + Arguments: none + Added commands: STLS + Standard commands affected: May enable USER/PASS as a side-effect. + CAPA command SHOULD be re-issued after successful completion. + Announced states/Valid states: AUTHORIZATION state only. + Specification reference: this memo + + The registration for the ACAP "STARTTLS" capability follows: + + Capability name: STARTTLS + Capability keyword: STARTTLS + Capability arguments: none + Published Specification(s): this memo + Person and email address for further information: + see author's address section below + + The registration for the PLAIN SASL mechanism follows: + + SASL mechanism name: PLAIN + Security Considerations: See section 9 of this memo + Published specification: this memo + Person & email address to contact for further information: + see author's address section below + Intended usage: COMMON + Author/Change controller: see author's address section below + + + +Newman Standards Track [Page 10] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +9. Security Considerations + + TLS only provides protection for data sent over a network connection. + Messages transferred over IMAP or POP3 are still available to server + administrators and usually subject to eavesdropping, tampering and + forgery when transmitted through SMTP or NNTP. TLS is no substitute + for an end-to-end message security mechanism using MIME security + multiparts [MIME-SEC]. + + A man-in-the-middle attacker can remove STARTTLS from the capability + list or generate a failure response to the STARTTLS command. In + order to detect such an attack, clients SHOULD warn the user when + session privacy is not active and/or be configurable to refuse to + proceed without an acceptable level of security. + + A man-in-the-middle attacker can always cause a down-negotiation to + the weakest authentication mechanism or cipher suite available. For + this reason, implementations SHOULD be configurable to refuse weak + mechanisms or cipher suites. + + Any protocol interactions prior to the TLS handshake are performed in + the clear and can be modified by a man-in-the-middle attacker. For + this reason, clients MUST discard cached information about server + capabilities advertised prior to the start of the TLS handshake. + + Clients are encouraged to clearly indicate when the level of + encryption active is known to be vulnerable to attack using modern + hardware (such as encryption keys with 56 bits of entropy or less). + + The LOGINDISABLED IMAP capability (discussed in section 3.2) only + reduces the potential for passive attacks, it provides no protection + against active attacks. The responsibility remains with the client + to avoid sending a password over a vulnerable channel. + + The PLAIN mechanism relies on the TLS encryption layer for security. + When used without TLS, it is vulnerable to a common network + eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used + unless a suitable TLS encryption layer is active or backwards + compatibility dictates otherwise. + + When the PLAIN mechanism is used, the server gains the ability to + impersonate the user to all services with the same password + regardless of any encryption provided by TLS or other network privacy + mechanisms. While many other authentication mechanisms have similar + weaknesses, stronger SASL mechanisms such as Kerberos address this + issue. Clients are encouraged to have an operational mode where all + mechanisms which are likely to reveal the user's password to the + server are disabled. + + + +Newman Standards Track [Page 11] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + The security considerations for TLS apply to STARTTLS and the + security considerations for SASL apply to the PLAIN mechanism. + Additional security requirements are discussed in section 2. + +10. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [ACAP] Newman, C. and J. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, November 1997. + + [AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", + RFC 1704, October 1994. + + [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP + AUTHorize Extension for Simple Challenge/Response", RFC + 2195, September 1997. + + [IMAP] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed, + "Security Multiparts for MIME: Multipart/Signed and + Multipart/Encrypted", RFC 1847, October 1995. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, May 1996. + + [POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension + Mechanism", RFC 2449, November 1998. + + [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, + December 1994. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over + TLS", RFC 2487, January 1999. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + + + + +Newman Standards Track [Page 12] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + +11. Author's Address + + Chris Newman + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 USA + + EMail: chris.newman@innosoft.com + + +A. Appendix -- Compliance Checklist + + An implementation is not compliant if it fails to satisfy one or more + of the MUST requirements for the protocols it implements. An + implementation that satisfies all the MUST and all the SHOULD + requirements for its protocols is said to be "unconditionally + compliant"; one that satisfies all the MUST requirements but not all + the SHOULD requirements for its protocols is said to be + "conditionally compliant". + + Rules Section + ----- ------- + Mandatory-to-implement Cipher Suite 2.1 + SHOULD have mode where encryption required 2.2 + server SHOULD have mode where TLS not required 2.2 + MUST be configurable to refuse all clear-text login + commands or mechanisms 2.3 + server SHOULD be configurable to refuse clear-text + login commands on entire server and on per-user basis 2.3 + client MUST check server identity 2.4 + client MUST use hostname used to open connection 2.4 + client MUST NOT use hostname from insecure remote lookup 2.4 + client SHOULD support subjectAltName of dNSName type 2.4 + client SHOULD ask for confirmation or terminate on fail 2.4 + MUST check result of STARTTLS for acceptable privacy 2.5 + client MUST NOT issue commands after STARTTLS + until server response and negotiation done 3.1,4,5.1 + client MUST discard cached information 3.1,4,5.1,9 + client SHOULD re-issue CAPABILITY/CAPA command 3.1,4 + IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2 + IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2 + POP server MUST implement POP3 extensions 4 + ACAP server MUST re-issue ACAP greeting 5.1 + + + + +Newman Standards Track [Page 13] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + client SHOULD warn when session privacy not active and/or + refuse to proceed without acceptable security level 9 + SHOULD be configurable to refuse weak mechanisms or + cipher suites 9 + + The PLAIN mechanism is an optional part of this specification. + However if it is implemented the following rules apply: + + Rules Section + ----- ------- + MUST NOT use PLAIN unless strong encryption active + or backwards compatibility dictates otherwise 6,9 + MUST use UTF-8 encoding for characters in PLAIN 6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 14] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 15] + diff --git a/server/src/site/resources/rfclist/imap4/rfc2683.txt b/server/src/site/resources/rfclist/imap4/rfc2683.txt new file mode 100644 index 00000000000..d92e3405651 --- /dev/null +++ b/server/src/site/resources/rfclist/imap4/rfc2683.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group B. Leiba +Request for Comments: 2683 IBM T.J. Watson Research Center +Category: Informational September 1999 + + + IMAP4 Implementation Recommendations + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Abstract + + The IMAP4 specification [RFC-2060] describes a rich protocol for use + in building clients and servers for storage, retrieval, and + manipulation of electronic mail. Because the protocol is so rich and + has so many implementation choices, there are often trade-offs that + must be made and issues that must be considered when designing such + clients and servers. This document attempts to outline these issues + and to make recommendations in order to make the end products as + interoperable as possible. + +2. Conventions used in this document + + In examples, "C:" indicates lines sent by a client that is connected + to a server. "S:" indicates lines sent by the server to the client. + + The words "must", "must not", "should", "should not", and "may" are + used with specific meaning in this document; since their meaning is + somewhat different from that specified in RFC 2119, we do not put + them in all caps here. Their meaning is as follows: + + must -- This word means that the action described is necessary + to ensure interoperability. The recommendation should + not be ignored. + must not -- This phrase means that the action described will be + almost certain to hurt interoperability. The + recommendation should not be ignored. + + + + + + + +Leiba Informational [Page 1] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + should -- This word means that the action described is strongly + recommended and will enhance interoperability or + usability. The recommendation should not be ignored + without careful consideration. + should not -- This phrase means that the action described is strongly + recommended against, and might hurt interoperability or + usability. The recommendation should not be ignored + without careful consideration. + may -- This word means that the action described is an + acceptable implementation choice. No specific + recommendation is implied; this word is used to point + out a choice that might not be obvious, or to let + implementors know what choices have been made by + existing implementations. + +3. Interoperability Issues and Recommendations + +3.1. Accessibility + + This section describes the issues related to access to servers and + server resources. Concerns here include data sharing and maintenance + of client/server connections. + +3.1.1. Multiple Accesses of the Same Mailbox + + One strong point of IMAP4 is that, unlike POP3, it allows for + multiple simultaneous access to a single mailbox. A user can, thus, + read mail from a client at home while the client in the office is + still connected; or the help desk staff can all work out of the same + inbox, all seeing the same pool of questions. An important point + about this capability, though is that NO SERVER IS GUARANTEED TO + SUPPORT THIS. If you are selecting an IMAP server and this facility + is important to you, be sure that the server you choose to install, + in the configuration you choose to use, supports it. + + If you are designing a client, you must not assume that you can + access the same mailbox more than once at a time. That means + + 1. you must handle gracefully the failure of a SELECT command if the + server refuses the second SELECT, + 2. you must handle reasonably the severing of your connection (see + "Severed Connections", below) if the server chooses to allow the + second SELECT by forcing the first off, + 3. you must avoid making multiple connections to the same mailbox in + your own client (for load balancing or other such reasons), and + 4. you must avoid using the STATUS command on a mailbox that you have + selected (with some server implementations the STATUS command has + the same problems with multiple access as do the SELECT and + + + +Leiba Informational [Page 2] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + EXAMINE commands). + + A further note about STATUS: The STATUS command is sometimes used to + check a non-selected mailbox for new mail. This mechanism must not + be used to check for new mail in the selected mailbox; section 5.2 of + [RFC-2060] specifically forbids this in its last paragraph. Further, + since STATUS takes a mailbox name it is an independent operation, not + operating on the selected mailbox. Because of this, the information + it returns is not necessarily in synchronization with the selected + mailbox state. + +3.1.2. Severed Connections + + The client/server connection may be severed for one of three reasons: + the client severs the connection, the server severs the connection, + or the connection is severed by outside forces beyond the control of + the client and the server (a telephone line drops, for example). + Clients and servers must both deal with these situations. + + When the client wants to sever a connection, it's usually because it + has finished the work it needed to do on that connection. The client + should send a LOGOUT command, wait for the tagged response, and then + close the socket. But note that, while this is what's intended in + the protocol design, there isn't universal agreement here. Some + contend that sending the LOGOUT and waiting for the two responses + (untagged BYE and tagged OK) is wasteful and unnecessary, and that + the client can simply close the socket. The server should interpret + the closed socket as a log out by the client. The counterargument is + that it's useful from the standpoint of cleanup, problem + determination, and the like, to have an explicit client log out, + because otherwise there is no way for the server to tell the + difference between "closed socket because of log out" and "closed + socket because communication was disrupted". If there is a + client/server interaction problem, a client which routinely + terminates a session by breaking the connection without a LOGOUT will + make it much more difficult to determine the problem. + + Because of this disagreement, server designers must be aware that + some clients might close the socket without sending a LOGOUT. In any + case, whether or not a LOGOUT was sent, the server should not + implicitly expunge any messages from the selected mailbox. If a + client wants the server to do so, it must send a CLOSE or EXPUNGE + command explicitly. + + When the server wants to sever a connection it's usually due to an + inactivity timeout or is because a situation has arisen that has + changed the state of the mail store in a way that the server can not + communicate to the client. The server should send an untagged BYE + + + +Leiba Informational [Page 3] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + response to the client and then close the socket. Sending an + untagged BYE response before severing allows the server to send a + human-readable explanation of the problem to the client, which the + client may then log, display to the user, or both (see section 7.1.5 + of [RFC-2060]). + + Regarding inactivity timeouts, there is some controversy. Unlike + POP, for which the design is for a client to connect, retrieve mail, + and log out, IMAP's design encourages long-lived (and mostly + inactive) client/server sessions. As the number of users grows, this + can use up a lot of server resources, especially with clients that + are designed to maintain sessions for mailboxes that the user has + finished accessing. To alleviate this, a server may implement an + inactivity timeout, unilaterally closing a session (after first + sending an untagged BYE, as noted above). Some server operators have + reported dramatic improvements in server performance after doing + this. As specified in [RFC-2060], if such a timeout is done it must + not be until at least 30 minutes of inactivity. The reason for this + specification is to prevent clients from sending commands (such as + NOOP) to the server at frequent intervals simply to avert a too-early + timeout. If the client knows that the server may not time out the + session for at least 30 minutes, then the client need not poll at + intervals more frequent than, say, 25 minutes. + +3.2. Scaling + + IMAP4 has many features that allow for scalability, as mail stores + become larger and more numerous. Large numbers of users, mailboxes, + and messages, and very large messages require thought to handle + efficiently. This document will not address the administrative + issues involved in large numbers of users, but we will look at the + other items. + +3.2.1. Flood Control + + There are three situations when a client can make a request that will + result in a very large response - too large for the client reasonably + to deal with: there are a great many mailboxes available, there are a + great many messages in the selected mailbox, or there is a very large + message part. The danger here is that the end user will be stuck + waiting while the server sends (and the client processes) an enormous + response. In all of these cases there are things a client can do to + reduce that danger. + + There is also the case where a client can flood a server, by sending + an arbitratily long command. We'll discuss that issue, too, in this + section. + + + + +Leiba Informational [Page 4] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.2.1.1. Listing Mailboxes + + Some servers present Usenet newsgroups to IMAP users. Newsgroups, + and other such hierarchical mailbox structures, can be very numerous + but may have only a few entries at the top level of hierarchy. Also, + some servers are built against mail stores that can, unbeknownst to + the server, have circular hierarchies - that is, it's possible for + "a/b/c/d" to resolve to the same file structure as "a", which would + then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy + will never end. The LIST response in this case will be unlimited. + + Clients that will have trouble with this are those that use + + C: 001 LIST "" * + + to determine the mailbox list. Because of this, clients should not + use an unqualified "*" that way in the LIST command. A safer + approach is to list each level of hierarchy individually, allowing + the user to traverse the tree one limb at a time, thus: + + C: 001 LIST "" % + S: * LIST () "/" Banana + S: * LIST ...etc... + S: 001 OK done + + and then + + C: 002 LIST "" Banana/% + S: * LIST () "/" Banana/Apple + S: * LIST ...etc... + S: 002 OK done + + Using this technique the client's user interface can give the user + full flexibility without choking on the voluminous reply to "LIST *". + + Of course, it is still possible that the reply to + + C: 005 LIST "" alt.fan.celebrity.% + + may be thousands of entries long, and there is, unfortunately, + nothing the client can do to protect itself from that. This has not + yet been a notable problem. + + Servers that may export circular hierarchies (any server that + directly presents a UNIX file system, for instance) should limit the + hierarchy depth to prevent unlimited LIST responses. A suggested + depth limit is 20 hierarchy levels. + + + + +Leiba Informational [Page 5] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.2.1.2. Fetching the List of Messages + + When a client selects a mailbox, it is given a count, in the untagged + EXISTS response, of the messages in the mailbox. This number can be + very large. In such a case it might be unwise to use + + C: 004 FETCH 1:* ALL + + to populate the user's view of the mailbox. One good method to avoid + problems with this is to batch the requests, thus: + + C: 004 FETCH 1:50 ALL + S: * 1 FETCH ...etc... + S: 004 OK done + C: 005 FETCH 51:100 ALL + S: * 51 FETCH ...etc... + S: 005 OK done + C: 006 FETCH 101:150 ALL + ...etc... + + Using this method, another command, such as "FETCH 6 BODY[1]" can be + inserted as necessary, and the client will not have its access to the + server blocked by a storm of FETCH replies. (Such a method could be + reversed to fetch the LAST 50 messages first, then the 50 prior to + that, and so on.) + + As a smart extension of this, a well designed client, prepared for + very large mailboxes, will not automatically fetch data for all + messages AT ALL. Rather, the client will populate the user's view + only as the user sees it, possibly pre-fetching selected information, + and only fetching other information as the user scrolls to it. For + example, to select only those messages beginning with the first + unseen one: + + C: 003 SELECT INBOX + S: * 10000 EXISTS + S: * 80 RECENT + S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen) + S: * OK [UIDVALIDITY 824708485] UID validity status + S: * OK [UNSEEN 9921] First unseen message + S: 003 OK [READ-WRITE] SELECT completed + C: 004 FETCH 9921:* ALL + ... etc... + + If the server does not return an OK [UNSEEN] response, the client may + use SEARCH UNSEEN to obtain that value. + + + + + +Leiba Informational [Page 6] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + This mechanism is good as a default presentation method, but only + works well if the default message order is acceptable. A client may + want to present various sort orders to the user (by subject, by date + sent, by sender, and so on) and in that case (lacking a SORT + extension on the server side) the client WILL have to retrieve all + message descriptors. A client that provides this service should not + do it by default and should inform the user of the costs of choosing + this option for large mailboxes. + +3.2.1.3. Fetching a Large Body Part + + The issue here is similar to the one for a list of messages. In the + BODYSTRUCTURE response the client knows the size, in bytes, of the + body part it plans to fetch. Suppose this is a 70 MB video clip. The + client can use partial fetches to retrieve the body part in pieces, + avoiding the problem of an uninterruptible 70 MB literal coming back + from the server: + + C: 022 FETCH 3 BODY[1]<0.20000> + S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000} + S: ...data...) + S: 022 OK done + C: 023 FETCH 3 BODY[1]<20001.20000> + S: * 3 FETCH (BODY[1]<20001> {20000} + S: ...data...) + S: 023 OK done + C: 024 FETCH 3 BODY[1]<40001.20000> + ...etc... + +3.2.1.4. BODYSTRUCTURE vs. Entire Messages + + Because FETCH BODYSTRUCTURE is necessary in order to determine the + number of body parts, and, thus, whether a message has "attachments", + clients often use FETCH FULL as their normal method of populating the + user's view of a mailbox. The benefit is that the client can display + a paperclip icon or some such indication along with the normal + message summary. However, this comes at a significant cost with some + server configurations. The parsing needed to generate the FETCH + BODYSTRUCTURE response may be time-consuming compared with that + needed for FETCH ENVELOPE. The client developer should consider this + issue when deciding whether the ability to add a paperclip icon is + worth the tradeoff in performance, especially with large mailboxes. + + Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[] + (or the equivalent FETCH RFC822) to retrieve the entire message. + They then do the MIME parsing in the client. This may give the + client slightly more flexibility in some areas (access, for instance, + to header fields that aren't returned in the BODYSTRUCTURE and + + + +Leiba Informational [Page 7] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + ENVELOPE responses), but it can cause severe performance problems by + forcing the transfer of all body parts when the user might only want + to see some of them - a user logged on by modem and reading a small + text message with a large ZIP file attached may prefer to read the + text only and save the ZIP file for later. Therefore, a client + should not normally retrieve entire messages and should retrieve + message body parts selectively. + +3.2.1.5. Long Command Lines + + A client can wind up building a very long command line in an effort to + try to be efficient about requesting information from a server. This + can typically happen when a client builds a message set from selected + messages and doesn't recognise that contiguous blocks of messages may + be group in a range. Suppose a user selects all 10,000 messages in a + large mailbox and then unselects message 287. The client could build + that message set as "1:286,288:10000", but a client that doesn't + handle that might try to enumerate each message individually and build + "1,2,3,4, [and so on] ,9999,10000". Adding that to the fetch command + results in a command line that's almost 49,000 octets long, and, + clearly, one can construct a command line that's even longer. + + A client should limit the length of the command lines it generates to + approximately 1000 octets (including all quoted strings but not + including literals). If the client is unable to group things into + ranges so that the command line is within that length, it should + split the request into multiple commands. The client should use + literals instead of long quoted strings, in order to keep the command + length down. + + For its part, a server should allow for a command line of at least + 8000 octets. This provides plenty of leeway for accepting reasonable + length commands from clients. The server should send a BAD response + to a command that does not end within the server's maximum accepted + command length. + +3.2.2. Subscriptions + + The client isn't the only entity that can get flooded: the end user, + too, may need some flood control. The IMAP4 protocol provides such + control in the form of subscriptions. Most servers support the + SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to + narrow down a large list of available mailboxes by subscribing to the + ones that they usually want to see. Clients, with this in mind, + should give the user a way to see only subscribed mailboxes. A + client that never uses the LSUB command takes a significant usability + feature away from the user. Of course, the client would not want to + hide the LIST command completely; the user needs to have a way to + + + +Leiba Informational [Page 8] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + choose between LIST and LSUB. The usual way to do this is to provide + a setting like "show which mailboxes?: [] all [] subscribed only". + +3.2.3. Searching + + IMAP SEARCH commands can become particularly troublesome (that is, + slow) on mailboxes containing a large number of messages. So let's + put a few things in perspective in that regard. + + The flag searches should be fast. The flag searches (ALL, [UN]SEEN, + [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT) + are known to be used by clients for the client's own use (for + instance, some clients use "SEARCH UNSEEN" to find unseen mail and + "SEARCH DELETED" to warn the user before expunging messages). + + Other searches, particularly the text searches (HEADER, TEXT, BODY) + are initiated by the user, rather than by the client itself, and + somewhat slower performance can be tolerated, since the user is aware + that the search is being done (and is probably aware that it might be + time-consuming). A smart server might use dynamic indexing to speed + commonly used text searches. + + The client may allow other commands to be sent to the server while a + SEARCH is in progress, but at the time of this writing there is + little or no server support for parallel processing of multiple + commands in the same session (and see "Multiple Accesses of the Same + Mailbox" above for a description of the dangers of trying to work + around this by doing your SEARCH in another session). + + Another word about text searches: some servers, built on database + back-ends with indexed search capabilities, may return search results + that do not match the IMAP spec's "case-insensitive substring" + requirements. While these servers are in violation of the protocol, + there is little harm in the violation as long as the search results + are used only in response to a user's request. Still, developers of + such servers should be aware that they ARE violating the protocol, + should think carefully about that behaviour, and must be certain that + their servers respond accurately to the flag searches for the reasons + outlined above. + + In addition, servers should support CHARSET UTF-8 [UTF-8] in + searches. + + + + + + + + + +Leiba Informational [Page 9] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.3 Avoiding Invalid Requests + + IMAP4 provides ways for a server to tell a client in advance what is + and isn't permitted in some circumstances. Clients should use these + features to avoid sending requests that a well designed client would + know to be invalid. This section explains this in more detail. + +3.3.1. The CAPABILITY Command + + All IMAP4 clients should use the CAPABILITY command to determine what + version of IMAP and what optional features a server supports. The + client should not send IMAP4rev1 commands and arguments to a server + that does not advertize IMAP4rev1 in its CAPABILITY response. + Similarly, the client should not send IMAP4 commands that no longer + exist in IMAP4rev1 to a server that does not advertize IMAP4 in its + CAPABILITY response. An IMAP4rev1 server is NOT required to support + obsolete IMAP4 or IMAP2bis commands (though some do; do not let this + fact lull you into thinking that it's valid to send such commands to + an IMAP4rev1 server). + + A client should not send commands to probe for the existance of + certain extensions. All standard and standards-track extensions + include CAPABILITY tokens indicating their presense. All private and + experimental extensions should do the same, and clients that take + advantage of them should use the CAPABILITY response to determine + whether they may be used or not. + +3.3.2. Don't Do What the Server Says You Can't + + In many cases, the server, in response to a command, will tell the + client something about what can and can't be done with a particular + mailbox. The client should pay attention to this information and + should not try to do things that it's been told it can't do. + + Examples: + + * Do not try to SELECT a mailbox that has the \Noselect flag set. + * Do not try to CREATE a sub-mailbox in a mailbox that has the + \Noinferiors flag set. + * Do not respond to a failing COPY or APPEND command by trying to + CREATE the target mailbox if the server does not respond with a + [TRYCREATE] response code. + * Do not try to expunge a mailbox that has been selected with the + [READ-ONLY] response code. + + + + + + + +Leiba Informational [Page 10] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.4. Miscellaneous Protocol Considerations + + We describe here a number of important protocol-related issues, the + misunderstanding of which has caused significant interoperability + problems in IMAP4 implementations. One general item is that every + implementer should be certain to take note of and to understand + section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec + [RFC-2060]. + +3.4.1. Well Formed Protocol + + We cannot stress enough the importance of adhering strictly to the + protocol grammar. The specification of the protocol is quite rigid; + do not assume that you can insert blank space for "readability" if + none is called for. Keep in mind that there are parsers out there + that will crash if there are protocol errors. There are clients that + will report every parser burp to the user. And in any case, + information that cannot be parsed is information that is lost. Be + careful in your protocol generation. And see "A Word About Testing", + below. + + In particular, note that the string in the INTERNALDATE response is + NOT an RFC-822 date string - that is, it is not in the same format as + the first string in the ENVELOPE response. Since most clients will, + in fact, accept an RFC-822 date string in the INTERNALDATE response, + it's easy to miss this in your interoperability testing. But it will + cause a problem with some client, so be sure to generate the correct + string for this field. + +3.4.2. Special Characters + + Certain characters, currently the double-quote and the backslash, may + not be sent as-is inside a quoted string. These characters must be + preceded by the escape character if they are in a quoted string, or + else the string must be sent as a literal. Both clients and servers + must handle this, both on output (they must send these characters + properly) and on input (they must be able to receive escaped + characters in quoted strings). Example: + + C: 001 LIST "" % + S: * LIST () "" INBOX + S: * LIST () "\\" TEST + S: * LIST () "\\" {12} + S: "My" mailbox + S: 001 OK done + C: 002 LIST "" "\"My\" mailbox\\%" + S: * LIST () "\\" {17} + S: "My" mailbox\Junk + + + +Leiba Informational [Page 11] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + S: 002 OK done + + Note that in the example the server sent the hierarchy delimiter as + an escaped character in the quoted string and sent the mailbox name + containing imbedded double-quotes as a literal. The client used only + quoted strings, escaping both the backslash and the double-quote + characters. + + The CR and LF characters may be sent ONLY in literals; they are not + allowed, even if escaped, inside quoted strings. + + And while we're talking about special characters: the IMAP spec, in + the section titled "Mailbox International Naming Convention", + describes how to encode mailbox names in modified UTF-7 [UTF-7 and + RFC-2060]. Implementations must adhere to this in order to be + interoperable in the international market, and servers should + validate mailbox names sent by client and reject names that do not + conform. + + As to special characters in userids and passwords: clients must not + restrict what a user may type in for a userid or a password. The + formal grammar specifies that these are "astrings", and an astring + can be a literal. A literal, in turn can contain any 8-bit + character, and clients must allow users to enter all 8-bit characters + here, and must pass them, unchanged, to the server (being careful to + send them as literals when necessary). In particular, some server + configurations use "@" in user names, and some clients do not allow + that character to be entered; this creates a severe interoperability + problem. + +3.4.3. UIDs and UIDVALIDITY + + Servers that support existing back-end mail stores often have no good + place to save UIDs for messages. Often the existing mail store will + not have the concept of UIDs in the sense that IMAP has: strictly + increasing, never re-issued, 32-bit integers. Some servers solve + this by storing the UIDs in a place that's accessible to end users, + allowing for the possibility that the users will delete them. Others + solve it by re-assigning UIDs every time a mailbox is selected. + + The server should maintain UIDs permanently for all messages if it + can. If that's not possible, the server must change the UIDVALIDITY + value for the mailbox whenever any of the UIDs may have become + invalid. Clients must recognize that the UIDVALIDITY has changed and + must respond to that condition by throwing away any information that + they have saved about UIDs in that mailbox. There have been many + problems in this area when clients have failed to do this; in the + worst case it will result in loss of mail when a client deletes the + + + +Leiba Informational [Page 12] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + wrong piece of mail by using a stale UID. + + It seems to be a common misunderstanding that "the UIDVALIDITY and + the UID, taken together, form a 64-bit identifier that uniquely + identifies a message on a server". This is absolutely NOT TRUE. + There is no assurance that the UIDVALIDITY values of two mailboxes be + different, so the UIDVALIDITY in no way identifies a mailbox. The + ONLY purpose of UIDVALIDITY is, as its name indicates, to give the + client a way to check the validity of the UIDs it has cached. While + it is a valid implementation choice to put these values together to + make a 64-bit identifier for the message, the important concept here + is that UIDs are not unique between mailboxes; they are only unique + WITHIN a given mailbox. + + Some server implementations have attempted to make UIDs unique across + the entire server. This is inadvisable, in that it limits the life + of UIDs unnecessarily. The UID is a 32-bit number and will run out + in reasonably finite time if it's global across the server. If you + assign UIDs sequentially in one mailbox, you will not have to start + re-using them until you have had, at one time or another, 2**32 + different messages in that mailbox. In the global case, you will + have to reuse them once you have had, at one time or another, 2**32 + different messages in the entire mail store. Suppose your server has + around 8000 users registered (2**13). That gives an average of 2**19 + UIDs per user. Suppose each user gets 32 messages (2**5) per day. + That gives you 2**14 days (16000+ days = about 45 years) before you + run out. That may seem like enough, but multiply the usage just a + little (a lot of spam, a lot of mailing list subscriptions, more + users) and you limit yourself too much. + + What's worse is that if you have to wrap the UIDs, and, thus, you + have to change UIDVALIDITY and invalidate the UIDs in the mailbox, + you have to do it for EVERY mailbox in the system, since they all + share the same UID pool. If you assign UIDs per mailbox and you have + a problem, you only have to kill the UIDs for that one mailbox. + + Under extreme circumstances (and this is extreme, indeed), the server + may have to invalidate UIDs while a mailbox is in use by a client - + that is, the UIDs that the client knows about in its active mailbox + are no longer valid. In that case, the server must immediately + change the UIDVALIDITY and must communicate this to the client. The + server may do this by sending an unsolicited UIDVALIDITY message, in + the same form as in response to the SELECT command. Clients must be + prepared to handle such a message and the possibly coincident failure + of the command in process. For example: + + + + + + +Leiba Informational [Page 13] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + C: 032 UID STORE 382 +Flags.silent \Deleted + S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value! + S: 032 NO UID command rejected because UIDVALIDITY changed! + C: ...invalidates local information and re-fetches... + C: 033 FETCH 1:* UID + ...etc... + + At the time of the writing of this document, the only server known to + do this does so only under the following condition: the client + selects INBOX, but there is not yet a physical INBOX file created. + Nonetheless, the SELECT succeeds, exporting an empty INBOX with a + temporary UIDVALIDITY of 1. While the INBOX remains selected, mail + is delivered to the user, which creates the real INBOX file and + assigns a permanent UIDVALIDITY (that is likely not to be 1). The + server reports the change of UIDVALIDITY, but as there were no + messages before, so no UIDs have actually changed, all the client + must do is accept the change in UIDVALIDITY. + + Alternatively, a server may force the client to re-select the + mailbox, at which time it will obtain a new UIDVALIDITY value. To do + this, the server closes this client session (see "Severed + Connections" above) and the client then reconnects and gets back in + synch. Clients must be prepared for either of these behaviours. + + We do not know of, nor do we anticipate the future existance of, a + server that changes UIDVALIDITY while there are existing messages, + but clients must be prepared to handle this eventuality. + +3.4.4. FETCH Responses + + When a client asks for certain information in a FETCH command, the + server may return the requested information in any order, not + necessarily in the order that it was requested. Further, the server + may return the information in separate FETCH responses and may also + return information that was not explicitly requested (to reflect to + the client changes in the state of the subject message). Some + examples: + + C: 001 FETCH 1 UID FLAGS INTERNALDATE + S: * 5 FETCH (FLAGS (\Deleted)) + S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345) + S: 001 OK done + + (In this case, the responses are in a different order. Also, the + server returned a flag update for message 5, which wasn't part of the + client's request.) + + + + + +Leiba Informational [Page 14] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + C: 002 FETCH 2 UID FLAGS INTERNALDATE + S: * 2 FETCH (INTERNALDATE "...") + S: * 2 FETCH (UID 399) + S: * 2 FETCH (FLAGS ()) + S: 002 OK done + + (In this case, the responses are in a different order and were + returned in separate responses.) + + C: 003 FETCH 2 BODY[1] + S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14} + S: Hello world! + S: ) + S: 003 OK done + + (In this case, the FLAGS response was added by the server, since + fetching the body part caused the server to set the \Seen flag.) + + Because of this characteristic a client must be ready to receive any + FETCH response at any time and should use that information to update + its local information about the message to which the FETCH response + refers. A client must not assume that any FETCH responses will come + in any particular order, or even that any will come at all. If after + receiving the tagged response for a FETCH command the client finds + that it did not get all of the information requested, the client + should send a NOOP command to the server to ensure that the server + has an opportunity to send any pending EXPUNGE responses to the + client (see [RFC-2180]). + +3.4.5. RFC822.SIZE + + Some back-end mail stores keep the mail in a canonical form, rather + than retaining the original MIME format of the messages. This means + that the server must reassemble the message to produce a MIME stream + when a client does a fetch such as RFC822 or BODY[], requesting the + entire message. It also may mean that the server has no convenient + way to know the RFC822.SIZE of the message. Often, such a server + will actually have to build the MIME stream to compute the size, only + to throw the stream away and report the size to the client. + + When this is the case, some servers have chosen to estimate the size, + rather than to compute it precisely. Such an estimate allows the + client to display an approximate size to the user and to use the + estimate in flood control considerations (q.v.), but requires that + the client not use the size for things such as allocation of buffers, + because those buffers might then be too small to hold the actual MIME + stream. Instead, a client should use the size that's returned in the + literal when you fetch the data. + + + +Leiba Informational [Page 15] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + The protocol requires that the RFC822.SIZE value returned by the + server be EXACT. Estimating the size is a protocol violation, and + server designers must be aware that, despite the performance savings + they might realize in using an estimate, this practice will cause + some clients to fail in various ways. If possible, the server should + compute the RFC822.SIZE for a particular message once, and then save + it for later retrieval. If that's not possible, the server must + compute the value exactly every time. Incorrect estimates do cause + severe interoperability problems with some clients. + +3.4.6. Expunged Messages + + If the server allows multiple connections to the same mailbox, it is + often possible for messages to be expunged in one client unbeknownst + to another client. Since the server is not allowed to tell the + client about these expunged messages in response to a FETCH command, + the server may have to deal with the issue of how to return + information about an expunged message. There was extensive + discussion about this issue, and the results of that discussion are + summarized in [RFC-2180]. See that reference for a detailed + explanation and for recommendations. + +3.4.7. The Namespace Issue + + Namespaces are a very muddy area in IMAP4 implementation right now + (see [NAMESPACE] for a proposal to clear the water a bit). Until the + issue is resolved, the important thing for client developers to + understand is that some servers provide access through IMAP to more + than just the user's personal mailboxes, and, in fact, the user's + personal mailboxes may be "hidden" somewhere in the user's default + hierarchy. The client, therefore, should provide a setting wherein + the user can specify a prefix to be used when accessing mailboxes. If + the user's mailboxes are all in "~/mail/", for instance, then the + user can put that string in the prefix. The client would then put + the prefix in front of any name pattern in the LIST and LSUB + commands: + + C: 001 LIST "" ~/mail/% + + (See also "Reference Names in the LIST Command" below.) + +3.4.8. Creating Special-Use Mailboxes + + It may seem at first that this is part of the namespace issue; it is + not, and is only indirectly related to it. A number of clients like + to create special-use mailboxes with particular names. Most + commonly, clients with a "trash folder" model of message deletion + want to create a mailbox with the name "Trash" or "Deleted". Some + + + +Leiba Informational [Page 16] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a + "Sent Mail" mailbox. And so on. There are two major + interoperability problems with this practice: + + 1. different clients may use different names for mailboxes with + similar functions (such as "Trash" and "Deleted"), or may manage + the same mailboxes in different ways, causing problems if a user + switches between clients and + 2. there is no guarantee that the server will allow the creation of + the desired mailbox. + + The client developer is, therefore, well advised to consider + carefully the creation of any special-use mailboxes on the server, + and, further, the client must not require such mailbox creation - + that is, if you do decide to do this, you must handle gracefully the + failure of the CREATE command and behave reasonably when your + special-use mailboxes do not exist and can not be created. + + In addition, the client developer should provide a convenient way for + the user to select the names for any special-use mailboxes, allowing + the user to make these names the same in all clients used and to put + them where the user wants them. + +3.4.9. Reference Names in the LIST Command + + Many implementers of both clients and servers are confused by the + "reference name" on the LIST command. The reference name is intended + to be used in much the way a "cd" (change directory) command is used + on Unix, PC DOS, Windows, and OS/2 systems. That is, the mailbox + name is interpreted in much the same way as a file of that name would + be found if one had done a "cd" command into the directory specified + by the reference name. For example, in Unix we have the following: + + > cd /u/jones/junk + > vi banana [file is "/u/jones/junk/banana"] + > vi stuff/banana [file is "/u/jones/junk/stuff/banana"] + > vi /etc/hosts [file is "/etc/hosts"] + + In the past, there have been several interoperability problems with + this. First, while some IMAP servers are built on Unix or PC file + systems, many others are not, and the file system semantics do not + make sense in those configurations. Second, while some IMAP servers + expose the underlying file system to the clients, others allow access + only to the user's personal mailboxes, or to some other limited set + of files, making such file-system-like semantics less meaningful. + Third, because the IMAP spec leaves the interpretation of the + reference name as "implementation-dependent", in the past the various + server implementations handled it in vastly differing ways. + + + +Leiba Informational [Page 17] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + The following recommendations are the result of significant + operational experience, and are intended to maximize + interoperability. + + Server implementations must implement the reference argument in a way + that matches the intended "change directory" operation as closely as + possible. As a minimum implementation, the reference argument may be + prepended to the mailbox name (while suppressing double delimiters; + see the next paragraph). Even servers that do not provide a way to + break out of the current hierarchy (see "breakout facility" below) + must provide a reasonable implementation of the reference argument, + as described here, so that they will interoperate with clients that + use it. + + Server implementations that prepend the reference argument to the + mailbox name should insert a hierarchy delimiter between them, and + must not insert a second if one is already present: + + C: A001 LIST ABC DEF + S: * LIST () "/" ABC/DEF <=== should do this + S: A001 OK done + + C: A002 LIST ABC/ /DEF + S: * LIST () "/" ABC//DEF <=== must not do this + S: A002 OK done + + On clients, the reference argument is chiefly used to implement a + "breakout facility", wherein the user may directly access a mailbox + outside the "current directory" hierarchy. Client implementations + should have an operational mode that does not use the reference + argument. This is to interoperate with older servers that did not + implement the reference argument properly. While it's a good idea to + give the user access to a breakout facility, clients that do not + intend to do so should not use the reference argument at all. + + Client implementations should always place a trailing hierarchy + delimiter on the reference argument. This is because some servers + prepend the reference argument to the mailbox name without inserting + a hierarchy delimiter, while others do insert a hierarchy delimiter + if one is not already present. A client that puts the delimiter in + will work with both varieties of server. + + Client implementations that implement a breakout facility should + allow the user to choose whether or not to use a leading hierarchy + delimiter on the mailbox argument. This is because the handling of a + leading mailbox hierarchy delimiter also varies from server to + server, and even between different mailstores on the same server. In + some cases, a leading hierarchy delimiter means "discard the + + + +Leiba Informational [Page 18] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + reference argument" (implementing the intended breakout facility), + thus: + + C: A001 LIST ABC/ /DEF + S: * LIST () "/" /DEF + S: A001 OK done + + In other cases, however, the two are catenated and the extra + hierarchy delimiter is discarded, thus: + + C: A001 LIST ABC/ /DEF + S: * LIST () "/" ABC/DEF + S: A001 OK done + + Client implementations must not assume that the server supports a + breakout facility, but may provide a way for the user to use one if + it is available. Any breakout facility should be exported to the + user interface. Note that there may be other "breakout" characters + besides the hierarchy delimiter (for instance, UNIX filesystem + servers are likely to use a leading "~" as well), and that their + interpretation is server-dependent. + +3.4.10. Mailbox Hierarchy Delimiters + + The server's selection of what to use as a mailbox hierarchy + delimiter is a difficult one, involving several issues: What + characters do users expect to see? What characters can they enter + for a hierarchy delimiter if it is desired (or required) that the + user enter it? What character can be used for the hierarchy + delimiter, noting that the chosen character can not otherwise be used + in the mailbox name? + + Because some interfaces show users the hierarchy delimiters or allow + users to enter qualified mailbox names containing them, server + implementations should use delimiter characters that users generally + expect to see as name separators. The most common characters used + for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows + file names), and "." (as in news groups). There is little to choose + among these apart from what users may expect or what is dictated by + the underlying file system, if any. One consideration about using + "\" is that it's also a special character in the IMAP protocol. While + the use of other hierarchy delimiter characters is permissible, A + DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the + server is intended for special purposes only. Implementers might be + thinking about using characters such as "-", "_", ";", "&", "#", "@", + and "!", but they should be aware of the surprise to the user as well + as of the effect on URLs and other external specifications (since + some of these characters have special meanings there). Also, a + + + +Leiba Informational [Page 19] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + server that uses "\" (and clients of such a server) must remember to + escape that character in quoted strings or to send literals instead. + Literals are recommended over escaped characters in quoted strings in + order to maintain compatibility with older IMAP versions that did not + allow escaped characters in quoted strings (but check the grammar to + see where literals are allowed): + + C: 001 LIST "" {13} + S: + send literal + C: this\%\%\%\h* + S: * LIST () "\\" {27} + S: this\is\a\mailbox\hierarchy + S: 001 OK LIST complete + + In any case, a server should not use normal alpha-numeric characters + (such as "X" or "0") as delimiters; a user would be very surprised to + find that "EXPENDITURES" actually represented a two-level hierarchy. + And a server should not use characters that are non-printable or + difficult or impossible to enter on a standard US keyboard. Control + characters, box-drawing characters, and characters from non-US + alphabets fit into this category. Their use presents + interoperability problems that are best avoided. + + The UTF-7 encoding of mailbox names also raises questions about what + to do with the hierarchy delimiters in encoded names: do we encode + each hierarchy level and separate them with delimiters, or do we + encode the fully qualified name, delimiters and all? The answer for + IMAP is the former: encode each hierarchy level separately, and + insert delimiters between. This makes it particularly important not + to use as a hierarchy delimiter a character that might cause + confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding. + + To repeat: a server should use "/", "\", or "." as its hierarchy + delimiter. The use of any other character is likely to cause + problems and is STRONGLY DISCOURAGED. + +3.4.11. ALERT Response Codes + + The protocol spec is very clear on the matter of what to do with + ALERT response codes, and yet there are many clients that violate it + so it needs to be said anyway: "The human-readable text contains a + special alert that must be presented to the user in a fashion that + calls the user's attention to the message." That should be clear + enough, but I'll repeat it here: Clients must present ALERT text + clearly to the user. + + + + + + +Leiba Informational [Page 20] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +3.4.12. Deleting Mailboxes + + The protocol does not guarantee that a client may delete a mailbox + that is not empty, though on some servers it is permissible and is, + in fact, much faster than the alternative or deleting all the + messages from the client. If the client chooses to try to take + advantage of this possibility it must be prepared to use the other + method in the even that the more convenient one fails. Further, a + client should not try to delete the mailbox that it has selected, but + should first close that mailbox; some servers do not permit the + deletion of the selected mailbox. + + That said, a server should permit the deletion of a non-empty + mailbox; there's little reason to pass this work on to the client. + Moreover, forbidding this prevents the deletion of a mailbox that for + some reason can not be opened or expunged, leading to possible + denial-of-service problems. + + Example: + + [User tells the client to delete mailbox BANANA, which is + currently selected...] + C: 008 CLOSE + S: 008 OK done + C: 009 DELETE BANANA + S: 009 NO Delete failed; mailbox is not empty. + C: 010 SELECT BANANA + S: * ... untagged SELECT responses + S: 010 OK done + C: 011 STORE 1:* +FLAGS.SILENT \DELETED + S: 011 OK done + C: 012 CLOSE + S: 012 OK done + C: 013 DELETE BANANA + S: 013 OK done + +3.5. A Word About Testing + + Since the whole point of IMAP is interoperability, and since + interoperability can not be tested in a vacuum, the final + recommendation of this treatise is, "Test against EVERYTHING." Test + your client against every server you can get an account on. Test + your server with every client you can get your hands on. Many + clients make limited test versions available on the Web for the + downloading. Many server owners will give serious client developers + guest accounts for testing. Contact them and ask. NEVER assume that + because your client works with one or two servers, or because your + server does fine with one or two clients, you will interoperate well + + + +Leiba Informational [Page 21] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + + in general. + + In particular, in addition to everything else, be sure to test + against the reference implementations: the PINE client, the + University of Washington server, and the Cyrus server. + + See the following URLs on the web for more information here: + + IMAP Products and Sources: http://www.imap.org/products.html + IMC MailConnect: http://www.imc.org/imc-mailconnect + +4. Security Considerations + + This document describes behaviour of clients and servers that use the + IMAP4 protocol, and as such, has the same security considerations as + described in [RFC-2060]. + +5. References + + [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC + 2180, July 1997. + + [UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode + and ISO 10646", RFC 2044, October 1996. + + [UTF-7] Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe + Transformation Format of Unicode", RFC 2152, May 1997. + + [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in + Progress. + +6. Author's Address + + Barry Leiba + IBM T.J. Watson Research Center + 30 Saw Mill River Road + Hawthorne, NY 10532 + + Phone: 1-914-784-7941 + EMail: leiba@watson.ibm.com + + + + + +Leiba Informational [Page 22] + +RFC 2683 IMAP4 Implementation Recommendations September 1999 + + +7. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Leiba Informational [Page 23] + diff --git a/server/src/site/resources/rfclist/ldap/rfc2251.txt b/server/src/site/resources/rfclist/ldap/rfc2251.txt new file mode 100644 index 00000000000..88844cbf38b --- /dev/null +++ b/server/src/site/resources/rfclist/ldap/rfc2251.txt @@ -0,0 +1,2803 @@ + + + + + + +Network Working Group M. Wahl +Request for Comments: 2251 Critical Angle Inc. +Category: Standards Track T. Howes + Netscape Communications Corp. + S. Kille + Isode Limited + December 1997 + + + Lightweight Directory Access Protocol (v3) + +1. 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. + +IESG Note + + This document describes a directory access protocol that provides + both read and update access. Update access requires secure + authentication, but this document does not mandate implementation of + any satisfactory authentication mechanisms. + + In accordance with RFC 2026, section 4.4.1, this specification is + being approved by IESG as a Proposed Standard despite this + limitation, for the following reasons: + + a. to encourage implementation and interoperability testing of + these protocols (with or without update access) before they + are deployed, and + + b. to encourage deployment and use of these protocols in read-only + applications. (e.g. applications where LDAPv3 is used as + a query language for directories which are updated by some + secure mechanism other than LDAP), and + + c. to avoid delaying the advancement and deployment of other Internet + standards-track protocols which require the ability to query, but + not update, LDAPv3 directory servers. + + + + + +Wahl, et. al. Standards Track [Page 1] + +RFC 2251 LDAPv3 December 1997 + + + Readers are hereby warned that until mandatory authentication + mechanisms are standardized, clients and servers written according to + this specification which make use of update functionality are + UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION + IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL. + + Implementors are hereby discouraged from deploying LDAPv3 clients or + servers which implement the update functionality, until a Proposed + Standard for mandatory authentication in LDAPv3 has been approved and + published as an RFC. + +Table of Contents + + 1. Status of this Memo .................................... 1 + Copyright Notice ....................................... 1 + IESG Note .............................................. 1 + 2. Abstract ............................................... 3 + 3. Models ................................................. 4 + 3.1. Protocol Model ........................................ 4 + 3.2. Data Model ............................................ 5 + 3.2.1. Attributes of Entries ............................... 5 + 3.2.2. Subschema Entries and Subentries .................... 7 + 3.3. Relationship to X.500 ................................. 8 + 3.4. Server-specific Data Requirements ..................... 8 + 4. Elements of Protocol ................................... 9 + 4.1. Common Elements ....................................... 9 + 4.1.1. Message Envelope .................................... 9 + 4.1.1.1. Message ID ........................................ 11 + 4.1.2. String Types ........................................ 11 + 4.1.3. Distinguished Name and Relative Distinguished Name .. 11 + 4.1.4. Attribute Type ...................................... 12 + 4.1.5. Attribute Description ............................... 13 + 4.1.5.1. Binary Option ..................................... 14 + 4.1.6. Attribute Value ..................................... 14 + 4.1.7. Attribute Value Assertion ........................... 15 + 4.1.8. Attribute ........................................... 15 + 4.1.9. Matching Rule Identifier ............................ 15 + 4.1.10. Result Message ..................................... 16 + 4.1.11. Referral ........................................... 18 + 4.1.12. Controls ........................................... 19 + 4.2. Bind Operation ........................................ 20 + 4.2.1. Sequencing of the Bind Request ...................... 21 + 4.2.2. Authentication and Other Security Services .......... 22 + 4.2.3. Bind Response ....................................... 23 + 4.3. Unbind Operation ...................................... 24 + 4.4. Unsolicited Notification .............................. 24 + 4.4.1. Notice of Disconnection ............................. 24 + 4.5. Search Operation ...................................... 25 + + + +Wahl, et. al. Standards Track [Page 2] + +RFC 2251 LDAPv3 December 1997 + + + 4.5.1. Search Request ...................................... 25 + 4.5.2. Search Result ....................................... 29 + 4.5.3. Continuation References in the Search Result ........ 31 + 4.5.3.1. Example ........................................... 31 + 4.6. Modify Operation ...................................... 32 + 4.7. Add Operation ......................................... 34 + 4.8. Delete Operation ...................................... 35 + 4.9. Modify DN Operation ................................... 36 + 4.10. Compare Operation .................................... 37 + 4.11. Abandon Operation .................................... 38 + 4.12. Extended Operation ................................... 38 + 5. Protocol Element Encodings and Transfer ................ 39 + 5.1. Mapping Onto BER-based Transport Services ............. 39 + 5.2. Transfer Protocols .................................... 40 + 5.2.1. Transmission Control Protocol (TCP) ................. 40 + 6. Implementation Guidelines .............................. 40 + 6.1. Server Implementations ................................ 40 + 6.2. Client Implementations ................................ 40 + 7. Security Considerations ................................ 41 + 8. Acknowledgements ....................................... 41 + 9. Bibliography ........................................... 41 + 10. Authors' Addresses ..................................... 42 + Appendix A - Complete ASN.1 Definition ..................... 44 + Full Copyright Statement ................................... 50 + +2. Abstract + + The protocol described in this document is designed to provide access + to directories supporting the X.500 models, while not incurring the + resource requirements of the X.500 Directory Access Protocol (DAP). + This protocol is specifically targeted at management applications and + browser applications that provide read/write interactive access to + directories. When used with a directory supporting the X.500 + protocols, it is intended to be a complement to the X.500 DAP. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document + are to be interpreted as described in RFC 2119 [10]. + + Key aspects of this version of LDAP are: + + - All protocol elements of LDAPv2 (RFC 1777) are supported. The + protocol is carried directly over TCP or other transport, bypassing + much of the session/presentation overhead of X.500 DAP. + + - Most protocol data elements can be encoded as ordinary strings + (e.g., Distinguished Names). + + + + +Wahl, et. al. Standards Track [Page 3] + +RFC 2251 LDAPv3 December 1997 + + + - Referrals to other servers may be returned. + + - SASL mechanisms may be used with LDAP to provide association + security services. + + - Attribute values and Distinguished Names have been + internationalized through the use of the ISO 10646 character set. + + - The protocol can be extended to support new operations, and + controls may be used to extend existing operations. + + - Schema is published in the directory for use by clients. + +3. Models + + Interest in X.500 [1] directory technologies in the Internet has led + to efforts to reduce the high cost of entry associated with use of + these technologies. This document continues the efforts to define + directory protocol alternatives, updating the LDAP [2] protocol + specification. + +3.1. Protocol Model + + The general model adopted by this protocol is one of clients + performing protocol operations against servers. In this model, a + client transmits a protocol request describing the operation to be + performed to a server. The server is then responsible for performing + the necessary operation(s) in the directory. Upon completion of the + operation(s), the server returns a response containing any results or + errors to the requesting client. + + In keeping with the goal of easing the costs associated with use of + the directory, it is an objective of this protocol to minimize the + complexity of clients so as to facilitate widespread deployment of + applications capable of using the directory. + + Note that although servers are required to return responses whenever + such responses are defined in the protocol, there is no requirement + for synchronous behavior on the part of either clients or servers. + Requests and responses for multiple operations may be exchanged + between a client and server in any order, provided the client + eventually receives a response for every request that requires one. + + In LDAP versions 1 and 2, no provision was made for protocol servers + returning referrals to clients. However, for improved performance + and distribution this version of the protocol permits servers to + return to clients referrals to other servers. This allows servers to + offload the work of contacting other servers to progress operations. + + + +Wahl, et. al. Standards Track [Page 4] + +RFC 2251 LDAPv3 December 1997 + + + Note that the core protocol operations defined in this document can + be mapped to a strict subset of the X.500(1997) directory abstract + service, so it can be cleanly provided by the DAP. However there is + not a one-to-one mapping between LDAP protocol operations and DAP + operations: server implementations acting as a gateway to X.500 + directories may need to make multiple DAP requests. + +3.2. Data Model + + This section provides a brief introduction to the X.500 data model, + as used by LDAP. + + The LDAP protocol assumes there are one or more servers which jointly + provide access to a Directory Information Tree (DIT). The tree is + made up of entries. Entries have names: one or more attribute values + from the entry form its relative distinguished name (RDN), which MUST + be unique among all its siblings. The concatenation of the relative + distinguished names of the sequence of entries from a particular + entry to an immediate subordinate of the root of the tree forms that + entry's Distinguished Name (DN), which is unique in the tree. An + example of a Distinguished Name is + + CN=Steve Kille, O=Isode Limited, C=GB + + Some servers may hold cache or shadow copies of entries, which can be + used to answer search and comparison queries, but will return + referrals or contact other servers if modification operations are + requested. + + Servers which perform caching or shadowing MUST ensure that they do + not violate any access control constraints placed on the data by the + originating server. + + The largest collection of entries, starting at an entry that is + mastered by a particular server, and including all its subordinates + and their subordinates, down to the entries which are mastered by + different servers, is termed a naming context. The root of the DIT + is a DSA-specific Entry (DSE) and not part of any naming context: + each server has different attribute values in the root DSE. (DSA is + an X.500 term for the directory server). + +3.2.1. Attributes of Entries + + Entries consist of a set of attributes. An attribute is a type with + one or more associated values. The attribute type is identified by a + short descriptive name and an OID (object identifier). The attribute + + + + + +Wahl, et. al. Standards Track [Page 5] + +RFC 2251 LDAPv3 December 1997 + + + type governs whether there can be more than one value of an attribute + of that type in an entry, the syntax to which the values must + conform, the kinds of matching which can be performed on values of + that attribute, and other functions. + + An example of an attribute is "mail". There may be one or more values + of this attribute, they must be IA5 (ASCII) strings, and they are + case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM"). + + Schema is the collection of attribute type definitions, object class + definitions and other information which a server uses to determine + how to match a filter or attribute value assertion (in a compare + operation) against the attributes of an entry, and whether to permit + add and modify operations. The definition of schema for use with + LDAP is given in [5] and [6]. Additional schema elements may be + defined in other documents. + + Each entry MUST have an objectClass attribute. The objectClass + attribute specifies the object classes of an entry, which along with + the system and user schema determine the permitted attributes of an + entry. Values of this attribute may be modified by clients, but the + objectClass attribute cannot be removed. Servers may restrict the + modifications of this attribute to prevent the basic structural class + of the entry from being changed (e.g. one cannot change a person into + a country). When creating an entry or adding an objectClass value to + an entry, all superclasses of the named classes are implicitly added + as well if not already present, and the client must supply values for + any mandatory attributes of new superclasses. + + Some attributes, termed operational attributes, are used by servers + for administering the directory system itself. They are not returned + in search results unless explicitly requested by name. Attributes + which are not operational, such as "mail", will have their schema and + syntax constraints enforced by servers, but servers will generally + not make use of their values. + + Servers MUST NOT permit clients to add attributes to an entry unless + those attributes are permitted by the object class definitions, the + schema controlling that entry (specified in the subschema - see + below), or are operational attributes known to that server and used + for administrative purposes. Note that there is a particular + objectClass 'extensibleObject' defined in [5] which permits all user + attributes to be present in an entry. + + Entries MAY contain, among others, the following operational + attributes, defined in [5]. These attributes are maintained + automatically by the server and are not modifiable by clients: + + + + +Wahl, et. al. Standards Track [Page 6] + +RFC 2251 LDAPv3 December 1997 + + + - creatorsName: the Distinguished Name of the user who added this + entry to the directory. + + - createTimestamp: the time this entry was added to the directory. + + - modifiersName: the Distinguished Name of the user who last modified + this entry. + + - modifyTimestamp: the time this entry was last modified. + + - subschemaSubentry: the Distinguished Name of the subschema entry + (or subentry) which controls the schema for this entry. + +3.2.2. Subschema Entries and Subentries + + Subschema entries are used for administering information about the + directory schema, in particular the object classes and attribute + types supported by directory servers. A single subschema entry + contains all schema definitions used by entries in a particular part + of the directory tree. + + Servers which follow X.500(93) models SHOULD implement subschema + using the X.500 subschema mechanisms, and so these subschemas are not + ordinary entries. LDAP clients SHOULD NOT assume that servers + implement any of the other aspects of X.500 subschema. A server + which masters entries and permits clients to modify these entries + MUST implement and provide access to these subschema entries, so that + its clients may discover the attributes and object classes which are + permitted to be present. It is strongly recommended that all other + servers implement this as well. + + The following four attributes MUST be present in all subschema + entries: + + - cn: this attribute MUST be used to form the RDN of the subschema + entry. + + - objectClass: the attribute MUST have at least the values "top" and + "subschema". + + - objectClasses: each value of this attribute specifies an object + class known to the server. + + - attributeTypes: each value of this attribute specifies an attribute + type known to the server. + + These are defined in [5]. Other attributes MAY be present in + subschema entries, to reflect additional supported capabilities. + + + +Wahl, et. al. Standards Track [Page 7] + +RFC 2251 LDAPv3 December 1997 + + + These include matchingRules, matchingRuleUse, dITStructureRules, + dITContentRules, nameForms and ldapSyntaxes. + + Servers SHOULD provide the attributes createTimestamp and + modifyTimestamp in subschema entries, in order to allow clients to + maintain their caches of schema information. + + Clients MUST only retrieve attributes from a subschema entry by + requesting a base object search of the entry, where the search filter + is "(objectClass=subschema)". (This will allow LDAPv3 servers which + gateway to X.500(93) to detect that subentry information is being + requested.) + +3.3. Relationship to X.500 + + This document defines LDAP in terms of X.500 as an X.500 access + mechanism. An LDAP server MUST act in accordance with the + X.500(1993) series of ITU recommendations when providing the service. + However, it is not required that an LDAP server make use of any X.500 + protocols in providing this service, e.g. LDAP can be mapped onto any + other directory system so long as the X.500 data and service model as + used in LDAP is not violated in the LDAP interface. + +3.4. Server-specific Data Requirements + + An LDAP server MUST provide information about itself and other + information that is specific to each server. This is represented as + a group of attributes located in the root DSE (DSA-Specific Entry), + which is named with the zero-length LDAPDN. These attributes are + retrievable if a client performs a base object search of the root + with filter "(objectClass=*)", however they are subject to access + control restrictions. The root DSE MUST NOT be included if the + client performs a subtree search starting from the root. + + Servers may allow clients to modify these attributes. + + The following attributes of the root DSE are defined in section 5 of + [5]. Additional attributes may be defined in other documents. + + - namingContexts: naming contexts held in the server. Naming contexts + are defined in section 17 of X.501 [6]. + + - subschemaSubentry: subschema entries (or subentries) known by this + server. + + - altServer: alternative servers in case this one is later + unavailable. + + + + +Wahl, et. al. Standards Track [Page 8] + +RFC 2251 LDAPv3 December 1997 + + + - supportedExtension: list of supported extended operations. + + - supportedControl: list of supported controls. + + - supportedSASLMechanisms: list of supported SASL security features. + + - supportedLDAPVersion: LDAP versions implemented by the server. + + If the server does not master entries and does not know the locations + of schema information, the subschemaSubentry attribute is not present + in the root DSE. If the server masters directory entries under one + or more schema rules, there may be any number of values of the + subschemaSubentry attribute in the root DSE. + +4. Elements of Protocol + + The LDAP protocol is described using Abstract Syntax Notation 1 + (ASN.1) [3], and is typically transferred using a subset of ASN.1 + Basic Encoding Rules [11]. In order to support future extensions to + this protocol, clients and servers MUST ignore elements of SEQUENCE + encodings whose tags they do not recognize. + + Note that unlike X.500, each change to the LDAP protocol other than + through the extension mechanisms will have a different version + number. A client will indicate the version it supports as part of + the bind request, described in section 4.2. If a client has not sent + a bind, the server MUST assume that version 3 is supported in the + client (since version 2 required that the client bind first). + + Clients may determine the protocol version a server supports by + reading the supportedLDAPVersion attribute from the root DSE. Servers + which implement version 3 or later versions MUST provide this + attribute. Servers which only implement version 2 may not provide + this attribute. + +4.1. Common Elements + + This section describes the LDAPMessage envelope PDU (Protocol Data + Unit) format, as well as data type definitions which are used in the + protocol operations. + +4.1.1. Message Envelope + + For the purposes of protocol exchanges, all protocol operations are + encapsulated in a common envelope, the LDAPMessage, which is defined + as follows: + + LDAPMessage ::= SEQUENCE { + + + +Wahl, et. al. Standards Track [Page 9] + +RFC 2251 LDAPv3 December 1997 + + + messageID MessageID, + protocolOp CHOICE { + bindRequest BindRequest, + bindResponse BindResponse, + unbindRequest UnbindRequest, + searchRequest SearchRequest, + searchResEntry SearchResultEntry, + searchResDone SearchResultDone, + searchResRef SearchResultReference, + modifyRequest ModifyRequest, + modifyResponse ModifyResponse, + addRequest AddRequest, + addResponse AddResponse, + delRequest DelRequest, + delResponse DelResponse, + modDNRequest ModifyDNRequest, + modDNResponse ModifyDNResponse, + compareRequest CompareRequest, + compareResponse CompareResponse, + abandonRequest AbandonRequest, + extendedReq ExtendedRequest, + extendedResp ExtendedResponse }, + controls [0] Controls OPTIONAL } + + MessageID ::= INTEGER (0 .. maxInt) + + maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- + + The function of the LDAPMessage is to provide an envelope containing + common fields required in all protocol exchanges. At this time the + only common fields are the message ID and the controls. + + If the server receives a PDU from the client in which the LDAPMessage + SEQUENCE tag cannot be recognized, the messageID cannot be parsed, + the tag of the protocolOp is not recognized as a request, or the + encoding structures or lengths of data fields are found to be + incorrect, then the server MUST return the notice of disconnection + described in section 4.4.1, with resultCode protocolError, and + immediately close the connection. In other cases that the server + cannot parse the request received by the client, the server MUST + return an appropriate response to the request, with the resultCode + set to protocolError. + + If the client receives a PDU from the server which cannot be parsed, + the client may discard the PDU, or may abruptly close the connection. + + The ASN.1 type Controls is defined in section 4.1.12. + + + + +Wahl, et. al. Standards Track [Page 10] + +RFC 2251 LDAPv3 December 1997 + + +4.1.1.1. Message ID + + All LDAPMessage envelopes encapsulating responses contain the + messageID value of the corresponding request LDAPMessage. + + The message ID of a request MUST have a value different from the + values of any other requests outstanding in the LDAP session of which + this message is a part. + + A client MUST NOT send a second request with the same message ID as + an earlier request on the same connection if the client has not + received the final response from the earlier request. Otherwise the + behavior is undefined. Typical clients increment a counter for each + request. + + A client MUST NOT reuse the message id of an abandonRequest or of the + abandoned operation until it has received a response from the server + for another request invoked subsequent to the abandonRequest, as the + abandonRequest itself does not have a response. + +4.1.2. String Types + + The LDAPString is a notational convenience to indicate that, although + strings of LDAPString type encode as OCTET STRING types, the ISO + 10646 [13] character set (a superset of Unicode) is used, encoded + following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm + characters which are the same as ASCII (0x0000 through 0x007F) are + represented as that same ASCII character in a single byte. The other + byte values are used to form a variable-length encoding of an + arbitrary character. + + LDAPString ::= OCTET STRING + + The LDAPOID is a notational convenience to indicate that the + permitted value of this string is a (UTF-8 encoded) dotted-decimal + representation of an OBJECT IDENTIFIER. + + LDAPOID ::= OCTET STRING + + For example, + + 1.3.6.1.4.1.1466.1.2.3 + +4.1.3. Distinguished Name and Relative Distinguished Name + + An LDAPDN and a RelativeLDAPDN are respectively defined to be the + representation of a Distinguished Name and a Relative Distinguished + Name after encoding according to the specification in [4], such that + + + +Wahl, et. al. Standards Track [Page 11] + +RFC 2251 LDAPv3 December 1997 + + + ::= + + ::= + + where and are as defined in [4]. + + LDAPDN ::= LDAPString + + RelativeLDAPDN ::= LDAPString + + Only Attribute Types can be present in a relative distinguished name + component; the options of Attribute Descriptions (next section) MUST + NOT be used in specifying distinguished names. + +4.1.4. Attribute Type + + An AttributeType takes on as its value the textual string associated + with that AttributeType in its specification. + + AttributeType ::= LDAPString + + Each attribute type has a unique OBJECT IDENTIFIER which has been + assigned to it. This identifier may be written as decimal digits + with components separated by periods, e.g. "2.5.4.10". + + A specification may also assign one or more textual names for an + attribute type. These names MUST begin with a letter, and only + contain ASCII letters, digit characters and hyphens. They are case + insensitive. (These ASCII characters are identical to ISO 10646 + characters whose UTF-8 encoding is a single byte between 0x00 and + 0x7F.) + + If the server has a textual name for an attribute type, it MUST use a + textual name for attributes returned in search results. The dotted- + decimal OBJECT IDENTIFIER is only used if there is no textual name + for an attribute type. + + Attribute type textual names are non-unique, as two different + specifications (neither in standards track RFCs) may choose the same + name. + + A server which masters or shadows entries SHOULD list all the + attribute types it supports in the subschema entries, using the + attributeTypes attribute. Servers which support an open-ended set of + attributes SHOULD include at least the attributeTypes value for the + 'objectClass' attribute. Clients MAY retrieve the attributeTypes + value from subschema entries in order to obtain the OBJECT IDENTIFIER + and other information associated with attribute types. + + + +Wahl, et. al. Standards Track [Page 12] + +RFC 2251 LDAPv3 December 1997 + + + Some attribute type names which are used in this version of LDAP are + described in [5]. Servers may implement additional attribute types. + +4.1.5. Attribute Description + + An AttributeDescription is a superset of the definition of the + AttributeType. It has the same ASN.1 definition, but allows + additional options to be specified. They are also case insensitive. + + AttributeDescription ::= LDAPString + + A value of AttributeDescription is based on the following BNF: + + ::= [ ";" ] + + ::=
::= the one or two decimal integer day of the month in + the range 1 to 31. + + ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | + "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" + + ::= the two decimal integer year of the century in the + range 00 to 99. + + + + + +[Page 32] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ::= the two decimal integer hour of the day in the + range 00 to 24. + + ::= the two decimal integer minute of the hour in the + range 00 to 59. + + ::= the two decimal integer second of the minute in the + range 00 to 59. + + ::= "UT" for Universal Time (the default) or other + time zone designator (as in [2]). + + + + ------------------------------------------------------------- + + Return Path Example + + Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA> + + Example 9 + + ------------------------------------------------------------- + + ------------------------------------------------------------- + + Time Stamp Line Example + + Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT + + Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25 + id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT + + Example 10 + + ------------------------------------------------------------- + + + + + + + + + + + + + +Postel [Page 33] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 4.2. SMTP REPLIES + + Replies to SMTP commands are devised to ensure the synchronization + of requests and actions in the process of mail transfer, and to + guarantee that the sender-SMTP always knows the state of the + receiver-SMTP. Every command must generate exactly one reply. + + The details of the command-reply sequence are made explicit in + Section 5.3 on Sequencing and Section 5.4 State Diagrams. + + An SMTP reply consists of a three digit number (transmitted as + three alphanumeric characters) followed by some text. The number + is intended for use by automata to determine what state to enter + next; the text is meant for the human user. It is intended that + the three digits contain enough encoded information that the + sender-SMTP need not examine the text and may either discard it or + pass it on to the user, as appropriate. In particular, the text + may be receiver-dependent and context dependent, so there are + likely to be varying texts for each reply code. A discussion of + the theory of reply codes is given in Appendix E. Formally, a + reply is defined to be the sequence: a three-digit code, , + one line of text, and , or a multiline reply (as defined in + Appendix E). Only the EXPN and HELP commands are expected to + result in multiline replies in normal circumstances, however + multiline replies are allowed for any command. + + + + + + + + + + + + + + + + + + + + + + + + +[Page 34] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.2.1. REPLY CODES BY FUNCTION GROUPS + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + + 220 Service ready + 221 Service closing transmission channel + 421 Service not available, + closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + + 250 Requested mail action okay, completed + 251 User not local; will forward to + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 451 Requested action aborted: error in processing + 551 User not local; please try + 452 Requested action not taken: insufficient system storage + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 354 Start mail input; end with . + 554 Transaction failed + + + + + + + + + + + + + +Postel [Page 35] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 4.2.2. NUMERIC ORDER LIST OF REPLY CODES + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + 220 Service ready + 221 Service closing transmission channel + 250 Requested mail action okay, completed + 251 User not local; will forward to + + 354 Start mail input; end with . + + 421 Service not available, + closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 551 User not local; please try + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 554 Transaction failed + + + + + + + + + + + + + +[Page 36] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.3. SEQUENCING OF COMMANDS AND REPLIES + + The communication between the sender and receiver is intended to + be an alternating dialogue, controlled by the sender. As such, + the sender issues a command and the receiver responds with a + reply. The sender must wait for this response before sending + further commands. + + One important reply is the connection greeting. Normally, a + receiver will send a 220 "Service ready" reply when the connection + is completed. The sender should wait for this greeting message + before sending any commands. + + Note: all the greeting type replies have the official name of + the server host as the first word following the reply code. + + For example, + + 220 USC-ISIF.ARPA Service ready + + The table below lists alternative success and failure replies for + each command. These must be strictly adhered to; a receiver may + substitute text in the replies, but the meaning and action implied + by the code numbers and by the specific command reply sequence + cannot be altered. + + COMMAND-REPLY SEQUENCES + + Each command is listed with its possible replies. The prefixes + used before the possible replies are "P" for preliminary (not + used in SMTP), "I" for intermediate, "S" for success, "F" for + failure, and "E" for error. The 421 reply (service not + available, closing transmission channel) may be given to any + command if the SMTP-receiver knows it must shut down. This + listing forms the basis for the State Diagrams in Section 4.4. + + CONNECTION ESTABLISHMENT + S: 220 + F: 421 + HELO + S: 250 + E: 500, 501, 504, 421 + MAIL + S: 250 + F: 552, 451, 452 + E: 500, 501, 421 + + + +Postel [Page 37] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + RCPT + S: 250, 251 + F: 550, 551, 552, 553, 450, 451, 452 + E: 500, 501, 503, 421 + DATA + I: 354 -> data -> S: 250 + F: 552, 554, 451, 452 + F: 451, 554 + E: 500, 501, 503, 421 + RSET + S: 250 + E: 500, 501, 504, 421 + SEND + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SOML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SAML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + VRFY + S: 250, 251 + F: 550, 551, 553 + E: 500, 501, 502, 504, 421 + EXPN + S: 250 + F: 550 + E: 500, 501, 502, 504, 421 + HELP + S: 211, 214 + E: 500, 501, 502, 504, 421 + NOOP + S: 250 + E: 500, 421 + QUIT + S: 221 + E: 500 + TURN + S: 250 + F: 502 + E: 500, 503 + + + + +[Page 38] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.4. STATE DIAGRAMS + + Following are state diagrams for a simple-minded SMTP + implementation. Only the first digit of the reply codes is used. + There is one state diagram for each group of SMTP commands. The + command groupings were determined by constructing a model for each + command and then collecting together the commands with + structurally identical models. + + For each command there are three possible outcomes: "success" + (S), "failure" (F), and "error" (E). In the state diagrams below + we use the symbol B for "begin", and the symbol W for "wait for + reply". + + First, the diagram that represents most of the SMTP commands: + + + 1,3 +---+ + ----------->| E | + | +---+ + | + +---+ cmd +---+ 2 +---+ + | B |---------->| W |---------->| S | + +---+ +---+ +---+ + | + | 4,5 +---+ + ----------->| F | + +---+ + + + This diagram models the commands: + + HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, + NOOP, QUIT, TURN. + + + + + + + + + + + + + + + +Postel [Page 39] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + A more complex diagram models the DATA command: + + + +---+ DATA +---+ 1,2 +---+ + | B |---------->| W |-------------------->| E | + +---+ +---+ ------------>+---+ + 3| |4,5 | + | | | + -------------- ----- | + | | | +---+ + | ---------- -------->| S | + | | | | +---+ + | | ------------ + | | | | + V 1,3| |2 | + +---+ data +---+ --------------->+---+ + | |---------->| W | | F | + +---+ +---+-------------------->+---+ + 4,5 + + + Note that the "data" here is a series of lines sent from the + sender to the receiver with no response expected until the last + line is sent. + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 40] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.5. DETAILS + + 4.5.1. MINIMUM IMPLEMENTATION + + In order to make SMTP workable, the following minimum + implementation is required for all receivers: + + COMMANDS -- HELO + MAIL + RCPT + DATA + RSET + NOOP + QUIT + + 4.5.2. TRANSPARENCY + + Without some provision for data transparency the character + sequence "." ends the mail text and cannot be sent + by the user. In general, users are not aware of such + "forbidden" sequences. To allow all user composed text to be + transmitted transparently the following procedures are used. + + 1. Before sending a line of mail text the sender-SMTP checks + the first character of the line. If it is a period, one + additional period is inserted at the beginning of the line. + + 2. When a line of mail text is received by the receiver-SMTP + it checks the line. If the line is composed of a single + period it is the end of mail. If the first character is a + period and there are other characters on the line, the first + character is deleted. + + The mail data may contain any of the 128 ASCII characters. All + characters are to be delivered to the recipient's mailbox + including format effectors and other control characters. If + the transmission channel provides an 8-bit byte (octets) data + stream, the 7-bit ASCII codes are transmitted right justified + in the octets with the high order bits cleared to zero. + + In some systems it may be necessary to transform the data as + it is received and stored. This may be necessary for hosts + that use a different character set than ASCII as their local + character set, or that store data in records rather than + + + + + +Postel [Page 41] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + strings. If such transforms are necessary, they must be + reversible -- especially if such transforms are applied to + mail being relayed. + + 4.5.3. SIZES + + There are several objects that have required minimum maximum + sizes. That is, every implementation must be able to receive + objects of at least these sizes, but must not send objects + larger than these sizes. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + user + + The maximum total length of a user name is 64 characters. + + domain + + The maximum total length of a domain name or number is 64 + characters. + + path + + The maximum total length of a reverse-path or + forward-path is 256 characters (including the punctuation + and element separators). + + command line + + The maximum total length of a command line including the + command word and the is 512 characters. + + reply line + + The maximum total length of a reply line including the + reply code and the is 512 characters. + + + + + +[Page 42] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + text line + + The maximum total length of a text line including the + is 1000 characters (but not counting the leading + dot duplicated for transparency). + + recipients buffer + + The maximum total number of recipients that must be + buffered is 100 recipients. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + Errors due to exceeding these limits may be reported by using + the reply codes, for example: + + 500 Line too long. + + 501 Path too long + + 552 Too many recipients. + + 552 Too much mail data. + + + + + + + + + + + + + + + + + + + +Postel [Page 43] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX A + + TCP Transport service + + The Transmission Control Protocol [3] is used in the ARPA + Internet, and in any network following the US DoD standards for + internetwork protocols. + + Connection Establishment + + The SMTP transmission channel is a TCP connection established + between the sender process port U and the receiver process port + L. This single full duplex connection is used as the + transmission channel. This protocol is assigned the service + port 25 (31 octal), that is L=25. + + Data Transfer + + The TCP connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 44] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX B + + NCP Transport service + + The ARPANET Host-to-Host Protocol [4] (implemented by the Network + Control Program) may be used in the ARPANET. + + Connection Establishment + + The SMTP transmission channel is established via NCP between + the sender process socket U and receiver process socket L. The + Initial Connection Protocol [5] is followed resulting in a pair + of simplex connections. This pair of connections is used as + the transmission channel. This protocol is assigned the + contact socket 25 (31 octal), that is L=25. + + Data Transfer + + The NCP data connections are established in 8-bit byte mode. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 45] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX C + + NITS + + The Network Independent Transport Service [6] may be used. + + Connection Establishment + + The SMTP transmission channel is established via NITS between + the sender process and receiver process. The sender process + executes the CONNECT primitive, and the waiting receiver + process executes the ACCEPT primitive. + + Data Transfer + + The NITS connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 46] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX D + + X.25 Transport service + + It may be possible to use the X.25 service [7] as provided by the + Public Data Networks directly, however, it is suggested that a + reliable end-to-end protocol such as TCP be used on top of X.25 + connections. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 47] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX E + + Theory of Reply Codes + + The three digits of the reply each have a special significance. + The first digit denotes whether the response is good, bad or + incomplete. An unsophisticated sender-SMTP will be able to + determine its next action (proceed as planned, redo, retrench, + etc.) by simply examining this first digit. A sender-SMTP that + wants to know approximately what kind of error occurred (e.g., + mail system error, command syntax error) may examine the second + digit, reserving the third digit for the finest gradation of + information. + + There are five values for the first digit of the reply code: + + 1yz Positive Preliminary reply + + The command has been accepted, but the requested action + is being held in abeyance, pending confirmation of the + information in this reply. The sender-SMTP should send + another command specifying whether to continue or abort + the action. + + [Note: SMTP does not have any commands that allow this + type of reply, and so does not have the continue or + abort commands.] + + 2yz Positive Completion reply + + The requested action has been successfully completed. A + new request may be initiated. + + 3yz Positive Intermediate reply + + The command has been accepted, but the requested action + is being held in abeyance, pending receipt of further + information. The sender-SMTP should send another command + specifying this information. This reply is used in + command sequence groups. + + 4yz Transient Negative Completion reply + + The command was not accepted and the requested action did + not occur. However, the error condition is temporary and + the action may be requested again. The sender should + + + +[Page 48] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + return to the beginning of the command sequence (if any). + It is difficult to assign a meaning to "transient" when + two different sites (receiver- and sender- SMTPs) must + agree on the interpretation. Each reply in this category + might have a different time value, but the sender-SMTP is + encouraged to try again. A rule of thumb to determine if + a reply fits into the 4yz or the 5yz category (see below) + is that replies are 4yz if they can be repeated without + any change in command form or in properties of the sender + or receiver. (E.g., the command is repeated identically + and the receiver does not put up a new implementation.) + + 5yz Permanent Negative Completion reply + + The command was not accepted and the requested action did + not occur. The sender-SMTP is discouraged from repeating + the exact request (in the same sequence). Even some + "permanent" error conditions can be corrected, so the + human user may want to direct the sender-SMTP to + reinitiate the command sequence by direct action at some + point in the future (e.g., after the spelling has been + changed, or the user has altered the account status). + + The second digit encodes responses in specific categories: + + x0z Syntax -- These replies refer to syntax errors, + syntactically correct commands that don't fit any + functional category, and unimplemented or superfluous + commands. + + x1z Information -- These are replies to requests for + information, such as status or help. + + x2z Connections -- These are replies referring to the + transmission channel. + + x3z Unspecified as yet. + + x4z Unspecified as yet. + + x5z Mail system -- These replies indicate the status of + the receiver mail system vis-a-vis the requested + transfer or other mail system action. + + The third digit gives a finer gradation of meaning in each + category specified by the second digit. The list of replies + + + +Postel [Page 49] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + illustrates this. Each reply text is recommended rather than + mandatory, and may even change according to the command with + which it is associated. On the other hand, the reply codes + must strictly follow the specifications in this section. + Receiver implementations should not invent new codes for + slightly different situations from the ones described here, but + rather adapt codes already defined. + + For example, a command such as NOOP whose successful execution + does not offer the sender-SMTP any new information will return + a 250 reply. The response is 502 when the command requests an + unimplemented non-site-specific action. A refinement of that + is the 504 reply for a command that is implemented, but that + requests an unimplemented parameter. + + The reply text may be longer than a single line; in these cases + the complete text must be marked so the sender-SMTP knows when it + can stop reading the reply. This requires a special format to + indicate a multiple line reply. + + The format for multiline replies requires that every line, + except the last, begin with the reply code, followed + immediately by a hyphen, "-" (also known as minus), followed by + text. The last line will begin with the reply code, followed + immediately by , optionally some text, and . + + For example: + 123-First line + 123-Second line + 123-234 text beginning with numbers + 123 The last line + + In many cases the sender-SMTP then simply needs to search for + the reply code followed by at the beginning of a line, and + ignore all preceding lines. In a few cases, there is important + data for the sender in the reply "text". The sender will know + these cases from the current context. + + + + + + + + + + + + +[Page 50] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX F + + Scenarios + + This section presents complete scenarios of several types of SMTP + sessions. + + A Typical SMTP Transaction Scenario + + This SMTP example shows mail sent by Smith at host USC-ISIF, to + Jones, Green, and Brown at host BBN-UNIX. Here we assume that + host USC-ISIF contacts host BBN-UNIX directly. The mail is + accepted for Jones and Brown. Green does not have a mailbox at + host BBN-UNIX. + + ------------------------------------------------------------- + + R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BBN-UNIX.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BBN-UNIX.ARPA Service closing transmission channel + + Scenario 1 + + ------------------------------------------------------------- + + + +Postel [Page 51] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Aborted SMTP Transaction Scenario + + ------------------------------------------------------------- + + R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready + S: HELO ISI-VAXA.ARPA + R: 250 MIT-Multics.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RSET + R: 250 OK + + S: QUIT + R: 221 MIT-Multics.ARPA Service closing transmission channel + + Scenario 2 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + +[Page 52] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Relayed Mail Scenario + + ------------------------------------------------------------- + + Step 1 -- Source Host to Relay Host + + R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-AI.ARPA + R: 250 USC-ISIE.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public + S: Subject: The Next Meeting of the Board + S: To: Jones@BBN-Vax.ARPA + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + +Postel [Page 53] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Step 2 -- Relay Host to Destination Host + + R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIE.ARPA + R: 250 BBN-VAX.ARPA + + S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA> + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; + 2 Nov 81 22:40:10 UT + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public + S: Subject: The Next Meeting of the Board + S: To: Jones@BBN-Vax.ARPA + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + Scenario 3 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + +[Page 54] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Verifying and Sending Scenario + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 4 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 55] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Sending and Mailing Scenarios + + First the user's name is verified, then an attempt is made to + send to the user's terminal. When that fails, the messages is + mailed to the user's mailbox. + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 450 User not active now + + S: RSET + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 5 + + ------------------------------------------------------------- + + + + + + +[Page 56] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Doing the preceding scenario more efficiently. + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SOML FROM: + R: 250 OK + + S: RCPT TO: + R: 250 User not active now, so will do mail. + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 6 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 57] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Mailing List Scenario + + First each of two mailing lists are expanded in separate sessions + with different hosts. Then the message is sent to everyone that + appeared on either list (but no duplicates) via a relay host. + + ------------------------------------------------------------- + + Step 1 -- Expanding the First List + + R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 MIT-AI.ARPA + + S: EXPN Example-People + R: 250- + R: 250-Fred Fonebone + R: 250-Xenon Y. Zither + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + S: QUIT + R: 221 MIT-AI.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 58] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Step 2 -- Expanding the Second List + + R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 MIT-MC.ARPA + + S: EXPN Interested-Parties + R: 250-Al Calico + R: 250- + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + S: QUIT + R: 221 MIT-MC.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 59] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Step 3 -- Mailing to All via a Relay Host + + R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 USC-ISIE.ARPA + + S: MAIL FROM: + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA> + R: 250 OK + S: RCPT + TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + Scenario 7 + + ------------------------------------------------------------- + + + + + + + + + + + + +[Page 60] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Forwarding Scenarios + + ------------------------------------------------------------- + + R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISIF.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 251 User not local; will forward to + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIF.ARPA Service closing transmission channel + + Scenario 8 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 61] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Step 1 -- Trying the Mailbox at the First Host + + R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISIF.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 251 User not local; will forward to + + S: RSET + R: 250 OK + + S: QUIT + R: 221 USC-ISIF.ARPA Service closing transmission channel + + Step 2 -- Delivering the Mail at the Second Host + + R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISI.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISI.ARPA Service closing transmission channel + + Scenario 9 + + ------------------------------------------------------------- + + + + +[Page 62] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Too Many Recipients Scenario + + ------------------------------------------------------------- + + R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BERKELEY.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 552 Recipient storage full, try again in another transaction + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BERKELEY.ARPA Service closing transmission channel + + Scenario 10 + + ------------------------------------------------------------- + + Note that a real implementation must handle many recipients as + specified in Section 4.5.3. + + + +Postel [Page 63] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +GLOSSARY + + ASCII + + American Standard Code for Information Interchange [1]. + + command + + A request for a mail service action sent by the sender-SMTP to the + receiver-SMTP. + + domain + + The hierarchially structured global character string address of a + host computer in the mail system. + + end of mail data indication + + A special sequence of characters that indicates the end of the + mail data. In particular, the five characters carriage return, + line feed, period, carriage return, line feed, in that order. + + host + + A computer in the internetwork environment on which mailboxes or + SMTP processes reside. + + line + + A a sequence of ASCII characters ending with a . + + mail data + + A sequence of ASCII characters of arbitrary length, which conforms + to the standard set in the Standard for the Format of ARPA + Internet Text Messages (RFC 822 [2]). + + mailbox + + A character string (address) which identifies a user to whom mail + is to be sent. Mailbox normally consists of the host and user + specifications. The standard mailbox naming convention is defined + to be "user@domain". Additionally, the "container" in which mail + is stored. + + + + + +[Page 64] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + receiver-SMTP process + + A process which transfers mail in cooperation with a sender-SMTP + process. It waits for a connection to be established via the + transport service. It receives SMTP commands from the + sender-SMTP, sends replies, and performs the specified operations. + + reply + + A reply is an acknowledgment (positive or negative) sent from + receiver to sender via the transmission channel in response to a + command. The general form of a reply is a completion code + (including error codes) followed by a text string. The codes are + for use by programs and the text is usually intended for human + users. + + sender-SMTP process + + A process which transfers mail in cooperation with a receiver-SMTP + process. A local language may be used in the user interface + command/reply dialogue. The sender-SMTP initiates the transport + service connection. It initiates SMTP commands, receives replies, + and governs the transfer of mail. + + session + + The set of exchanges that occur while the transmission channel is + open. + + transaction + + The set of exchanges required for one message to be transmitted + for one or more recipients. + + transmission channel + + A full-duplex communication path between a sender-SMTP and a + receiver-SMTP for the exchange of commands, replies, and mail + text. + + transport service + + Any reliable stream-oriented data communication services. For + example, NCP, TCP, NITS. + + + + + +Postel [Page 65] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + user + + A human being (or a process on behalf of a human being) wishing to + obtain mail transfer service. In addition, a recipient of + computer mail. + + word + + A sequence of printing characters. + + + + The characters carriage return and line feed (in that order). + + + + The space character. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 66] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +REFERENCES + + [1] ASCII + + ASCII, "USA Code for Information Interchange", United States of + America Standards Institute, X3.4, 1968. Also in: Feinler, E. + and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for + the Defense Communications Agency by SRI International, Menlo + Park, California, Revised January 1978. + + [2] RFC 822 + + Crocker, D., "Standard for the Format of ARPA Internet Text + Messages," RFC 822, Department of Electrical Engineering, + University of Delaware, August 1982. + + [3] TCP + + Postel, J., ed., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", RFC 793, USC/Information Sciences + Institute, NTIS AD Number A111091, September 1981. Also in: + Feinler, E. and J. Postel, eds., "Internet Protocol Transition + Workbook", SRI International, Menlo Park, California, March 1982. + + [4] NCP + + McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, + January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [5] Initial Connection Protocol + + Postel, J., "Official Initial Connection Protocol", NIC 7101, + 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [6] NITS + + PSS/SG3, "A Network Independent Transport Service", Study Group 3, + The Post Office PSS Users Group, February 1980. Available from + the DCPU, National Physical Laboratory, Teddington, UK. + + + + +Postel [Page 67] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + [7] X.25 + + CCITT, "Recommendation X.25 - Interface Between Data Terminal + Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for + Terminals Operating in the Packet Mode on Public Data Networks," + CCITT Orange Book, Vol. VIII.2, International Telephone and + Telegraph Consultative Committee, Geneva, 1976. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 68] Postel + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc0974.txt b/server/src/site/resources/rfclist/smtp/rfc0974.txt new file mode 100644 index 00000000000..912ba11d3fd --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc0974.txt @@ -0,0 +1,365 @@ + +Network Working Group Craig Partridge +Request for Comments: 974 CSNET CIC BBN Laboratories Inc + January 1986 + + MAIL ROUTING AND THE DOMAIN SYSTEM + + +Status of this Memo + + This RFC presents a description of how mail systems on the Internet + are expected to route messages based on information from the domain + system described in RFCs 882, 883 and 973. Distribution of this memo + is unlimited. + +Introduction + + The purpose of this memo is to explain how mailers are to decide how + to route a message addressed to a given Internet domain name. This + involves a discussion of how mailers interpret MX RRs, which are used + for message routing. Note that this memo makes no statement about + how mailers are to deal with MB and MG RRs, which are used for + interpreting mailbox names. + + Under RFC-882 and RFC-883 certain assumptions about mail addresses + have been changed. Up to now, one could usually assume that if a + message was addressed to a mailbox, for example, at LOKI.BBN.COM, + that one could just open an SMTP connection to LOKI.BBN.COM and pass + the message along. This system broke down in certain situations, + such as for certain UUCP and CSNET hosts which were not directly + attached to the Internet, but these hosts could be handled as special + cases in configuration files (for example, most mailers were set up + to automatically forward mail addressed to a CSNET host to + CSNET-RELAY.ARPA). + + Under domains, one cannot simply open a connection to LOKI.BBN.COM, + but must instead ask the domain system where messages to LOKI.BBN.COM + are to be delivered. And the domain system may direct a mailer to + deliver messages to an entirely different host, such as SH.CS.NET. + Or, in a more complicated case, the mailer may learn that it has a + choice of routes to LOKI.BBN.COM. This memo is essentially a set of + guidelines on how mailers should behave in this more complex world. + + Readers are expected to be familiar with RFCs 882, 883, and the + updates to them (e.g., RFC-973). + + + + + + + + + +Partridge [Page 1] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + +What the Domain Servers Know + + The domain servers store information as a series of resource records + (RRs), each of which contains a particular piece of information about + a given domain name (which is usually, but not always, a host). The + simplest way to think of a RR is as a typed pair of datum, a domain + name matched with relevant data, and stored with some additional type + information to help systems determine when the RR is relevant. For + the purposes of message routing, the system stores RRs known as MX + RRs. Each MX matches a domain name with two pieces of data, a + preference value (an unsigned 16-bit integer), and the name of a + host. The preference number is used to indicate in what order the + mailer should attempt deliver to the MX hosts, with the lowest + numbered MX being the one to try first. Multiple MXs with the same + preference are permitted and have the same priority. + + In addition to mail information, the servers store certain other + types of RR's which mailers may encounter or choose to use. These + are: the canonical name (CNAME) RR, which simply states that the + domain name queried for is actually an alias for another domain name, + which is the proper, or canonical, name; and the Well Known Service + (WKS) RR, which stores information about network services (such as + SMTP) a given domain name supports. + +General Routing Guidelines + + Before delving into a detailed discussion of how mailers are expected + to do mail routing, it would seem to make sense to give a brief + overview of how this memo is approaching the problems that routing + poses. + + The first major principle is derived from the definition of the + preference field in MX records, and is intended to prevent mail + looping. If the mailer is on a host which is listed as an MX for the + destination host, the mailer may only deliver to an MX which has a + lower preference count than its own host. + + It is also possible to cause mail looping because routing information + is out of date or incomplete. Out of date information is only a + problem when domain tables are changed. The changes will not be + known to all affected hosts until their resolver caches time out. + There is no way to ensure that this will not happen short of + requiring mailers and their resolvers to always send their queries to + an authoritative server, and never use data stored in a cache. This + is an impractical solution, since eliminating resolver caching would + make mailing inordinately expensive. What is more, the out-of-date + RR problem should not happen if, when a domain table is changed, + + +Partridge [Page 2] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + + affected hosts (those in the list of MXs) have their resolver caches + flushed. In other words, given proper precautions, mail looping as a + result of domain information should be avoidable, without requiring + mailers to query authoritative servers. (The appropriate precaution + is to check with a host's administrator before adding that host to a + list of MXs). + + The incomplete data problem also requires some care when handling + domain queries. If the answer section of a query is incomplete + critical MX RRs may be left out. This may result in mail looping, or + in a message being mistakenly labelled undeliverable. As a result, + mailers may only accept responses from the domain system which have + complete answer sections. Note that this entire problem can be + avoided by only using virtual circuits for queries, but since this + situation is likely to be very rare and datagrams are the preferred + way to interact with the domain system, implementors should probably + just ensure that their mailer will repeat a query with virtual + circuits should the truncation bit ever be set. + +Determining Where to Send a Message + + The explanation of how mailers should decide how to route a message + is discussed in terms of the problem of a mailer on a host with + domain name LOCAL trying to deliver a message addressed to the domain + name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically + correct domain names. Furthermore, LOCAL is assumed to be the + official name for the host on which the mailer resides (i.e., it is + not a alias). + +Issuing a Query + + The first step for the mailer at LOCAL is to issue a query for MX RRs + for REMOTE. It is strongly urged that this step be taken every time + a mailer attempts to send the message. The hope is that changes in + the domain database will rapidly be used by mailers, and thus domain + administrators will be able to re-route in-transit messages for + defective hosts by simply changing their domain databases. + + Certain responses to the query are considered errors: + + Getting no response to the query. The domain server the mailer + queried never sends anything back. (This is distinct from an + answer which contains no answers to the query, which is not an + error). + + Getting a response in which the truncation field of the header is + + + +Partridge [Page 3] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + + set. (Recall discussion of incomplete queries above). Mailers + may not use responses of this type, and should repeat the query + using virtual circuits instead of datagrams. + + Getting a response in which the response code is non-zero. + + Mailers are expected to do something reasonable in the face of an + error. The behaviour for each type of error is not specified here, + but implementors should note that different types of errors should + probably be treated differently. For example, a response code of + "non-existent domain" should probably cause the message to be + returned to the sender as invalid, while a response code of "server + failure" should probably cause the message to be retried later. + + There is one other special case. If the response contains an answer + which is a CNAME RR, it indicates that REMOTE is actually an alias + for some other domain name. The query should be repeated with the + canonical domain name. + + If the response does not contain an error response, and does not + contain aliases, its answer section should be a (possibly zero + length) list of MX RRs for domain name REMOTE (or REMOTE's true + domain name if REMOTE was a alias). The next section describes how + this list is interpreted. + +Interpreting the List of MX RRs + + NOTE: This section only discusses how mailers choose which names to + try to deliver a message to, working from a list of RR's. It does + not discuss how the mailers actually make delivery. Where ever + delivering a message is mentioned, all that is meant is that the + mailer should do whatever it needs to do to transfer a message to a + remote site, given a domain name for that site. (For example, an + SMTP mailer will try to get an address for the domain name, which + involves another query to the domain system, and then, if it gets an + address, connect to the SMTP TCP port). The mechanics of actually + transferring the message over the network to the address associated + with a given domain name is not within the scope of this memo. + + It is possible that the list of MXs in the response to the query will + be empty. This is a special case. If the list is empty, mailers + should treat it as if it contained one RR, an MX RR with a preference + value of 0, and a host name of REMOTE. (I.e., REMOTE is its only + MX). In addition, the mailer should do no further processing on the + list, but should attempt to deliver the message to REMOTE. The idea + + + + +Partridge [Page 4] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + + here is that if a domain fails to advertise any information about a + particular name we will give it the benefit of the doubt and attempt + delivery. + + If the list is not empty, the mailer should remove irrelevant RR's + from the list according to the following steps. Note that the order + is significant. + + For each MX, a WKS query should be issued to see if the domain + name listed actually supports the mail service desired. MX RRs + which list domain names which do not support the service should be + discarded. This step is optional, but strongly encouraged. + + If the domain name LOCAL is listed as an MX RR, all MX RRs with a + preference value greater than or equal to that of LOCAL's must be + discarded. + + After removing irrelevant RRs, the list can again be empty. This is + now an error condition and can occur in several ways. The simplest + case is that the WKS queries have discovered that none of the hosts + listed supports the mail service desired. The message is thus deemed + undeliverable, though extremely persistent mail systems might want to + try a delivery to REMOTE's address (if it exists) before returning + the message. Another, more dangerous, possibility is that the domain + system believes that LOCAL is handling message for REMOTE, but the + mailer on LOCAL is not set up to handle mail for REMOTE. For + example, if the domain system lists LOCAL as the only MX for REMOTE, + LOCAL will delete all the entries in the list. But LOCAL is + presumably querying the domain system because it didn't know what to + do with a message addressed to REMOTE. Clearly something is wrong. + How a mailer chooses to handle these situations is to some extent + implementation dependent, and is thus left to the implementor's + discretion. + + If the list of MX RRs is not empty, the mailer should try to deliver + the message to the MXs in order (lowest preference value tried + first). The mailer is required to attempt delivery to the lowest + valued MX. Implementors are encouraged to write mailers so that they + try the MXs in order until one of the MXs accepts the message, or all + the MXs have been tried. A somewhat less demanding system, in which + a fixed number of MXs is tried, is also reasonable. Note that + multiple MXs may have the same preference value. In this case, all + MXs at with a given value must be tried before any of a higher value + are tried. In addition, in the special case in which there are + several MXs with the lowest preference value, all of them should be + tried before a message is deemed undeliverable. + + + +Partridge [Page 5] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + +Minor Special Issues + + There are a couple of special issues left out of the preceding + section because they complicated the discussion. They are treated + here in no particular order. + + Wildcard names, those containing the character '*' in them, may be + used for mail routing. There are likely to be servers on the network + which simply state that any mail to a domain is to be routed through + a relay. For example, at the time that this RFC is being written, all + mail to hosts in the domain IL is routed through RELAY.CS.NET. This + is done by creating a wildcard RR, which states that *.IL has an MX + of RELAY.CS.NET. This should be transparent to the mailer since the + domain servers will hide this wildcard match. (If it matches *.IL + with HUJI.IL for example, a domain server will return an RR + containing HUJI.IL, not *.IL). If by some accident a mailer receives + an RR with a wildcard domain name in its name or data section it + should discard the RR. + + Note that the algorithm to delete irrelevant RRs breaks if LOCAL has + a alias and the alias is listed in the MX records for REMOTE. (E.g. + REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This + can be avoided if aliases are never used in the data section of MX + RRs. + + Implementors should understand that the query and interpretation of + the query is only performed for REMOTE. It is not repeated for the + MX RRs listed for REMOTE. You cannot try to support more extravagant + mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an MX + for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL, + but this does not mean that UNIX.BBN.COM accepts any responsibility + for mail for .IL). + + Finally, it should be noted that this is a standard for routing on + the Internet. Mailers serving hosts which lie on multiple networks + will presumably have to make some decisions about which network to + route through. This decision making is outside the scope of this + memo, although mailers may well use the domain system to help them + decide. However, once a mailer decides to deliver a message via the + Internet it must apply these rules to route the message. + + + + + + + + + +Partridge [Page 6] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + +Examples + + To illustrate the discussion above, here are three examples of how + mailers should route messages. All examples work with the following + database: + + A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG + A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG + A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG + A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP + + B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG + B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG + B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP + + C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG + C.EXAMP + diff --git a/server/src/site/resources/rfclist/smtp/rfc1652.txt b/server/src/site/resources/rfclist/smtp/rfc1652.txt new file mode 100644 index 00000000000..4700eb5c950 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1652.txt @@ -0,0 +1,340 @@ + + + + + +Network Working Group J. Klensin, WG Chair +Request for Comments: 1652 MCI +Obsoletes: 1426 N. Freed, Editor +Category: Standards Track Innosoft + M. Rose + Dover Beach Consulting, Inc. + E. Stefferud + Network Management Associates, Inc. + D. Crocker + Silicon Graphics, Inc. + July 1994 + + + SMTP Service Extension for 8bit-MIMEtransport + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines an extension to the SMTP service whereby an SMTP + content body consisting of text containing octets outside of the US- + ASCII octet range (hex 00-7F) may be relayed using SMTP. + +1. Introduction + + Although SMTP is widely and robustly deployed, various extensions + have been requested by parts of the Internet community. In + particular, a significant portion of the Internet community wishes to + exchange messages in which the content body consists of a MIME + message [3] containing arbitrary octet-aligned material. This memo + uses the mechanism described in [5] to define an extension to the + SMTP service whereby such contents may be exchanged. Note that this + extension does NOT eliminate the possibility of an SMTP server + limiting line length; servers are free to implement this extension + but nevertheless set a line length limit no lower than 1000 octets. + Given that this restriction still applies, this extension does NOT + provide a means for transferring unencoded binary via SMTP. + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 1] + +RFC 1652 SMTP 8bit-MIMEtransport July 1994 + + +2. Framework for the 8bit MIME Transport Extension + + The 8bit MIME transport extension is laid out as follows: + + (1) the name of the SMTP service extension defined here is + 8bit-MIMEtransport; + + (2) the EHLO keyword value associated with the extension is + 8BITMIME; + + (3) no parameter is used with the 8BITMIME EHLO keyword; + + (4) one optional parameter using the keyword BODY is added to + the MAIL FROM command. The value associated with this + parameter is a keyword indicating whether a 7bit message + (in strict compliance with [1]) or a MIME message (in + strict compliance with [3]) with arbitrary octet content + is being sent. The syntax of the value is as follows, + using the ABNF notation of [2]: + + body-value ::= "7BIT" / "8BITMIME" + + (5) no additional SMTP verbs are defined by this extension; + and, + + (6) the next section specifies how support for the extension + affects the behavior of a server and client SMTP. + +3. The 8bit-MIMEtransport service extension + + When a client SMTP wishes to submit (using the MAIL command) a + content body consisting of a MIME message containing arbitrary lines + of octet-aligned material, it first issues the EHLO command to the + server SMTP. If the server SMTP responds with code 250 to the EHLO + command, and the response includes the EHLO keyword value 8BITMIME, + then the server SMTP is indicating that it supports the extended MAIL + command and will accept MIME messages containing arbitrary octet- + aligned material. + + The extended MAIL command is issued by a client SMTP when it wishes + to transmit a content body consisting of a MIME message containing + arbitrary lines of octet-aligned material. The syntax for this + command is identical to the MAIL command in [1], except that a BODY + parameter must appear after the address. Only one BODY parameter may + be used in a single MAIL command. + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 2] + +RFC 1652 SMTP 8bit-MIMEtransport July 1994 + + + The complete syntax of this extended command is defined in [5]. The + esmtp-keyword is BODY and the syntax for esmtp-value is given by the + syntax for body-value shown above. + + The value associated with the BODY parameter indicates whether the + content body which will be passed using the DATA command consists of + a MIME message containing some arbitrary octet-aligned material + ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT"). + + A server which supports the 8-bit MIME transport service extension + shall preserve all bits in each octet passed using the DATA command. + + Naturally, the usual SMTP data-stuffing algorithm applies so that a + content which contains the five-character sequence of + + + + or a content that begins with the three-character sequence of + + + + does not prematurely terminate the transfer of the content. Further, + it should be noted that the CR-LF pair immediately preceeding the + final dot is considered part of the content. Finally, although the + content body contains arbitrary lines of octet-aligned material, the + length of each line (number of octets between two CR-LF pairs), is + still subject to SMTP server line length restrictions (which may + allow as few as 1000 octets on a single line). This restriction means + that this extension MAY provide the necessary facilities for + transferring a MIME object with the 8BIT content-transfer-encoding, + it DOES NOT provide a means of transferring an object with the BINARY + content-transfer-encoding. + + Once a server SMTP supporting the 8bit-MIMEtransport service + extension accepts a content body containing octets with the high- + order (8th) bit set, the server SMTP must deliver or relay the + content in such a way as to preserve all bits in each octet. + + If a server SMTP does not support the 8-bit MIME transport extension + (either by not responding with code 250 to the EHLO command, or by + not including the EHLO keyword value 8BITMIME in its response), then + the client SMTP must not, under any circumstances, attempt to + transfer a content which contains characters outside the US-ASCII + octet range (hex 00-7F). + + A client SMTP has two options in this case: first, it may implement a + gateway transformation to convert the message into valid 7bit MIME, + or second, or may treat this as a permanent error and handle it in + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 3] + +RFC 1652 SMTP 8bit-MIMEtransport July 1994 + + + the usual manner for delivery failures. The specifics of the + transformation from 8bit MIME to 7bit MIME are not described by this + RFC; the conversion is nevertheless constrained in the following + ways: + + (1) it must cause no loss of information; MIME transport + encodings must be employed as needed to insure this is + the case, and + + (2) the resulting message must be valid 7bit MIME. + +4. Usage Example + + The following dialogue illustrates the use of the 8bit-MIMEtransport + service extension: + + S: + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250-dbc.mtview.ca.us says hello + S: 250 8BITMIME + C: MAIL FROM: BODY=8BITMIME + S: 250 ... Sender and 8BITMIME ok + C: RCPT TO: + S: 250 ... Recipient ok + C: DATA + S: 354 Send 8BITMIME message, ending in CRLF.CRLF. + ... + C: . + S: 250 OK + C: QUIT + S: 250 Goodbye + +5. 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 [1]. + +6. Acknowledgements + + This document represents a synthesis of the ideas of many people and + reactions to the ideas and proposals of others. Randall Atkinson, + Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas + and text sufficient to be considered co-authors. Other important + suggestions, text, or encouragement came from Harald Alvestrand, Jim + Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 4] + +RFC 1652 SMTP 8bit-MIMEtransport July 1994 + + + Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. + Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John + Wagner, Rayan Zachariassen, and the contributions of the entire IETF + SMTP Working Group. Of course, none of the individuals are + necessarily responsible for the combination of ideas represented + here. Indeed, in some cases, the response to a particular criticism + was to accept the problem identification but to include an entirely + different solution from the one originally proposed. + +7. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, September 1993. + + [4] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1522, University of Tennessee, September 1993. + + [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, + "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach + Consulting, Inc., Network Management Associates, Inc., Silicon + Graphics, Inc., July 1994. + + [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC + 974, BBN, January 1986. + +8. Chair, Editor, and Authors' Addresses + + John Klensin, WG Chair + MCI Data Services Division + 2100 Reston Parkway, 6th floor + Reston, VA 22091 + USA + + Phone:: 1 703 715 7361 + Fax: +1 703 715 7435 + EMail: klensin@mci.net + + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 5] + +RFC 1652 SMTP 8bit-MIMEtransport July 1994 + + + Ned Freed, Editor + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone:: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Moutain View, CA 94043-2186 + USA + + Phone: +1 415 968 1052 + Fax: +1 415 968 2510 + EMail: mrose@dbc.mtview.ca.us + + + Einar A. Stefferud + Network Management Associates, Inc. + 17301 Drey Lane + Huntington Beach, CA, 92647-5615 + USA + + Phone: +1 714 842 3711 + Fax: +1 714 848 2091 + EMail: stef@nma.com + + + Dave Crocker + Silicon Graphics, Inc. + 2011 N. Shoreline Blvd. + P.O. Box 7311 + Mountain View, CA 94039 + USA + + Phone: +1 415 390 1804 + Fax: +1 415 962 8404 + EMail: dcrocker@sgi.com + + + + + + + + +Klensin, Freed, Rose, Stefferud & Crocker [Page 6] + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc1830.txt b/server/src/site/resources/rfclist/smtp/rfc1830.txt new file mode 100644 index 00000000000..dab73522c16 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1830.txt @@ -0,0 +1,452 @@ + + + + + +Network Working Group G. Vaudreuil +Request for Comments: 1830 Octel Network Services +Category: Experimental August 1995 + + + SMTP Service Extensions + for Transmission of Large + and Binary MIME Messages + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +1. Abstract + + This memo defines two extensions to the SMTP service. The first + service enables a SMTP client and server to negotiate the use of an + alternate DATA command "BDAT" for efficiently sending large MIME + messages. The second extension takes advantage of the BDAT command + to permit the negotiated sending of unencoded binary data. + +2. Introduction + + The MIME extensions to the Internet message protocol provides for the + transmission of many kinds of data which were previously unsupported + in Internet mail. Anticipating the need to more efficiently + transport the new media made possible with MIME, the SMTP protocol + has been extended to provide transport for new message types. RFC + 1426 defines one such extension for the transmission of unencoded 8 + bit MIME messages [8BIT]. This service extension permits the + receiver SMTP to declare support for 8 bit body parts and the sender + to request 8 bit transmission of a particular message. + + One expected result of the use of MIME is that the Internet mail + system will be expected to carry very large mail messages. In such + transactions, there is a need to eliminate the requirement that the + message be scanned for "CR LF . CR LF" sequences upon sending and + receiving to detect the end of message. + + Independent of the need to send large messages, Internet mail is + increasingly multi-media there is a need to avoid the overhead of + base64 and quoted-printable encoding of binary objects sent using the + MIME message format over SMTP between hosts which support binary + message processing. + + + + +Vaudreuil Experimental [Page 1] + +RFC 1830 Binary and Large Message Transport August 1995 + + + This memo uses the mechanism defined in [ESMTP] to define two + extensions to the SMTP service whereby a client ("sender-SMTP") may + declare support for the message chunking transmission mode using the + BDAT command and support for the sending of Binary messages. + +3. Framework for the Large Message Extensions + + The following service extension is hereby defined: + + 1) The name of the data chunking service extension is + "CHUNKING". + + 2) The EHLO keyword value associated with this extension is + "CHUNKING". + + 3) A new SMTP verb is defined "BDAT" as an alternative to + the "DATA" command of [RFC821]. The BDAT verb takes two + arguments. The first argument indicates the length of the + binary data packet. The second optional argument indicates + that the data packet is the last. + + bdat-cmd ::= "BDAT" SP chunk-size + [ SP end-marker ] CR LF + chunk-size ::= 1*DIGIT + end-marker ::= "LAST" + + + The CHUNKING service extension enables the use of the BDAT + alternative to the DATA command. This extension can be used for any + message, whether 7 bit, 8BITMIME or BINARYMIME. + + When a client SMTP wishes to submit (using the MAIL command) a large + message using the CHUNKING extension, it first issues the EHLO + command to the server SMTP. If the server SMTP responds with code + 250 to the EHLO command, and the response includes the EHLO keyword + value CHUNKING, then the server SMTP is indicating that it supports + the BDAT command and will accept the sending of messages in chunks. + + After all MAIL FROM and RCPT TO responses are collected and + processed, the message is sent using a series of BDAT commands. The + BDAT command takes one argument, the exact length of the data segment + in octets. The message data is sent immediately after the BDAT + command. Once the receiver-SMTP receives the specified number of + octets, it will return a 250 reply code. + + The LAST parameter on the BDAT command indicates that this is the + last chunk of message data to be sent. Any BDAT command sent after + the BDAT LAST is illegal and must be replied to with a 503 "Bad + + + +Vaudreuil Experimental [Page 2] + +RFC 1830 Binary and Large Message Transport August 1995 + + + sequence of commands" reply code. The state resulting from this error + is indeterminate. A RSET command must be sent to clear the + transaction before continuing. + + A 250 response should be sent to each BDAT data block. If a 5XX code + is sent in response to a BDAT chunk the message should be considered + failed and, the sender SMTP must not send any additional BDAT + segments. If using the ESMTP pipelining extensions [PIPE], the + sender SMTP must complete the sending of the current segment and not + send any more BDATs. When streaming, the receiver SMTP must accept + and discard additional BDAT chunks after the failed BDAT. After + receiving a 5XX error in response to a BDAT command, the resulting + state is indeterminate. A RSET command must be issued to clear the + transaction before additional commands may be sent. + + Note that an error on the receiver SMTP such as disk full or + imminent shutdown can only be reported after the BDAT segment has + been sent. It is therefore important to choose a reasonable chunk + size given the expected end to end bandwidth. + + The RSET command when issued during after the first BDAT and before + the BDAT LAST clears all segments sent during that transaction and + resets the session. + + DATA and BDAT commands cannot be used in the same transaction. If a + DATA statement is issued after a BDAT for the current transaction, a + 503 "Bad sequence of commands" must be issued. The state resulting + from this error is indeterminate. A RSET command must be sent to + clear the transaction before continuing. There is no prohibition on + using DATA and BDAT in the same session, so long as they are not + mixed in the same transaction. + + The local storage size of a message may not accurately reflect the + actual size of the message sent due to local storage conventions. In + particular, text messages sent with the BDAT command must be sent in + the canonical MIME format with lines delimited with a . It + may not be possible to convert the entire message to the canonical + format at once. Chunking provides a mechanism to convert the message + to canonical form, accurately count the bytes, and send the message a + single chunk at a time. + + Note that correct byte counting is essential. If too many bytes + are indicated by the sender SMTP, the receiver SMTP will continue + to wait for the remainder of the data or will read the subsequent + command as additional message data. In the case where a portion + of the previous command was read as data, the parser will return a + syntax error when the incomplete command is read. + + + + +Vaudreuil Experimental [Page 3] + +RFC 1830 Binary and Large Message Transport August 1995 + + + If too few bytes are indicated by the sender SMTP, the receiver + SMTP will interpret the remainder of the message data as invalid + commands. Note that the remainder of the message data may be + binary and as such lexigraphical parsers must be prepared to + receive, process, and reject lines of arbitrary octets. + +4. Framework for the Binary Service Extension + + The following service extension is hereby defined: + + 1) The name of the binary service extension is "BINARYMIME". + + 2) The EHLO keyword value associated with this extension is + "BINARYMIME". + + 3) The BINARYMIME service extension can only be used with + the "CHUNKING" service extension. + + 4) No parameter is used with the BINARYMIME keyword. + + 5) One additional parameter to the BODY keyword defined + [8BIT] for the MAIL FROM command is defined, "BINARYMIME". + The value "BINARYMIME" associated with this parameter + indicates that this message is a Binary MIME message (in + strict compliance with [MIME]) with arbitrary octet content + being sent. The revised syntax of the value is as follows, + using the ABNF notation of [RFC822]: + + body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME" + + 6) No new verbs are defined for the BINARYMIME extension. + + A sender SMTP may request that a binary MIME message be sent without + transport encoding by sending a BINARYMIME parameter with the MAIL + FROM command. When the receiver SMTP accepts a MAIL FROM command + with the BINARYMIME body type requested, it agrees to preserve all + bits in each octet passed using the BDAT command. + + BINARYMIME cannot be used with the DATA command. If a DATA command + is issued after a MAIL FROM command containing the body-value of + "BINARYMIME", a 501 response should be sent. The resulting state + from this error condition is indeterminate and the transaction should + be reset with the RSET command. + + It is important to note that when using BINARYMIME, it is + especially important to ensure that the MIME message itself is + properly formed. In particular, it is essential that text be + canonically encoded with each line properly terminated with + + + +Vaudreuil Experimental [Page 4] + +RFC 1830 Binary and Large Message Transport August 1995 + + + . Any transformation of text into non-canonical MIME to + observe local storage conventions must be reversed before sending + as BINARYMIME. The usual line-oriented shortcuts will break if + used with BINARYMIME. + + The syntax of the extended MAIL command is identical to the MAIL + command in [RFC821], except that a BODY parameter must appear after + the address. The complete syntax of this extended command is defined + in [ESMTP]. The ESMTP-keyword is BODY and the syntax for ESMTP-value + is given by the syntax for body-value in [ESMTP]. + + If a receiver SMTP does not support the BINARYMIME message format + (either by not responding with code 250 to the EHLO command, or by + rejecting the BINARYMIME parameter to the MAIL FROM command, then the + client SMTP must not, under any circumstances, send binary data using + the DATA or BDAT commands. + + If the receiver-SMTP does not support BINARYMIME and the message + content is a MIME object with a binary encoding, a client SMTP has + two options in this case: first, it may implement a gateway + transformation to convert the message into valid 7bit encoded MIME, + or second, it may treat this as a permanent error and handle it in + the usual manner for delivery failures. The specifics of the + transformation from Binary MIME to 7bit MIME are not described by + this RFC; the conversion is nevertheless constrained in the following + ways: + + o The conversion must cause no loss of information; MIME + transport encodings must be employed as needed to insure this + is the case. + + o The resulting message must be valid 7bit MIME. + + As of present there are no mechanisms for converting a binary MIME + object into a 8 bit-MIME object. Such a transformation will require + the specification of a new MIME content-transfer-encoding, the + standardization of which is discouraged by [MIME]. + + + + + + + + + + + + + + +Vaudreuil Experimental [Page 5] + +RFC 1830 Binary and Large Message Transport August 1995 + + +5. Examples + +5.1 Simple Chunking + + The following simple dialogue illustrates the use of the large + message extension to send a short psudo-RFC822 message to one + recipient using the CHUNKING extension: + + + R: + S: + R: 220 cnri.reston.va.us SMTP service ready + S: EHLO ymir.claremont.edu + R: 250-cnri.reston.va.us says hello + R: 250 CHUNKING + S: MAIL FROM: + R: 250 ... Sender ok + S: RCPT TO: + R: 250 ... Recipient ok + S: BDAT 69 LAST + S: To: Susan@random.com + S: From: Sam@random.com + S: Subject: This is a bodyless test message + R: 250 Message OK, 69 octets received + S: QUIT + R: 221 Goodbye + +5.2 Pipelining Binarymime + + The following dialogue illustrates the use of the large message + extension to send a BINARYMIME object to two recipients using the + CHUNKING and PIPELINING extensions: + + R: + S: + R: 220 cnri.reston.va.us SMTP service ready + S: EHLO ymir.claremont.edu + R: 250-cnri.reston.va.us says hello + R: 250-PIPELINING + R: 250-BINARYMIME + R: 250 CHUNKING + S: MAIL FROM: BODY=BINARYMIME + S: RCPT TO: + S: RCPT TO: + R: 250 ... Sender and BINARYMIME ok + R: 250 ... Recipient ok + R: 250 ... Recipient ok + S: BDAT 100000 + + + +Vaudreuil Experimental [Page 6] + +RFC 1830 Binary and Large Message Transport August 1995 + + + S: (First 10000 octets of canonical MIME message data) + S: BDAT 324 LAST + S: (Remaining 324 octets of canonical MIME message data) + R: 250 100000 bytes received + R: 250 Message OK, 100324 octets received + S: QUIT + R: 221 Goodbye + +6. 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 [RFC821], or otherwise + made possible by [MIME]. + +7. Acknowledgments + + This document is the result of numerous discussions in the IETF SMTP + Extensions Working Group and in particular due to the continued + advocacy of "chunking" by Neil Katin. + +8. 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, UDEL, August 1982. + + [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, June 1992. + + [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., + Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC + 1425, United Nations University, Innosoft International, + Inc., Dover Beach Consulting, Inc., Network Management + Associates, Inc., The Branch Office, February 1993. + + [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., + Stefferud, E., and D. Crocker, "SMTP Service Extension for + 8bit-MIMEtransport" RFC 1426, United Nations University, + Innosoft International, Inc., Dover Beach Consulting, Inc., + Network Management Associates, Inc., The Branch Office, + February 1993. + + [PIPE] Freed, N., "SMTP Service Extensions for Command + Pipelining", Innosoft International, Work in Progress. + + + + +Vaudreuil Experimental [Page 7] + +RFC 1830 Binary and Large Message Transport August 1995 + + +9. Author's Address + + Gregory M. Vaudreuil + Octel Network Services + 17060 Dallas Parkway + Suite 214 + Dallas, TX 75248-1905 + + Voice/Fax: 214-733-2722 + EMail: Greg.Vaudreuil@Octel.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Experimental [Page 8] + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc1869.txt b/server/src/site/resources/rfclist/smtp/rfc1869.txt new file mode 100644 index 00000000000..64e84a70424 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1869.txt @@ -0,0 +1,620 @@ + + + + + +Network Working Group J. Klensin, WG Chair +Request For Comments: 1869 MCI +STD: 10 N. Freed, Editor +Obsoletes: 1651 Innosoft International, Inc. +Category: Standards Track M. Rose + Dover Beach Consulting, Inc. + E. Stefferud + Network Management Associates, Inc. + D. Crocker + Brandenburg Consulting + November 1995 + + + SMTP Service Extensions + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This memo defines a framework for extending the SMTP service by + defining a means whereby a server SMTP can inform a client SMTP as to + the service extensions it supports. Extensions to the SMTP service + are registered with the IANA. This framework does not require + modification of existing SMTP clients or servers unless the features + of the service extensions are to be requested or provided. + +2. Introduction + + The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable, + effective basis for the relay function of message transfer agents. + Although a decade old, SMTP has proven remarkably resilient. + Nevertheless, the need for a number of protocol extensions has become + evident. Rather than describing these extensions as separate and + haphazard entities, this document enhances SMTP in a straightforward + fashion that provides a framework in which all future extensions can + be built in a single consistent way. + +3. Framework for SMTP Extensions + + For the purpose of service extensions to SMTP, SMTP relays a mail + object containing an envelope and a content. + + + + +Klensin, et al Standards Track [Page 1] + +RFC 1869 SMTP Service Extensions November 1995 + + + (1) The SMTP envelope is straightforward, and is sent as a + series of SMTP protocol units: it consists of an + originator address (to which error reports should be + directed); a delivery mode (e.g., deliver to recipient + mailboxes); and, one or more recipient addresses. + + (2) The SMTP content is sent in the SMTP DATA protocol unit + and has two parts: the headers and the body. The + headers form a collection of field/value pairs + structured according to RFC 822 [2], whilst the body, + if structured, is defined according to MIME [3]. The + content is textual in nature, expressed using the US + ASCII repertoire (ANSI X3.4-1986). Although extensions + (such as MIME) may relax this restriction for the + content body, the content headers are always encoded + using the US ASCII repertoire. The algorithm defined in + [4] is used to represent header values outside the US + ASCII repertoire, whilst still encoding them using the + US ASCII repertoire. + + Although SMTP is widely and robustly deployed, some parts of the + Internet community might wish to extend the SMTP service. This memo + defines a means whereby both an extended SMTP client and server may + recognize each other as such and the server can inform the client as + to the service extensions that it supports. + + It must be emphasized that any extension to the SMTP service should + not be considered lightly. SMTP's strength comes primarily from its + simplicity. Experience with many protocols has shown that: + + protocols with few options tend towards ubiquity, whilst + protocols with many options tend towards obscurity. + + This means that 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. + + Given this environment, the framework for the extensions described in + this memo consists of: + + (1) a new SMTP command (section 4) + + (2) a registry of SMTP service extensions (section 5) + + (3) additional parameters to the SMTP MAIL FROM and RCPT TO + commands (section 6). + + + + +Klensin, et al Standards Track [Page 2] + +RFC 1869 SMTP Service Extensions November 1995 + + +4. The EHLO command + + A client SMTP supporting SMTP service extensions should start an SMTP + session by issuing the EHLO command instead of the HELO command. If + the SMTP server supports the SMTP service extensions it will give a + successful response (see section 4.3), a failure response (see 4.4), + or an error response (4.5). If the SMTP server does not support any + SMTP service extensions it will generate an error response (see + section 4.5). + +4.1. Changes to STD 10, RFC 821 + + This specification is intended to extend STD 10, RFC 821 without + impacting existing services in any way. The minor changes needed are + enumerated below. + +4.1.1. First command + + RFC 821 states that the first command in an SMTP session must be the + HELO command. This requirement is hereby amended to allow a session + to start with either EHLO or HELO. + +4.1.2. Maximum command line length + + This specification extends the SMTP MAIL FROM and RCPT TO to allow + additional parameters and parameter values. It is possible that the + MAIL FROM and RCPT TO lines that result will exceed the 512 character + limit on command line length imposed by RFC 821. This limit is + hereby amended to only apply to command lines without any parameters. + Each specification that defines new MAIL FROM or RCPT TO parameters + must also specify maximum parameter value lengths for each parameter + so that implementors of some set of extensions know how much buffer + space must be allocated. The maximum command length that must be + supported by an SMTP implementation with extensions is 512 plus the + sum of all the maximum parameter lengths for all the extensions + supported. + +4.2. Command syntax + + The syntax for this command, using the ABNF notation of [2], is: + + ehlo-cmd ::= "EHLO" SP domain CR LF + + If successful, the server SMTP responds with code 250. On failure, + the server SMTP responds with code 550. On error, the server SMTP + responds with one of codes 500, 501, 502, 504, or 421. + + + + + +Klensin, et al Standards Track [Page 3] + +RFC 1869 SMTP Service Extensions November 1995 + + + This command is issued instead of the HELO command, and may be issued + at any time that a HELO command would be appropriate. That is, if + the EHLO command is issued, and a successful response is returned, + then a subsequent HELO or EHLO command will result in the server SMTP + replying with code 503. A client SMTP must not cache any information + returned if the EHLO command succeeds. That is, a client SMTP must + issue the EHLO command at the start of each SMTP session if + information about extended facilities is needed. + +4.3. Successful response + + If the server SMTP implements and is able to perform the EHLO + command, it will return code 250. This indicates that both the + server and client SMTP are in the initial state, that is, there is no + transaction in progress and all state tables and buffers are cleared. + + Normally, this response will be a multiline reply. Each line of the + response contains a keyword and, optionally, one or more parameters. + The syntax for a positive response, using the ABNF notation of [2], + is: + + ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF + / ( "250-" domain [ SP greeting ] CR LF + *( "250-" ehlo-line CR LF ) + "250" SP ehlo-line CR LF ) + + ; the usual HELO chit-chat + greeting ::= 1* + + ehlo-line ::= ehlo-keyword *( SP ehlo-param ) + + ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on ehlo-keyword + ehlo-param ::= 1* + + ALPHA ::= + DIGIT ::= + + CR ::= + LF ::= + + + +Klensin, et al Standards Track [Page 4] + +RFC 1869 SMTP Service Extensions November 1995 + + + SP ::= + + 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 begun in + RFC 821. + + The IANA maintains a registry of SMTP service extensions. Associated + with each such extension is a corresponding EHLO keyword value. Each + service extension registered with the IANA must be defined in an RFC. + Such RFCs must either be on the standards-track or must define an + IESG-approved experimental protocol. The definition must include: + + (1) the textual name of the SMTP service extension; + + (2) the EHLO keyword value associated with the extension; + + (3) the syntax and possible values of parameters associated + with the EHLO keyword value; + + (4) 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); + + (5) any new parameters the extension associates with the + MAIL FROM or RCPT TO verbs; + + (6) how support for the extension affects the behavior of a + server and client SMTP; and, + + (7) the increment by which the extension is increasing the + maximum length of the commands MAIL FROM, RCPT TO, or + both, over that specified in RFC 821. + + In addition, any EHLO keyword value that starts with an upper or + lower case "X" refers to a local SMTP service extension, which is + used through bilateral, rather than standardized, agreement. Keywords + beginning with "X" may not be used in a registered service extension. + + Any 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. + + + + + + +Klensin, et al Standards Track [Page 5] + +RFC 1869 SMTP Service Extensions November 1995 + + + Additional verbs are bound by the same rules as EHLO keywords; + specifically, verbs begining with "X" are local extensions that may + not be registered or standardized and verbs not beginning with "X" + must always be registered. + +4.4. Failure response + + If for some reason the server SMTP is unable to list the service + extensions it supports, it will return code 554. + + In the case of a failure response, the client SMTP should issue + either the HELO or QUIT command. + +4.5. Error responses from extended servers + + If the server SMTP recognizes the EHLO command, but the command + argument is unacceptable, it will return code 501. + + If the server SMTP recognizes, but does not implement, the EHLO + command, it will return code 502. + + If the server SMTP determines that the SMTP service is no longer + available (e.g., due to imminent system shutdown), it will return + code 421. + + In the case of any error response, the client SMTP should issue + either the HELO or QUIT command. + +4.6. Responses from servers without extensions + + A server SMTP that conforms to RFC 821 but does not support the + extensions specified here will not recognize the EHLO command and + will consequently return code 500, as specified in RFC 821. The + server SMTP should stay in the same state after returning this code + (see section 4.1.1 of RFC 821). The client SMTP may then issue + either a HELO or a QUIT command. + +4.7. Responses from improperly implemented servers + + Some SMTP servers are known to disconnect the SMTP transmission + channel upon receipt of the EHLO command. The disconnect can occur + immediately or after sending a response. Such behavior violates + section 4.1.1 of RFC 821, which explicitly states that disconnection + should only occur after a QUIT command is issued. + + Nevertheless, in order to achieve maxmimum interoperablity it is + suggested that extended SMTP clients using EHLO be coded to check for + server connection closure after EHLO is sent, either before or after + + + +Klensin, et al Standards Track [Page 6] + +RFC 1869 SMTP Service Extensions November 1995 + + + returning a reply. If this happens the client must decide if the + operation can be successfully completed without using any SMTP + extensions. If it can a new connection can be opened and the HELO + command can be used. + + Other improperly-implemented servers will not accept a HELO command + after EHLO has been sent and rejected. In some cases, this problem + can be worked around by sending a RSET after the failure response to + EHLO, then sending the HELO. Clients that do this should be aware + that many implementations will return a failure code (e.g., 503 Bad + sequence of commands) in response to the RSET. This code can be + safely ignored. + +5. Initial IANA Registry + + The IANA's initial registry of SMTP service extensions consists of + these entries: + + Service Ext EHLO Keyword Parameters Verb Added Behavior + ------------- ------------ ---------- ---------- ------------------ + Send SEND none SEND defined in RFC 821 + Send or Mail SOML none SOML defined in RFC 821 + Send and Mail SAML none SAML defined in RFC 821 + Expand EXPN none EXPN defined in RFC 821 + Help HELP none HELP defined in RFC 821 + Turn TURN none TURN defined in RFC 821 + + which correspond to those SMTP commands which are defined as optional + in [5]. (The mandatory SMTP commands, according to [5], are HELO, + MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.) + +6. MAIL FROM and RCPT TO Parameters + + It is recognized that several of the extensions planned for SMTP will + make use of additional parameters associated with the MAIL FROM and + RCPT TO command. The syntax for these commands, again using the ABNF + notation of [2] as well as underlying definitions from [1], is: + + esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF + esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) + esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] + esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on esmtp-keyword + esmtp-value ::= 1* + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250 dbc.mtview.ca.us says hello + ... + + indicates that the server SMTP implements only those + SMTP commands which are defined as mandatory in [5]. + + + + + + +Klensin, et al Standards Track [Page 8] + +RFC 1869 SMTP Service Extensions November 1995 + + + (2) In contrast, an interaction of the form: + + S: + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 250-dbc.mtview.ca.us says hello + S: 250-EXPN + S: 250-HELP + S: 250-8BITMIME + S: 250-XONE + S: 250 XVRB + ... + + indicates that the server SMTP also implements the SMTP + EXPN and HELP commands, one standard service extension + (8BITMIME), and two nonstandard and unregistered + service extensions (XONE and XVRB). + + (3) Finally, a server that does not support SMTP service + extensions would act as follows: + + S: + C: + S: 220 dbc.mtview.ca.us SMTP service ready + C: EHLO ymir.claremont.edu + S: 500 Command not recognized: EHLO + ... + + The 500 response indicates that the server SMTP does + not implement the extensions specified here. The + client would normally send a HELO command and proceed + as specified in RFC 821. See section 4.7 for + additional discussion. + +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 RFC-821. It does + provide an announcement of server mail capabilities via the response + to the EHLO verb. However, all information provided by announcement + of any of the initial set of service extensions defined by this RFC + can be readily deduced by selective probing of the verbs required to + transport and deliver mail. The security implications of service + extensions described in other RFCs should be dealt with in those + RFCs. + + + + +Klensin, et al Standards Track [Page 9] + +RFC 1869 SMTP Service Extensions November 1995 + + +10. Acknowledgements + + This document represents a synthesis of the ideas of many people and + reactions to the ideas and proposals of others. Randall Atkinson, + Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas + and text sufficient to be considered co-authors. Other important + suggestions, text, or encouragement came from Harald Alvestrand, Jim + Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per + Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. + Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan + Zachariassen, and the contributions of the entire IETF SMTP Working + Group. Of course, none of the individuals are necessarily responsible + for the combination of ideas represented here. Indeed, in some cases, + the response to a particular criticism was to accept the problem + identification but to include an entirely different solution from the + one originally proposed. + +11. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, September 1993. + + [4] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1522, University of Tennessee, September 1993. + + [5] Braden, R., "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, USC/Information Sciences Institute, + October 1989. + +12. Chair, Editor, and Author Addresses + + John Klensin, WG Chair + MCI + 2100 Reston Parkway + Reston, VA 22091 + + Phone: +1 703 715-7361 + Fax: +1 703 715-7436 + EMail: klensin@mci.net + + + + + + +Klensin, et al Standards Track [Page 10] + +RFC 1869 SMTP Service Extensions November 1995 + + + Ned Freed, Editor + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Moutain View, CA 94043-2186 + USA + + Phone: +1 415 968 1052 + Fax: +1 415 968 2510 + EMail: mrose@dbc.mtview.ca.us + + + Einar A. Stefferud + Network Management Associates, Inc. + 17301 Drey Lane + Huntington Beach, CA, 92647-5615 + USA + + Phone: +1 714 842 3711 + Fax: +1 714 848 2091 + EMail: stef@nma.com + + + Dave Crocker + Brandenburg Consulting + 675 Spruce Dr. + Sunnyvale, CA 94086 USA + USA + + Phone: +1 408 246 8253 + Fax: +1 408 249 6205 + EMail: dcrocker@mordor.stanford.edu + + + + + + + + + +Klensin, et al Standards Track [Page 11] + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc1870.txt b/server/src/site/resources/rfclist/smtp/rfc1870.txt new file mode 100644 index 00000000000..30d32082009 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1870.txt @@ -0,0 +1,508 @@ + + + + + +Network Working Group J. Klensin, WG Chair +Request For Comments: 1870 MCI +STD: 10 N. Freed, Editor +Obsoletes: 1653 Innosoft International, Inc. +Category: Standards Track K. Moore + University of Tennessee + November 1995 + + + SMTP Service Extension + for Message Size Declaration + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This memo defines an extension to the SMTP service whereby an SMTP + client and server may interact to give the server an opportunity to + decline to accept a message (perhaps temporarily) based on the + client's estimate of the message size. + +2. Introduction + + The MIME extensions to the Internet message protocol provide for the + transmission of many kinds of data which were previously unsupported + in Internet mail. One expected result of the use of MIME is that + SMTP will be expected to carry a much wider range of message sizes + than was previously the case. This has an impact on the amount of + resources (e.g. disk space) required by a system acting as a server. + + This memo uses the mechanism defined in [5] to define extensions to + the SMTP service whereby a client ("sender-SMTP") may declare the + size of a particular message to a server ("receiver-SMTP"), after + which the server may indicate to the client that it is or is not + willing to accept the message based on the declared message size and + whereby a server ("receiver-SMTP") may declare the maximum message + size it is willing to accept to a client ("sender-SMTP"). + + + + + + + + +Klensin, et al Standards Track [Page 1] + +RFC 1870 SMTP Size Declaration November 1995 + + +3. Framework for the Size Declaration Extension + + The following service extension is therefore defined: + + (1) the name of the SMTP service extension is "Message Size + Declaration"; + + (2) the EHLO keyword value associated with this extension is "SIZE"; + + (3) one optional parameter is allowed with this EHLO keyword value, a + decimal number indicating the fixed maximum message size in bytes + that the server will accept. The syntax of the parameter is as + follows, using the augmented BNF notation of [2]: + + size-param ::= [1*DIGIT] + + A parameter value of 0 (zero) indicates that no fixed maximum + message size is in force. If the parameter is omitted no + information is conveyed about the server's fixed maximum message + size; + + (4) one optional parameter using the keyword "SIZE" is added to the + MAIL FROM command. The value associated with this parameter is a + decimal number indicating the size of the message that is to be + transmitted. The syntax of the value is as follows, using the + augmented BNF notation of [2]: + + size-value ::= 1*20DIGIT + + (5) the maximum length of a MAIL FROM command line is increased by 26 + characters by the possible addition of the SIZE keyword and + value; + + (6) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + affects the behavior of an SMTP client and server. + +4. The Message Size Declaration service extension + + An SMTP server may have a fixed upper limit on message size. Any + attempt by a client to transfer a message which is larger than this + fixed upper limit will fail. In addition, a server normally has + limited space with which to store incoming messages. Transfer of a + message may therefore also fail due to a lack of storage space, but + might succeed at a later time. + + + + + +Klensin, et al Standards Track [Page 2] + +RFC 1870 SMTP Size Declaration November 1995 + + + A client using the unextended SMTP protocol defined in [1], can only + be informed of such failures after transmitting the entire message to + the server (which discards the transferred message). If, however, + both client and server support the Message Size Declaration service + extension, such conditions may be detected before any transfer is + attempted. + + An SMTP client wishing to relay a large content may issue the EHLO + command to start an SMTP session, to determine if the server supports + any of several service extensions. If the server responds with code + 250 to the EHLO command, and the response includes the EHLO keyword + value SIZE, then the Message Size Declaration extension is supported. + + If a numeric parameter follows the SIZE keyword value of the EHLO + response, it indicates the size of the largest message that the + server is willing to accept. Any attempt by a client to transfer a + message which is larger than this limit will be rejected with a + permanent failure (552) reply code. + + A server that supports the Message Size Declaration extension will + accept the extended version of the MAIL command described below. + When supported by the server, a client may use the extended MAIL + command (instead of the MAIL command as defined in [1]) to declare an + estimate of the size of a message it wishes to transfer. The server + may then return an appropriate error code if it determines that an + attempt to transfer a message of that size would fail. + +5. Definitions + + The message size is defined as the number of octets, including CR-LF + pairs, but not the SMTP DATA command's terminating dot or doubled + quoting dots, to be transmitted by the SMTP client after receiving + reply code 354 to the DATA command. + + The fixed maximum message size is defined as the message size of the + largest message that a server is ever willing to accept. An attempt + to transfer any message larger than the fixed maximum message size + will always fail. The fixed maximum message size may be an + implementation artifact of the SMTP server, or it may be chosen by + the administrator of the server. + + The declared message size is defined as a client's estimate of the + message size for a particular message. + + + + + + + + +Klensin, et al Standards Track [Page 3] + +RFC 1870 SMTP Size Declaration November 1995 + + +6. The extended MAIL command + + The extended MAIL command is issued by a client when it wishes to + inform a server of the size of the message to be sent. The extended + MAIL command is identical to the MAIL command as defined in [1], + except that a SIZE parameter appears after the address. + + The complete syntax of this extended command is defined in [5]. The + esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by + the syntax for size-value shown above. + + The value associated with the SIZE parameter is a decimal + representation of the declared message size in octets. This number + should include the message header, body, and the CR-LF sequences + between lines, but not the SMTP DATA command's terminating dot or + doubled quoting dots. Only one SIZE parameter may be specified in a + single MAIL command. + + Ideally, the declared message size is equal to the true message size. + However, since exact computation of the message size may be + infeasable, the client may use a heuristically-derived estimate. + Such heuristics should be chosen so that the declared message size is + usually larger than the actual message size. (This has the effect of + making the counting or non-counting of SMTP DATA dots largely an + academic point.) + + NOTE: Servers MUST NOT use the SIZE parameter to determine end of + content in the DATA command. + +6.1 Server action on receipt of the extended MAIL command + + Upon receipt of an extended MAIL command containing a SIZE parameter, + a server should determine whether the declared message size exceeds + its fixed maximum message size. If the declared message size is + smaller than the fixed maximum message size, the server may also wish + to determine whether sufficient resources are available to buffer a + message of the declared message size and to maintain it in stable + storage, until the message can be delivered or relayed to each of its + recipients. + + A server may respond to the extended MAIL command with any of the + error codes defined in [1] for the MAIL command. In addition, one of + the following error codes may be returned: + + (1) If the server currently lacks sufficient resources to accept a + message of the indicated size, but may be able to accept the + message at a later time, it responds with code "452 insufficient + system storage". + + + +Klensin, et al Standards Track [Page 4] + +RFC 1870 SMTP Size Declaration November 1995 + + + (2) If the indicated size is larger than the server's fixed maximum + message size, the server responds with code "552 message size + exceeds fixed maximium message size". + + A server is permitted, but not required, to accept a message which + is, in fact, larger than declared in the extended MAIL command, such + as might occur if the client employed a size-estimation heuristic + which was inaccurate. + +6.2 Client action on receiving response to extended MAIL command + + The client, upon receiving the server's response to the extended MAIL + command, acts as follows: + + (1) If the code "452 insufficient system storage" is returned, the + client should next send either a RSET command (if it wishes to + attempt to send other messages) or a QUIT command. The client + should then repeat the attempt to send the message to the server + at a later time. + + (2) If the code "552 message exceeds fixed maximum message size" is + received, the client should immediately send either a RSET command + (if it wishes to attempt to send additional messages), or a QUIT + command. The client should then declare the message undeliverable + and return appropriate notification to the sender (if a sender + address was present in the MAIL command). + + A successful (250) reply code in response to the extended MAIL + command does not constitute an absolute guarantee that the message + transfer will succeed. SMTP clients using the extended MAIL command + must still be prepared to handle both temporary and permanent error + reply codes (including codes 452 and 552), either immediately after + issuing the DATA command, or after transfer of the message. + +6.3 Messages larger than the declared size. + + Once a server has agreed (via the extended MAIL command) to accept a + message of a particular size, it should not return a 552 reply code + after the transfer phase of the DATA command, unless the actual size + of the message transferred is greater than the declared message size. + A server may also choose to accept a message which is somewhat larger + than the declared message size. + + A client is permitted to declare a message to be smaller than its + actual size. However, in this case, a successful (250) reply code is + no assurance that the server will accept the message or has + sufficient resources to do so. The server may reject such a message + after its DATA transfer. + + + +Klensin, et al Standards Track [Page 5] + +RFC 1870 SMTP Size Declaration November 1995 + + +6.4 Per-recipient rejection based on message size. + + A server that implements this extension may return a 452 or 552 reply + code in response to a RCPT command, based on its unwillingness to + accept a message of the declared size for a particular recipient. + + (1) If a 452 code is returned, the client may requeue the message for + later delivery to the same recipient. + + (2) If a 552 code is returned, the client may not requeue the message + for later delivery to the same recipient. + +7. Minimal usage + + A "minimal" client may use this extension to simply compare its + (perhaps estimated) size of the message that it wishes to relay, with + the server's fixed maximum message size (from the parameter to the + SIZE keyword in the EHLO response), to determine whether the server + will ever accept the message. Such an implementation need not + declare message sizes via the extended MAIL command. However, + neither will it be able to discover temporary limits on message size + due to server resource limitations, nor per-recipient limitations on + message size. + + A minimal server that employs this service extension may simply use + the SIZE keyword value to inform the client of the size of the + largest message it will accept, or to inform the client that there is + no fixed limit on message size. Such a server must accept the + extended MAIL command and return a 552 reply code if the client's + declared size exceeds its fixed size limit (if any), but it need not + detect "temporary" limitations on message size. + + The numeric parameter to the EHLO SIZE keyword is optional. If the + parameter is omitted entirely it indicates that the server does not + advertise a fixed maximum message size. A server that returns the + SIZE keyword with no parameter in response to the EHLO command may + not issue a positive (250) response to an extended MAIL command + containing a SIZE specification without first checking to see if + sufficient resources are available to transfer a message of the + declared size, and to retain it in stable storage until it can be + relayed or delivered to its recipients. If possible, the server + should actually reserve sufficient storage space to transfer the + message. + + + + + + + + +Klensin, et al Standards Track [Page 6] + +RFC 1870 SMTP Size Declaration November 1995 + + +8. Example + + The following example illustrates the use of size declaration with + some permanent and temporary failures. + + S: + C: + S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992) + C: EHLO ymir.claremont.edu + S: 250-sigurd.innosoft.com + S: 250-EXPN + S: 250-HELP + S: 250 SIZE 1000000 + C: MAIL FROM: SIZE=500000 + S: 250 Address Ok. + C: RCPT TO: + S: 250 ned@innosoft.com OK; can accomodate 500000 byte message + C: RCPT TO: + S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU + C: RCPT TO: + S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU + C: DATA + S: 354 Send message, ending in CRLF.CRLF. + ... + C: . + S: 250 Some recipients OK + C: QUIT + S: 221 Goodbye + +9. Security Considerations + + The size declaration extensions described in this memo can + conceivably be used to facilitate crude service denial attacks. + Specifically, both the information contained in the SIZE parameter + and use of the extended MAIL command make it somewhat quicker and + easier to devise an efficacious service denial attack. However, + unless implementations are very weak, these extensions do not create + any vulnerability that has not always existed with SMTP. In addition, + no issues are addressed involving trusted systems and possible + release of information via the mechanisms described in this RFC. + +10. Acknowledgements + + This document was derived from an earlier Working Group work in + progess contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot + Lear, Marshall T. Rose, and Einar Stefferud provided extensive + comments in response to earlier works in progress of both this and + the previous memo. + + + +Klensin, et al Standards Track [Page 7] + +RFC 1870 SMTP Size Declaration November 1995 + + +11. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions", RFC 1521, Bellcore, Innosoft, September 1993. + + [4] Moore, K., "Representation of Non-ASCII Text in Internet Message + Headers", RFC 1522, University of Tennessee, September 1993. + + [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, + "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft + International, Inc., Dover Beach Consulting, Inc., Network + Management Associates, Inc., Brandenburg Consulting, November + 1995. + + [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC + 974, BBN, January 1986. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Klensin, et al Standards Track [Page 8] + +RFC 1870 SMTP Size Declaration November 1995 + + +12. Chair, Editor, and Author Addresses + + John Klensin, WG Chair + MCI + 2100 Reston Parkway + Reston, VA 22091 + + Phone: +1 703 715-7361 + Fax: +1 703 715-7436 + EMail: klensin@mci.net + + + Ned Freed, Editor + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + Keith Moore + Computer Science Dept. + University of Tennessee + 107 Ayres Hall + Knoxville, TN 37996-1301 + USA + + EMail: moore@cs.utk.edu + + + + + + + + + + + + + + + + + + + + +Klensin, et al Standards Track [Page 9] + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc1891.txt b/server/src/site/resources/rfclist/smtp/rfc1891.txt new file mode 100644 index 00000000000..578cb00d464 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1891.txt @@ -0,0 +1,521 @@ + + + + + +Network Working Group K. Moore +Request for Comments: 1891 University of Tennessee +Category: Standards Track January 1996 + + + SMTP Service Extension + for Delivery Status Notifications + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This memo defines an extension to the SMTP service, which allows an + SMTP client to specify (a) that delivery status notifications (DSNs) + should be generated under certain conditions, (b) whether such + notifications should return the contents of the message, and (c) + additional information, to be returned with a DSN, that allows the + sender to identify both the recipient(s) for which the DSN was + issued, and the transaction in which the original message was sent. + + Any questions, comments, and reports of defects or ambiguities in + this specification may be sent to the mailing list for the NOTARY + working group of the IETF, using the address + . Requests to subscribe to the mailing + list should be addressed to . + Implementors of this specification are encouraged to subscribe to the + mailing list, so that they will quickly be informed of any problems + which might hinder interoperability. + + NOTE: This document is a Proposed Standard. If and when this + protocol is submitted for Draft Standard status, any normative text + (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in + this document will be re-evaluated in light of implementation + experience, and are thus subject to change. + +2. Introduction + + The SMTP protocol [1] requires that an SMTP server provide + notification of delivery failure, if it determines that a message + cannot be delivered to one or more recipients. Traditionally, such + notification consists of an ordinary Internet mail message (format + defined by [2]), sent to the envelope sender address (the argument of + + + +Moore Standards Track [Page 1] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + the SMTP MAIL command), containing an explanation of the error and at + least the headers of the failed message. + + Experience with large mail distribution lists [3] indicates that such + messages are often insufficient to diagnose problems, or even to + determine at which host or for which recipients a problem occurred. + In addition, the lack of a standardized format for delivery + notifications in Internet mail makes it difficult to exchange such + notifications with other message handling systems. + + Such experience has demonstrated a need for a delivery status + notification service for Internet electronic mail, which: + +(a) is reliable, in the sense that any DSN request will either be + honored at the time of final delivery, or result in a response + that indicates that the request cannot be honored, + +(b) when both success and failure notifications are requested, + provides an unambiguous and nonconflicting indication of whether + delivery of a message to a recipient succeeded or failed, + +(c) is stable, in that a failed attempt to deliver a DSN should never + result in the transmission of another DSN over the network, + +(d) preserves sufficient information to allow the sender to identify + both the mail transaction and the recipient address which caused + the notification, even when mail is forwarded or gatewayed to + foreign environments, and + +(e) interfaces acceptably with non-SMTP and non-822-based mail + systems, both so that notifications returned from foreign mail + systems may be useful to Internet users, and so that the + notification requests from foreign environments may be honored. + Among the requirements implied by this goal are the ability to + request non-return-of-content, and the ability to specify whether + positive delivery notifications, negative delivery notifications, + both, or neither, should be issued. + + In an attempt to provide such a service, this memo uses the mechanism + defined in [4] to define an extension to the SMTP protocol. Using + this mechanism, an SMTP client may request that an SMTP server issue + or not issue a delivery status notification (DSN) under certain + conditions. The format of a DSN is defined in [5]. + + + + + + + + +Moore Standards Track [Page 2] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +3. Framework for the Delivery Status Notification Extension + + The following service extension is therefore defined: + +(1) The name of the SMTP service extension is "Delivery Status + Notification"; + +(2) the EHLO keyword value associated with this extension is "DSN", + the meaning of which is defined in section 4 of this memo; + +(3) no parameters are allowed with this EHLO keyword value; + +(4) two optional parameters are added to the RCPT command, and two + optional parameters are added to the MAIL command: + + An optional parameter for the RCPT command, using the + esmtp-keyword "NOTIFY", (to specify the conditions under which a + delivery status notification should be generated), is defined in + section 5.1, + + An optional parameter for the RCPT command, using the + esmtp-keyword "ORCPT", (used to convey the "original" + (sender-specified) recipient address), is defined in section 5.2, + and + + An optional parameter for the MAIL command, using the + esmtp-keyword "RET", (to request that DSNs containing an + indication of delivery failure either return the entire contents + of a message or only the message headers), is defined in section + 5.3, + + An optional parameter for the MAIL command, using the + esmtp-keyword "ENVID", (used to propagate an identifier for this + message transmission envelope, which is also known to the sender + and will, if present, be returned in any DSNs issued for this + transmission), is defined in section 5.4; + +(5) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + effects the behavior of a message transfer agent. + +4. The Delivery Status Notification service extension + + An SMTP client wishing to request a DSN for a message may issue the + EHLO command to start an SMTP session, to determine if the server + supports any of several service extensions. If the server responds + with code 250 to the EHLO command, and the response includes the EHLO + + + +Moore Standards Track [Page 3] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + keyword DSN, then the Delivery Status Notification extension (as + described in this memo) is supported. + + Ordinarily, when an SMTP server returns a positive (2xx) reply code + in response to a RCPT command, it agrees to accept responsibility for + either delivering the message to the named recipient, or sending a + notification to the sender of the message indicating that delivery + has failed. However, an extended SMTP ("ESMTP") server which + implements this service extension will accept an optional NOTIFY + parameter with the RCPT command. If present, the NOTIFY parameter + alters the conditions for generation of delivery status notifications + from the default (issue notifications only on failure) specified in + [1]. The ESMTP client may also request (via the RET parameter) + whether the entire contents of the original message should be + returned (as opposed to just the headers of that message), along with + the DSN. + + In general, an ESMTP server which implements this service extension + will propagate delivery status notification requests when relaying + mail to other SMTP-based MTAs which also support this extension, and + make a "best effort" to ensure that such requests are honored when + messages are passed into other environments. + + In order that any delivery status notifications thus generated will + be meaningful to the sender, any ESMTP server which supports this + extension will attempt to propagate the following information to any + other MTAs that are used to relay the message, for use in generating + DSNs: + +(a) for each recipient, a copy of the original recipient address, as + used by the sender of the message. + + This address need not be the same as the mailbox specified in the + RCPT command. For example, if a message was originally addressed + to A@B.C and later forwarded to A@D.E, after such forwarding has + taken place, the RCPT command will specify a mailbox of A@D.E. + However, the original recipient address remains A@B.C. + + Also, if the message originated from an environment which does not + use Internet-style user@domain addresses, and was gatewayed into + SMTP, the original recipient address will preserve the original + form of the recipient address. + +(b) for the entire SMTP transaction, an envelope identification + string, which may be used by the sender to associate any delivery + status notifications with the transaction used to send the + original message. + + + + +Moore Standards Track [Page 4] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +5. Additional parameters for RCPT and MAIL commands + + The extended RCPT and MAIL commands are issued by a client when it + wishes to request a DSN from the server, under certain conditions, + for a particular recipient. The extended RCPT and MAIL commands are + identical to the RCPT and MAIL commands defined in [1], except that + one or more of the following parameters appear after the sender or + recipient address, respectively. The general syntax for extended + SMTP commands is defined in [4]. + + NOTE: Although RFC 822 ABNF is used to describe the syntax of these + parameters, they are not, in the language of that document, + "structured field bodies". Therefore, while parentheses MAY appear + within an emstp-value, they are not recognized as comment delimiters. + + The syntax for "esmtp-value" in [4] does not allow SP, "=", control + characters, or characters outside the traditional ASCII range of 1- + 127 decimal to be transmitted in an esmtp-value. Because the ENVID + and ORCPT parameters may need to convey values outside this range, + the esmtp-values for these parameters are encoded as "xtext". + "xtext" is formally defined as follows: + + xtext = *( xchar / hexchar ) + + xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, + except for "+" and "=". + +; "hexchar"s are intended to encode octets that cannot appear +; as ASCII characters within an esmtp-value. + + hexchar = ASCII "+" immediately followed by two upper case + hexadecimal digits + +When encoding an octet sequence as xtext: + ++ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", + MAY be encoded as itself. (A CHAR in this range MAY instead be + encoded as a "hexchar", at the implementor's discretion.) + ++ ASCII CHARs that fall outside the range above must be encoded as + "hexchar". + +5.1 The NOTIFY parameter of the ESMTP RCPT command + + A RCPT command issued by a client may contain the optional esmtp- + keyword "NOTIFY", to specify the conditions under which the SMTP + server should generate DSNs for that recipient. If the NOTIFY + esmtp-keyword is used, it MUST have an associated esmtp-value, + + + +Moore Standards Track [Page 5] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + formatted according to the following rules, using the ABNF of RFC + 822: + + notify-esmtp-value = "NEVER" / 1#notify-list-element + + notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" + +Notes: + +a. Multiple notify-list-elements, separated by commas, MAY appear in a + NOTIFY parameter; however, the NEVER keyword MUST appear by itself. + +b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled + in any combination of upper and lower case letters. + +The meaning of the NOTIFY parameter values is generally as follows: + ++ A NOTIFY parameter value of "NEVER" requests that a DSN not be + returned to the sender under any conditions. + ++ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" + keywords requests that a DSN be issued on successful delivery or + delivery failure, respectively. + ++ A NOTIFY parameter value containing the keyword "DELAY" indicates the + sender's willingness to receive "delayed" DSNs. Delayed DSNs may be + issued if delivery of a message has been delayed for an unusual amount + of time (as determined by the MTA at which the message is delayed), + but the final delivery status (whether successful or failure) cannot + be determined. The absence of the DELAY keyword in a NOTIFY parameter + requests that a "delayed" DSN NOT be issued under any conditions. + + The actual rules governing interpretation of the NOTIFY parameter are + given in section 6. + + For compatibility with SMTP clients that do not use the NOTIFY + facility, the absence of a NOTIFY parameter in a RCPT command may be + interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. + +5.2 The ORCPT parameter to the ESMTP RCPT command + + The ORCPT esmtp-keyword of the RCPT command is used to specify an + "original" recipient address that corresponds to the actual recipient + to which the message is to be delivered. If the ORCPT esmtp-keyword + is used, it MUST have an associated esmtp-value, which consists of + the original recipient address, encoded according to the rules below. + The ABNF for the ORCPT parameter is: + + + + +Moore Standards Track [Page 6] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + orcpt-parameter = "ORCPT=" original-recipient-address + + original-recipient-address = addr-type ";" xtext + + addr-type = atom + + The "addr-type" portion MUST be an IANA-registered electronic mail + address-type (as defined in [5]), while the "xtext" portion contains + an encoded representation of the original recipient address using the + rules in section 5 of this document. The entire ORCPT parameter MAY + be up to 500 characters in length. + + When initially submitting a message via SMTP, if the ORCPT parameter + is used, it MUST contain the same address as the RCPT TO address + (unlike the RCPT TO address, the ORCPT parameter will be encoded as + xtext). Likewise, when a mailing list submits a message via SMTP to + be distributed to the list subscribers, if ORCPT is used, the ORCPT + parameter MUST match the new RCPT TO address of each recipient, not + the address specified by the original sender of the message.) + + The "addr-type" portion of the original-recipient-address is used to + indicate the "type" of the address which appears in the ORCPT + parameter value. However, the address associated with the ORCPT + keyword is NOT constrained to conform to the syntax rules for that + "addr-type". + + Ideally, the "xtext" portion of the original-recipient-address should + contain, in encoded form, the same sequence of characters that the + sender used to specify the recipient. However, for a message + gatewayed from an environment (such as X.400) in which a recipient + address is not a simple string of printable characters, the + representation of recipient address must be defined by a + specification for gatewaying between DSNs and that environment. + +5.3 The RET parameter of the ESMTP MAIL command + + The RET esmtp-keyword on the extended MAIL command specifies whether + or not the message should be included in any failed DSN issued for + this message transmission. If the RET esmtp-keyword is used, it MUST + have an associated esmtp-value, which is one of the following + keywords: + + FULL requests that the entire message be returned in any "failed" + delivery status notification issued for this recipient. + + HDRS requests that only the headers of the message be returned. + + + + + +Moore Standards Track [Page 7] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + The FULL and HDRS keywords may be spelled in any combination of upper + and lower case letters. + + If no RET parameter is supplied, the MTA MAY return either the + headers of the message or the entire message for any DSN containing + indication of failed deliveries. + + Note that the RET parameter only applies to DSNs that indicate + delivery failure for at least one recipient. If a DSN contains no + indications of delivery failure, only the headers of the message + should be returned. + +5.4 The ENVID parameter to the ESMTP MAIL command + + The ENVID esmtp-keyword of the SMTP MAIL command is used to specify + an "envelope identifier" to be transmitted along with the message and + included in any DSNs issued for any of the recipients named in this + SMTP transaction. The purpose of the envelope identifier is to allow + the sender of a message to identify the transaction for which the DSN + was issued. + + The ABNF for the ENVID parameter is: + + envid-parameter = "ENVID=" xtext + + The ENVID esmtp-keyword MUST have an associated esmtp-value. No + meaning is assigned by the mail system to the presence or absence of + this parameter or to any esmtp-value associated with this parameter; + the information is used only by the sender or his user agent. The + ENVID parameter MAY be up to 100 characters in length. + +5.5 Restrictions on the use of Delivery Status Notification parameters + + The RET and ENVID parameters MUST NOT appear more than once each in + any single MAIL command. If more than one of either of these + parameters appears in a MAIL command, the ESMTP server SHOULD respond + with "501 syntax error in parameters or arguments". + + The NOTIFY and ORCPT parameters MUST NOT appear more than once in any + RCPT command. If more than one of either of these parameters appears + in a RCPT command, the ESMTP server SHOULD respond with "501 syntax + error in parameters or arguments". + +6. Conformance requirements + + The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer + Agents (MTAs) when accepting, relaying, or gatewaying mail, as well + as User Agents (UAs) when submitting mail to the mail transport + + + +Moore Standards Track [Page 8] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + system. The DSN extension to SMTP may be used to allow UAs to convey + the sender's requests as to when DSNs should be issued. A UA which + claims to conform to this specification must meet certain + requirements as described below. + + Typically, a message transfer agent (MTA) which supports SMTP will + assume, at different times, both the role of a SMTP client and an + SMTP server, and may also provide local delivery, gatewaying to + foreign environments, forwarding, and mailing list expansion. An MTA + which, when acting as an SMTP server, issues the DSN keyword in + response to the EHLO command, MUST obey the rules below for a + "conforming SMTP client" when acting as a client, and a "conforming + SMTP server" when acting as a server. The term "conforming MTA" + refers to an MTA which conforms to this specification, independent of + its role of client or server. + +6.1 SMTP protocol interactions + + The following rules apply to SMTP transactions in which any of the + ENVID, NOTIFY, RET, or ORCPT keywords are used: + +(a) If an SMTP client issues a MAIL command containing a valid ENVID + parameter and associated esmtp-value and/or a valid RET parameter + and associated esmtp-value, a conforming SMTP server MUST return + the same reply-code as it would to the same MAIL command without + the ENVID and/or RET parameters. A conforming SMTP server MUST + NOT refuse a MAIL command based on the absence or presence of + valid ENVID or RET parameters, or on their associated + esmtp-values. + + However, if the associated esmtp-value is not valid (i.e. contains + illegal characters), or if there is more than one ENVID or RET + parameter in a particular MAIL command, the server MUST issue the + reply-code 501 with an appropriate message (e.g. "syntax error in + parameter"). + +(b) If an SMTP client issues a RCPT command containing any valid + NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST + return the same response as it would to the same RCPT command + without those NOTIFY and/or ORCPT parameters. A conforming SMTP + server MUST NOT refuse a RCPT command based on the presence or + absence of any of these parameters. + + However, if any of the associated esmtp-values are not valid, or + if there is more than one of any of these parameters in a + particular RCPT command, the server SHOULD issue the response "501 + syntax error in parameter". + + + + +Moore Standards Track [Page 9] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2 Handling of messages received via SMTP + + This section describes how a conforming MTA should handle any + messages received via SMTP. + + NOTE: A DSN MUST NOT be returned to the sender for any message for + which the return address from the SMTP MAIL command was NULL ("<>"), + even if the sender's address is available from other sources (e.g. + the message header). However, the MTA which would otherwise issue a + DSN SHOULD inform the local postmaster of delivery failures through + some appropriate mechanism that will not itself + diff --git a/server/src/site/resources/rfclist/smtp/rfc1893.txt b/server/src/site/resources/rfclist/smtp/rfc1893.txt new file mode 100644 index 00000000000..47454b8811a --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1893.txt @@ -0,0 +1,844 @@ + + + + + +Network Working Group G. Vaudreuil +Request for Comments: 1893 Octel Network Services +Category: Standards Track January 1996 + + + Enhanced Mail System Status Codes + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Overview + + There currently is not a standard mechanism for the reporting of mail + system errors except for the limited set offered by SMTP and the + system specific text descriptions sent in mail messages. There is a + pressing need for a rich machine readable status code for use in + delivery status notifications [DSN]. This document proposes a new + set of status codes for this purpose. + + SMTP [SMTP] error codes have historically been used for reporting + mail system errors. Because of limitations in the SMTP code design, + these are not suitable for use in delivery status notifications. + SMTP provides about 12 useful codes for delivery reports. The + majority of the codes are protocol specific response codes such as + the 354 response to the SMTP data command. Each of the 12 useful + codes are each overloaded to indicate several error conditions each. + SMTP suffers some scars from history, most notably the unfortunate + damage to the reply code extension mechanism by uncontrolled use. + This proposal facilitates future extensibility by requiring the + client to interpret unknown error codes according to the theory of + codes while requiring servers to register new response codes. + + The SMTP theory of reply codes partitioned in the number space such a + manner that the remaining available codes will not provide the space + needed. The most critical example is the existence of only 5 + remaining codes for mail system errors. The mail system + classification includes both host and mailbox error conditions. The + remaining third digit space would be completely consumed as needed to + indicate MIME and media conversion errors and security system errors. + + A revision to the SMTP theory of reply codes to better distribute the + error conditions in the number space will necessarily be incompatible + with SMTP. Further, consumption of the remaining reply-code number + + + +Vaudreuil Standards Track [Page 1] + +RFC 1893 Mail System Status Codes January 1996 + + + space for delivery notification reporting will reduce the available + codes for new ESMTP extensions. + + The following proposal is based on the SMTP theory of reply codes. + It adopts the success, permanent error, and transient error semantics + of the first value, with a further description and classification in + the second. This proposal re-distributes the classifications to + better distribute the error conditions, such as separating mailbox + from host errors. + +2. Status Codes + + This document defines a new set of status codes to report mail system + conditions. These status codes are intended to be used for media and + language independent status reporting. They are not intended for + system specific diagnostics. + + The syntax of the new status codes is defined as: + + status-code = class "." subject "." detail + class = "2"/"4"/"5" + subject = 1*3digit + detail = 1*3digit + + White-space characters and comments are NOT allowed within a status- + code. Each numeric sub-code within the status-code MUST be expressed + without leading zero digits. + + Status codes consist of three numerical fields separated by ".". The + first sub-code indicates whether the delivery attempt was successful. + The second sub-code indicates the probable source of any delivery + anomalies, and the third sub-code indicates a precise error + condition. + + The codes space defined is intended to be extensible only by + standards track documents. Mail system specific status codes should + be mapped as close as possible to the standard status codes. Servers + should send only defined, registered status codes. System specific + errors and diagnostics should be carried by means other than status + codes. + + New subject and detail codes will be added over time. Because the + number space is large, it is not intended that published status codes + will ever be redefined or eliminated. Clients should preserve the + extensibility of the code space by reporting the general error + described in the subject sub-code when the specific detail is + unrecognized. + + + + +Vaudreuil Standards Track [Page 2] + +RFC 1893 Mail System Status Codes January 1996 + + + The class sub-code provides a broad classification of the status. + The enumerated values the class are defined as: + + 2.X.X Success + + Success specifies that the DSN is reporting a positive delivery + action. Detail sub-codes may provide notification of + transformations required for delivery. + + 4.X.X Persistent Transient Failure + + A persistent transient failure is one in which the message as + sent is valid, but some temporary event prevents the successful + sending of the message. Sending in the future may be successful. + + 5.X.X Permanent Failure + + A permanent failure is one which is not likely to be resolved by + resending the message in the current form. Some change to the + message or the destination must be made for successful delivery. + + A client must recognize and report class sub-code even where + subsequent subject sub-codes are unrecognized. + + The subject sub-code classifies the status. This value applies to + each of the three classifications. The subject sub-code, if + recognized, must be reported even if the additional detail provided + by the detail sub-code is not recognized. The enumerated values for + the subject sub-code are: + + X.0.X Other or Undefined Status + + There is no additional subject information available. + + X.1.X Addressing Status + + The address status reports on the originator or destination + address. It may include address syntax or validity. These + errors can generally be corrected by the sender and retried. + + X.2.X Mailbox Status + + Mailbox status indicates that something having to do with the + mailbox has cause this DSN. Mailbox issues are assumed to be + under the general control of the recipient. + + + + + + +Vaudreuil Standards Track [Page 3] + +RFC 1893 Mail System Status Codes January 1996 + + + X.3.X Mail System Status + + Mail system status indicates that something having to do + with the destination system has caused this DSN. System + issues are assumed to be under the general control of the + destination system administrator. + + X.4.X Network and Routing Status + + The networking or routing codes report status about the + delivery system itself. These system components include any + necessary infrastructure such as directory and routing + services. Network issues are assumed to be under the + control of the destination or intermediate system + administrator. + + X.5.X Mail Delivery Protocol Status + + The mail delivery protocol status codes report failures + involving the message delivery protocol. These failures + include the full range of problems resulting from + implementation errors or an unreliable connection. Mail + delivery protocol issues may be controlled by many parties + including the originating system, destination system, or + intermediate system administrators. + + X.6.X Message Content or Media Status + + The message content or media status codes report failures + involving the content of the message. These codes report + failures due to translation, transcoding, or otherwise + unsupported message media. Message content or media issues + are under the control of both the sender and the receiver, + both of whom must support a common set of supported + content-types. + + X.7.X Security or Policy Status + + The security or policy status codes report failures + involving policies such as per-recipient or per-host + filtering and cryptographic operations. Security and policy + status issues are assumed to be under the control of either + or both the sender and recipient. Both the sender and + recipient must permit the exchange of messages and arrange + the exchange of necessary keys and certificates for + cryptographic operations. + + + + + +Vaudreuil Standards Track [Page 4] + +RFC 1893 Mail System Status Codes January 1996 + + +3. Enumerated Status Codes + + The following section defines and describes the detail sub-code. The + detail value provides more information about the status and is + defined relative to the subject of the status. + + 3.1 Other or Undefined Status + + X.0.0 Other undefined Status + + Other undefined status is the only undefined error code. It + should be used for all errors for which only the class of the + error is known. + + 3.2 Address Status + + X.1.0 Other address status + + Something about the address specified in the message caused + this DSN. + + X.1.1 Bad destination mailbox address + + The mailbox specified in the address does not exist. For + Internet mail names, this means the address portion to the + left of the "@" sign is invalid. This code is only useful + for permanent failures. + + X.1.2 Bad destination system address + + The destination system specified in the address does not + exist or is incapable of accepting mail. For Internet mail + names, this means the address portion to the right of the + "@" is invalid for mail. This codes is only useful for + permanent failures. + + X.1.3 Bad destination mailbox address syntax + + The destination address was syntactically invalid. This can + apply to any field in the address. This code is only useful + for permanent failures. + + X.1.4 Destination mailbox address ambiguous + + The mailbox address as specified matches one or more + recipients on the destination system. This may result if a + heuristic address mapping algorithm is used to map the + specified address to a local mailbox name. + + + +Vaudreuil Standards Track [Page 5] + +RFC 1893 Mail System Status Codes January 1996 + + + X.1.5 Destination address valid + + This mailbox address as specified was valid. This status + code should be used for positive delivery reports. + + X.1.6 Destination mailbox has moved, No forwarding address + + The mailbox address provided was at one time valid, but mail + is no longer being accepted for that address. This code is + only useful for permanent failures. + + X.1.7 Bad sender's mailbox address syntax + + The sender's address was syntactically invalid. This can + apply to any field in the address. + + X.1.8 Bad sender's system address + + The sender's system specified in the address does not exist + or is incapable of accepting return mail. For domain names, + this means the address portion to the right of the "@" is + invalid for mail. + + 3.3 Mailbox Status + + X.2.0 Other or undefined mailbox status + + The mailbox exists, but something about the destination + mailbox has caused the sending of this DSN. + + X.2.1 Mailbox disabled, not accepting messages + + The mailbox exists, but is not accepting messages. This may + be a permanent error if the mailbox will never be re-enabled + or a transient error if the mailbox is only temporarily + disabled. + + X.2.2 Mailbox full + + The mailbox is full because the user has exceeded a + per-mailbox administrative quota or physical capacity. The + general semantics implies that the recipient can delete + messages to make more space available. This code should be + used as a persistent transient failure. + + + + + + + +Vaudreuil Standards Track [Page 6] + +RFC 1893 Mail System Status Codes January 1996 + + + X.2.3 Message length exceeds administrative limit + + A per-mailbox administrative message length limit has been + exceeded. This status code should be used when the + per-mailbox message length limit is less than the general + system limit. This code should be used as a permanent + failure. + + X.2.4 Mailing list expansion problem + + The mailbox is a mailing list address and the mailing list + was unable to be expanded. This code may represent a + permanent failure or a persistent transient failure. + + 3.4 Mail system status + + X.3.0 Other or undefined mail system status + + The destination system exists and normally accepts mail, but + something about the system has caused the generation of this + DSN. + + X.3.1 Mail system full + + Mail system storage has been exceeded. The general + semantics imply that the individual recipient may not be + able to delete material to make room for additional + messages. This is useful only as a persistent transient + error. + + X.3.2 System not accepting network messages + + The host on which the mailbox is resident is not accepting + messages. Examples of such conditions include an immanent + shutdown, excessive load, or system maintenance. This is + useful for both permanent and permanent transient errors. + + X.3.3 System not capable of selected features + + Selected features specified for the message are not + supported by the destination system. This can occur in + gateways when features from one domain cannot be mapped onto + the supported feature in another. + + + + + + + + +Vaudreuil Standards Track [Page 7] + +RFC 1893 Mail System Status Codes January 1996 + + + X.3.4 Message too big for system + + The message is larger than per-message size limit. This + limit may either be for physical or administrative reasons. + This is useful only as a permanent error. + + X.3.5 System incorrectly configured + + The system is not configured in a manner which will permit + it to accept this message. + + 3.5 Network and Routing Status + + X.4.0 Other or undefined network or routing status + + Something went wrong with the networking, but it is not + clear what the problem is, or the problem cannot be well + expressed with any of the other provided detail codes. + + X.4.1 No answer from host + + The outbound connection attempt was not answered, either + because the remote system was busy, or otherwise unable to + take a call. This is useful only as a persistent transient + error. + + X.4.2 Bad connection + + The outbound connection was established, but was otherwise + unable to complete the message transaction, either because + of time-out, or inadequate connection quality. This is + useful only as a persistent transient error. + + X.4.3 Directory server failure + + The network system was unable to forward the message, + because a directory server was unavailable. This is useful + only as a persistent transient error. + + The inability to connect to an Internet DNS server is one + example of the directory server failure error. + + X.4.4 Unable to route + + The mail system was unable to determine the next hop for the + message because the necessary routing information was + unavailable from the directory server. This is useful for + both permanent and persistent transient errors. + + + +Vaudreuil Standards Track [Page 8] + +RFC 1893 Mail System Status Codes January 1996 + + + A DNS lookup returning only an SOA (Start of Administration) + record for a domain name is one example of the unable to + route error. + + X.4.5 Mail system congestion + + The mail system was unable to deliver the message because + the mail system was congested. This is useful only as a + persistent transient error. + + X.4.6 Routing loop detected + + A routing loop caused the message to be forwarded too many + times, either because of incorrect routing tables or a user + forwarding loop. This is useful only as a persistent + transient error. + + X.4.7 Delivery time expired + + The message was considered too old by the rejecting system, + either because it remained on that host too long or because + the time-to-live value specified by the sender of the + message was exceeded. If possible, the code for the actual + problem found when delivery was attempted should be returned + rather than this code. This is useful only as a persistent + transient error. + + 3.6 Mail Delivery Protocol Status + + X.5.0 Other or undefined protocol status + + Something was wrong with the protocol necessary to deliver + the message to the next hop and the problem cannot be well + expressed with any of the other provided detail codes. + + X.5.1 Invalid command + + A mail transaction protocol command was issued which was + either out of sequence or unsupported. This is useful only + as a permanent error. + + X.5.2 Syntax error + + A mail transaction protocol command was issued which could + not be interpreted, either because the syntax was wrong or + the command is unrecognized. This is useful only as a + permanent error. + + + + +Vaudreuil Standards Track [Page 9] + +RFC 1893 Mail System Status Codes January 1996 + + + X.5.3 Too many recipients + + More recipients were specified for the message than could + have been delivered by the protocol. This error should + normally result in the segmentation of the message into two, + the remainder of the recipients to be delivered on a + subsequent delivery attempt. It is included in this list in + the event that such segmentation is not possible. + + X.5.4 Invalid command arguments + + A valid mail transaction protocol command was issued with + invalid arguments, either because the arguments were out of + range or represented unrecognized features. This is useful + only as a permanent error. + + X.5.5 Wrong protocol version + + A protocol version mis-match existed which could not be + automatically resolved by the communicating parties. + + 3.7 Message Content or Message Media Status + + X.6.0 Other or undefined media error + + Something about the content of a message caused it to be + considered undeliverable and the problem cannot be well + expressed with any of the other provided detail codes. + + X.6.1 Media not supported + + The media of the message is not supported by either the + delivery protocol or the next system in the forwarding path. + This is useful only as a permanent error. + + X.6.2 Conversion required and prohibited + + The content of the message must be converted before it can + be delivered and such conversion is not permitted. Such + prohibitions may be the expression of the sender in the + message itself or the policy of the sending host. + + X.6.3 Conversion required but not supported + + The message content must be converted to be forwarded but + such conversion is not possible or is not practical by a + host in the forwarding path. This condition may result when + an ESMTP gateway supports 8bit transport but is not able to + + + +Vaudreuil Standards Track [Page 10] + +RFC 1893 Mail System Status Codes January 1996 + + + downgrade the message to 7 bit as required for the next hop. + + X.6.4 Conversion with loss performed + + This is a warning sent to the sender when message delivery + was successfully but when the delivery required a conversion + in which some data was lost. This may also be a permanant + error if the sender has indicated that conversion with loss + is prohibited for the message. + + X.6.5 Conversion Failed + + A conversion was required but was unsuccessful. This may be + useful as a permanent or persistent temporary notification. + + 3.8 Security or Policy Status + + X.7.0 Other or undefined security status + + Something related to security caused the message to be + returned, and the problem cannot be well expressed with any + of the other provided detail codes. This status code may + also be used when the condition cannot be further described + because of security policies in force. + + X.7.1 Delivery not authorized, message refused + + The sender is not authorized to send to the destination. + This can be the result of per-host or per-recipient + filtering. This memo does not discuss the merits of any + such filtering, but provides a mechanism to report such. + This is useful only as a permanent error. + + X.7.2 Mailing list expansion prohibited + + The sender is not authorized to send a message to the + intended mailing list. This is useful only as a permanent + error. + + X.7.3 Security conversion required but not possible + + A conversion from one secure messaging protocol to another + was required for delivery and such conversion was not + possible. This is useful only as a permanent error. + + + + + + + +Vaudreuil Standards Track [Page 11] + +RFC 1893 Mail System Status Codes January 1996 + + + X.7.4 Security features not supported + + A message contained security features such as secure + authentication which could not be supported on the delivery + protocol. This is useful only as a permanent error. + + X.7.5 Cryptographic failure + + A transport system otherwise authorized to validate or + decrypt a message in transport was unable to do so because + necessary information such as key was not available or such + information was invalid. + + X.7.6 Cryptographic algorithm not supported + + A transport system otherwise authorized to validate or + decrypt a message was unable to do so because the necessary + algorithm was not supported. + + X.7.7 Message integrity failure + + A transport system otherwise authorized to validate a + message was unable to do so because the message was + corrupted or altered. This may be useful as a permanent, + transient persistent, or successful delivery code. + +4. References + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, University of + Tennessee, Octel Network Services, January 1996. + +5. Security Considerations + + This document describes a status code system with increased + precision. Use of these status codes may disclose additional + information about how an internal mail system is implemented beyond + that currently available. + +6. Acknowledgments + + The author wishes to offer special thanks to Harald Alvestrand, Marko + Kaittola, and Keith Moore for their extensive review and constructive + suggestions. + + + + +Vaudreuil Standards Track [Page 12] + +RFC 1893 Mail System Status Codes January 1996 + + +7. Author's Address + + Gregory M. Vaudreuil + Octel Network Services + 17060 Dallas Parkway + Suite 214 + Dallas, TX 75248-1905 + + Voice/Fax: +1-214-733-2722 + EMail: Greg.Vaudreuil@Octel.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 13] + +RFC 1893 Mail System Status Codes January 1996 + + +8. Appendix - Collected Status Codes + + X.1.0 Other address status + X.1.1 Bad destination mailbox address + X.1.2 Bad destination system address + X.1.3 Bad destination mailbox address syntax + X.1.4 Destination mailbox address ambiguous + X.1.5 Destination mailbox address valid + X.1.6 Mailbox has moved + X.1.7 Bad sender's mailbox address syntax + X.1.8 Bad sender's system address + + X.2.0 Other or undefined mailbox status + X.2.1 Mailbox disabled, not accepting messages + X.2.2 Mailbox full + X.2.3 Message length exceeds administrative limit. + X.2.4 Mailing list expansion problem + + X.3.0 Other or undefined mail system status + X.3.1 Mail system full + X.3.2 System not accepting network messages + X.3.3 System not capable of selected features + X.3.4 Message too big for system + + X.4.0 Other or undefined network or routing status + X.4.1 No answer from host + X.4.2 Bad connection + X.4.3 Routing server failure + X.4.4 Unable to route + X.4.5 Network congestion + X.4.6 Routing loop detected + X.4.7 Delivery time expired + + X.5.0 Other or undefined protocol status + X.5.1 Invalid command + X.5.2 Syntax error + X.5.3 Too many recipients + X.5.4 Invalid command arguments + X.5.5 Wrong protocol version + + X.6.0 Other or undefined media error + X.6.1 Media not supported + X.6.2 Conversion required and prohibited + X.6.3 Conversion required but not supported + X.6.4 Conversion with loss performed + X.6.5 Conversion failed + + + + + +Vaudreuil Standards Track [Page 14] + +RFC 1893 Mail System Status Codes January 1996 + + + X.7.0 Other or undefined security status + X.7.1 Delivery not authorized, message refused + X.7.2 Mailing list expansion prohibited + X.7.3 Security conversion required but not possible + X.7.4 Security features not supported + X.7.5 Cryptographic failure + X.7.6 Cryptographic algorithm not supported + X.7.7 Message integrity failure + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 15] + + + diff --git a/server/src/site/resources/rfclist/smtp/rfc1985.txt b/server/src/site/resources/rfclist/smtp/rfc1985.txt new file mode 100644 index 00000000000..a604b425ea1 --- /dev/null +++ b/server/src/site/resources/rfclist/smtp/rfc1985.txt @@ -0,0 +1,396 @@ + + + + + +Network Working Group J. De Winter +Request for Comments: 1985 Wildbear Consulting, Inc. +Category: Standards Track August 1996 + + + SMTP Service Extension + for Remote Message Queue Starting + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines an extension to the SMTP service whereby an SMTP + client and server may interact to give the server an opportunity to + start the processing of its queues for messages to go to a given + host. This extension is meant to be used in startup conditions as + well as for mail nodes that have transient connections to their + service providers. + +1. Introduction + + The TURN command was a valid attempt to address the problem of having + to start the processing for the mail queue on a remote machine. + However, the TURN command presents a large security loophole. As + there is no verification of the remote host name, the TURN command + could be used by a rogue system to download the mail for a site other + than itself. + + Therefore, this memo introduces the ETRN command. This command uses + the mechanism defined in [4] to define extensions to the SMTP service + whereby a client ("sender-SMTP") may request that the server + ("receiver-SMTP") start the processing of its mail queues for + messages that are waiting at the server for the client machine. If + any messages are at the server for the client, then the server should + create a new SMTP session and send the messages at that time. + + + + + + + + + + +De Winter Standards Track [Page 1] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + +2. Framework for the ETRN Extension + + The following service extension is therefore defined: + + (1) the name of the SMTP service extension is "Remote Queue + Processing Declaration"; + + (2) the EHLO keyword value associated with this extension is "ETRN", + with no associated parameters; + + (3) one additional verb, ETRN, with a single parameter that + specifies the name of the client(s) to start processing for; + + (4) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + affects the behavior of an SMTP client and server. + +3. The Remote Queue Processing Declaration service extension + + To save money, many small companies want to only maintain transient + connections to their service providers. In addition, there are some + situations where the client sites depend on their mail arriving + quickly, so forcing the queues on the server belonging to their + service provider may be more desirable than waiting for the retry + timeout to occur. + + Both of these situations could currently be fixed using the TURN + command defined in [1], if it were not for a large security loophole + in the TURN command. As it stands, the TURN command will reverse the + direction of the SMTP connection and assume that the remote host is + being honest about what its name is. The security loophole is that + there is no documented stipulation for checking the authenticity of + the remote host name, as given in the HELO or EHLO command. As such, + most SMTP and ESMTP implementations do not implement the TURN command + to avoid this security loophole. + + This has been addressed in the design of the ETRN command. This + extended turn command was written with the points in the first + paragraph in mind, yet paying attention to the problems that + currently exist with the TURN command. The security loophole is + avoided by asking the server to start a new connection aimed at the + specified client. + + In this manner, the server has a lot more certainty that it is + talking to the correct SMTP client. This mechanism can just be seen + as a more immediate version of the retry queues that appear in most + SMTP implementations. In addition, as this command will take a + + + +De Winter Standards Track [Page 2] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + + single parameter, the name of the remote host(s) to start the queues + for, the server can decide whether it wishes to respect the request + or deny it for any local administrative reasons. + +4. Definitions + + Remote queue processing means that using an SMTP or ESMTP connection, + the client may request that the server start to process parts of its + messaging queue. This processing is performed using the existing + SMTP infrastructure and will occur at some point after the processing + is initiated. + + The server host is the node that is responding to the ETRN + command. + + The client host is the node that is initiating the ETRN command. + + The remote host name is defined to be a plain-text field that + specifies a name for the remote host(s). This remote host name may + also include an alias for the specified remote host or special + commands to identify other types of queues. + +5. The extended ETRN command + + The extended ETRN command is issued by the client host when it wishes + to start the SMTP queue processing of a given server host. The + syntax of this command is as follows: + + ETRN [
+

+

+

+
+
+ + +

James currently (v2.1) includes only the most basic list functionality, users can subscribe and unsubscribe, but there is no moderation of messages or subscriptions

+

To enable a list you need the following in config.xml in the root processor block and above the final mailet block -

+ +<mailet match="CommandForListserv=james@localhost" + class="AvalonListservManager"> + <repositoryName>list-james</repositoryName> +</mailet> + +

that will intercept the command emails sent to +

    +
  • james-on@localhost to subscribe the sender
    • +
  • james-off@localhost to unsubscribe the sender
    • +
+

+

and-

+ +<mailet match="RecipientIs=james@localhost" class="AvalonListserv"> + <membersonly> false </membersonly> + <attachmentsallowed> true </attachmentsallowed> + <replytolist> true </replytolist> + <repositoryName>list-james</repositoryName> + <subjectprefix>JamesList</subjectprefix> +</mailet> + +

Which will distribute the mail to the current subscribers

+

in addition to the above you need to have a repository configured in the users-store block(usually near the bottom of config.xml) like so (database)-

+ +<repository name="list-james" + class="org.apache.james.userrepository.ListUsersJdbcRepository" + destinationURL="db://maildb/lists/list-james"> + <sqlFile>file://conf/sqlResources.xml</sqlFile> +</repository> + +

Database users will also need to ensure that they have configured a data-source named to match the destination URL

+

Using the filesystem:-

+ +<repository name="list-james" + class="org.apache.james.userrepository.UsersFileRepository"> + <destination URL="file://var/lists/list-james/"/> +</repository> + +

Restart James, send a mail to james-on@localhost and you should be subscribed.

+

The repository, be it a database table or directory in the filesystem will be created automatically.

+

Database users can manipulate the users repository using SQL, and hence any application capable of running SQL queries against it.

+ + + +

In some simple tests of mail relays James appears to be an open relay, properly configured it is not.

+

Because James is an email application platform it currently accepts all mail delivered to it via SMTP for processing. Only after the mail has been recieved does this processing begin.

+

This means that James accepts Spam. However the default configuration, and any sensible re-configuration has a number of anti-spam measures which will prevent the re-transmisson of spam from James. This makes it a blackhole for spam.

+

This also means that James will not verify addresses, but of course this means that valid addresses can't be harvested from James by spammers either.

+ + + +

Check that you've added valid DNS servers to your James installation. Email delivery requires the use of special mail related DNS information (MX records), so James needs to explicitly be given DNS servers. Look at your config.xml file for a <dnsserver> section and add one or more DNS servers.

+

Additionally, check the RemoteAddrNotInNetwork matcher under<processor name="transport">. By default it looks like this:

+ +<mailet match="RemoteAddrNotInNetwork=127.0.0.1" class="ToProcessor"> + <processor> spam </processor> +</mailet> + +

because most mail programs will use the external IP address (as opposed to 127.0.0.1) when processing mail, you need to add your internal network and/or your static IP address to this list. You may also use a DNS domain name in this list. The resulting entry would look something like this:

+ +<mailet match="RemoteAddrNotInNetwork=127.0.0.1,192.168.1.*" + class="ToProcessor"> + <processor> spam </processor> +</mailet> + +

This tells the processor that anything not in this address list should go to the spam processor.

+

Please note that if you wish to configure James to allow users to send email from any domain or IP address you will need to disable this matcher. In this situation you must use SMTP AUTH to ensure that your server does not act as an open relay. For more on open relays, please see the Open Relay Database.

+ + + +

You need to do one of two things: +

    +
  1. Update your domain's DNS entries so there are MX records that point to the machine that is running James. Note that it is illegal for MX records to point to IP addresses. You need to point MX records to a valid CNAME or A name entry, and then map that eventually to an IP address.
    2. +
  2. You could alternatively give people an email address with IP addresses. Most people will think it's a very strange email address, but hello@[192.168.0.1] is a valid email address. Note that you need to wrap the IP address in brackets.
    3. +
+

+ + + +

First step is to look in the log directory at the mailet.log file. Look for entries that include the text "RemoteDelivery". This should provide some high-level debug information of James' attempt to delivery mail remotely.

+

If you want to delve into the code, look at the RemoteDelivery mailet. You may also want to review the mail repository source code for the repository type you are using (file, db, etc...).

+ + + +

IMAP development had been stalled, but has recently attracted new activity. IMAP support is scheduled for inclusion in James v3. In the meantime, there is experimental code in the repository. If you are interested in working on or trying the IMAP prototype code, join the james-dev mailing list and let us know.

+ + + +

James v2.1 includes a new mailet for database users, JDBCVirtualUserTable, that mimics some of the sendmail capabilities of the same name.

+

JDBCVirtualUserTable does not provide any administation tools. +You'll have to create and maintain the database table yourself. The +standard configuration is as follows:

+ +CREATE TABLE VirtualUserTable +( + user varchar(64) NOT NULL default '', + domain varchar(255) NOT NULL default '', + target_address varchar(255) NOT NULL default '', + PRIMARY KEY (user,domain) +); + +

The standard query used with VirtualUserTable is:

+ +select VirtualUserTable.target_address from VirtualUserTable, VirtualUserTable as VUTDomains +where (VirtualUserTable.user like ? or VirtualUserTable.user like "\%") +and (VirtualUserTable.domain like ? +or (VirtualUserTable.domain like "\%" and VUTDomains.domain like ?)) +order by concat(VirtualUserTable.user,'@',VirtualUserTable.domain) desc limit 1 + +

For a given [user, domain, domain] used with the query, this will +match as follows (in precedence order): +

    +
  1. user@domain - explicit mapping for user@domain
    2. +
  2. user@% - catchall mapping for user anywhere
    3. +
  3. %@domain - catchall mapping for anyone at domain
    4. +
  4. null - no valid mapping
    5. +
+

+

A sample mailet looks like:

+ +<mailet match="All" class="JDBCVirtualUserTable"> + <table>db://maildb/VirtualUserTable</table> +</mailet> + +

More generalized viirtual hosting is something the developers are still discussing. One issue is that POP3 does not support virtual hosting in that it does not have a command to indicate what domain the user is in. What this means is the mail server needs to support a 'mapping' or 'translation' convention, e.g., 'user1@domaina.com' gets a username 'domaina.user1'. This allows the mail server to have a single username namespace. We have seen a few good proposals put forward, but nothing that seemed the clear solution, as ideally we could have this part solve the next issue.

+

Beyond that, James needs to refine virtual hosting for mailet processing. With the current user model, the mailet API has a Mail.getUser() method that no longer would be useable as a reliable indicator of whether they were in the local username namespace. To date we are unclear of the best way to bring this translation into the mailet processing. Similarly, it would be nice to support different mailet processing based on the domain, although this is somewhat feasible using the limited processing flow offered with a HostIs matcher.

+

Virtual hosting is one of the most requested features, and additional work is scheduled for the 3.0 release.

+ + + +

We are largely reliant on what Avalon is doing in terms of classloading, but here are a few tips and suggestions: +

+ Eventually we hope to support mailet reloading and a special lib and classes directory within the james directory that custom mailets can load from, but for now these are hopefully some useful tips.

+ + + +

+

    +
  1. Rename the previous james directory into a james.old
    2. +
  2. Run phoenix to let the new james.sar be deployed.
    3. +
  3. Edit the newly deployed config.xml to reflect your customizations from the previous config.xml.
    4. +
  4. If using JDBC, see necessary table changes. +
    5. +
  5. Replace the var directory by the previous var directory. This will copy over user accounts, inboxes, spools, and whatever else.
    6. +
  6. Restart James.
    7. +
+

+ + + +

The version of Avalon Phoenix distributed with James v2.1 and later includes a wrapper that lets you run James as a service. An alternative strategy is to install the JavaService from Alexandia Software.

+ + + +

Check the JavaMail docs. Per the API, when you call MimeMessage.setContent(blah), you have to call saveChanges() to apply your changes. James tries to automatically call this method so you don't have to, but in certain cases you'll still have to call saveChanges().

+ + + +

The following information is based on James 2.0a3, but the + upcoming 2.1 version should be similar.

+

NNTP and other underlying services are called "blocks" in the + Avalon Phoenix terminology. Blocks are specified in the + assembly.xml file which is located in the apps/james/SAR-INF directory (2.1) + or apps/james/conf directory (2.0a3). Note: this file is created + during the first startup of James.

+

There are dependencies between the blocks, which you can read from + the file. For example the SMTP Server block depends on the + users-store block, so if you want SMTP then you cannot remove the + users-store block even if you only want to relay messages.

+

To remove the NNTP Server comment out the following blocks: + NNTP server, NNTP Authentication Service, NNTP repository. + To remove the POP3 Server comment out the POP3 Server block.

+

If you remove a block it wont't be loaded next time you restart + James. You must also remove all sections related to the removed + blocks from the James configuration file - config.xml - otherwise + you will get error messages, saying that there is no corresponding + block.

+ + + +

Read the "Contributors How To" here +

+ + + +

Read the "sendmail How To" here +

+ + + +

I am using Microsoft's SQL Type 4 JDBC Driver, why do I get the following exception?
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Can't start manual transaction mode because there are cloned connections.

+

This seems to be a problem with the Microsoft Type 4 JDBC Driver and concurrent statements/transactions/resultsets on the same database conntection.

+

To solve this you need to add ;SelectMethod=cursor to the end of your dburl string. Your dburl string would then look something like this
<dburl>jdbc:microsoft:sqlserver://dbserver.host.name:1433;SelectMethod=cursor</dburl>

+

NOTE: some people have complained about performance when using this option, the alternative is a 3rd party JDBC driver but these are often not free.

+ + + +

When a user tries to send a large message that is close to but not quite at the max message limit the send fails and an exception similar to the following appears in the log:

+

Sent: 451 Error processing message:
+ Exception spooling message: Exception caught while storing mail Container:
+ java.lang.IllegalArgumentException: Packet is larger than max_allowed_packet
+ from server configuration of 4193280 bytes;
+ nested exception is:
+ java.lang.RuntimeException: Exception caught while storing mail
+ Container: java.lang.IllegalArgumentException: Packet is larger than
+ max_allowed_packet from server configuration of 4193280 bytes
+

+

Because of how the JDBC driver is written, a 25% + factor is necessary between the maximum message size and the max_packet_size + to prevent the driver from throwing an exception. So if you want a 4MB + maximum message size, you need a 5MB max_packet size. Or a 4MB + max_packet_size allows only a 3.2MB max message. +

+ + + +

First of all read this: ASF Source Code. +
Now go to http://subversion.tigris.org/ and download a subversion client. +
James subversion repository is at http://svn.apache.org/repos/asf/james/server. Commiters use "https". +
You may want to search the web, our dev and user mail archives or our wiki for more information.

+ +
+ + diff --git a/server/src/site/xdoc/archive/announcement_2_1.xml b/server/src/site/xdoc/archive/announcement_2_1.xml new file mode 100755 index 00000000000..9c94d0384bb --- /dev/null +++ b/server/src/site/xdoc/archive/announcement_2_1.xml @@ -0,0 +1,57 @@ + + + + + James 2.1 - Release Announcement + + +
+

The Java Apache Mail Enterprise Server (a.k.a. Apache James) Project is happy to announce the release +of version 2.1 of the Apache James server.

+ +

James is a 100% pure Java Mail and News server designed to be a complete and portable enterprise +mail engine solution. James supports currently available IETF protocols, including SMTP and POP3 +(NNTP is experimental in v2.1, and it and IMAP are targeted for full functionality in v3). James +is able to store user and message data either in a file-system or a JDBC-compatible database, +allowing fast, reliable, even real-time replicated storage.

+ +

James provides a powerful, flexible mail application engine through support for the Apache Mailet +API. With its Mailet pipeline architecture, James can be used not only to provide standard e-mail +services, but also to implement custom e-mail applications.

+ +

The James mail server is deployed in production environments and has proven itself to be a robust +and high performance mail solution. Tests indicate that version 2.1 is able to maintain a constant +mail throughput rate of thousands of messages/minute for continuous periods.

+ +

The James Community is also happy to announce the beginning of the design phase for James version +3.0. Features tentatively slated for that version include enhancements to nearly every area of +functionality, including full IMAP support, improved mailing list capabilities, and the next revision +of the Mailet API. This is expected to be an exciting time in James development. We are actively +looking for eager, capable developers to contribute to James. If you're interesting in contributing +to the James project, please subscribe to the James developer mailing list.

+ +

Information about James can be found at the James web site +at http://james.apache.org/. Users interested in subscribing to the James +user and +developer mailings lists should send emails +to server-user-subscribe@james.apache.org and server-dev-subscribe@james.apache.org, respectively

+
+ + diff --git a/server/src/site/xdoc/archive/architecture_v1_2.xml b/server/src/site/xdoc/archive/architecture_v1_2.xml new file mode 100644 index 00000000000..42e1bbf1f1f --- /dev/null +++ b/server/src/site/xdoc/archive/architecture_v1_2.xml @@ -0,0 +1,51 @@ + + + + + + James 1.2 - Architecture + + + +
+ +

+ JAMES is a multi-protocol message processing and storage engine. JAMES + currently consists of: +

+
    +
  • two mail prototcol servers (SMTP and POP3),
    • +
  • a remote administration server,
    • +
  • a mail processing engine that supports the Mailet API
    • +
  • file-system message storage and a message storage interface to RDBMS's
    • +
  • file-system user record storage and an experimental interface to LDAP directories
    • +
  • beta support for TLS (SSL) for POP3 and remote administration
    • +
+

+ JAMES is built on top of Avalon, the Java Apache Server Framework. + Versions 1.1 and 1.2 of James use a slightly older version of Avalon, + specifically the avalon-james-1-1b1 branch. We intend to + migrate to the new Avalon in the near future. +

+ +
+ + + diff --git a/server/src/site/xdoc/archive/architecture_v2_0.xml b/server/src/site/xdoc/archive/architecture_v2_0.xml new file mode 100644 index 00000000000..a47c631ef61 --- /dev/null +++ b/server/src/site/xdoc/archive/architecture_v2_0.xml @@ -0,0 +1,55 @@ + + + + + + Notes for developers + Serge Knystautas + + + + +
+ +

+ James is a multi-protocol message processing and storage engine. James + currently consists of: +

    +
  • two mail prototcol servers (SMTP and POP3),
    • +
  • a remote administration server,
    • +
  • an NNTP server,
    • +
  • a mail processing engine that supports the Mailet API
    • +
  • file-system message storage and a message storage interface to RDBMS's
    • +
  • file-system user record storage and an experimental interface to LDAP directories
    • +
  • support for TLS (SSL) for POP3 and remote administration
    • +
  • support for SMTP auth
    • +
+

+ +

+ James is built on top of Avalon, the Java Apache Server Framework. + Versions 2.0 of James use a date-snapshot of Avalon code as of November 2001. + The lib directory includes date-stamped jars of the various Avalon libraries. + We intend to stay current with new versions of Avalon as they are released.

+ +
+ + + diff --git a/server/src/site/xdoc/archive/configuration_v2_0.xml b/server/src/site/xdoc/archive/configuration_v2_0.xml new file mode 100644 index 00000000000..7020fabc809 --- /dev/null +++ b/server/src/site/xdoc/archive/configuration_v2_0.xml @@ -0,0 +1,716 @@ + + + + + + Configuration + Serge Knystautas + + + + +
+ +

+

+

This document explains the JAMES.conf.xml file for James 2.0 +
JAMES 2.0 uses a date-stamped version of Avalon from late September 2001. + The lib directory includes jars with date-stamped names for the Avalon libraries. +
+

+
+

+ +
+ +
+ +

+ These tag elements control the JAMES spooling and identification + settings. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
<name>default valuemeaning
postmaster Postmaster@localhost Is the source of error replies and the email users will mail to for any problem. You + should change this to an address that can receive incoming messages.
helloName attribute autodetect=TRUE and value of 'myMailServer' The name by which James will identify itself in SMTP and POP3 + greetings. If autodetect is TRUE James will attempt to detect + automatically the name, failing which it will use 'localhost'. If + autodetect is not TRUE, James will use the specified name or + 'localhost' if none is specified. Look in jamesinfo.log for + lines like "[...] Local host is: [servername] and [...] Hello Name is: [machine name]"
servernames/servername attribute autodetect=TRUE and last value of 'localhost' A list of host names James will consider as local. Any user [user]@[servername] + will be considered to be local. If autodetect is TRUE James will attempt to detect + automatically the name and use any names specified. Look in jamesinfo.log for a line like "[...] Handling mail for:: [domain/host]"
spoolRepository file://var/mail/spool/ This is the path where incoming messages are stored before beeing processed.
inboxRepository file://var/mail/localinbox/ This is the root for local users inbox. Each user will have a personal folder + [inboxRepository]/[user]
spoolmanagerthreads 5 This is the number of thread that work polling mails from the spool and take care + of processing them.
+ + + +

+ These tag elements affect the SMTP listener (for incoming messages). +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
<name>default valuemeaning
port 25 The port we are listening to.
bind N.A. Specific IP addresses that you wish to bind this service to.
smtphandler N.A. Parent for all SMTPHandler configuations.
connectiontimeout 120000 If nothing is received from an open connection for more than {timeout] mills + the connection is closed.
+ + + +

+ These tag elements affect the POP3 server (for message retrieval) +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
<name>default valuemeaning
port 110 The port we are listening to.
bind N.A. Specific IP addresses that you wish to bind this service to.
useTLS false Whether you wish to require/use TLS (SSL) on this port.
pop3handler N.A. Parent for all POP3Handler configuations.
connectiontimeout 120000 If nothing is received from an open connection for more than {timeout] mills + the connection is closed.
+ + + +

+ These tag elements affect the configuration of the list of local users. +

+ + + + + + + + + + + +
<name>default valuemeaning
repository file://var/users/ The path where local mail account informations are stored.
+ + + +

+ These tag elements affect the remote manager, a telnet based utility + to manage the User Manager. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
<name>default valuemeaning
port 4555 The port we are listening to.
bind N.A. Specific IP addresses that you wish to bind this service to.
useTLS false Whether you wish to require/use TLS (SSL) on this port.
administrator_accounts N.A. The parent of <account>
account login="root" password="root" A list of root account to administer JAMES.
connectiontimeout 120000 If nothing is received from an open connection for more than {timeout] mills
+ + + +

+ These tag elements affect SMTP remote delivery, specifically, DNS + lookup functionality. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
<name>default valuemeaning
dnsServer/servers/server N.A. This is a list of DNS to resolve external address.
authoritative false Whether to require authoritative (non-cached) DNS records. Should always be false + unless you understand the implications.
repository file://var/mail/delayed/ This is a temp repository path shared with the name of "TMP_REPOSITORY". + It is used by the RemoteDelivery Mailet to store mail for futher delivery. + (Note: this is not very elegant and will probally change soon)
mailets rootpath="org.apache.james.transport.mailets." This is the parent node for all mailet configurations. The rootpath specify + where mailet repository is. (Note: need to plug more than one repository)
+ +
+ +
+

+ This is James sitemap. It defines how each incoming mail will be + processed. Incoming mails begins their process at the first mailet in the + pipe. Each step is described by a <servet> tag with some attributes: + <mailet match="[matchClass]=[matchParameters]" + class="[mailetClass]">. + The Matcher class split the mail into two Collections: one with all recipients + matching conditions and the other with all recipient not matching. All information + in the mail except recipients cloned so the message that both matching and not matching + are identical (again except recipients). The matching recipients and mail will be passed to + the specified mailet for processing. After processing both mails, the + untouched not-matching mail and the processed matching mail, each go to next step in + the processor. Some mailets will indicate the mail should be consumed and no continue processing. + The Null mailet for example will simply consume any incoming mail as will the RemoteDelivery + since after delivery the mail needs no more processing. +

+ + +

+ The Matcher interface defines how match class should work. Their work is + to split a Vector of recipients into two: the ones matching a specified + condition and all others. + Currently implemented matchers: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
class nameparameteractionexample
All none match all recipients. match="All"
HasAttachment none match all recipients if the message has an attachment (if content type is multipart/mixed). match="All"
HostIs comma separated list of hosts names match all recipients belonging to one of the specified hosts match="HostIs=myHost.mydom.org,yourHost"
HostIsLocal none check recipients's hosts against the list of host names set in configuration for localhost + (see <servername>). match="HostIsLocal"
InSpammerBlacklist DNS zone with blacklist match all recipients if mail received from an IP address on the blacklist. match="InSpammerBlacklist=blackholes.mail-abuse.org"
IsSingleRecipient none match mail if only has 1 recipient. match="IsSingleRecipient"
NESSpamCheck none match all recipients if mail matches various spam detection rules. match="NESSpamCheck"
RecipientIs comma separated list of recipients match all recipients defined in condition. match="RecipientIs=root@localhost,admin@localhost"
RecipientIsLocal none match recipient which host is local (see HostIsLocal) and that are recognized by the + Users Manager to be local accounts. match="RecipientIsLocal"
RelayLimit Maximum number of hops. match all recipients if the message has more than the specified number of SMTP hops. + Important to prevent race conditions in SMTP delivery. + match="RelayLimit=30"
RemoteAddrInNetwork comma separated list of network addresses match all recipients if the message was received from an IP address that matches the + comma separated list. Wildcards are supposed, e.g., 192.168.0.* is a valid option. + match="RemoteAddrInNetwork=127.0.0.1,192.168.*"
RemoteAddrNotInNetwork comma separated list of network addresses match all recipients if the message was not received from an IP address that matches + the comma separated list. Wildcards are supposed, e.g., 192.168.0.* is a valid option. + match="RemoteAddrNotInNetwork=127.0.0.1,192.168.*"
SenderInFakeDomain none match recipients who's domain name portion of their email address is invalid. Queries + for A, CNAME, and MX record entries. match="SenderInFakeDomain"
SenderIs comma separated list of address. match all recipients if sender is in the condition string, else match none. match="SenderIs=badBay@badhost"
SizeGreaterThan number of bytes. supports 'k' and 'm' suffixes. match all recipients if message is larger than the given number of bytes, kilobytes, or megabytes. match="SizeGreaterThan=1m"
SubjectIs comma separated list of address. match all recipients if the subject is equal to the condition string, else match none. match="SubjectIs=REMOVE"
SubjectStartsWith comma separated list of address. match all recipients if the subject starts with the condition string, else match none. match="SubjectStartsWith: [ADV]"
UserIs comma separated list of accounts match all recipients defined in condition regardless of host. match="UserIs=root,admin"
+

+ Some examples: +
+ - <mailet match="RecipientIsLocal" + class="LocalDelivery"> +
+
+ - <mailet match="UserIs=root" + class="Forward"> +
+
+ - <mailet match="SenderIs=badBoy@myhost,badGirl@yourhost" + class="Null"> +
+

+ + + +

+ Mailet are classes that process a message. They are + passed a Mail object on which they can perform any kind of task. + Clever use of mailets allow you to write an email-based application. + Simple mailets provide basic mail functionality like mail forwarding, + mailing list, "I'm on vacation" message, mail logging etc. As simply as + these mailet, you can write and deploy your own mailet to perform any kind of task. +
+ Here you are some of the mailets bundled with James along with their configuration: +
+

+ Null +
+ Consume any incoming mail. No configuration needed. +
+ <mailet match="SenderIs=badBoy@badhost" class="Null"> + </mailet> +
+
+ debug.Identity +
+ Leave any incoming mail untouched. A debug mailet + (not really useful). + No configuration needed. +
+ <mailet match="All" class="Identity"> + </mailet>
+
+ Forward +
+
+ Replace the recipient list with recipient specified in + configurations.
+
+ <mailet match="RecipientIs=root@localhost" + class="Forward">
+
+
+ <forwardto> green@blue.org </forwardto> + <forwardto> red@yellow.com </forwardto> +
+
+ </mailet> +
+ + ToProcessor +
+ Sends the incoming mail object to a new processor pipeline. + root and error are special processors that + should always be defined. +
+ <mailet match="RecipientIsLocal" class="ToProcessor"> +
+
+ <processor> localdelivery </processor> +
+ </mailet> +
+ + ServerTime +
+ Replies to the sender with a short message with the current time. + No configuration needed. +
+ <mailet match="RecipientIs=time@localhost" class="ServerTime"> +
+ </mailet> +
+ + ToRepository +
+ Stores mails in the specified MailRepository. Useful for mail logging + etc. If the passThrough parameter is false the mail will be consumed, if true + it will be returned untouched to the pipe. +
+ <mailet match="RecipientIs=root@localhost" + class="ToRepository"> +
+
+
+ <repositoryPath> file://var/mail/logAdmin + </repositoryPath> +
+
+ <passThrough> true </passThrough> (default false) +
+
+ </mailet> +
+ + LocalDelivery +
+ Store mail in the local inbox, one folder for each user. +
+ <mailet match="RecipientIsLocal" class="LocalDelivery"> +
+ </mailet> +
+ + RemoteDelivery + + Relays mails to remote hosts. "delayTime" is the time in mills the + mailet will wait before retrying sending a mail which fail at first time. "maxRetries" + is the number of retries before sending back to sender the mail.
+ <mailet match="!RecipientIsLocal" class="RemoteDelivery"> +
+
+
+ <delayTime> 21600000 </delayTime> +
+
+ <maxRetries> 5 </maxRetries> +
+
+ +

</mailet>

+ + Redirect +
A mailet providing configurable redirection services

+ This mailet can produce listserver, forward and notify behaviour, with the + original message intact, attached, appended or left out altogether.

+ This built in functionality is controlled by the configuration as laid out + below.
+
+

However it is also designed to be easily subclassed to make authoring redirection + mailets simple.

+ By extending it and overriding one or more of its methods new behaviour can + be quickly created without the author having to address any other issue than + the relevant one. For more information see the javadocs

+

The configuration parameters are:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
paramdesc
<recipients>A comma delimited list of email addresses for recipients of this message, + it will use the "to" list if not specified. These addresses + will only appear in the To: header if no "to" list is supplied.
<to>A comma delimited list of addresses to appear in the To: header, the + email will only be delivered to these addresses if they are in the recipients + list.
+
+ The recipients list will be used if this is not supplied
<sender>A single email address to appear in the From: header
+
+ It can include constants "sender" and "postmaster"
<message>A text message to be the body of the email. Can be omitted.
<inline> +

One of the following items:

+
    +
  • unaltered The original message is the new + message, for forwarding/aliasing
    • +
  • heads The + headers of the original message are appended to the message
    • +
  • body The + body of the original is appended to the new message
    • +
  • all Both + headers and body are appended
    • +
  • none Neither + body nor headers are appended
    • +
+
<attachment> +

One of the following items:

+
    +
  • heads The headers of the original + are attached as text
    • +
  • body The body of the original + is attached as text
    • +
  • all Both + headers and body are attached as a single text file
    • +
  • none Nothing is attached
    • +
  • message The original message is attached as type message/rfc822, + this means that it can, in many cases, be opened, resent, fw'd, replied + to etc by email client software.
    • +
+
<passThrough>TRUE or FALSE, if true the original message continues in the mailet + processor after this mailet is finished. False causes the original to + be stopped.
<attachError>TRUE or FALSE, if true any error message available to the mailet is + appended to the message body (except in the case of inline == unaltered)
<replyto>A single email address to appear in the Rely-To: header, can also be + "sender" or "postmaster", this header is not set if + this is omited.
<prefix>An optional subject prefix prepended to the original message subject, + for example..
+
+ Undeliverable mail:
<static> +

TRUE or FALSE, if this is true it hints to the mailet that none of + the parameters are set dynamically, and therefore they can be set once + in the init method.

+ False tells the mailet to call all the "getters" for every + mail processed.

+

This defaults to false.

+ It should be TRUE in all cases, except where one of the getter methods + has been overriden to provide dynamic values, such as a listserve which + might override getRecipients() to get a list from a users repository.

+
+ +
+

Example, creates a distribution list:

+

<mailet match="RecipientIs=test@localhost" class="Redirect">

+ <recipients>x@localhost, y@localhost, z@localhost</recipients>

+ <to>list@localhost</to>

+ <sender>owner@localhost</sender>

+ <message>sent on from James</message>

+ <inline>unaltered</inline>

+ <passThrough>FALSE</passThrough>

+ <replyto>postmaster</replyto>

+ <prefix>[test mailing]</prefix>

+ <static>TRUE</static>

+ <passThrough>FALSE</passThrough>

+ </mailet>

+

+ +
+ +

and this sends a spam notification to the postmaster

with the original message + attached as a message, and a subject prefix:

+

<mailet match="All" class="Redirect">

+ <recipients>x@localhost</recipients>

+ <sender>postmaster</sender>

+ <message>Message marked as spam:

+ </message>

+ <inline>heads</inline>

+ <attachment>message</attachment>

+ <passThrough>FALSE</passThrough>

+ <attachError>TRUE</attachError>

+ <replyto>postmaster</replyto>

+ <prefix>[spam notification]</prefix>

+ <static>TRUE</static>

+ <passThrough>FALSE</passThrough>

+ </mailet>

+
+ +
+ + + diff --git a/server/src/site/xdoc/archive/document_archive.xml b/server/src/site/xdoc/archive/document_archive.xml new file mode 100644 index 00000000000..7fa00ab636a --- /dev/null +++ b/server/src/site/xdoc/archive/document_archive.xml @@ -0,0 +1,54 @@ + + + + + + James Document Archive - Table of Contents + + + +
+ +

The Java Apache Mail Enterprise Server (a.k.a. Apache James) is a +100% pure Java SMTP and POP3 Mail server and NNTP News server designed +to be a complete and portable enterprise mail engine solution. James +is based on currently available open protocols.

+ +

The documentation for obsolete versions of James is preserved here +for users who still have need of it. The James project urges all +users to upgrade to the current Release Build of James.

+ + +

+

+

+ +
+ + diff --git a/server/src/site/xdoc/archive/install.xml b/server/src/site/xdoc/archive/install.xml new file mode 100644 index 00000000000..0aeddbf1170 --- /dev/null +++ b/server/src/site/xdoc/archive/install.xml @@ -0,0 +1,113 @@ + + + + + + Installation +Serge Knystautas +
+

If you have downloaded a binary distribution, you do not need to build James. + Proceed directory to Step 1.

+

To compile James from the source code you need Ant. + This is a Java-tailored, XML-configured, extensible build or make system. We + are currently using Ant 1.4, which is included in the source distribution.

+

If you have downloaded a daily snapshot, you need to build a distribution. + James includes Ant to compile and package its distribution. Extract the snapshot + to your favorite directory, cd to that directory and run the build by calling "build" + or "./build.sh" which will create an unpacked binary distribution + in the dist directory, but no archives.

+

This "./dist" directory is the distribution directory used in Step 1 and beyond. + You may either cd to ./dist, or you may copy and rename the dist directory to your + installation directory.

+

If you prefer you can run build with the "dist" task "build dist" + (or "./build.sh dist"). This will create the distribution in the "./dist" + directory as well as create .tgz and .zip copies of this directory, however it may + require other resources to build the documentation.

+

Warning! Any changes you've made in the 'dist' directory + will be lost after a recompilation. If you are making changes to the conf.xml + or other files, we recommend you backup and then change the copies in src to + avoid losing work.

+
+

Download distibution. Extract or copy all the files in the archive or dist + directory intto your installation directory.

+
+ +
+

+ Read the short and snappy documentation at docs/index.html for a proper + overview of configuring the system. +

+

+ Summary (for impatient people) +

+ +

M$ users should just run /bin/run.bat. Unix users will find run.sh under the + same directory. A JVM must be present and its location specified in the JAVA_HOME + environment variable. Set this on windows at the command prompt with something + similar to "set JAVA_HOME=\jdk1.3\bin" on *nix with JAVA_HOME=/jdk1.3/

+

Running [run* --help] will provide a simple command line help.

+

+ Most UNIX systems require superuser privileges to open sockets below 1024, + which includes the IANA-standard SMTP (on port 25) and POP3 (on port 110). + These default ports can be changed in the conf.xml file. (Obviously, you + would then need to reconfigure your clients. This may not be an option if + you want to receive mail from external mailservers.) +

+ +

The Avalon framework will unpack the necessary configuration files you will + need to start the server. Wait until it is running, stop it again (ctrl-c), and + edit the configuration (thereafter *nix users can run the server in the background + using ./run.sh &). For basic use, you only need to set two items in the + JAMES.conf.xml file: a root password for the remote administration facility + and the IP address of a DNS server. Once you have edited the configuration files, + press 'Enter' on the terminal where Avalon is waiting.

+
+ +
+

+ Once started you'll see a message saying Avalon is running. This means that + Avalon has loaded JAMES and every other needed Block (see /logs/avalon.log) + and is now waiting for a socket request. + Since at the beginning James is empty, it will not have any local users + registered. + To register a local user open a telnet session with localhost on port 4555, + log in as root ("root[enter] <password-you-set-in-conf.xml>[enter]") and + type "help" for a list of available commands in the "JAMES remote + administrator tool". It is really a basic set but should allow you to test + installation. +

+

+ Once you have some local users registered, try sending mail to one of them + @localhost with SMTP (port 25) (assuming you have not changed the default + server names in the conf.xml file). You'll see the mail appear under + ../var/mail/localinbox/[user]. + Try now to retrieve that mail using POP3 (port 110). + Trace out JAMES actions in /logs/*info.log. + Actions that will be taken by JAMES on incoming mail are configured in + the mailet pipe line (/conf/JAMES.conf.xml). Look at it if you want to + understand what's happening. +

+

+ Good luck :) +

+
+ + + diff --git a/server/src/site/xdoc/archive/usingJDBC_v2.0.xml b/server/src/site/xdoc/archive/usingJDBC_v2.0.xml new file mode 100644 index 00000000000..541c85f3bea --- /dev/null +++ b/server/src/site/xdoc/archive/usingJDBC_v2.0.xml @@ -0,0 +1,174 @@ + + + + + + Using JDBC + Charles Benett + + + + +
+ +

+ This document explains how to enable JAMES 2.0 to use database storage via JDBC. Based on ReadMe notes by Darrell DeBoer and ??. +

+
+ +
+ +

Main Goals. +

    +
  • use Avalon and Cornerstone DataSource components for connection serving and pooling (done)
    • +
  • Remove hard-coded SQL statements from UsersJdbcRepository (done)
    • +
  • 'SqlResources.java' - detect db product from jdbc connection and select appropriate SQL statements from SQL definition file for specific product (done)
    • +
  • Simpler to create database-backed UserRepository implementations for different User implementations (done)
    • +
  • Simplify UserRepository specification in config - make it URL:// based, like MailRepository. (done)
    • +
  • Consolidate existing UserRepository implementations - refactor out common functionality (TODO)
    • +
  • Have UserStore serve up repository implementations based on: storage, User implementation, and location. (TODO)
    • +
+

+

Other Goals (reuse development in JdbcMailRepository): +

    +
  • use Avalon and Cornerstone DataSource components in JdbcMailRepository (done)
    • +
  • Use SqlResources.java to provide db-specific SQL to JdbcMailRepository (done)
    • +
  • Automatic table generation for JdbcMailRepository (done)
    • +
  • Get rid of the separate database .properties files. (done)
    • +
+

+ +
+ +
+ +

+ The main configuration is setting up the "database-connections" section of the +config file. There's an example there using MySql - I haven't yet tested on +other databases (although the SQL statements haven't changed much, so I +imagine it will still work on other platforms). +

+

+The only config properties you should need to set are: +

    +
  • <driver> Class name of database driver to use </driver>
    • +
  • <dburl> the jdbc connection string for your database </dburl>
    • +
  • <user> database user </user>
    • +
  • <password> database password </password>
    • +
+

+
+ +
+

+

    +
  • Telnet to the remote manager: "telnet localhost 4555".
    • +
  • Do some user management - type "help" for options.
    • +
  • type "use list-james", to switch to the repository for this list.
    • +
  • list the users
    • +
  • send an email to "james-on@localhost"
    • +
  • list the users again
    • +
+(note: some user management commands fail for repositories other than "LocalUsers"). +

+ +
+ +
+

+Mail repositories are now configured primarily by their "destinationURL" +property. This has the format "db://datasource/table[/repository]". Other +config such as the "sqlFile" (where to find sqlResources.xml, and the "filestore" +for mixed storage, can also be included, or can be left to defaults (see below). +

+

+Each repository registered in the MailStore can now take a "config" section, +which is the default configuration used by the MailStore when creating a repository +of that class. This allows us to have a configurable JDBCMailRepository, without +needing to specify config everywhere it's used. I've set up the SPOOL repository +to use mixed storage (a filestore in addition to the database), but the MAIL +repository to use pure db storage. +

+

+The new config has been tested with "inbox" and "spool" repositories, but it's not +yet tested with the "error", "spam" and "outgoing" repositories. +

+

+The statements in the SqlResources.xml file have been tested on MySQL and M$SQL. +Only M$ has the optimised "getMessageSize" SQL, but this is optional. +

+

+You no longer have to manually create the tables required - this is automatic. +Create Table statements are included for M$SQL and MySQL; we'll need to add others +for other db products. +

+ +
+ +
+

+I've added an "AbstractJdbcUsersRepository", which takes care of most of the work +of a JdbcUsersRepository, making it pretty easy to add new ones. The abstract +implementation doesn't have knowledge of User implementations, this is restricted to +overridden methods in concrete UsersRepository implementations. +

+

+The AbstractJdbcUsersRepository obtains SQL statements via an "SqlResources" object, +which reads an sql definition file, finds the appropriate <sqlDefs> element, and +provides the sql strings contained. In addition, the SqlResources class handles +2 other things: +

    +
  • + a) Parameter replacement in SQL (eg replace all occurances of ${table} within + an sql statement with the parameter value for "table". Currently, all + parameters are taken from the configuration <sqlParameters> element. It + is also possible to define parameters (defaults, if you like) within the + sql definition file itself (a <parameters> element).
    • +
  • b) Examines the Jdbc Connection to determine what database product is being + used. SQL statements specific to a db product (eg mysql) can then be used + automatically. (Detection is done by regexp matches on + Connection.getMetaData.getDatabaseProductName())
    • +
+I've added 3 concrete subclasses of AbstractJdbcUserRepository: for DefaultUser, +DefaultJamesUser, and "ListUser" (which for now is nothing more than a name). These +give an example of how little work there is to implement a new repository. The +ListUsersJdbcRepository can store multiple lists of names in a single table. +

+

+I've made a simple modification to "RemoteManagerHandler", to allow testing. The +"use [userRepositoryName]" command will switch the Remote manager to manage the +named repository. This isn't really intended for production, makes for easier testing. +The "james-config.xml" included in the proposal sets up 4 JDBC repositories: +

    +
  • "localUsers" - a JamesUsersJdbcRepository.
    • +
  • "list-james" - a ListUsersJdbcRepository, used by the ListServ mailet.
    • +
  • "list-test" - another ListUsersJdbcRepositor, for testing.
    • +
  • "default-users" - a DefaultUsersJdbcRepository, for testing.
    • +
+

+

+Note that in order for the Avalon DataSource components to work, I've included +an upgraded "avalon-excalibur.jar" in the proposal. + +

+ +
+ + diff --git a/server/src/site/xdoc/archive/usingLDAP_v1_2.xml b/server/src/site/xdoc/archive/usingLDAP_v1_2.xml new file mode 100644 index 00000000000..6f57bf2f933 --- /dev/null +++ b/server/src/site/xdoc/archive/usingLDAP_v1_2.xml @@ -0,0 +1,185 @@ + + + + + + Using LDAP + Charles Benett + + + + +
+ +

+ This document explains how to enable JAMES to use an LDAP directory as a + Users Repository. +

+
+ +
+ +

+ We have tried to make the LDAP implementation of UsersRepository as + flexible a possible, recognising that each installation will have a unique + directory schema. +
We assume that all users that a James Mailserver will handle fall + within one single-rooted tree. The root of this tree, ie the lowest node + in the directory which is an ancestor for all users served by this + mailserver and the mailserver, is called the LDAPRoot. (See diagram) +
+
It is entirely possible that an organization may have more than one + mail server. Consequently, the fact that a user is in the Directory does + not imply that this mailserver should handle mail for them. +
+
This implementation of UsersRepository creates one node (object) for + each set of mail users. The set called 'LocalUsers' is the set of users + whose mail is handled by this server. Other sets include any mail-lists + handled by the server. Each member of a set is recorded as an attribute + of these objects. These nodes are child nodes of the mailserver. +
+
The mailserver will accept mail for local delivery if the user part of + the email address matches a member of LocalUsers and if the domain/host + part of the email address matches the first servername . + (Set servernames autodetect to false and enter the domain served as the + first servername, e.g. apache.org). +
+
For POP3 authentication, the mailserver first finds the user entry in + the directory, underLDAPRoot, whose attribute, specified as + MailAttribute in conf, matches user@domain. The mailserver authenticates + the POP3 user if it can bind to the directory as that user entry with + the offered password. +
+
+ This implementation does not set passwords in the directory. Use a dummy + password when invoking adduser in RemoteManger. +
+
+ If ManageGroupAttribute is set to TRUE (as it is by default), then the + RemoteManger will add/remove the full DN of the email group to/from the + user entry. This facilty allows users to ask the directory what is my + mailserver and what email lists am I subscribed to? +
+ +

+ + + + + + + + + + + + + + + + + + + + + +
Root of Directory +
Example: dc=org
+
May not be referenced in conf.xml
+
|
+
|
+
-------------------------------------------------------------------------------------------------
| +
Subtree not served by James
+
e.g.: dc=w3c, dc=org
+ 		| +
Subtree served by James
+
e.g.: dc=apache, dc=org
+
"LDAPRoot"
+
|
+ 		| +
Subtree not served by James
+
e.g.: dc=xml, dc=org
+
+ + + + + + + + + + + + + + + + +
----------------------------------------------------
| +
This mailserver
+
cn=mailserver.apache.org
+
|
+
---------------
+ 		| +
A user
+
cn=King Arthur
+
memberOfGroup=
+
cn=LocalUsers etc
+ 		| +
A user
+
cn=Morgan LeFay
+ 		| +
Another mailserver
+
cn=oldmail.apache.org
+
+ + + + + +
| +
LocalUsers
+
member=Arthur
+ 		| +
list-james
+
member=Arthur
+
+
+
+
+ +
+ +

+ Six entries in JAMES.conf.xml must be set for this to work: +

    +
  • change usersManager - type to ldap.
    • +
  • Set the ldapServer element to point to the correct host and port
    • +
  • Set LDAPRoot and ThsServerRDN.
    • +
  • Set the direcory FDN and password that should be used to write to the directory.
    • +
  • Unless all your users have email addresses of the form, name@the-machine-running-James, set servernames-autodetect to false and apecify the your email domain as the first servername.
    • +
+

+ +
+ + + diff --git a/server/src/site/xdoc/archive/usingTLS_v1_2.xml b/server/src/site/xdoc/archive/usingTLS_v1_2.xml new file mode 100644 index 00000000000..0e6c13053fc --- /dev/null +++ b/server/src/site/xdoc/archive/usingTLS_v1_2.xml @@ -0,0 +1,96 @@ + + + + + + Using TLS + Charles Benett + + + + +
+ +

+ This document explains how to enable JAMES 1.2.1 to use Transport Layer + Security (TLS) (ie SSL). +

+
+ +
+ +

+ Obtain JSSE source from java.sun.com. Follow their installation directions. + We assume that you install JSSE as a standard extension, with a static + provider definition. (See notes with JSSE distribution) +

+

+ Note that the US export restrictions still apply to JSSE + (at version 1.0.2), so while both the international and domestic versions + offer the same level of crypto, the international version does not take + alternative providers. +

+ +
+ +
+ +

+ Using JAMES with TLS. You need to do three things over and above the + normal operation of James: +

    +
  • In Avalon.conf.xml, uncomment the TLS listener defintion.
    • +
  • In JAMES.conf.xml, uncomment the <useTLS>TRUE</useTLS> element + for the service you want to use TLS. It is currently available for + remote manager and POP3. (If using POP3 over TLS, it is probably best + to change port to 995, which is the IANA designated POP3S port).
    • +
  • Ensure that avalonTestKeys is in the conf directory. You may need + to manually extract this from the Avalon.jar (with: jar xvf Avalon.jar + conf/avalonTestKeys). Note that this is a self-signed certificate for + test purposes only. You can specify a different server certificate in + the Avalon.conf.xml file.
    • +
+

+

+ Start James +

+
+ +
+

+ (Positive Test) Use an SSL client to open a socket to the appropriate port. + I used openssl from www.openssl.org to test this. + E.g. openssl s_client -connect localhost:4555. You should see the normal + remote manager or POP3 server greeting and have normal operation. +
+ - If, using openssl s_client, you get a connection refused/ error no + 111, just try again. This probably means you got to the port before it + was ready. +
+

+

+ (Negative Test) telnet to port 4555 (ie without SSL). This should hang the + telnet client. It should also lock port 4555 until the connection times out, + I think. +

+
+ + + diff --git a/server/src/site/xdoc/design_objectives.xml b/server/src/site/xdoc/design_objectives.xml new file mode 100644 index 00000000000..a373e108d46 --- /dev/null +++ b/server/src/site/xdoc/design_objectives.xml @@ -0,0 +1,122 @@ + + + + + Design Objectives + James Project Web Team + + +
+ + +

These are some of the currently implemented features:

+

+ + Complete portability + Apache James is be a 100% pure Java application + based on the Java 2 platform and the JavaMail 1.3 API. +

+

+ + Protocol abstraction + Unlike other mail engines, protocols are seen only + like "communication languages" ruling comunications between clients and + the server. Apache James is not be tied to any particular protocol but + follow an abstracted server design (like JavaMail did on the + client side)

+

+ + Complete solution + the mail system is able to handle both mail + transport and storage in a single server application. Apache James + works alone without the need for any other server or solution.

+

+ + Mailet support + Apache James supports the Apache Mailet API. A Mailet + is a discrete piece of mail-processing logic which is incorporated into + a Mailet-compliant mail-server's processing. This easy-to-write, + easy-to-use pattern allows developers to build powerful customized mail + systems. Examples of the services a Mailet might provide include: a + mail-to-fax or mail-to-phone transformer, a filter, a language translator, a mailing + list manager, etc. Several Mailets are included in the JAMES + distribution (see documentation).

+

+ + Resource abstraction + Like protocols, resources are abstracted and, + accessed through defined interfaces (JavaMail for transport, JDBC for + spool storage or user accounts in RDBMS's, Apache Mailet API). The server is + highly modular and reuse solutions from other projects.

+

+ + Secure and multi-threaded design + Based on the technology developed + for the Apache JServ servlet engine, Apache James has a careful, + security-oriented, full multi-threaded design, to allow performance, + scalability and mission-critical use.

+

Anything else you may want if you help us write it :-)

+ + +

It is the existence of published "open" standards which +allows independant teams to develop interoperable software. +
James attempts to support a number of these standards most of which are +IETF RFC's and in the areas covered by these standards the published standard +is our requirements document. +
This sometimes leads to confusion where behaviour is not +the subject of a relevant standard, or conflict where common +(de-facto) behaviour is actually at odds with a supported standard. +
We believe that it is our responsibility to adhere to the published standard. +If we allow our implementation to deviate it means that we are tacitly encouraging +the situation whereby interoperability is no longer guarenteed by standards +compliance alone, but also requires access to undocumented and possibly +even commercially licenced technology. There is no easy route for a +newcomer to aquire these secrets, and interoperabilty +becomes something only available to the elite. +

+

The James policy for issues of non-compliance tries to tread the fine line +between a pragmatic acceptance of other people's misinterpretation of the +RFC's and an evangelical defence of open standards as the key to freedom of interoperation. +

+

+In practice this policy is that certain well argued of cases of +non-compliance which can be *safely* worked around, will be tolerated by +James. +

+

+In cases (like jira issue JAMES-344 ) where variance from a published standard is +required it is desirable that this functionality is disabled in James by default, +it must be prominently and clearly documented that this causes James +to violate the relevant standard, and should be enabled by explicit +configuration, making its use a conscious decision of the user rather +than an decision taken by the James team. +

+

+In cases where the required behaviour is not within the scope of any standard which +James claims to support (such as behaviour which is a de-facto standard or +an internet draft RFC but not yet subject of a standards track RFC) it is +acceptable to implement the behaviour so long as it is adequately +documented (for instance by refrence to an internet draft or +other public document) and users can be clear about what to expect from James. +

+ +
+ + diff --git a/server/src/site/xdoc/index.xml b/server/src/site/xdoc/index.xml new file mode 100644 index 00000000000..fc3b5e8693b --- /dev/null +++ b/server/src/site/xdoc/index.xml @@ -0,0 +1,131 @@ + + + + + Overview + James Project Web Team + + +
+

The Apache Java Enterprise Mail Server (a.k.a. Apache James) is a 100% pure Java SMTP and POP3 Mail server and NNTP News server. We have designed James to be a complete and portable enterprise mail engine solution based on currently available open protocols.

+

James is also a mail application platform. We have developed a Java API to let you write Java code to process emails that we call the mailet API. A mailet can generate an automatic reply, update a database, prevent spam, build a message archive, or whatever you can imagine. A matcher determines whether your mailet should process an email in the server. The James project hosts the Mailet API, and James provides an implementation of this mail application platform API.

+

James is based upon the Apache Avalon application framework, formerly a product of the Apache Avalon project (see "news" below).

+

James requires Java 1.4 (For further information you may want to search the web, our dev and user mail archives or our wiki).

+
+
+

+ Latest and Stable: James v2.2.0 +
+James v2.2.0 is the current release, and the latest in the James v2 series. +Both binary and source distributions are available.

+

James v2.2.0 is a major update to the James platform, with many new features, functional improvements, and bug fixes. +See the Change Log for a detailed list of changes. All +users are urged to upgrade to v2.2.0 as soon as possible.

+

Any bugs found in James are dealt with promptly. Please provide feedback on the james-user and james-dev mailing lists.

+

+ Get your hands on the latest versions.. +
We put significant milestones, and potential release candidates in the download area. +
Whilst the quality of these versions cannot be guaranteed they may contain important bug fixes and cool new features.
+

+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ItemStatusSinceFirst released
SMTP serverStable1.00.95
Mailet EngineStable1.20.95
FileSystem mailboxes/spoolStable1.21.0
RDBMS mailboxes/spoolStable1.21.2
POP3 serverStable1.11.0
RDBMS - UsersStable1.2.11.2.1
LDAP Support - UsersExperimental1.21.2
TLS Support - POP3Experimental1.21.2
Remote ManagerStable1.01.0
TLS Support - Remote ManagerStable1.21.2
NNTP serverExperimental1.21.2
FetchPOPDeprecated2.32.1
+
+ + diff --git a/server/src/site/xdoc/rfclist.xml b/server/src/site/xdoc/rfclist.xml new file mode 100644 index 00000000000..f7c2af12841 --- /dev/null +++ b/server/src/site/xdoc/rfclist.xml @@ -0,0 +1,93 @@ + + + + + + James - RFC Directory + + + +
+

This document contains a list of and links to RFCs relevant to James.

+ +RFC 822: Mail Message Format
+RFC 1123: Requirements for Internet Hosts -- Application and Support (updated by RFC 2821)
+RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
+RFC 2822: Internet Message Format
+ + +RFC 821: SMTP Protocol
+RFC 974: Mail Routing and the Domain System
+RFC 1652: SMTP Service Extension for 8bit-MIMEtransport (elective, but widely adopted)
+RFC 1830: SMTP Service Extensions for Transmission of Large and Binary MIME Messages (experimental, but cool idea)
+RFC 1869: SMTP Service Extensions
+RFC 1870: SMTP Service Extension for Message Size Declaration
+RFC 1891: SMTP Service Extension for Delivery Status Notifications (elective)
+RFC 1893: Enhanced Mail System Status Codes (experimental)
+RFC 1985: SMTP Service Extension for Remote Message Queue Starting (elective)
+RFC 2034: SMTP Service Extension for Returning Enhanced Error Codes (elective)
+RFC 2142: Mailbox Names For Common Services, Roles And Functions
+RFC 2197: SMTP Service Extension for Command Pipelining (elective)
+RFC 2554: SMTP Service Extension for Authentication
+RFC 2821: Simple Mail Transfer Protocol (obsoletes RFC 821)
+ + +RFC 1725: POP3 Protocol
+RFC 1734: POP3 AUTHentication command
+RFC 1939: POP3 Protocol (obsoletes RFC 1725)
+ + + +RFC 1731: IMAP4 Authentication Mechanisms
+RFC 2060: IMAP Version 4rev1
+RFC 2086: IMAP4 ACL extension
+RFC 2087: IMAP4 QUOTA extension
+RFC 2088: IMAP4 non-synchronizing literals
+RFC 2177: IMAP4 IDLE command
+RFC 2180: IMAP4 Multi-accessed Mailbox Practice
+RFC 2192: IMAP URL Scheme
+RFC 2193: IMAP4 Mailbox Referrals
+RFC 2195: IMAP/POP AUTHorize Extension for Simple Challenge/Response
+RFC 2221: IMAP4 Login Referrals
+RFC 2342: IMAP4 Namespace (elective)
+RFC 2359: IMAP4 UIDPLUS extension (elective)
+RFC 2595: Using TLS with IMAP, POP and ACAP
+RFC 2683: IMAP4 Implementation Recommendations
+ + +RFC 977 : NNTP Protocol
+RFC 1036: Format of News Messages
+RFC 2980: Common NNTP Extensions
+NNTP Working Group
+ + +RFC 3377 : Lightweight Directory Access Protocol (v3): Technical Specification
+RFC 2251 : Lightweight Directory Access Protocol (v3)
+RFC 2252 : Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
+RFC 2253 : Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
+RFC 2254 : The String Representation of LDAP Search Filters
+RFC 2255 : The LDAP URL Format
+RFC 2256 : A Summary of the X.500(96) User Schema for use with LDAPv3
+RFC 2829 : Authentication Methods for LDAP
+RFC 2830 : Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
+ +
+ + diff --git a/server/src/site/xdoc/todo.xml b/server/src/site/xdoc/todo.xml new file mode 100644 index 00000000000..8c249fd8c5b --- /dev/null +++ b/server/src/site/xdoc/todo.xml @@ -0,0 +1,109 @@ + + + + + + TODO + Serge Knystautas + Charles Benett + Peter M. Goldstein + + + + +
+

This is a living document that will give new and existing volunteers some areas where we need help. As always, any help is appreciated, be it documentation, code, suggestions, or feedback. +Last Updated July 2006.

+
+ +
+

Determine a way to support multiple domains.

+

Revisit UserRepository. The interface must support multiple authentication types per user, +aliasing (both local and non-local), as well as per-user quotas. It may be desirable to be able +to associate attributes with users in the repository.

+

Revisit the MailRepository interface and associated implementations. Special consideration is +necessary to support IMAP Search functionality. It should be possible to associate attributes +with mail messages stored in the repository.

+

Revisit the SpoolRepository implementations and do away with the current exception-generating +two-phase message retrieval.

+

Define a simple mechaism for addressing repositories in a uniform way.

+

Add support for mbox mail file repository.

+

Add support for the maildir file repository.

+

Add support for DRAC login/relay authorization. This feature records the IP addresses and times of +POP3 logins. SMTP connections from these same IP addresses are considered authenticated if they occur +within a fixed period of the POP3 authentication.

+

Develop repository migration tools so that users of the old repositories can easily migrate to newer repositories.

+
+ +
+

Add support for the 8BITMIME extension.

+

Expand the SMTP server so it supports a variety of SASL authentication mechanisms.

+

Complete support for delivery service notification (RFC 1891).

+

Discuss optional support for VRFY and EXPN.

+
+ +
+

Get IMAP server to alpha standard (i.e. basic interoperation with e-mail clients).

+

Add #news namespace to IMAP system

+
+ +
+

Give admins the option to enforce one access at a time to a POP3 mailbox.

+
+ +
+

Refactor NNTP code base.

+

Tie in the NNTP Repository with POP/SMTP/IMAP repository structure.

+
+ +
+

Write a list server implementation with functionality comparable to ezmlm. This would include +the capability to handle multiple lists of 100,000+ members, double opt-in subscription mechanisms, +and a full suite of mail-driven commands.

+
+
+

Discuss and agree future architecture in the light of Avalon's demise. Modify codebase to implement architecture design.

+
+ +
+

Discuss and design the next revision of the Mailet API.

+
+ +
+

Improve the debugging output, including a) catching that DNS servers are not correct (at least have DNS log channel record DNS server usage)

+
+
+

Add support for better mailet router/processing (maybe like RequestDispatcher) - Use Stage/Pipeline pattern

+

Add support for deployable message processing apps using Camelot pattern

+
+ +
+

Rewrite RemoteManager to be an exposed object that can be controlled via RMI or what have you, and have the remote manager telnet interface make appropriate calls to this interface.

+

Take advantage of Phoenix JMX capabilities to enable more complete measurement of James behavior.

+

Add support in the RemoteManager to manage repositories. This includes listing what's in a repository, viewing individual messages, deleting messages, copying messages, and moving messages.

+

Add needed functions to RemoteManager, Including Stop and ReConfigure (?), Reinject mail (this should just be copying/moving messages...), Store RemoteManger password securely.

+
+ +
+

Document instructions on configuring logging in James.

+
+ + + From 6513a12987ebef7c0d9e3ec08f05cc4b21af3227 Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 30 Sep 2006 17:23:30 +0000 Subject: [PATCH 005/541] Reorganizing project folder to include trunk/tags/branches structure. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@451623 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/resources/css/site.css | 13 + src/site/resources/download.cgi | 6 + src/site/resources/favicon.ico | Bin 0 -> 3638 bytes .../resources/images/asf-logo-reduced.gif | Bin 0 -> 6636 bytes .../resources/images/james-project-logo.gif | Bin 0 -> 7227 bytes src/site/resources/robots.txt | 5 + src/site/site.xml | 113 ++++++++ src/site/xdoc/code-standards.xml | 97 +++++++ src/site/xdoc/contribute.xml | 112 ++++++++ src/site/xdoc/download.xml | 159 +++++++++++ src/site/xdoc/index.xml | 46 ++++ src/site/xdoc/license.xml | 208 +++++++++++++++ src/site/xdoc/mail.xml | 249 ++++++++++++++++++ src/site/xdoc/weare.xml | 172 ++++++++++++ 14 files changed, 1180 insertions(+) create mode 100644 src/site/resources/css/site.css create mode 100644 src/site/resources/download.cgi create mode 100644 src/site/resources/favicon.ico create mode 100644 src/site/resources/images/asf-logo-reduced.gif create mode 100644 src/site/resources/images/james-project-logo.gif create mode 100644 src/site/resources/robots.txt create mode 100644 src/site/site.xml create mode 100644 src/site/xdoc/code-standards.xml create mode 100644 src/site/xdoc/contribute.xml create mode 100644 src/site/xdoc/download.xml create mode 100644 src/site/xdoc/index.xml create mode 100644 src/site/xdoc/license.xml create mode 100644 src/site/xdoc/mail.xml create mode 100644 src/site/xdoc/weare.xml diff --git a/src/site/resources/css/site.css b/src/site/resources/css/site.css new file mode 100644 index 00000000000..b9279090553 --- /dev/null +++ b/src/site/resources/css/site.css @@ -0,0 +1,13 @@ +#apacheconbox { + margin: 20px 0px 0px 20px; + padding: 10px; + border: 1px solid #ccc; + background-color: white; + background-image: url(../images/button-top.gif); + background-repeat: repeat-x; +} +#apacheconspacer { + float: right; + margin: 0px 0px 10px 10px; + background-color: white; +} diff --git a/src/site/resources/download.cgi b/src/site/resources/download.cgi new file mode 100644 index 00000000000..06a42f2012b --- /dev/null +++ b/src/site/resources/download.cgi @@ -0,0 +1,6 @@ +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* diff --git a/src/site/resources/favicon.ico b/src/site/resources/favicon.ico new file mode 100644 index 0000000000000000000000000000000000000000..f0c22ad9bf0c7db2eaa899c41405a27f6b2281d5 GIT binary patch literal 3638 zcmeH}i(k$6AIG1kbLmu4%-AiL%zd_Do6Y7r6Xw1wl|qE5SSl7%8Ix9RvNUrkYS|Ez zp)ytzN^UFZcGRg;o$gXeNayz<9#h)m@%sbzemq|1d|vO@`}6sJzn|~-`+j{vf*z)( zJdUMu=qpA&d$#ajln^9x{RMqg@+d7qBt?voJpOy`N2k-_XQt*i<#6WynaAosWsstr5rqX5Z~G5tWor4tKxIk>0QFB zM>1Q@j<9-cE{9Yl?30I)U^s=MtOk;js;H@YK=jEfHeA1nyM7$@eYAKiEyhJLp1(Ty z;_-4mmT^~z-Eo7mvO+@qig4A-;z!w5GIDF#uW;v*finlf%UQ1I&+@SvyezadHa4)u z(1N8y^Vuvr&oVO&c3nzw=%!+(yf>STP7$iV2fs~U@$Iz&&MVgtd!z!_4w)1bG!UYH z41ehvwku{3vZ0IvhJM_?_mGpo7m&OU(Ke$8?br52zQw+`KB8fV(*T#vop54O8M(V z72m%SM^08U(?a4fH#aBl_fW>_O&}yahZ1!iJKfZrFipj+?_~~!77`udg_qtH;T;~F zQh0MsxqyV;lj)&njAvjr9+&>cW=fZ4$=@Tiy+Yb@pP4Fs7e84dZn8<7?YahA{R&ojWpVuHEWT5W zV8x5+q#AAHa>rRXy_d(lekH8$eu2Cj#Y8Iiuxl~q`vo7K$ zi@N7<;tvfDor{^>tAP9tmiRgsvgo`DBjhyRZ6rH88>^97>`~bBt9&={M%!30K9?Kn z+k7p&ck*{fSS86MARqwi85(SkXEJweDT$|cVLiBt9bP#M&@*MmzBAY^Ea&>QvjjTl zV{<8=goHA}uI7@IrWO9!$g)wHq?|uVV4#|U+jT6F6p4LVfK@^ku?i24EBweYUBwTw z1Hy|2;wA4x@I@6#@dw#qu!c|N-6=JmK!EUeyUw@pm8J2U(N12HC`mVPBIZ~*U&*YA z|2>R3rUfJzco8a(!_3T#WD^h07=FVpSrqQBD$0t=*xzvuw&@xccTq7>+6Aq_EbI)c zQR*wOmz3Zt(eSk_g`ea{ITx>Gu6ZT)z4EZSlFdBhQVuEivce|^$Ir5P@Sur1wf6`T z-kp(lku#@?*mFb0@*dgTuBqg@(PUgCDr|-nQ>MLxx~huBvV7|6YYCSfWUizftGL_E5sVI>w>XE4IBw-lPg| z2#GxU79on%X@ zz$YDsir(}u;ko+*iRTR8e^I&qXV3m2Lwkrm*IrzIz4SHxcTddtwmlK9&kfg(STwmq z{EZVi?Nmr!4{x>@v~KWuD|!DDHP01DzH(F@o_Q?V@|}(czBBWDPTzXLUt3rao$+R@ z!-N%6#Z|VB;&aK`jn?ai#dN-?(oAcu36}Rwy~-l?w)EDWZog@U|K3)=XK>EH{B(uX z^3doxea=;HZmVy<+Td?dyKYkO=sDLue(#00`;)ohq$(=X`j?pHKP&wm7YiF`6|-Nw zIw0zFtf6C)@pkC85i|khmE!OV;-#3s)B+Vr?i&$)T_%QkG-+~*1?r2Doyq3ovmca#OnI+ z@`t%+SDms@grE-)jzJ@P zw^|$0FFT#y8_{clZKQwrr6PBqw(__jFFn&vpI)44p>dp^+D0Ypt?$)`kC)Ag^l#1% zaL#KhPg(!U4>uKEBQ2U;>ZbqHRz>pmmC*4ob(bv6!#;^mRJ5M5jv-y3Z4cPm5-OrYC4bUsoeOH4+4T=pml9(aqr9B$jMMBG4kM87)e@ Ubv|M>F;ge1bt0t`R41tJf5W(}rvLx| literal 0 HcmV?d00001 diff --git a/src/site/resources/images/asf-logo-reduced.gif b/src/site/resources/images/asf-logo-reduced.gif new file mode 100644 index 0000000000000000000000000000000000000000..93cc102077a940966a0bf6d77e74ac273a10ef8f GIT binary patch literal 6636 zcmW-jdpy&NB^`k5({Ud=*EWJLJM77(p_7Ubjo^?L{6ozBTG zrT8~-uT3`YA6z(iU(uWv#wdC?*LrZ+m}~LRdiKU&$f@Oy^oJ`=i6+hgRAVF_PDwp- ztgxs!1ZD4l68M_KW_UVk-#Q!$Pa@K2Br166_?3pnI2h|A-a0BAXQR5&A?Fpb?Gb8 z2*k5oCs=r^?5ey-sZ^AxYup^lC`5wE?{)1hj19^$$^{?dW+pEpj_VrXL%+<@Wf;^t zJCdiUvs(#-G^G|kfoFntz873~ctb_>t(@D#$7q=4Jv#>J`Qv=$b>~!(=u%)Bm4nQx4G0uy}~g_xl^(YUhBvak#5 zgOuvw;WT+BuH_Fe^Qfh^cx6`2s#Q)p=qizh0B=u>WgT3-Um`*}GI*J|%p$EpRN<4Y zGf~z{=<@Z%ciE4S^38-`SDls-3H17pfQxW&*i~EFS~THa;&q8l$;Vfpq4`<-XV(d$ z`-SexHAn1eerw`+&nuVTz17YrVcMN=n%6b~Pk7R#fQs2Gpwl_l;)!9Zix3)AS!c&C zQ34C)+gAHfADmZ#J!@ouF>Xj{z_YVB18pQxGV z#8&ZYQIjf}4+ukXt98XP)EbGFTjdXCr7XQ<39V`EX@7dX7sgi%K^WawfM#Gv=)Aa1 z+o?NS!01`I1iDVjJKI}zgx$&^C5Ef~EU7JH?OH!a+{=QV@_zU`-5PH*I zPuRv#n3aaLEiBR7@r{SVvX-}mUhuV3xb?k!BFIAH>qbPzbWFRFgIRYuh*K-nKBmlY zXo!mHbNn_F82LJk8Y(6HVBaJGfDmIP$=s!3^Huul_S2gBtEE}_T2@5k_$OT|Hfb(5 z)X<#6D%iKo^EXxX4F^7^85Vz6sG)}#XEvtZDoScZ&v0xHPB;j%ar+w*l2aoKKDo2- zb9>!cbUD@Cqd08ehtuEgl-E^3le=d;7%p1%H-?USDXO&=Ns#x}Gv34#dLGHj^Mbev){8$exY)@D8txn4_GgU^Q#nGSmQLy^q-T1(e6TLYS zkyodfAaB@J5Bc38m*mNB>VrC0Ux|ebUq~Fex!-O z_3SLrfr{Ra$gx{pd(y!YKvCLGkH;%6{CVnQ{;UW?4*=tq1vDz`SEy-1yIj(V2R)ZFCY__!(Zs!f z`rl=^e16E7%Pt1a*QGNC=$-{`qOzJAu$vUT+P&2n>8pCwFvLX7zj^SYb`8p=S+0`E z$XYnM2{X2F1lL-FD1N}lfYe#DT)AY*L<*-3n_K(QvY5+XtlTfjs_Xqib0@!ESbnk! zSA5ArtJN=qF`{-hEnA~6zDFo%d=8mF^^sHw%D{yEh@{rPMqBF5>hB{?M8h{}t@d0a z$TBh@8x%i2xYqf->Z_kO?ik9N@?Tnd1s`-Sm~BEsL0u8q&B1GhLXeauby8lte(=TH z=AV&6s2Bxw4Bv}#m_ApmU%KiQkf8nY=}IGzQPzj<_?tbT?S^q>@387$GCgoZ>{a?} zs*!BKHygc@UGbJ=GHbM@>qZ!K2AH8?ChBt!Rc8lW$zk7VEIyd*pHZ< zE$>3tEVKs2MMV7_y;EJ&`Ixn`WSsRp6bJd9jN0ez7 z|Ma|Lc!>!cW3KHdjTYX+6Ie1ce`!;(oJVsG#TcaQP4A00xHl)OMsj5M5|l7eC(3az zDJOcF{El8dJ#Rzx_qnmF*i5mBua?=I@#wMvrXgR?ichil(W`n;21chubB`0YX{t^$lR@)6e zzxHWowXNRH^1Qj<$tzEf&Y^`bdfs&ERfbPdDZ3B53tO443vu5as^NZ_IwXJfQLrGe z*svE7@rd$rX)~s^qXx&9l&pV0F0Lg#>vRaEt0D{^yK6JYuX|TyX#+v*D)2mcq;*Cp zfmg+{`z{X8I**n$^E#AvnZc#GzrRAukx7ov5b^QQouH>j)7lqpVBE5P^}wWc9VJMF zl|RDZCikc^4kDE8%0ixL8a>;T0`GN{#v6|OnR?@tEUXAkxLJ7eVdS$v?N0>>6O+H` z^2{Fo2$O4$vb6y!ta9)n;7$uEBjvIC)aTjix?Ev&58b zTHCwd`4prf7n;f;4aFhXHwe2DD!6nD&voHBVW_e^kk z4BA-^s7S#3%MdJ4#z`=;Gr>L_NJXrykOQM%3PUrC{5VkM211p-l*eeZE_gIfIC*wHsp5pD4ONn{s>gfc~b%Z~YZ zfnp?qAD#z;w}Pl!;NNdN^7{Ah$UuBd#BGr$q;yX1IYErS2Le0Dx zqKPdB6#2#+aF1s2nU>;y3GRIxtU@)ZW|^FpfQ~=ZZp%^@YPfu9&Thx@P=y`kq&RXQ zrP!}nk8sM64X>6!PGY$JGH6aPF_geaVX2e20;v#Fg(T&7r%qiezhli!WB6VLkCZ*B zG&`?pe<1&KTg6Y!%9gm&{(-Dz0m4ZN2hm-2e=EFq8EYj6+(TS9F#>*%LhWhDO$Eqg(i@Bw z)ysu*&R-5ba{&B^X%ph=;~Ze6V^@UXC;oaVAh3nK4e=SJ+})Q!mhX`!p&LC@;->&y z*%W2taFQ)dn8M%$JL=tRX3)qPH=>dPFsJGwCA2L|HJ%mKj z+y{JohjEIwLdk)ki%L3nlF_un1W|C)_?oXdHHJxWEt5OSuAY78a@UvZQv>#fngy#D zda$eabAW`YbKVk=e-xVk`<#M<0C`~Vq#5R;JN!<{#bsQ{XJ#H_~xNkfws>)tk=Nd2=DuVh(`? zKbj9|62X&jT2m5yRsj^6*w}MyONIWHK+*)q!^jL_U2(Mwdv&9cwJ)Nvvpa7o8k)iy zo$y3h|0JtOk~^bd8{WmujPMc%sHVchB03^Sb~uD=9ux_+r#L6jz0P(=Y$!X|c){Km z?fLK}si+@jkFBv!Q@K0>0$w#6{ub%)YMSm>%~9uFy#et(ya<}gRQ2;ElN`gOWOB)M z?>DekR{i9Jsx8$4$*0#w)Bf5RkUxJ!K+o^z4rbhv;V_6(p-7uz?>a# zDmQ!+XacocAKJy4EE*aJ5_O zOl7@}o4eoGZTmg|$@UZeg7>|qstB=;z~yyP7^X&>6Iul9wdDbqR!|(HgI(~y4bEgj z%tqp_C+GnG6Eu5vYZwFarm%kO0S`>W{wXs4Bc*Kx9v*U#|E11@P&c^;w33o+rS3mX zZ^{t6E||fFhT*& z$DjcTq$Y2;o9%Wf9FZevyFIOXQdsN9MYJA58+<3}B-N#2cE!;z5WI==7sz?xMoOhz zCcFEp2Joy;%Tm{v(b4hj?*Q^*NLZjte-Cvs+}BwF*3RDM+ZvgK2YRtLoAP1um6~CC zw@>rEM)H;)OM3k2JaP$*d$h-ya-e6dr-4L468u-H8afR_e5*9CiF(K(Cm9J@isrWu;W$PP1TA^Q5f6Fvm^0E!e%5G?i3bKu z{Y_bc)_ET~Je&J>&|Ppxty-gD7^mFzg)*;3yK$m!uh89nW?=u;;J(Ukj}X{@$o$uk z$D||T{CMs~RQp&nti<#1&O(x{p7CHf|PgnQpY-@>Nvror76~GP}JT(kgx;Nb}5NhSZnAlLKawpPv{}C;)2hij} z-VORkhG$HWlVpA6+QO`}!i1jeMpnIN(Qw3S+*Ou5@BOsu;ShlNeakxDSlH5X@`wsZ-B=B^}t8EVN2WpeWtGP7&oYjaRX;8E)O+J)+0Eg`%&btht7o@_=5B zG}L1PyFKiFGCjmEgcCDdUcVCjw?p#*6+*WFo_@ZNNb6~LvrE2P1Ru4##STL3u4F3L z*$=Vae1mATs5Qf%z+bemF7Xbf3~@o!*q#q%6(KZ*3pVUEz8tvgS;Lvcg@LO8O#eXH zq>p^m_Q3Yl@-yi5M)=KD;6NHM`7vBn)9`{|U3AEtE=_e1P?$VMP7CLdHrY4?p-KJt z?4I-SV<|g?s@V3;aUsaKmh-9j@-TT;R2b6YKEmiZGJXW%GmD56}7a!qg*ZT093>v zRz?yK$i^kR0fx>=K=sg4p)3658SV*r>97F6DgYB65WZigcl|(D>z%LO=H`Mnn`wZ$ z17R)!YJR$CP66?+0Ra!Q>N@l%0q;r2xtIPhwW?=e^`9!vZwV17-} z`v&|Lxi`;X*yrlGVH2dVIefugw~g0%h=SUIP?B$j31DUvBdWX!RR_#(g^grxEaBNF zPBtudN<)iV+FZ!d+5hg+5J&Kc{8OETWxW%AhS&-JAzgnD!y2*9@s(5EO^-9pGAbx= zg#EdZxG!MeuOgDwu1+Avr1pU-1JvD&F&{S%|h`1jKPE8AZ9k@JRFi0v2K#muJ(ewI`fD=fye1%bs?&BeGF zZ;Kf*o`hYW^tpt?tq$ty>AH5Dulshs%z~6tiW1;GG`f9=Ly2Rh*sacZBEQUkRMCso zF(ECs$v<#4B+Ci`W8DE(IH(va?>eRhd&*Ws)cPcdW>57a3zdK*%pb*f<;JNtKI0 z-OK4Xju4k0B=B+2Gi?d-6YhU0Hg-u4T3_eoi!hE{=_4w2X!!hhR9UR3Z*bVfO^dB@ z%PGwF+v0V23+}E!LbhW#s?0(LXH?3&zWt$Tk-C=x5J4Uxye3j?S>N?L*6t@Ap4dt zcM)kz>l6V3L(wORWE4ZuXZU>MMajkfSMTVD^jZMsMn!gIo{f6w>v(K0>sOvxzEw=a zrNq05F^F4qmE!-zC(QGQ`ALI5Ao<%CXooIt<-mU(5n<_HaS8j zDuLZSYT+|{!Wh1VGuH~Ji%q}YTBR-VL>(y61_$YZ82tG5K;VJrr`+k+V ifk3o@FNQYto?ua@#Ta7 literal 0 HcmV?d00001 diff --git a/src/site/resources/images/james-project-logo.gif b/src/site/resources/images/james-project-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..715a9bf970849d7564a7c4ac46f6512d6e2d8bbd GIT binary patch literal 7227 zcmWldc{J3E1I54Fm>G;2``E_V*OmMZ?MPVgzsp_gB9UnA&z+p~Kl7iG{Gvt6|9<|nAzEG<(XiQWWs^wr6n*(Q-*!i| z_G`0D^y1>@-9|4#oMYiaRv-}au`y08B()Kyp4*xC8-2s`2H_xA1d z%KE=QfBtN2YAn4}+}_sqYIg3$Kz}FiF#rJnWooP;{}})<{=fXc6CftyRWh87l`r(w zMD~Z;RPr05UH|gA`MNoF@N41|0XKfHN!g3Jw#4DE2Y(COH>^tK#IN*JkF3h2SQ2rv zc0@^{Y|<`boQ^D!75}g_r@+tkGkP>>q#n%k1PGist$Taf^BBjU9QcAKrm5JY_e6* zWt$~qMB73=d9y(4teu1V(SEZDLoucB3<`znn5W#R%qd}mwT7ZRyvAKs*XY4?`RIV! zEshOt@L7G;hSQsw0E%E7SfyX+=ia}ct&14B-Zhr1NoTjvugYlBUJfB=9YXgkIW=|LrTpezp=(vH=JcTaOl zs|`omJF`JKV2C2Ek}e5pTizI0-s<5n%F9vqy`^9fav~`c_nVi>%tx?$860YPS0)~( z5IrYEtJiGn?3Ue~*j?av*Db;D?+*aNoWnL9WO7+AR(25|rYXLttiFYjo@R9Wxng$@ zXeo9w;7~c9qI!&iF#y9PNm&=|e@|MExLc`mL;zyF%;@%crex-PoWkP+665`WU1?Vy zae09XJFDNF-ypxFN{OcfAdaxi%`!aqddykvTQu#^N!^DSAcibSKQ4x1r*)<5=4O1j zd`XULha;`W^T4gkls>%G>q{&x|4j#g(7l#xA3ez>Z*0Z1E~e>7`$W!vQZedlrAqE{ z<#d5tRC%_z>4eK(R%+IC&$N99EbAq-Y2H-q&_-QJ{khDmz3!kY2f}G2W$WX%P8$r0 zcV^$|LaR&CU!9G7erigJgbd_I95&Ql;0A5nvWwlEpA&+ijtag=7z@FEoJZu3G?bZ# zLOJ%b@5xRK<;!@drqi;^myQ#}ZK6)>)_kljMuR~%MQb9ba&aieAwXP`%`l3d_HqoW zqj0)%rDv;ea21{XxX+*y6Dq0576$DWrrD7X6rZJVyC8*)sQ_rd&%_AHfYT-%IMp2E z0b2x9bU|@vO7}wrd!9X3Eg>-j$F^CgFSP~xMY8Ds8D?tGXt z3Y>{NwvP}Q%6Fls@($s+%-uv8(0D9V<>feLI|Be8X)ugTahiQ9Jji2`ZHF>xBbFoD z_VacCu4d~~^)ps~(yzQSwhh4l$mORZ;vU<74MW!i{~(INjMBThuZ<}f1rJI-x8NQL z^`SFN_SZv=Rf5PAZBC$=;-C2nyH4Vu?JJk=DlvjW9=5kUBowNHzX|9cGM&?HNA@N6 z$Uot~gp~Wpk(b^`C9SyIH9y)|b5ks|G(-RPLli57>7vo;4)OeVfycW=FO-Pdt;DIsVl)x?PzA|wZ|3ZsA7RE?bE}>9a zW?dQ8&mIFqI4IYy7+;fSjtU0!)_%{t<{*$-lE8ecrc^|xCWnEE$lj~(CJwP-RSXqy z`vT%a7*Gx6x%ExELA)ygm>!mZEUtU^%<0@D9VG`Wf+h3WucXgv6Ew5+dl!5)0QJ|R zrGlNjX)uvs$Kdk{wgPApo`=xJHBiz#Td7C_thRk5=lmC2#Enwjt@?@5RPy#=AfY#Y zc>if;)C;~g)pC4C&k1~Ex7JfLr$ggQ1zW5^ygvup--l0g?<( zn&W!_y*Zloj(xNL`*c3bQggPX9&aIE)@D`I@-`-Re`t`g)cku@2hVdwke*cwop zhYT{DfeV`j|EOW#q_@2WOKfP`2yxz7PeC?!FrRsaf-Quep2=U{M*SLg#VRqvp=e6; zs^|b3qak@6oY}0Ww$$)kQwUrDX}wtC9IVc6|y8S0$}`l1x-4UDYY>aA;rzr3W=mPig-_BZWJ{kTCKZ7H~!J-N+@Rg zhD_Vbs}pHt8yXCHTUKtSn3Pt$?(<)vmOhna!du9x56|bo7C%_fT-K{GnZ;-m0qEG{ zpH_?9EqAd7Nc~2cveOEgTVK~IL%bnOG%Fo;?aI7F$g!uvWGx~~i!9x6YvRz8e&{c= zS0V4OnEZ0GE*sirjt0jHTFw5b@KB_8v3Kem(f&Dduv`$JWTND3S7PiZ`s6Zge*nG1b6@#l*QwK@6(c@Z-n!oA*_;2w;{zlUxF^1k*{f~X~9(FkACLqYjYf>8* zAj3aAr8VUB&s(oh+2>zjN4)Jreu~|uv13T|)wuq+p}5OTyYpBf?{7>nD^1!~^D)9} z-jw;CGNp4b?bDAOQ;s4?#)!I=KHfqhK*fcsZpU5mN!n!<+}1+Ms7{$`ZTk66oMVBL zk-El}gri-dPm+;vE8EFftFG(G{7~I&#VIGkw-<4z7YXTdejJ0KLte|@&~1V&S$+KX z0ky*chUS%Q4{IdT;IQ6f-r=$brLVHq`C&FWH|4#l`o2(Pqv1O-?PA_kt?R1Yhg-tk zya)L7f^_+5=~ZXpZ<(6mGZ#{$vDVxZvX}>}*NkixGQE$%mi$!ob}FpJP_pfhEAhU) zTJp!ZnG%970CW&SUkS zuAC$nYE)kkawf=0gw95=#Q4EO$w`NZtpv$JE@aAw6FY$vd#N5a1dm#gD8~nC;YF*1 z2D2uc`HY@)^V}|%gk_7J3Xt+ANRgl*OTauBkxiv)k1|0k9-0M;YcAPO>7+L~X!r)Y zg)Jk@Sj5xf%=cN(_Bf~eP6*1HxsM)>(~ojyXB;m)Geu6HS z)cp$~eSS0xIBvm%cLY-X8v-I6u)ob&>LWZ86(N4_5KshJQZO%h@;f>K z-6c@&K!B??Bae+sW8l7VTnz-E!6nG!fVSZnawr(N-ph0#hhMNlcChn0ypa{LDA8Uv z^X`?TzDk2_P7ShWOKw3;S9j0k1Keuf3m;@J8Aq1*% zAr%5(8kjg318oy#<&VSL2nBu$f!lbn#RsT;Go(iV{Z?QlD)jsv(9Koz2j%?Sp|&ph zsS!|}&hBQw9EwH{&%BAD_R1Q1*UoMl-_C81jdMESC=5N-huofn&%`Iccoo-8O!{^A zqHzc7;_SHtg!2oq^ms5$n+oaC(Ni(F4`!eQ2PV+BZsJ3c-LMuP1ce763gltA+k&mA zCxm3ip&PwUDgX!z04*UzpuqP1peY41rh`%fU&uf~lu5_z;sav+4gttz6^dk%A3m}O zR3`w+WLpbIfI!VIsW041$b;tc?1Z6|!+v5!RHi|G`0Ba2%oMg#=|uy;k)2@?hcZhD zi7GMOBnWp(6Oa2Y^^5;sWHN>W?jQh1*8mqQV4-Bc4Fy63;buZm3jiGqAaPp4j1?eo zhRO|K3$KJtR486EgGfpJCNNVW8`Ss1+nKPYAROkh7496=lm^V0fbDmGgkSn+1q$`o zawC`6Q&y1Z7ccq6|CiSLnv{)5!p-A2X~;N3h1ADE$$+FDOA;c?%q6KIrtuqLeCi zLU~gXo&6Pni}m1=z6)A{WE(yZ%qkS?fb6`;4!Hr2%*Y|{ytaj;4;Cl|%kZX!i)-Sj zmEI^mkvo)@oHqt`goxLd;G~(+o0;ly{?a4>))rO)21rCMU?#*U7MrmtRUzxpGfTBv?0JVJ%BXt3K@|q1Py`wY*lO)cB6(VZk|8oMaI21| z@=>T(JD&`3aovFAk%+r9ieL}#f|9^Woea%b6>Z`GsYdOhm2eyK*?a*|X8>EV&334C zWCJC82zlGtp3>HpH*yjES7#6KJAO6Q*m3faZK$vF@GqrHVh@gmby>GB)Yb_JMg;7X ztxlpJTOpyy?=Gm`v?D8`TK+zU>WwD-fQsv3|KHe7LMqf`C?Pqsz#q21}TMtt~7;I`UrO)h(oy{;v01yG;p}LT4>2K@TNxtoVX_P5wDtliP8B z7d`yvHq_eZj@5y-r99O4m3;4kr-o1OvH1Y)8a9guNK?vHB?@A$vPTR%Ih}x9NN1vR zZ)Q!W#zUJ^)8Ot2aKMN6q!_n_&@NJ;Xyo%7Dw%S^-8$--=V9vYW&_A>_E1`Wck$`I zo%wy=W1qTGp6)kde*28%Ha|T`zoTfJPi)U*OOIfI!6;9XEjD; z57m@TAbd$$cjXkqD@RBr2n$qWlQU zlltV^qv7mOt+StBbgWmdjRJDHfH74k>Z?@D`Fco*H7ei!aVwJYR-%dU+FGSuf_IGi zZ*uQdNbL5pUljbdQuPb}!V+9aTTm65=qeM4a3$Acq7jdAQ&)R&W<-?0V7 zmPZyOKE6SVk_Y*xbFsz8P*;v2b;>A(yKi?fp45MaPkllz8;sr#=}(fu)<2qvWrCx$ z@fjz8K}n=1YTjN5YY_m{amZV4fnrgFz^Ut*(D%$ zjhU$2b2+s8Sj0>FvX|Kp-^Dxh?_*YEB|JGzjP_=~^E^AzWhCBk=HurKXzQM7HoaB6 zX!d3j+RqsFi|DjtL)(1uJ7)lC`c;^U&K3+H0^eCg@`P@}>nrL;XJ@Dl3hDr;A0j1N zPS>%{&NqoIcZDyO!JA&e}7KGHRj_}Njp+- z(xT*bLLBdb@1*=HuU#|&8F5VWE9N2%=EA4s)F$L~3vZ|cs8??h`LK81`zCgOe(c0; z>kLL|JfE)#n>|%N6Z+^<_p!MP=ew8p=@`*I#r<*2<9>S05dTM5^^a=05-+)~A8MIZ z=?D{?={(@s;EUoaDNMa@@tXH`d%v6g)w>=L!b^DXYMYAajP~E4jYYJpO=*00A;VT%}3 z)R^1X*rNO6nNDSOFPBd*(>VD@cfQwrt{2p@;<}W-QF(n23`B{; z_fK74c=SNGlKnBw_${7ZuH67{63La>-s>{PSq)2w)u9*fS+|MCj zv6FkqNyopwUHA~Y5Zkt5IpNA&V%q-vyZ+KQE>PZoRZ&1lQu!9Uslp?2s?HlpDHpG# zNuF~b#1jA=27E#1ErtM4D8J(T-JG&br)|Slt5nsP=^I2$s-U*jYV}34@TcMIK6Z%< z<4xIO_x1BlJ2}IO_{F)uxSr=`l{s}U*LuF7Bz=rJJ~qIOofvo0)L-+fDTxS=|cpK?y4 z3ED{a(4w2X{Jp~?`QCSPLEg!jm;4Qh@GGS$2Xs@!clwY>TQXB}T`dDh1d`=WqRBxs zJy$8&7%y=%W8IS&330BNuDY+d<^Bwghb%UevYogSBctwYLoq35ZgzFFv~xD|Wgl|Y zJ+L#~)hi`5RCf!(SiviF^;%t1%j4SNIXYfLQ7)Qs+IOU{wZXt-)!D)fJuCzYn$V_3v`rj2ac zIgKf<>V%|ksBRBsT*v0hYdN$vENd2KN>gZCf~mKZ^gK1aw%Ce(Zc;6d_){^|y%122 zS3555F~8aAw3715C{tP%klbaNTz&V!_ZMzBkiO&|KD@R*PJTnWkJ}pTKVP9v;R<~7e)0=~ynjExoujyqIseY+A zF?MIIb|9aLw%o+!vE)n+M=-$@I#2`WG3fg@wnWl)V0ICrUnq{22w=LnF)PDTcFEXH z!KS?md>b;!10|-Hjj_^VujwpQiIA7p7@B^<^<4Dc#Vpl}ZJ(H?jn|>n==fkMsT=Q? z>NDZ{2QKCk{H-)#$WzEF%>cYmlZ^c4mNvcC>rQq@KrlQe?ANx{&>Mfs`O*Nd9U}0qQhZtPF~p-8<}ppS+{KR$;-AT z2?51%zNNEOev8&Y)oHQcgR9)7)`B=`y|1xRf6iV#Rb1tGb*?1p`Q*vs;)%6|yeC7< zn~=D}yFwQq?`k%mOrtJ#%(qM}K3IBwSf*=URnwg*s;c(TFD_^PCdL zmcsF!wO0Y1OqlZG=#Sy8-==@Ou*Dx+9&s^!yFBK;|5$W)BisJxD?hzQ#|zVGVJ#2H41jm5+f7=(PS-jwIkwq*^Kiu^rUy*Bsxv3a{f$Dl6^c0b}#ADTXxRawATq6 zNj5|XOcb$+?(9Xl*Mn-o=`CmBZ|a$N&@LoyM7@)~_gzXIk;vKi)DG=mfx-GFa2%ONrx-#U&LD z>UCL7UdEv%_Y4x%+ZJuZgzODRVPZ+YM=JX1mwh@H(%U}jl#|7GS9aKfNlQ+ Deg8ll literal 0 HcmV?d00001 diff --git a/src/site/resources/robots.txt b/src/site/resources/robots.txt new file mode 100644 index 00000000000..da97f40a611 --- /dev/null +++ b/src/site/resources/robots.txt @@ -0,0 +1,5 @@ +# /robots.txt file for http://james.apache.org + +User-agent: * +Disallow: /CVS +Disallow: /images diff --git a/src/site/site.xml b/src/site/site.xml new file mode 100644 index 00000000000..08407856b26 --- /dev/null +++ b/src/site/site.xml @@ -0,0 +1,113 @@ + + + + + + James Project + images/james-project-logo.gif + http://james.apache.org/index.html + + + + The Apache Software Foundation + images/asf-logo-reduced.gif + http://www.apache.org/index.html + + + + org.apache.james + maven-skin + 1.1-SNAPSHOT + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/site/xdoc/code-standards.xml b/src/site/xdoc/code-standards.xml new file mode 100644 index 00000000000..c1343f7258e --- /dev/null +++ b/src/site/xdoc/code-standards.xml @@ -0,0 +1,97 @@ + + + + + + Coding Standards + Serge Knystautas + + + + +
+ +

+ Submissions to the James project must follow the coding conventions + outlined in this document. James developers + are asked to follow coding conventions already present in the code. + (For example, if the existing code has the bracket on + the same line as the if statement, then all subsequent code + should also follow that convention.) Anything not + explicitly mentioned in this document should adhere to the + official + Sun + Java Coding Conventions. +

+ +

+ Developers who commit code that does not follow + the coding conventions outlined in this document will be + responsible for fixing their own code. +

+ +

+1. Spaces between parentheses are optional. The preference is to exclude +extra spaces. Both of these conventions are acceptable: +

+ +

+ +

+ +

+2. Four spaces. NO tabs. Period. The James +mailing list receives cvs commit messages that are almost impossible +to read if tabs are used. +

+ +

+In Emacs-speak, this translates to the following command: + +(setq-default tab-width 4 indent-tabs-mode nil) +

+ +

+3. Use Unix linefeeds for all .java source code files. Only platform-specific +files (e.g. .bat files for Windows) should contain non-Unix linefeeds. +

+ +

+4. Javadoc must exist on all methods. Contributing +a missing javadoc for any method, class, variable, etc., will be GREATLY +appreciated as this will help to improve the James project. +

+ +

+5. The Jakarta Apache/James License MUST be placed +at the top of every file. +

+ +
+ + + diff --git a/src/site/xdoc/contribute.xml b/src/site/xdoc/contribute.xml new file mode 100644 index 00000000000..c3af9292fa1 --- /dev/null +++ b/src/site/xdoc/contribute.xml @@ -0,0 +1,112 @@ + + + + + Contributors How To + Danny Angus + + +
+

+ Anyone can contribute
+ That's right, we always want to hear from people with contributions to the code, + the documentation, the website, and bug reports.
+ The rest of this document outlines the way to go about these to maximum effect.
+

+

+ If you are new to this you may be interested in some of these resources.
+ A good, full, summary of links to guidelines
+ Subscribe to the relevant mailing lists (link on the left).
+ Craig R. McClanahan's advice how to get involved
+ How Jakarta projects run
+

+ +
+ +
+

+ Patches should be submitted to the developers mailing list.
+ Always use diff -u to generate patches, so we can apply them using 'patch'.
+ Make sure you are patching the latest cvs (the HEAD). + (You might want to try 'cvs diff -u -w -b -rHEAD' against the checked out module where + you have implemented the patch.
+
Make sure the patch only contains what is intended, your checkout could be outdated.
+ Make your patch from the jakarta-james directory and make sure it conforms + to the code standards, otherwise it may be ignored. It is OK to make a single patch covering several + files, but please only one issue at a time.
+ Prefix the mail subject with [PATCH]
+ Briefly outline the reason for your patch, + the solution your patch implements, why a patch is + needed and why your code will solve the problem. Note any bug numbers your patch addresses.
+ Submit the patch as an attachment to the mail, this + mail should preferably be in either BASE64 or QuotedPrintable format, to prevent line wrapping.
+

+ +

+ The reason for these rules is so that commiters can easily see what you are trying to achieve, + it is their resonsibility to manage the code and review submissions, + if you make it easy for them to see what you are doing your patch is more likely to + be commited quickly (or at all).
+

+
+ +
+

+ Like the principles for patch submission, mark your mail [PATCH] and ensure + your submission conforms to the code standards. Provide a Brief outline of + your intentions, as above, so that your code can be reviewed easily, and a + note of any relevant bug numbers.
+ New files must contain a reference to the Apache licence, copy the header from an existing file.
+ It also helps if you send your files in an archive (tar, zip) which preserves directories, make it from the jakarta-james directory so we can un-tar your files into the right place. +

+
+ +
+

+ Many improvements come as a direct result of bug + reports, and contributed fixes, often by the same person. It is sometimes said that Apache + projects evolve because users become so fed-up waiting for bugs to be addressed that they + fix them themselves. :)
+ If you report a bug, here we'd appreciate it if you could send a mail to the users or developers + mailing lists, so that we can discuss it with you, bugzilla isn't a great way for mediating + communication.
+ If you want to fix a bug, please contribute your changes according to the guidelines above, + in the Code Patches section. It is much simpler to deal with submissions if they all come + through the same channel. If you still really want to attach patches to bug submissions, please do send us a mail tagged [PATCH] too, so that we notice your patch. +

+
+ +
+

+ While we are glad to accept contributions to documentation + from anyone, in almost any format, because its much better than none, please consider these + guidelines to help us to assimilate your contribution.
+ To edit an existing document try to edit the xml version in src/xdocs (check it out from cvs) + and if you can, submit a patch as for Code Patches.
+ If you want to contribute new files please try to use the simple xml format we use.
+ If this means nothing to you please try to contribute HTML or plain text documents without + any styling, so that we can get at the words and easily convert them into our xml format.
+ If all this seems like unnecessary nonsense, send us whatever you like, we'd still be + happy to receive good documentation. +

+
+ + + diff --git a/src/site/xdoc/download.xml b/src/site/xdoc/download.xml new file mode 100644 index 00000000000..36aa4f34163 --- /dev/null +++ b/src/site/xdoc/download.xml @@ -0,0 +1,159 @@ + + + + + Apache James Mail Server Project + Download + + +
+ +

Use the links below to download the Apache James Mail Server from one of +our mirrors. You must verify the +integrity of the downloaded files using signatures downloaded from +our main distribution directory.

+ +

Only current recommended releases are available on the main +distribution site and its mirrors. Older releases are available from +the archive download +site.

+ +
+ +

[if-any logo] +[end] +The currently selected mirror is [preferred]. If you encounter a +problem with this mirror, please select another mirror. If all +mirrors are failing, there are backup mirrors (at the end of +the mirrors list) that should be available.

+ +
+Other mirrors: + +
+ +

You may also consult the complete +list of mirrors.

+ +
+ +
+ +

This release has many enhancements and bug fixes over the previous +release. See the Change Log +for a detailed list of changes. Some of the earlier defects could +turn a James mail server into an Open Relay. All users of James are urged to upgrade to James v2.2.0 as soon as +possible.

+ + + +
+ +
+ +

It is essential that you verify the integrity of the downloaded +files using the PGP or MD5 signatures.

+ +

The PGP signatures can be verified using PGP or GPG. First +download the KEYS +as well as the asc signature file for the particular +distribution. Make sure you get these files from the main distribution +directory, rather than from a mirror. Then verify the signatures +using

+ +

+% pgpk -a KEYS
+% pgpv james-version.tar.gz.asc
+ +or
+ +% pgp -ka KEYS
+% pgp james-version.tar.gz.asc
+ +or
+ +% gpg --import KEYS
+% gpg --verify james-version.tar.gz.asc +

+ +
+ +
+ +

The software listed above represents the latest Release Build +available from the Apache James Project. From time to time, we also +make available Test Builds. These Test Builds are periodic +snapshots during development. Generally, these are considered +stable snapshots, but they have not undergone as much testing as a +Release Build, nor have they been voted upon for release by the +developer community. These are simply convenient test builds. +Sometimes the purpose for a Test Build could be soliciting feedback on +a specific change. Test Builds are announced on the General mailing +list (general@james.apache.org).

+ +Latest Test Build + +
+ +
+ + diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml new file mode 100644 index 00000000000..d0ddcd4139f --- /dev/null +++ b/src/site/xdoc/index.xml @@ -0,0 +1,46 @@ + + + + Overview + JAMES Project Web Team + + +
+

The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

+

JAMES is organized into subprojects with JAMES Server and the Mailet API as their core.

+

Apache JAMEs is a project of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.

+

The ASF maintains other Java projects which may also be of interest. These are detailed on the ASF Projects page.

+

We recommended that users of JAMES products subscribe to the JAMES users mailing list.

+
+
+
+
+ + ApacheCon US 2006 +
+ +

JAMES Server 2.3.0 RC3 Released

+

James PMC is proud to announce the availability of the third, and hopefully last, release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

+

New development roadmaps are being discussed right now, so stay tuned for 2.3.0 final and for the following news. - Sep/2006

+

JAMES Products website revamped

+

We just finished a major update of james products to be able to publish each product specific site under this new website structure - Aug/2006

+

JAMES Server 2.3.0 on the way

+

After a long time of development we have released the first release candidate of JAMES Server 2.3.0. After a period of user testing version 2.3.0 will be released. - Jul/2006

+

New project JAMES jSPF

+

JAMES PMC is happy to announce that we are working on a Java implementation of the SPF specification. The first betas are already available for download. - Jul/2006

+ + +

JAMES PMC react to the closure of Apache Avalon.

+

JAMES PMC would like to reassure all of our users that JAMES Server is alive and well. All of the James team have kept abreast of the Avalon developments culminating in the closure of the Avalon project and dispersal of its codebase. We are are keen to stress that this has little impact on our ability to support and develop Server in both the short and long terms.
Over the coming months we will be finalising and publishing a road map for JAMES Server which will address all of the specific concerns raised by Avalon's closure, but rest assured JAMES Server' future is safe, and we have enthusiasm and plans aplenty.
In the meantime we would like to extend our best wishes to all our friends from Avalon, here's luck with your future projects guys!
If you are at all concerned please subscribe to the server-user mailing list and raise your points there. - 05/Jan/2005

+ +

JAMES product sources have moved to "Subversion"

+

Subversion is a version control system like CVS, but it has advantages over CVS for Apache Software Foundation (ASF) projects.
In common with all other ASF projects we have reviewed our use of CVS and migrated our code to Subversion.
+Have a look at this FAQ for further details. - 05/Jan/2005

+

+ +

+ + diff --git a/src/site/xdoc/license.xml b/src/site/xdoc/license.xml new file mode 100644 index 00000000000..06475cf8c68 --- /dev/null +++ b/src/site/xdoc/license.xml @@ -0,0 +1,208 @@ + + + + + + Apache Software License + Serge Knystautas + + + +
+

+ James is released under the Apache Software License + listed below: +

+ + + +
+ +
+

+ dnsjava is distributed with James, a copy of the licence is contained in the distribution +

+
+ + + + diff --git a/src/site/xdoc/mail.xml b/src/site/xdoc/mail.xml new file mode 100644 index 00000000000..5919d820f48 --- /dev/null +++ b/src/site/xdoc/mail.xml @@ -0,0 +1,249 @@ + + + + + Mailing lists + James Project Web Team + + +
+

This is a living +document that provides details of mailing lists and guidelines for their +use for the Apache James project.
Please read the whole document +and find a list of available mailinglists at the bottom of the +page.
Last Updated June 2006.

+
+
+

A mailing list is an electronic discussion forum +that anyone can subscribe to. When someone sends an email message to the +mailing list, a copy of that message is broadcast to everyone who is +subscribed to that mailing list. Mailing lists provide a simple and +effective communication mechanism for discussion and decision making. +

+

The Apache Software Foundation has well established reasons for +using email and not other types of forum.
We are +not interested in hearing proposals to use NNTP (news +groups) or web forums or any other medium.
You may use a mail-news +gateway, gmail or anything else you like but email is, and will remain, +the official medium.

+

With potentially thousands of subscribers, +there is a common etiquette that you should observe. Please keep on +reading.

+

+ Respect the mailing list type +

+

+

    +
  • "User" lists are lists where you can send questions +and comments about configuration, setup, usage and other "user" types of +questions.
    • +
  • "Developer" lists are lists where you can send +questions, comments and contributions about the project's software +source code and general "development" types of questions.
    • +
+

+

Some questions are appropriate for posting on both the +"user" and the "developer" lists. In this case, pick one and only one. +Do not cross post.

+

Asking a configuration question on the +developers list is frowned upon because developers' time is as precious +as yours. By contacting them directly instead of the users list you are +abusing resources. It is unlikely that you will get a quicker answer +this way, those developers who have time to devote to providing support +are also subscribed to the users list. If you contact individuals +directly, or post your user issues to the developer list you may get no +answer at all.

+

+ Join the lists that are appropriate for +your discussion. +
Please make sure that you are joining +the list that is appropriate for the topic that you would like to +discuss. The general list is for discussions about the management and +direction of the James project, not for "general support".

+

+ Ask smart questions. +
+ +Every volunteer project obtains its strength from the people involved in +it. You are welcome to join any of our mailing lists. You can choose to +lurk, or actively participate; it's up to you. The level of community +responsiveness to specific questions is generally directly proportional +to the amount of effort you spend formulating your question. Eric +Raymond and Rick Moen have even written an essay entitled "Asking +Smart Questions" precisely on this topic. Although somewhat +militant, it is definitely worth reading.
+ Note: Please do +NOT send your Java problems to the two authors. They welcome feedback on +the FAQ's contents, but are simply not a Java help resource. Follow the +essay's advice and choose +your forum carefully.

+

+ Keep your email short and to +the point. +
If your email is more than about a page of +text, chances are that it won't get read by very many people. It is much +better to try to pack a lot of informative information (see above about +asking smart questions) into as small of an email as possible. If you +are replying to a previous email only quote the parts that you are +replying to and to remove the unnecessary bits. This makes it easier for +people to follow a thread as well as making the email archives easier to +search and read.

+

+ Do your best to ensure that you are +not sending HTML or "Stylelized" email to the list. +
If +you are using Outlook or Outlook Express or Eudora, chances are that you +are sending HTML email by default. There is usually a setting that will +allow you to send "Plain Text" email. If you are using Microsoft +products to send email, there are several bugs in the software that +prevent you from turning off the sending of HTML email. Please read this +page as well...

+

+ Watch +where you are sending email. +
The majority of our mailing +lists have set the Reply-To to go back to the list. That means that when +you Reply to a message, it will go to the list and not to the original +author directly. The reason is because it helps facilitate discussion on +the list for everyone to benefit from. Be careful of this as sometimes +you may intend to reply to a message directly to someone instead of the +entire list. The appropriate contents of the Reply-To header is an +age-old debate that should not be brought up on the mailing lists. You +can examine opposing points of view condemning our +convention and +condoning it. Bringing this up for debate on a mailing list will add +nothing new and is considered off-topic. +

+

+ Do not +cross post messages. +
In other words, pick one mailing +list and send your messages to that mailing list only. Do not send your +messages to multiple mailing lists. The reason is that people may be +subscribed to one list and not to the other. Therefore, some people will +only see part of the conversation.

+
+
+

There are several sites on the net that archive and +provide searching for our mailing lists in HTML readable format. If a +list is not there, then feel free to take initiative and submit it for +us via jakarta-general mailing list. +

+

+

+

+
+
+

+ Now that you have +read the guidelines above please subscribe to our lists and join our +community.

+ +

+ Low +Traffic + Subscribe + Unsubscribe + Guidelines + +Archive +

+

This is the list where users of the Apache James +(Server) meet and discuss issues. Developers are also expected to be +subscribed to this list to offer support to users of Apache James +(Server).

+ + +

+ Low Traffic + Subscribe + Unsubscribe + Guidelines + +Archive +

+

This is the list where participating developers of +the the Apache James Project meet and discuss issues, code +changes/additions, etc. Subscribers to this list get notices of each and +every code change, build results, testing notices, etc. Do not send +mail to this list with usage questions or configuration problems -- +that's what server-user@james is for.

+ + +

+ Very Low Traffic + Subscribe + Unsubscribe + Guidelines + +Archive +

+

This is the list where participating developers of +the the Apache James project discuss changes/additions to the James +websites etc. Subscribers to this list get notifications of every commit +of the website reaourcesDo not send mail to this list with James +software problems -- that's what server-user@james is for.

+ + +

+ Low +Traffic + Subscribe + Unsubscribe + Guidelines + +

+

This is the list for general discussions +relating to the running of the project, it is the public list of the +James project management comittee (PMC) and is a public list open to +all. Do not send mail to this list with James software problems +-- that's what server-user@james is for.

+ +
+ + diff --git a/src/site/xdoc/weare.xml b/src/site/xdoc/weare.xml new file mode 100644 index 00000000000..eab3e15ad63 --- /dev/null +++ b/src/site/xdoc/weare.xml @@ -0,0 +1,172 @@ + + + + + Who We Are + James Project Web Team + + +
+

Special thanks go to the following people for their contributions to this project. We also appreciate documentation, feedback, and bug reports. This is a living document that describes the key contributors to James. Last Updated July 2006.

+
+
+

+ Serge Knystautas (sergek at lokitech.com) (SK) +
Serge was the original donator of the James code, which has since been massively improved by people smarter than him. He tries to answer questions on the listserv and make code contributions when he does get a rare bit of free time.

+

+ Harmeet Bedi (harmeet at kodemuse.com) (HB) +

+

+ Danny Angus (danny at apache.org) (DA) +
Danny is a member of the Apache Software Foundation and married father of two by night, and by day works as lead technical consultant for the Student Loans Company ltd. +

+

+ Noel J. Bergman (noel at devtech.com) (NjB) +

+

+ Vincenzo Gianferrari Pini (vincenzo.gianferraripini at praxis.it) [VGP] +

+

+ Soeren Hilmer (sh at widetrail.dk) [SH] +

+

+ Steve Brewin (sbrewin at synsys.com) [SB] +

+

+ Jason Webb (jw at inovem.com) [JW] +

+

+ Stefano Bagnara (apache at bago.org) [SB2] +

+

+ Norman Maurer (nm at byteaction.de) [NM] +

+

+ Bernd Fondermann (bf_jak at brainlounge.de) [BF] +

+ +
+
+

Many people have had a hand in James' success over the years, here we'd like to give credit to those who have made a difference and to those who have left.

+

+ Alan D. Cabrera (list at toolazydogs.com) [ADC] +

+

+ Darrell DeBoer (DD) +

+

+ Stephen J. McConnell (mcconnell at apache.org) (SJM) +

+

+ Peter M. Goldstein (farsight at alum.mit.edu) (PG) +

+

+ Pete Donald (PD) +

+

+ Charles Benett (charles at benett1.demon.co.uk) (CB) +

+

+ Federico Barbieri, (scoobie at systemy.it) (FB) +

+

+ Stuart Roebuck, stuart.roebuck at adolos.co.uk (SR) +

+

+ Ivan Seskar, iseskar at upsideweb.com (IS) +

+

+ Prasanna Uppaladadium, prasanna at vayusphere.com (PU) +

+

+ Gabriel Bucher, gabriel.bucher at razor.ch (GB) +

+

+ Matthew Pangaro, mattp at lokitech.com (MP) +

+

+ Jason Borden, jborden at javasense.com (JB) +

+

+ Randy Stanard (rstanard at lokitech.com) (RS) +
Contributed the James logo.

+

+ Samuel Sadek (Samuel.Sadek at kpmg.co.uk) (SS) +

+

+ Stephan Schiessling (s at rapi.com) (SS2) +

+

+ Eung-ju Park (colus at apache.org) (EP) +

+

+ Paul Hammant (Paul_Hammant at yahoo.com) (PH) +

+

+ Jeff Keyser (JKeyser at telocity.com) (JK) +

+

+ Andrei Ivanov (myfam at surfeu.fi) (AI) +

+

+ Brad Walker (bwalker at studentadvantage.com) (BW) +

+

+ Christian Buchegger (christian.buchegger at planet-interkom.de) (CB2) +

+

+ Shilpa Dalmia (shilpa at postx.com) (SD) +

+

+ Steve Short (sshort at postx.com) (SS3) +

+

+ Aaron Knauf (aknauf at xtra.co.nz) (AK) +

+

+ Serge "Sergei" Sozonoff (serge at globalbeach.com) (SS4) +

+

+ Kai Londenberg (kai.londenberg at my-vwclub.de) [KL] +

+

+ Mark Imel (james at imelshire.com) [MI] +

+

+ Kevin Schmidt (ktschmidt at earthlink.net) [KS] +

+

+ Hontvari Jozsef (hontvari2 at solware.com) [HJ] +

+

+ Cesar Bonadio (bonadio at picture.com.br) [CB3] +

+

+ Marco Tedone (mtedone at jemos.org) [MT] +

+

+ Tim Stephenson (tim at thestephensons.me.uk) [TS] +

+

+ Richard O. Hammer (rohammer at earthlink.net) [ROH] +

+
+ + From 68f864b752d31752bfbd5e80437b52bc5dd4d8c3 Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 30 Sep 2006 17:29:31 +0000 Subject: [PATCH 006/541] Updated pom urls to reflect "trunk" folder move. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@451625 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 6 +++--- server/2.2.0/pom.xml | 6 +++--- server/pom.xml | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index ce9707112f0..d5fc06ca6df 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -48,9 +48,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/maven-skin - scm:svn:https://svn.apache.org/repos/asf/james/project/maven-skin - http://svn.apache.org/viewvc/james/project/maven-skin + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/maven-skin + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/maven-skin + http://svn.apache.org/viewvc/james/project/trunk/maven-skin \ No newline at end of file diff --git a/server/2.2.0/pom.xml b/server/2.2.0/pom.xml index 1055c16207b..6ba8a4ab0ee 100644 --- a/server/2.2.0/pom.xml +++ b/server/2.2.0/pom.xml @@ -37,9 +37,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/server/2.2.0 - scm:svn:https://svn.apache.org/repos/asf/james/project/server/2.2.0 - http://svn.apache.org/viewvc/james/project/server/2.2.0 + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/server/2.2.0 + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/server/2.2.0 + http://svn.apache.org/viewvc/james/project/trunk/server/2.2.0 diff --git a/server/pom.xml b/server/pom.xml index 3ead2a35eea..87baec87ee9 100644 --- a/server/pom.xml +++ b/server/pom.xml @@ -39,9 +39,9 @@ 2006 - scm:svn:http://svn.apache.org/repos/asf/james/project/server - scm:svn:https://svn.apache.org/repos/asf/james/project/server - http://svn.apache.org/viewvc/james/project/server + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/server + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/server + http://svn.apache.org/viewvc/james/project/trunk/server From 339d21df7859c9568638736474536ebff8200349 Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 2 Oct 2006 10:50:10 +0000 Subject: [PATCH 007/541] Update index site to reflect new james version git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@451967 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/index.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index d0ddcd4139f..44c00cc959c 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -22,6 +22,10 @@ ApacheCon US 2006 +

JAMES Server 2.3.0 RC4 Released

+

James PMC is proud to announce the availability of the forth release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog. - Oct/2006

+

jSPF 0.9 b3 Released

+

James PMC is proud to announce the availability of the third beta of jspf 0.9. This version has start to use the official spf testsuite to fix all rfc issues. - Sep/2006

JAMES Server 2.3.0 RC3 Released

James PMC is proud to announce the availability of the third, and hopefully last, release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

New development roadmaps are being discussed right now, so stay tuned for 2.3.0 final and for the following news. - Sep/2006

From 368a3c1d9330059355febed6ed4bde1bb27fa93c Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 2 Oct 2006 15:46:16 +0000 Subject: [PATCH 008/541] Fix broken changelog links git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@452087 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/index.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index 44c00cc959c..a62d3be48f0 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -23,11 +23,11 @@

JAMES Server 2.3.0 RC4 Released

-

James PMC is proud to announce the availability of the forth release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog. - Oct/2006

+

James PMC is proud to announce the availability of the forth release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog. - Oct/2006

jSPF 0.9 b3 Released

James PMC is proud to announce the availability of the third beta of jspf 0.9. This version has start to use the official spf testsuite to fix all rfc issues. - Sep/2006

JAMES Server 2.3.0 RC3 Released

-

James PMC is proud to announce the availability of the third, and hopefully last, release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

+

James PMC is proud to announce the availability of the third, and hopefully last, release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

New development roadmaps are being discussed right now, so stay tuned for 2.3.0 final and for the following news. - Sep/2006

JAMES Products website revamped

We just finished a major update of james products to be able to publish each product specific site under this new website structure - Aug/2006

From 942a6bbbcfb3cb5bb9cb412ef4865a933c22506e Mon Sep 17 00:00:00 2001 From: bago Date: Wed, 4 Oct 2006 20:04:29 +0000 Subject: [PATCH 009/541] Moved james_and_sendmail faq to site/server level (Thanks to Danny) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@452998 13f79535-47bb-0310-9956-ffa450edef68 --- server/2.2.0/src/site/site.xml | 1 - server/src/site/site.xml | 4 +++- server/{2.2.0 => }/src/site/xdoc/james_and_sendmail.xml | 0 3 files changed, 3 insertions(+), 2 deletions(-) rename server/{2.2.0 => }/src/site/xdoc/james_and_sendmail.xml (100%) diff --git a/server/2.2.0/src/site/site.xml b/server/2.2.0/src/site/site.xml index dc999b340cb..bfa026e2310 100644 --- a/server/2.2.0/src/site/site.xml +++ b/server/2.2.0/src/site/site.xml @@ -39,7 +39,6 @@ - diff --git a/server/src/site/site.xml b/server/src/site/site.xml index 9b4b2ba51a0..4f9ecbe8be5 100644 --- a/server/src/site/site.xml +++ b/server/src/site/site.xml @@ -36,7 +36,9 @@ - + + + diff --git a/server/2.2.0/src/site/xdoc/james_and_sendmail.xml b/server/src/site/xdoc/james_and_sendmail.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/james_and_sendmail.xml rename to server/src/site/xdoc/james_and_sendmail.xml From 033297e9dbba053dbb0576011e7af83b7c45c062 Mon Sep 17 00:00:00 2001 From: berndf Date: Sun, 29 Oct 2006 14:23:22 +0000 Subject: [PATCH 010/541] added traffic level for server-def to 'high'; added mailet-api to list git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@468908 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/mail.xml | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/src/site/xdoc/mail.xml b/src/site/xdoc/mail.xml index 5919d820f48..fcfc0d2d34a 100644 --- a/src/site/xdoc/mail.xml +++ b/src/site/xdoc/mail.xml @@ -30,8 +30,7 @@ use for the Apache James project.
Please read the whole document and find a list of available mailinglists at the bottom of the page.
Last Updated June 2006.

-
+

A mailing list is an electronic discussion forum that anyone can subscribe to. When someone sends an email message to the mailing list, a copy of that message is broadcast to everyone who is @@ -96,8 +95,7 @@ the FAQ's contents, but are simply not a Java help resource. Follow the essay's advice and choose your forum carefully.

- Keep your email short and to -the point. + Keep your email short and to the point.
If your email is more than about a page of text, chances are that it won't get read by very many people. It is much better to try to pack a lot of informative information (see above about @@ -117,8 +115,7 @@ products to send email, there are several bugs in the software that prevent you from turning off the sending of HTML email. Please read this page as well...

- Watch -where you are sending email. + Watch where you are sending email.
The majority of our mailing lists have set the Reply-To to go back to the list. That means that when you Reply to a message, it will go to the list and not to the original @@ -133,8 +130,7 @@ condoning it. Bringing this up for debate on a mailing list will add nothing new and is considered off-topic.

- Do not -cross post messages. + Do not cross post messages.
In other words, pick one mailing list and send your messages to that mailing list only. Do not send your messages to multiple mailing lists. The reason is that people may be @@ -155,8 +151,7 @@ us via jakarta-general mailing list. Index on mail-archives.apache.org

  • - Full -mbox archives of all lists. + Full mbox archives of all lists.
  • Mail-Archive @@ -183,8 +178,7 @@ read the guidelines above please subscribe to our lists and join our community.

    - Low -Traffic + Low Traffic Subscribe Unsubscribe Guidelines @@ -198,7 +192,7 @@ subscribed to this list to offer support to users of Apache James

    - Low Traffic + High Traffic Subscribe Unsubscribe Guidelines @@ -229,8 +223,7 @@ software problems -- that's what server-user@james is for.

    - Low -Traffic + Low Traffic Subscribe Unsubscribe Guidelines @@ -240,10 +233,21 @@ Archive -->

    This is the list for general discussions relating to the running of the project, it is the public list of the -James project management comittee (PMC) and is a public list open to +James project management committee (PMC) and is a public list open to all. Do not send mail to this list with James software problems -- that's what server-user@james is for.

    + +

    + Very Low Traffic + Subscribe + Unsubscribe + Guidelines +

    +

    This is the public list discussing all Mailet API + related topics. +

    +
    • From f222ca5da2be17faa12cc015e833c8429fdff8a4 Mon Sep 17 00:00:00 2001 From: bago Date: Mon, 30 Oct 2006 10:55:19 +0000 Subject: [PATCH 011/541] Updated website to reflect 2.3.0 final release. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@469116 13f79535-47bb-0310-9956-ffa450edef68 --- server/src/site/xdoc/index.xml | 11 +++++------ src/site/xdoc/download.xml | 28 ++++++++++++++-------------- src/site/xdoc/index.xml | 4 ++-- 3 files changed, 21 insertions(+), 22 deletions(-) diff --git a/server/src/site/xdoc/index.xml b/server/src/site/xdoc/index.xml index fc3b5e8693b..4a284d1e29d 100644 --- a/server/src/site/xdoc/index.xml +++ b/server/src/site/xdoc/index.xml @@ -31,13 +31,12 @@

    - Latest and Stable: James v2.2.0 + Latest and Stable: James v2.3.0
    -James v2.2.0 is the current release, and the latest in the James v2 series. -Both binary and source distributions are available.

    -

    James v2.2.0 is a major update to the James platform, with many new features, functional improvements, and bug fixes. -See the Change Log for a detailed list of changes. All -users are urged to upgrade to v2.2.0 as soon as possible.

    +James v2.3.0 is the current best release. Both binary and source distributions are available.

    +

    James v2.3.0 is a major update to the James platform, with many new features, functional improvements, and bug fixes. +See the Change Log for a detailed list of changes. All +users are urged to upgrade to v2.3.0 as soon as possible.

    Any bugs found in James are dealt with promptly. Please provide feedback on the james-user and james-dev mailing lists.

    Get your hands on the latest versions.. diff --git a/src/site/xdoc/download.xml b/src/site/xdoc/download.xml index 36aa4f34163..e2f58841e44 100644 --- a/src/site/xdoc/download.xml +++ b/src/site/xdoc/download.xml @@ -64,40 +64,40 @@ list of mirrors.

    -
    +

    This release has many enhancements and bug fixes over the previous release. See the Change Log for a detailed list of changes. Some of the earlier defects could -turn a James mail server into an Open Relay. All users of James are urged to upgrade to James v2.2.0 as soon as +turn a James mail server into an Open Relay. All users of James are urged to upgrade to James v2.3.0 as soon as possible.

    • Binary (Unix TAR): james-2.2.0.tar.gz [PGP]
      • +href="[preferred]/james/server/binaries/james-2.3.0.tar.gz">james-2.3.0.tar.gz [PGP]
    • Binary (ZIP Format): james-2.2.0.zip [PGP]
      • +href="[preferred]/james/server/binaries/james-2.3.0.zip">james-2.3.0.zip [PGP]
    • Source (Unix TAR): james-2.2.0-src.tar.gz [PGP]
      • +href="[preferred]/james/server/source/james-2.3.0-src.tar.gz">james-2.3.0-src.tar.gz [PGP]
    • Source (ZIP Format): james-2.2.0-src.zip [PGP]
      • +href="[preferred]/james/server/source/james-2.3.0-src.zip">james-2.3.0-src.zip [PGP]
    • Source with Avalon Phoenix binaries (Unix TAR): james-with-phoenix-2.2.0-src.tar.gz [PGP]
      • +href="[preferred]/james/server/source/james-with-phoenix-2.3.0-src.tar.gz">james-with-phoenix-2.3.0-src.tar.gz [PGP]
    • Source with Avalon Phoenix binaries (ZIP Format): james-with-phoenix-2.2.0-src.zip [PGP]
      • +href="[preferred]/james/server/source/james-with-phoenix-2.3.0-src.zip">james-with-phoenix-2.3.0-src.zip [PGP]
    • Other diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index a62d3be48f0..ad928b002db 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -22,8 +22,8 @@ ApacheCon US 2006 -

      JAMES Server 2.3.0 RC4 Released

      -

      James PMC is proud to announce the availability of the forth release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog. - Oct/2006

      +

      JAMES Server 2.3.0 Final Released

      +

      James PMC is proud to announce the availability of the long awaited final release of JAMES Server 2.3.0. More informations on what's new can be found in the changelog. - Oct/2006

      jSPF 0.9 b3 Released

      James PMC is proud to announce the availability of the third beta of jspf 0.9. This version has start to use the official spf testsuite to fix all rfc issues. - Sep/2006

      JAMES Server 2.3.0 RC3 Released

      From efbe3f4c8a5da2688828616aafc1e025647781b2 Mon Sep 17 00:00:00 2001 From: bago Date: Mon, 30 Oct 2006 18:23:51 +0000 Subject: [PATCH 012/541] Fixed the link to the download page in the release news. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@469220 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/index.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index ad928b002db..ce4794386f2 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -23,7 +23,7 @@

      JAMES Server 2.3.0 Final Released

      -

      James PMC is proud to announce the availability of the long awaited final release of JAMES Server 2.3.0. More informations on what's new can be found in the changelog. - Oct/2006

      +

      James PMC is proud to announce the availability of the long awaited final release of JAMES Server 2.3.0. More informations on what's new can be found in the changelog. - Oct/2006

      jSPF 0.9 b3 Released

      James PMC is proud to announce the availability of the third beta of jspf 0.9. This version has start to use the official spf testsuite to fix all rfc issues. - Sep/2006

      JAMES Server 2.3.0 RC3 Released

      From 545cfd27801efb696bd6043a8127b096dba3ff5f Mon Sep 17 00:00:00 2001 From: bago Date: Tue, 31 Oct 2006 00:26:32 +0000 Subject: [PATCH 013/541] Removed fetchPOP, added fetchMail git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@469328 13f79535-47bb-0310-9956-ffa450edef68 --- server/src/site/xdoc/index.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/server/src/site/xdoc/index.xml b/server/src/site/xdoc/index.xml index 4a284d1e29d..b956db59d18 100644 --- a/server/src/site/xdoc/index.xml +++ b/server/src/site/xdoc/index.xml @@ -119,10 +119,10 @@ users are urged to upgrade to v2.3.0 as soon as possible.

      1.2 - FetchPOP - Deprecated - 2.3 - 2.1 + FetchMail + Stable + 2.2 + 2.2
    From 83c44a3b46a00d950b232b3b7f76dc2d2ec179d4 Mon Sep 17 00:00:00 2001 From: bago Date: Wed, 15 Nov 2006 11:19:43 +0000 Subject: [PATCH 014/541] Fixed a bunch of broken links on the new website (JAMES-691) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@475203 13f79535-47bb-0310-9956-ffa450edef68 --- server/2.2.0/src/site/xdoc/changelog.xml | 2 +- server/2.2.0/src/site/xdoc/index.xml | 5 ----- server/2.2.0/src/site/xdoc/usingTLS.xml | 2 +- server/2.2.0/src/site/xdoc/using_database.xml | 2 +- server/src/site/xdoc/FAQ.xml | 8 ++++---- 5 files changed, 7 insertions(+), 12 deletions(-) diff --git a/server/2.2.0/src/site/xdoc/changelog.xml b/server/2.2.0/src/site/xdoc/changelog.xml index d9841e13ebd..8cd9c6459e1 100644 --- a/server/2.2.0/src/site/xdoc/changelog.xml +++ b/server/2.2.0/src/site/xdoc/changelog.xml @@ -439,7 +439,7 @@ Below are some highlights of features and changes already available:
    -

    Check out our Who We Are page to see who to thank.

    +

    Check out our Who We Are page to see who to thank.

    diff --git a/server/2.2.0/src/site/xdoc/index.xml b/server/2.2.0/src/site/xdoc/index.xml index 837d82d68a1..59663d9533d 100644 --- a/server/2.2.0/src/site/xdoc/index.xml +++ b/server/2.2.0/src/site/xdoc/index.xml @@ -85,7 +85,6 @@ V. Common Configurations
  • Using SMTP AUTH
  • Using a Database with James
  • Using TLS/SSL
    • -
  • James and Sendmail
  • Creating Mailing Lists
    • VI. Customizing James @@ -93,10 +92,6 @@ VI. Customizing James
  • How to write a custom Matcher
  • How to write a custom Mailet
    • -V. Other Information -

    diff --git a/server/2.2.0/src/site/xdoc/usingTLS.xml b/server/2.2.0/src/site/xdoc/usingTLS.xml index a2d25ec76c2..bf5c2acebe4 100644 --- a/server/2.2.0/src/site/xdoc/usingTLS.xml +++ b/server/2.2.0/src/site/xdoc/usingTLS.xml @@ -38,7 +38,7 @@ configuring the JVM to use JSSE services.

    If you are using a Java distribution that does not include JSSE as part of the distribution you will need to download the JSSE package separately. It can be obtained from -here. Please follow Sun's instructions for installation +here. Please follow Sun's instructions for installation and configuration of JSSE.

    In either case, you will need to statically define a JSSE TLS provider. In general, this is the default installation.

    diff --git a/server/2.2.0/src/site/xdoc/using_database.xml b/server/2.2.0/src/site/xdoc/using_database.xml index b7b2d7ed156..275b0a6a460 100644 --- a/server/2.2.0/src/site/xdoc/using_database.xml +++ b/server/2.2.0/src/site/xdoc/using_database.xml @@ -135,7 +135,7 @@ storage mechanism for the message spool:

    There are some vendor-specific subtleties in using databases with James that have been observed by some users. These issues (and methods to resolve them) are recorded on the -James FAQ as they are reported. Please consult the FAQ if you encounter any +James FAQ as they are reported. Please consult the FAQ if you encounter any difficulties.
    diff --git a/server/src/site/xdoc/FAQ.xml b/server/src/site/xdoc/FAQ.xml index 0ef746a04d1..5d1393b6ba8 100644 --- a/server/src/site/xdoc/FAQ.xml +++ b/server/src/site/xdoc/FAQ.xml @@ -119,7 +119,7 @@ <sqlFile>file://conf/sqlResources.xml</sqlFile> </repository> -

    Database users will also need to ensure that they have configured a data-source named to match the destination URL

    +

    Database users will also need to ensure that they have configured a data-source named to match the destination URL

    Using the filesystem:-

    <repository name="list-james" @@ -177,7 +177,7 @@ -

    James v2.1 includes a new mailet for database users, JDBCVirtualUserTable, that mimics some of the sendmail capabilities of the same name.

    +

    James v2.1+ includes a new mailet for database users, JDBCVirtualUserTable, that mimics some of the sendmail capabilities of the same name.

    JDBCVirtualUserTable does not provide any administation tools. You'll have to create and maintain the database table yourself. The standard configuration is as follows:

    @@ -222,7 +222,7 @@ match as follows (in precedence order):

    We are largely reliant on what Avalon is doing in terms of classloading, but here are a few tips and suggestions:

    • Stick jars in the james/lib directory and add them to the classpath in run.bat or run.sh.
      • -
    • Instructions for including classes for custom mailets and matchers can be found here and here respectively..
      • +
    • Instructions for including classes for custom mailets and matchers can be found here and here respectively..
    Eventually we hope to support mailet reloading and a special lib and classes directory within the james directory that custom mailets can load from, but for now these are hopefully some useful tips.

    @@ -272,7 +272,7 @@ match as follows (in precedence order): -

    Read the "Contributors How To" here +

    Read the "Contributors How To" here

    From b576aa3f6431e6a067a47c9da401ce7ec72580be Mon Sep 17 00:00:00 2001 From: bago Date: Wed, 15 Nov 2006 12:31:27 +0000 Subject: [PATCH 015/541] Fixed few more broken links on the new website (JAMES-691) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@475213 13f79535-47bb-0310-9956-ffa450edef68 --- server/pom.xml | 2 +- src/site/xdoc/contribute.xml | 3 +-- src/site/xdoc/download.xml | 2 +- src/site/xdoc/index.xml | 2 +- src/site/xdoc/mail.xml | 7 ++----- 5 files changed, 6 insertions(+), 10 deletions(-) diff --git a/server/pom.xml b/server/pom.xml index 87baec87ee9..046874ceb3e 100644 --- a/server/pom.xml +++ b/server/pom.xml @@ -86,7 +86,7 @@ James General List server-general-subscribe@james.apache.org server-general-unsubscribe@james.apache.org - http://www.mail-archive.com/server-general@james.apache.org/ + http://www.mail-archive.com/general%40james.apache.org/ diff --git a/src/site/xdoc/contribute.xml b/src/site/xdoc/contribute.xml index c3af9292fa1..b433172d7d0 100644 --- a/src/site/xdoc/contribute.xml +++ b/src/site/xdoc/contribute.xml @@ -32,10 +32,9 @@

    If you are new to this you may be interested in some of these resources.
    -     A good, full, summary of links to guidelines
    + A good, full, summary of links to guidelines
    Subscribe to the relevant mailing lists (link on the left).
    Craig R. McClanahan's advice how to get involved
    - How Jakarta projects run

    diff --git a/src/site/xdoc/download.xml b/src/site/xdoc/download.xml index e2f58841e44..2fc16df8ace 100644 --- a/src/site/xdoc/download.xml +++ b/src/site/xdoc/download.xml @@ -68,7 +68,7 @@ list of mirrors.

    This release has many enhancements and bug fixes over the previous release. See the Change Log +href="server/2.3.0/changelog.html">Change Log for a detailed list of changes. Some of the earlier defects could turn a James mail server into an Open Relay. All users of James are urged to upgrade to James v2.3.0 as soon as possible.

    diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index ce4794386f2..719598f8db0 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -42,7 +42,7 @@

    JAMES product sources have moved to "Subversion"

    Subversion is a version control system like CVS, but it has advantages over CVS for Apache Software Foundation (ASF) projects.
    In common with all other ASF projects we have reviewed our use of CVS and migrated our code to Subversion.
    -Have a look at this FAQ for further details. - 05/Jan/2005

    +Have a look at this FAQ for further details. - 05/Jan/2005

    diff --git a/src/site/xdoc/mail.xml b/src/site/xdoc/mail.xml index fcfc0d2d34a..bd61be571a4 100644 --- a/src/site/xdoc/mail.xml +++ b/src/site/xdoc/mail.xml @@ -112,8 +112,7 @@ you are using Outlook or Outlook Express or Eudora, chances are that you are sending HTML email by default. There is usually a setting that will allow you to send "Plain Text" email. If you are using Microsoft products to send email, there are several bugs in the software that -prevent you from turning off the sending of HTML email. Please read this -page as well...

    +prevent you from turning off the sending of HTML email.

    Watch where you are sending email.
    The majority of our mailing @@ -139,9 +138,7 @@ only see part of the conversation.

    There are several sites on the net that archive and -provide searching for our mailing lists in HTML readable format. If a -list is not there, then feel free to take initiative and submit it for -us via jakarta-general mailing list. +provide searching for our mailing lists in HTML readable format.

      From 92bbbe52730390d490b5f5a7debf8678db99c106 Mon Sep 17 00:00:00 2001 From: bago Date: Wed, 15 Nov 2006 12:33:09 +0000 Subject: [PATCH 016/541] Fixed general list definition in parent server pom.xml git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@475214 13f79535-47bb-0310-9956-ffa450edef68 --- server/pom.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/server/pom.xml b/server/pom.xml index 046874ceb3e..6d510df41c2 100644 --- a/server/pom.xml +++ b/server/pom.xml @@ -84,8 +84,8 @@ James General List - server-general-subscribe@james.apache.org - server-general-unsubscribe@james.apache.org + general-subscribe@james.apache.org + general-unsubscribe@james.apache.org http://www.mail-archive.com/general%40james.apache.org/ From e9d61acb47b07da943430c84376bd91edad70257 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Sun, 7 Jan 2007 19:40:22 +0000 Subject: [PATCH 017/541] Test karma by adding personal details. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@493822 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 9 +++++++++ src/site/xdoc/weare.xml | 7 +++++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index 5b788edf13f..d06daea9c30 100644 --- a/pom.xml +++ b/pom.xml @@ -135,6 +135,15 @@ Alan D. Cabrera -8 + + rdonkin + Robert Burrell Donkin + rdonkin at apache.org + + + Developer + + diff --git a/src/site/xdoc/weare.xml b/src/site/xdoc/weare.xml index eab3e15ad63..cc6c5302cb6 100644 --- a/src/site/xdoc/weare.xml +++ b/src/site/xdoc/weare.xml @@ -24,7 +24,7 @@
      -

      Special thanks go to the following people for their contributions to this project. We also appreciate documentation, feedback, and bug reports. This is a living document that describes the key contributors to James. Last Updated July 2006.

      +

      Special thanks go to the following people for their contributions to this project. We also appreciate documentation, feedback, and bug reports. This is a living document that describes the key contributors to James. Last Updated January 2007.

      @@ -61,7 +61,10 @@

      Bernd Fondermann (bf_jak at brainlounge.de) [BF]

      - +

      + Robert Burrell Donkin (rdonkin at apache.org) [RBD] +

      +

      Many people have had a hand in James' success over the years, here we'd like to give credit to those who have made a difference and to those who have left.

      From 8e7e5d74bf7a2368112935b454d8d2b65298dce1 Mon Sep 17 00:00:00 2001 From: danny Date: Wed, 7 Feb 2007 15:10:52 +0000 Subject: [PATCH 018/541] added APachecon ad banner IFrame organised News into dated headlines on the front page and a new newsarchive.xml page for the full stories added news about my feathercast and the mailet API sub project git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@504574 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/site.xml | 149 +++++++++++++++++----------------- src/site/xdoc/index.xml | 52 +++++------- src/site/xdoc/mail.xml | 4 +- src/site/xdoc/newsarchive.xml | 48 +++++++++++ 4 files changed, 143 insertions(+), 110 deletions(-) create mode 100644 src/site/xdoc/newsarchive.xml diff --git a/src/site/site.xml b/src/site/site.xml index 08407856b26..557d9da1f27 100644 --- a/src/site/site.xml +++ b/src/site/site.xml @@ -1,52 +1,52 @@ - - - - - James Project - images/james-project-logo.gif - http://james.apache.org/index.html - - - - The Apache Software Foundation - images/asf-logo-reduced.gif - http://www.apache.org/index.html - - - - org.apache.james - maven-skin - 1.1-SNAPSHOT - - - - + + + + James Project + images/james-project-logo.gif + http://james.apache.org/index.html + + + + The Apache Software Foundation + images/asf-logo-reduced.gif + http://www.apache.org/index.html + + + + org.apache.james + maven-skin + 1.1-SNAPSHOT + + + + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - - - - - - - + + + + + + + + @@ -97,7 +98,7 @@ - + diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index 719598f8db0..b0b2003416d 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -5,46 +5,32 @@ JAMES Project Web Team -
      -

      The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

      +
      +
      +

      The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

      JAMES is organized into subprojects with JAMES Server and the Mailet API as their core.

      Apache JAMEs is a project of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.

      The ASF maintains other Java projects which may also be of interest. These are detailed on the ASF Projects page.

      We recommended that users of JAMES products subscribe to the JAMES users mailing list.

      -
      -
      -
      - - ApacheCon US 2006 -
      +
      + Read all the news in full in the News Archive
      + Or click the titles to read the full story + + Feb/2007 - Feathercast features James
      + Jan/2007 - Mailet API to become sub-project
      +

      +       -

      JAMES Server 2.3.0 Final Released

      -

      James PMC is proud to announce the availability of the long awaited final release of JAMES Server 2.3.0. More informations on what's new can be found in the changelog. - Oct/2006

      -

      jSPF 0.9 b3 Released

      -

      James PMC is proud to announce the availability of the third beta of jspf 0.9. This version has start to use the official spf testsuite to fix all rfc issues. - Sep/2006

      -

      JAMES Server 2.3.0 RC3 Released

      -

      James PMC is proud to announce the availability of the third, and hopefully last, release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

      -

      New development roadmaps are being discussed right now, so stay tuned for 2.3.0 final and for the following news. - Sep/2006

      -

      JAMES Products website revamped

      -

      We just finished a major update of james products to be able to publish each product specific site under this new website structure - Aug/2006

      -

      JAMES Server 2.3.0 on the way

      -

      After a long time of development we have released the first release candidate of JAMES Server 2.3.0. After a period of user testing version 2.3.0 will be released. - Jul/2006

      -

      New project JAMES jSPF

      -

      JAMES PMC is happy to announce that we are working on a Java implementation of the SPF specification. The first betas are already available for download. - Jul/2006

      + Oct/2006 - JAMES Server 2.3.0 Final Released
      + Sep/2006 - jSPF 0.9 b3 Released
      + Aug/2006 - JAMES Server 2.3.0 RC3 Released
      + Aug/2006 - JAMES Products website revamped
      + Jul/2006 - JAMES Server 2.3.0 on the way
      + Jul/2006 - New project JAMES jSPF
       - -

      JAMES PMC react to the closure of Apache Avalon.

      -

      JAMES PMC would like to reassure all of our users that JAMES Server is alive and well. All of the James team have kept abreast of the Avalon developments culminating in the closure of the Avalon project and dispersal of its codebase. We are are keen to stress that this has little impact on our ability to support and develop Server in both the short and long terms.
      Over the coming months we will be finalising and publishing a road map for JAMES Server which will address all of the specific concerns raised by Avalon's closure, but rest assured JAMES Server' future is safe, and we have enthusiasm and plans aplenty.
      In the meantime we would like to extend our best wishes to all our friends from Avalon, here's luck with your future projects guys!
      If you are at all concerned please subscribe to the server-user mailing list and raise your points there. - 05/Jan/2005

      - -

      JAMES product sources have moved to "Subversion"

      -

      Subversion is a version control system like CVS, but it has advantages over CVS for Apache Software Foundation (ASF) projects.
      In common with all other ASF projects we have reviewed our use of CVS and migrated our code to Subversion.
      -Have a look at this FAQ for further details. - 05/Jan/2005

      -

      -

      diff --git a/src/site/xdoc/mail.xml b/src/site/xdoc/mail.xml index bd61be571a4..25bfc73fd3d 100644 --- a/src/site/xdoc/mail.xml +++ b/src/site/xdoc/mail.xml @@ -241,9 +241,7 @@ all. Do not send mail to this list with James software problems Unsubscribe Guidelines

      -

      This is the public list discussing all Mailet API - related topics. -

      +

      This is the public list for the Mailet API subproject, discussing all Mailet API design and implementation related topics. Questions about using Mailets and their configuration should be addressed to the server-user list.

      diff --git a/src/site/xdoc/newsarchive.xml b/src/site/xdoc/newsarchive.xml new file mode 100644 index 00000000000..cb8547ee58d --- /dev/null +++ b/src/site/xdoc/newsarchive.xml @@ -0,0 +1,48 @@ + + + + News Archive + JAMES Project Web Team + + +
      +
      + +

      Feb/2007 - Feathercast features James

       +

      James PMC member and commiter Danny Angus was interviewed about James by David Reid for Feathercast episode 24. You can download the podcast from here.

      +

      Jan/2007 - Mailet API to become a sub-project

       +

      The James commiters have voted to promote the Mailet API to its own James sub-project.
      + This move will provide a clearer division between development of the API and development of James server, and we hope this will encourage more participation from external projects.

      +

      The effort will start small, by releasing the current version, and move on to look at the enhancements we've been discussing over on the mailet api list where we will extend a warm welcome to anyone who has something to contribute.

      +

      Eventually we hope to extend the scope of the sub-project to include things like a Reference Implementation independent of James Server and suitable for embedding, an SDK, and possibly a TCK. +

      +       + +

      Oct/2006 - JAMES Server 2.3.0 Final Released

      +

      James PMC is proud to announce the availability of the long awaited final release of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

      +

      Sep/2006 - jSPF 0.9 b3 Released

      +

      James PMC is proud to announce the availability of the third beta of jspf 0.9. This version has start to use the official spf testsuite to fix all rfc issues.

      +

      Aug/2006 - JAMES Server 2.3.0 RC3 Released

      +

      James PMC is proud to announce the availability of the third, and hopefully last, release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

      +

      New development roadmaps are being discussed right now, so stay tuned for 2.3.0 final and for the following news. - Sep/2006

      +

      Aug/2006 - JAMES Products website revamped

      +

      We just finished a major update of james products to be able to publish each product specific site under this new website structure

      +

      Jul/2006 - JAMES Server 2.3.0 on the way

      +

      After a long time of development we have released the first release candidate of JAMES Server 2.3.0. After a period of user testing version 2.3.0 will be released.

      +

      Jul/2006 - New project JAMES jSPF

      +

      JAMES PMC is happy to announce that we are working on a Java implementation of the SPF specification. The first betas are already available for download.

      +       + +

      JAMES PMC react to the closure of Apache Avalon.

      +

      JAMES PMC would like to reassure all of our users that JAMES Server is alive and well. All of the James team have kept abreast of the Avalon developments culminating in the closure of the Avalon project and dispersal of its codebase. We are are keen to stress that this has little impact on our ability to support and develop Server in both the short and long terms.
      Over the coming months we will be finalising and publishing a road map for JAMES Server which will address all of the specific concerns raised by Avalon's closure, but rest assured JAMES Server' future is safe, and we have enthusiasm and plans aplenty.
      In the meantime we would like to extend our best wishes to all our friends from Avalon, here's luck with your future projects guys!
      If you are at all concerned please subscribe to the server-user mailing list and raise your points there. - 05/Jan/2005

      + +

      JAMES product sources have moved to "Subversion"

      +

      Subversion is a version control system like CVS, but it has advantages over CVS for Apache Software Foundation (ASF) projects.
      In common with all other ASF projects we have reviewed our use of CVS and migrated our code to Subversion.
      +Have a look at this FAQ for further details. - 05/Jan/2005

      +

      + +

      + +       From ea14129c7e4f4b7a329ce9c9745800389906fcf3 Mon Sep 17 00:00:00 2001 From: danny Date: Wed, 7 Feb 2007 15:35:40 +0000 Subject: [PATCH 019/541] fixed inconsistent capitalisation of JAMES git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@504589 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/index.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index b0b2003416d..92f0829a14c 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -11,7 +11,7 @@ width="250" height="70">

      The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

      JAMES is organized into subprojects with JAMES Server and the Mailet API as their core.

      -

      Apache JAMEs is a project of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.

      +

      Apache JAMES is a project of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.

      The ASF maintains other Java projects which may also be of interest. These are detailed on the ASF Projects page.

      We recommended that users of JAMES products subscribe to the JAMES users mailing list.

      @@ -19,7 +19,7 @@ width="250" height="70">
      Read all the news in full in the News Archive
      Or click the titles to read the full story - Feb/2007 - Feathercast features James
      + Feb/2007 - Feathercast features JAMES
      Jan/2007 - Mailet API to become sub-project

       From 014b7cf03134425c4eee09654803d7b36cc907d3 Mon Sep 17 00:00:00 2001 From: norman Date: Sat, 10 Feb 2007 14:12:17 +0000 Subject: [PATCH 020/541] Add news for new jspf beta release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@505691 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/index.xml | 1 + src/site/xdoc/newsarchive.xml | 2 ++ 2 files changed, 3 insertions(+) diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index 92f0829a14c..7624b566c20 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -19,6 +19,7 @@ width="250" height="70">
    Read all the news in full in the News Archive
    Or click the titles to read the full story + Feb/2007 - jSPF-0.9b4 released
    Feb/2007 - Feathercast features JAMES
    Jan/2007 - Mailet API to become sub-project

    diff --git a/src/site/xdoc/newsarchive.xml b/src/site/xdoc/newsarchive.xml index cb8547ee58d..2fadbec47b7 100644 --- a/src/site/xdoc/newsarchive.xml +++ b/src/site/xdoc/newsarchive.xml @@ -10,6 +10,8 @@ style="border-width:0;" frameborder="0" scrolling="no" width="250" height="70">
    +

    Feb/2007 - jSPF-0.9b4 released

     +

    James PMC is proud to announce the availability of the forth beta of jspf 0.9. This version pass all tests in the last official release of the spf testsuite.

    Feb/2007 - Feathercast features James

    James PMC member and commiter Danny Angus was interviewed about James by David Reid for Feathercast episode 24. You can download the podcast from here.

    Jan/2007 - Mailet API to become a sub-project

     From 450080aff21c3314c50674d6b9f48ef357feecfb Mon Sep 17 00:00:00 2001 From: norman Date: Sat, 10 Feb 2007 14:14:55 +0000 Subject: [PATCH 021/541] Correct spelling git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@505693 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/newsarchive.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/xdoc/newsarchive.xml b/src/site/xdoc/newsarchive.xml index 2fadbec47b7..c239fc2673d 100644 --- a/src/site/xdoc/newsarchive.xml +++ b/src/site/xdoc/newsarchive.xml @@ -11,7 +11,7 @@ width="250" height="70">

    Feb/2007 - jSPF-0.9b4 released

     -

    James PMC is proud to announce the availability of the forth beta of jspf 0.9. This version pass all tests in the last official release of the spf testsuite.

    +

    James PMC is proud to announce the availability of the fourth beta of jspf 0.9. This version pass all tests in the last official release of the spf testsuite.

    Feb/2007 - Feathercast features James

    James PMC member and commiter Danny Angus was interviewed about James by David Reid for Feathercast episode 24. You can download the podcast from here.

    Jan/2007 - Mailet API to become a sub-project

     From c453b59783539e7f0b46a53a90df9056b10aa473 Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 31 Mar 2007 13:38:48 +0000 Subject: [PATCH 022/541] Fix broken url to mail archives git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@524424 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/mail.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/xdoc/mail.xml b/src/site/xdoc/mail.xml index 25bfc73fd3d..eaa61bf806e 100644 --- a/src/site/xdoc/mail.xml +++ b/src/site/xdoc/mail.xml @@ -144,7 +144,7 @@ provide searching for our mailing lists in HTML readable format.
    • Archives with many Jakarta lists:
      • - List + List Index on mail-archives.apache.org
      • From 23606aa70ce5c1797e5edbf711bd06b79e1f3633 Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 31 Mar 2007 13:39:39 +0000 Subject: [PATCH 023/541] Updated james m2 skin to include our google analytics (UA-1384591-1) tracking code. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@524425 13f79535-47bb-0310-9956-ffa450edef68 --- .../src/main/resources/META-INF/maven/site.vm | 340 ++++++++++++++++++ .../src/main/resources/css/maven-base.css | 148 ++++++++ maven-skin/src/main/resources/css/print.css | 7 + 3 files changed, 495 insertions(+) create mode 100644 maven-skin/src/main/resources/META-INF/maven/site.vm create mode 100644 maven-skin/src/main/resources/css/maven-base.css create mode 100644 maven-skin/src/main/resources/css/print.css diff --git a/maven-skin/src/main/resources/META-INF/maven/site.vm b/maven-skin/src/main/resources/META-INF/maven/site.vm new file mode 100644 index 00000000000..ce116cdc4da --- /dev/null +++ b/maven-skin/src/main/resources/META-INF/maven/site.vm @@ -0,0 +1,340 @@ + + +#macro ( banner $banner $id ) + #if ( $banner ) + #if( $banner.href ) + + #else + + #end + + #if( $banner.src ) + #set ( $src = $banner.src ) + #if ( ! ( $src.toLowerCase().startsWith("http") || $src.toLowerCase().startsWith("https") ) ) + #set ( $src = $PathTool.calculateLink( $src, $relativePath ) ) + #set ( $src = $src.replaceAll( "\\", "/" ) ) + #end + #if ( $banner.alt ) + #set ( $alt = $banner.alt ) + #else + #set ( $alt = "" ) + #end + $alt + #else + $banner.name + #end + + #if( $banner.href ) + + #else + + #end + #end +#end + +#macro ( links $links ) + #set ( $counter = 0 ) + #foreach( $item in $links ) + #set ( $counter = $counter + 1 ) + #set ( $currentItemHref = $PathTool.calculateLink( $item.href, $relativePath ) ) + #set ( $currentItemHref = $currentItemHref.replaceAll( "\\", "/" ) ) + $item.name + #if ( $links.size() > $counter ) + | + #end + #end +#end + +#macro ( breadcrumbs $breadcrumbs ) + #set ( $counter = 0 ) + #foreach( $item in $breadcrumbs ) + #set ( $counter = $counter + 1 ) + #set ( $currentItemHref = $PathTool.calculateLink( $item.href, $relativePath ) ) + #set ( $currentItemHref = $currentItemHref.replaceAll( "\\", "/" ) ) + + #if ( $currentItemHref == $alignedFileName || $currentItemHref == "" ) + $item.name + #else + $item.name + #end + #if ( $breadcrumbs.size() > $counter ) + > + #end + #end +#end + +#macro ( displayTree $display $item ) + #if ( $item && $item.items && $item.items.size() > 0 ) + #foreach( $subitem in $item.items ) + #set ( $subitemHref = $PathTool.calculateLink( $subitem.href, $relativePath ) ) + #set ( $subitemHref = $subitemHref.replaceAll( "\\", "/" ) ) + + #if ( $alignedFileName == $subitemHref ) + #set ( $display = true ) + #end + + #displayTree( $display $subitem ) + #end + #end +#end + +#macro ( menuItem $item ) + #set ( $collapse = "none" ) + #set ( $currentItemHref = $PathTool.calculateLink( $item.href, $relativePath ) ) + #set ( $currentItemHref = $currentItemHref.replaceAll( "\\", "/" ) ) + + #if ( $item && $item.items && $item.items.size() > 0 ) + #if ( $item.collapse == false ) + #set ( $collapse = "expanded" ) + #else + ## By default collapsed + #set ( $collapse = "collapsed" ) + #end + + #set ( $display = false ) + #displayTree( $display $item ) + + #if ( $alignedFileName == $currentItemHref || $display ) + #set ( $collapse = "expanded" ) + #end + #end +
      • + #if ( $item.img ) + #if ( ! ( $item.img.toLowerCase().startsWith("http") || $item.img.toLowerCase().startsWith("https") ) ) + #set ( $src = $PathTool.calculateLink( $item.img, $relativePath ) ) + #set ( $src = $item.img.replaceAll( "\\", "/" ) ) + + #else + + #end + #end + #if ( $alignedFileName == $currentItemHref ) + $item.name + #else + $item.name + #end + #if ( $item && $item.items && $item.items.size() > 0 ) + #if ( $collapse == "expanded" ) +
          + #foreach( $subitem in $item.items ) + #menuItem( $subitem ) + #end +
        + #end + #end +
        • +#end + +#macro ( mainMenu $menus ) + #foreach( $menu in $menus ) + #if ( $menu.name ) +
        $menu.name
        + #end +
          + #foreach( $item in $menu.items ) + #menuItem( $item ) + #end +
        + #end +#end + +#macro ( copyright ) + #if ( $project ) + #set ( $currentYear = ${currentDate.year} + 1900 ) + + #if ( ${project.inceptionYear} && ( ${project.inceptionYear} != ${currentYear.toString()} ) ) + ${project.inceptionYear}-${currentYear} + #else + ${currentYear} + #end + + #if ( ${project.organization} && ${project.organization.name} ) + ${project.organization.name} + #end + #end +#end + +#macro ( publishDate $position $publishDate $version ) + #if ( $publishDate && $publishDate.format ) + #set ( $format = $publishDate.format ) + #else + #set ( $format = "MM/dd/yyyy" ) + #end + + $dateFormat.applyPattern( $format ) + + #set ( $dateToday = $dateFormat.format( $currentDate ) ) + + #if ( $publishDate && $publishDate.position ) + #set ( $datePosition = $publishDate.position ) + #else + #set ( $datePosition = "left" ) + #end + + #if ( $version ) + #if ( $version.position ) + #set ( $versionPosition = $version.position ) + #else + #set ( $versionPosition = "left" ) + #end + #end + + #set ( $breadcrumbs = $decoration.body.breadcrumbs ) + + #if ( $datePosition.equalsIgnoreCase( $position ) ) + #if ( ( $datePosition.equalsIgnoreCase( "right" ) ) || ( $datePosition.equalsIgnoreCase( "bottom" ) ) ) +  | $i18n.getString( "site-renderer", $locale, "template.lastpublished" ): $dateToday + #if ( $versionPosition.equalsIgnoreCase( $position ) ) +  | $i18n.getString( "site-renderer", $locale, "template.version" ): ${project.version} + #end + #elseif ( ( $datePosition.equalsIgnoreCase( "navigation-bottom" ) ) || ( $datePosition.equalsIgnoreCase( "navigation-top" ) ) ) +
        + $i18n.getString( "site-renderer", $locale, "template.lastpublished" ): $dateToday + #if ( $versionPosition.equalsIgnoreCase( $position ) ) +  | $i18n.getString( "site-renderer", $locale, "template.version" ): ${project.version} + #end +
        + #elseif ( $datePosition.equalsIgnoreCase("left") ) +
        + $i18n.getString( "site-renderer", $locale, "template.lastpublished" ): $dateToday + #if ( $versionPosition.equalsIgnoreCase( $position ) ) +  | $i18n.getString( "site-renderer", $locale, "template.version" ): ${project.version} + #end + #if ( $breadcrumbs && $breadcrumbs.size() > 0 ) + | #breadcrumbs( $breadcrumbs ) + #end +
        + #end + #elseif ( $versionPosition.equalsIgnoreCase( $position ) ) + #if ( ( $versionPosition.equalsIgnoreCase( "right" ) ) || ( $versionPosition.equalsIgnoreCase( "bottom" ) ) ) +  | $i18n.getString( "site-renderer", $locale, "template.version" ): ${project.version} + #elseif ( ( $versionPosition.equalsIgnoreCase( "navigation-bottom" ) ) || ( $versionPosition.equalsIgnoreCase( "navigation-top" ) ) ) +
        + $i18n.getString( "site-renderer", $locale, "template.version" ): ${project.version} +
        + #elseif ( $versionPosition.equalsIgnoreCase("left") ) +
        + $i18n.getString( "site-renderer", $locale, "template.version" ): ${project.version} + #if ( $breadcrumbs && $breadcrumbs.size() > 0 ) + | #breadcrumbs( $breadcrumbs ) + #end +
        + #end + #elseif ( $position.equalsIgnoreCase( "left" ) ) + #if ( $breadcrumbs && $breadcrumbs.size() > 0 ) +
        + #breadcrumbs( $breadcrumbs ) +
        + #end + #end +#end + +#macro ( poweredByLogo $poweredBy ) + #if( $poweredBy ) + #foreach ($item in $poweredBy) + #if( $item.href ) + #set ( $href = $PathTool.calculateLink( $item.href, $relativePath ) ) + #set ( $href = $href.replaceAll( "\\", "/" ) ) + #else + #set ( $href="http://maven.apache.org/" ) + #end + + #if( $item.name ) + #set ( $name = $item.name ) + #else + #set ( $name = $i18n.getString( "site-renderer", $locale, "template.builtby" ) ) + #set ( $name = "${name} Maven" ) + #end + + #if( $item.img ) + #set ( $img = $item.img ) + #else + #set ( $img = "images/logos/maven-feather.png" ) + #end + + + #set ( $img = $PathTool.calculateLink( $img, $relativePath ) ) + #set ( $img = $img.replaceAll( "\\", "/" ) ) + $name + + #end + #if( $poweredBy.isEmpty() ) + + $i18n.getString( + + #end + #else + + $i18n.getString( + + #end +#end + + + + $title + + + #foreach( $author in $authors ) + + #end + + #if ( $decoration.body.head ) + #foreach( $item in $decoration.body.head.getChildren() ) + #if ( $item.name == "script" ) + $item.toUnescapedString() + #else + $item.toString() + #end + #end + #end + + + + +
        + +
        +
        +
        + $bodyContent +
        +
        +
        +
        +
        + + + + + diff --git a/maven-skin/src/main/resources/css/maven-base.css b/maven-skin/src/main/resources/css/maven-base.css new file mode 100644 index 00000000000..5fe1845a4d6 --- /dev/null +++ b/maven-skin/src/main/resources/css/maven-base.css @@ -0,0 +1,148 @@ +body { + margin: 0px; + padding: 0px; +} +img { + border:none; +} +table { + padding:0px; + width: 100%; + margin-left: -2px; + margin-right: -2px; +} +acronym { + cursor: help; + border-bottom: 1px dotted #feb; +} +table.bodyTable th, table.bodyTable td { + padding: 2px 4px 2px 4px; + vertical-align: top; +} +div.clear{ + clear:both; + visibility: hidden; +} +div.clear hr{ + display: none; +} +#bannerLeft, #bannerRight { + font-size: xx-large; + font-weight: bold; +} +#bannerLeft img, #bannerRight img { + margin: 0px; +} +.xleft, #bannerLeft img { + float:left; + text-shadow: #7CFC00; +} +.xright, #bannerRight img { + float:right; + text-shadow: #7CFC00; +} +#banner { + padding: 0px; +} +#banner img { + border: none; +} +#breadcrumbs { + padding: 3px 10px 3px 10px; +} +#leftColumn { + width: 170px; + float:left; + overflow: auto; +} +#bodyColumn { + margin-right: 1.5em; + margin-left: 197px; +} +#legend { + padding: 8px 0 8px 0; +} +#navcolumn { + padding: 8px 4px 0 8px; +} +#navcolumn h5 { + margin: 0; + padding: 0; + font-size: small; +} +#navcolumn ul { + margin: 0; + padding: 0; + font-size: small; +} +#navcolumn li { + list-style-type: none; + background-image: none; + background-repeat: no-repeat; + background-position: 0 0.4em; + padding-left: 16px; + list-style-position: outside; + line-height: 1.2em; + font-size: smaller; +} +#navcolumn li.expanded { + background-image: url(../images/expanded.gif); +} +#navcolumn li.collapsed { + background-image: url(../images/collapsed.gif); +} +#poweredBy { + text-align: center; +} +#navcolumn img { + margin-top: 10px; + margin-bottom: 3px; +} +#poweredBy img { + display:block; + margin: 20px 0 20px 17px; + border: 1px solid black; + width: 90px; + height: 30px; +} +#search img { + margin: 0px; + display: block; +} +#search #q, #search #btnG { + border: 1px solid #999; + margin-bottom:10px; +} +#search form { + margin: 0px; +} +#lastPublished { + font-size: x-small; +} +.navSection { + margin-bottom: 2px; + padding: 8px; +} +.navSectionHead { + font-weight: bold; + font-size: x-small; +} +.section { + padding: 4px; +} +#footer { + padding: 3px 10px 3px 10px; + font-size: x-small; +} +#breadcrumbs { + font-size: x-small; + margin: 0pt; +} +.source { + padding: 12px; + margin: 1em 7px 1em 7px; +} +.source pre { + margin: 0px; + padding: 0px; +} diff --git a/maven-skin/src/main/resources/css/print.css b/maven-skin/src/main/resources/css/print.css new file mode 100644 index 00000000000..26ad7f0b599 --- /dev/null +++ b/maven-skin/src/main/resources/css/print.css @@ -0,0 +1,7 @@ +#banner, #footer, #leftcol, #breadcrumbs, .docs #toc, .docs .courtesylinks, #leftColumn, #navColumn { + display: none !important; +} +#bodyColumn, body.docs div.docs { + margin: 0 !important; + border: none !important +} From cf43e0c0c55c6ce5ea4996fc0fba398732e74fcd Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 31 Mar 2007 13:41:01 +0000 Subject: [PATCH 024/541] Restored placement of ApacheCon banners git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@524426 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/index.xml | 10 ++++++---- src/site/xdoc/newsarchive.xml | 10 ++++++---- 2 files changed, 12 insertions(+), 8 deletions(-) diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index 7624b566c20..e0f7ffc29e5 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -5,11 +5,13 @@ JAMES Project Web Team -
        +
        +
        + +
        +
        -

        The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

        +

        The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

        JAMES is organized into subprojects with JAMES Server and the Mailet API as their core.

        Apache JAMES is a project of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.

        The ASF maintains other Java projects which may also be of interest. These are detailed on the ASF Projects page.

        diff --git a/src/site/xdoc/newsarchive.xml b/src/site/xdoc/newsarchive.xml index c239fc2673d..5d55063bd52 100644 --- a/src/site/xdoc/newsarchive.xml +++ b/src/site/xdoc/newsarchive.xml @@ -5,10 +5,12 @@ JAMES Project Web Team -
        -
        +
        +
        +
        + +
        +

        Feb/2007 - jSPF-0.9b4 released

        James PMC is proud to announce the availability of the fourth beta of jspf 0.9. This version pass all tests in the last official release of the spf testsuite.

        From 808d2b2f6118b3a3ae2edfb718302697652044a1 Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 31 Mar 2007 13:42:13 +0000 Subject: [PATCH 025/541] Fixed repositories location (remove m1 repository added by mistake). Fixed Hilmer name to use an xml entity. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@524427 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 43 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index d06daea9c30..bd8c28dd669 100644 --- a/pom.xml +++ b/pom.xml @@ -105,7 +105,7 @@ hilmer - S�ren Hilmer + Søren Hilmer sh at widetrail.dk @@ -170,6 +170,20 @@ + + + + never + + + false + + maven-central + maven-central + http://repo1.maven.org/maven2 + + + central @@ -182,6 +196,7 @@ true + apache.snapshots Apache Snapshot Repository @@ -213,5 +229,28 @@ http://mail-archives.apache.org/mod_mbox/james-site-dev/ - + \ No newline at end of file From bdfdc3a36e1ae79e6d7e4aa9baf5cb7b8be7f800 Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 31 Mar 2007 13:52:34 +0000 Subject: [PATCH 026/541] Fixed repositories location (remove m1 repository added by mistake). Fixed Hilmer name to use an xml entity. Changed Norman email to apache address. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@524429 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 2 +- src/site/xdoc/weare.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index bd8c28dd669..87567ddb3d3 100644 --- a/pom.xml +++ b/pom.xml @@ -70,7 +70,7 @@ norman Norman Maurer - nm at byteaction.de + norman at apache.org 2 Developer diff --git a/src/site/xdoc/weare.xml b/src/site/xdoc/weare.xml index cc6c5302cb6..d7a8abd97ea 100644 --- a/src/site/xdoc/weare.xml +++ b/src/site/xdoc/weare.xml @@ -56,7 +56,7 @@ Stefano Bagnara (apache at bago.org) [SB2]

        - Norman Maurer (nm at byteaction.de) [NM] + Norman Maurer (norman at apache.org) [NM]

        Bernd Fondermann (bf_jak at brainlounge.de) [BF] From b985f803012e827ddd7eb136e34cc5e7aa35f5df Mon Sep 17 00:00:00 2001 From: danny Date: Wed, 11 Apr 2007 12:02:25 +0000 Subject: [PATCH 027/541] JAMES-774 (added documentation) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@527464 13f79535-47bb-0310-9956-ffa450edef68 --- server/src/site/xdoc/FAQ.xml | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/server/src/site/xdoc/FAQ.xml b/server/src/site/xdoc/FAQ.xml index 5d1393b6ba8..91ef004ddfc 100644 --- a/server/src/site/xdoc/FAQ.xml +++ b/server/src/site/xdoc/FAQ.xml @@ -80,6 +80,9 @@

      • How do I use Subversion to get James source code?
        • +
      • + How can I control Sun's JVM DNS Lookup Configuration. +

    @@ -313,6 +316,15 @@ match as follows (in precedence order):
    James subversion repository is at http://svn.apache.org/repos/asf/james/server. Commiters use "https".
    You may want to search the web, our dev and user mail archives or our wiki for more information.

    + + +

    Sun's JVM Internet address lookup uses a cache which is unbounded and doesn't time out.
    +This is obviously not great for a long running process like a mail server so we have introduced a system property networkaddress.cache.ttl that is used by the distributed phoenix start-up scripts, at startup, to override the java 1.4 Security.setProperty("networkaddress.cache.ttl").
    By default this is set to 300 seconds.

    +

    This workaround will only be present if you use James as distributed. If you use James in any other container, including different versions of Phoenix, you will need to ensure that you make a similar configuration change to allow the internet address cache to perform acceptably.

    +

    James 2.3 has this workaround and it requires it to operate acceptably. Future versions of James will continue to have the workaround in place but will *not* require it. This will provide continued support for any mailets which you may deploy from other sources which might continue to use Sun's InetAddress class for DNS resolution.

    +

    We are not currently aware of the behaviour of this cache in other JVM implementations, nor of the effect, if any, which this change might have on them

    +

    For more on this read defect report JAMES-592 and related defects.

    +
    From 5eebd9f2cd843adc8454f4437ef331715c9ffb98 Mon Sep 17 00:00:00 2001 From: berndf Date: Tue, 17 Apr 2007 20:00:34 +0000 Subject: [PATCH 028/541] add guidlines and related news item to website git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@529745 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO.txt | 9 ++ src/site/site.xml | 20 +-- src/site/xdoc/guidelines.xml | 239 ++++++++++++++++++++++++++++++++++ src/site/xdoc/index.xml | 1 + src/site/xdoc/newsarchive.xml | 2 + 5 files changed, 252 insertions(+), 19 deletions(-) create mode 100644 HOWTO.txt create mode 100644 src/site/xdoc/guidelines.xml diff --git a/HOWTO.txt b/HOWTO.txt new file mode 100644 index 00000000000..f2f447d6433 --- /dev/null +++ b/HOWTO.txt @@ -0,0 +1,9 @@ +How to build and publish the website: + +1. Install Apache Maven 2 and make its binary 'mvn' available on your PATH. +2. Execute 'mvn site' +3. Test the built site in your browser from target/site +4. If everything looks OK, copy target/site to the site/server subfolder +5. Commit changes to SVN +6. svn-up on minotaur +7. Wait for the changes to replicate to the Apache web server diff --git a/src/site/site.xml b/src/site/site.xml index 557d9da1f27..970c3e5303f 100644 --- a/src/site/site.xml +++ b/src/site/site.xml @@ -38,25 +38,6 @@ - - @@ -78,6 +59,7 @@ + diff --git a/src/site/xdoc/guidelines.xml b/src/site/xdoc/guidelines.xml new file mode 100644 index 00000000000..099ab468256 --- /dev/null +++ b/src/site/xdoc/guidelines.xml @@ -0,0 +1,239 @@ + + + + + Apache JAMES Project Guidelines + James Project Web Team + + +
    + +

    + This document defines the guidelines for the Apache JAMES Project. It includes definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the Apache JAMES products. + +

    +

    + The objective here is to avoid unnecessary conflict over changes and continue to produce a quality system in a timely manner. Not all conflict can be avoided, but at least we can agree on the procedures for conflict to be resolved. + +

    +
    +
    + + +

    + The group of volunteers who are responsible for managing the Apache JAMES Project. This includes deciding what is distributed as products of the Apache JAMES Project, maintaining the Project's shared resources, speaking on behalf of the Project, resolving license disputes regarding Apache JAMES products, nominating new PMC members or committers, and establishing these guidelines. + +

    +

    + Membership in the Apache JAMES PMC is by invitation only and must be approved by consensus of the active Apache JAMES PMC members. A PMC member is considered inactive by their own declaration or by not contributing in any form to the project for over six months. An inactive member can become active again by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the project's work). Membership can be revoked by a unanimous vote of all the active PMC members other than the member in question. + +

    +     + +

    + The group of volunteers who are responsible for the technical aspects of the Apache JAMES Project. This group has write access to the appropriate source repositories and these volunteers may cast non-binding votes on any technical discussion. +

    +

    + Membership as a Committer is by invitation only and must be approved by consensus of the active Apache JAMES PMC members. A Committer is considered inactive by their own declaration or by not contributing in any form to the project for over six months. An inactive member can become active again by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the project's work). Membership can be revoked by a unanimous vote of all the active PMC members (except the member in question if they are a PMC member). + +

    +     + +

    + The Apache committers' primary mailing list for discussion of issues and changes related to the project (server-dev@james.apache.org). Subscription to the list is open, but only subscribers can post directly to the list. + +

    +     + +

    + The Apache JAMES Project's private mailing list for discussion of issues that are inappropriate for public discussion, such as legal, personal, or security issues prior to a published fix. Subscription to the list is only open to Apache JAMES PMC members and Apache Software Foundation Members. + +

    +     + +

    + All of the Apache JAMES products are maintained in shared information repositories using SVN on svn.apache.org. The Apache committers have write access to these repositories; everyone has read access via anonymous SVN. + +

    +     +
    +
    + +

    + Each of the Apache Project's active source code repositories contain a file called "STATUS" which is used to keep track of the agenda and plans for work within that repository. The STATUS file includes information about release plans, a summary of code changes committed since the last release, a list of proposed changes that are under discussion, brief notes about items that individual committers are working on or want discussion about, and anything else that might be useful to help the group track progress. The active STATUS files are automatically posted to the mailing list each week. + +

    +

    + Many issues will be encountered by the project, each resulting in zero or more proposed action items. Issues should be raised on the mailing list as soon as they are identified. Action items must be raised on the mailing list and added to the relevant STATUS file. All action items may be voted on, but not all of them will require a formal vote. + +

    +
    +
    + +

    + Any of the Apache JAMES Committers may vote on any issue or action item. However, the only binding votes are those cast by active members of the Apache James PMC; if the vote is about a change to source code or documentation, the primary author of what is being changed may also cast a binding vote on that issue. All other votes are non-binding. All committers are encouraged to participate in decisions, but the decision itself is made by those who have been long-time contributors to the project. In other words, the Apache Project is a minimum-threshold meritocracy. + +

    +

    + The act of voting carries certain obligations -- voting members are not only stating their opinion, they are agreeing to help do the work of the Apache Project. Since we are all volunteers, members often become inactive for periods of time in order to take care of their "real jobs" or devote more time to other projects. It is therefore unlikely that the entire group membership will vote on every issue. To account for this, all voting decisions are based on a minimum quorum. + +

    +

    + Each vote can be made in one of three flavors: +

    +

    + +1
    + Yes, agree, or the action should be performed. On some issues, this vote is only binding if the voter has tested the action on their own system(s). +

    +

    + +-0
    + Abstain, no opinion, or I am happy to let the other group members decide this issue. An abstention may have detrimental effects if too many people abstain. +

    +

    + -1
    + No. On issues where consensus is required, this vote counts as a veto. All vetos must include an explanation of why the veto is appropriate. A veto with no explanation is void. No veto can be overruled. If you disagree with the veto, you should lobby the person who cast the veto. Voters intending to veto an action item should make their opinions known to the group immediately, so that the problem can be remedied as early as possible. + +

    +

    + An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetos. An action item requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes (i.e., a majority with a minimum quorum of three positive votes). All other action items are considered to have lazy approval until someone votes -1, after which point they are decided by either consensus or a majority vote, depending upon the type of action item. + +

    +

    + Votes are tallied within the STATUS file, adjacent to the action item under vote. All votes must be either sent to the mailing list or added directly to the STATUS file entry for that action item. +

    + +

    + Votes are to remain open for 72 hours after which the developer who put forth the vote should tabulate the result and send this to the mailing list. A developer should be sensitive to holidays that could dampen participation in the vote. +

    + +
    +
    + + +

    + Long term plans are simply announcements that group members are working on particular issues related to the Apache software. These are not voted on, but group members who do not agree with a particular plan, or think an alternate plan would be better, are obligated to inform the group of their feelings. In general, it is always better to hear about alternate plans prior to spending time on less adequate solutions. +

    +     + +

    + Short term plans are announcements that a developer is working on a particular set of documentation or code files, with the implication that other committers should avoid them or try to coordinate their changes. This is a good way to proactively avoid conflict and possible duplication of work. +

    +     + +

    + A release plan is used to keep all the committers aware of when a release is desired, who will be the release manager, when the repository will be frozen in order to create the release, and assorted other trivia to keep us from tripping over ourselves during the final moments. Lazy majority decides each issue in the release plan. +

    +     + +

    + After a new release is built, colloquially termed a tarball, it must be tested before being released to the public. Majority approval is required before the tarball can be publically released. +

    +     + +

    + Showstoppers are issues that require a fix be in place before the next public release. They are listed in the STATUS file in order to focus special attention on the problem. An issue becomes a showstopper when it is listed as such in STATUS and remains so by lazy consensus. +

    +     + +

    + Changes to the Apache JAMES products, including code and documentation, will appear as action items under several categories corresponding to the change status: + +

    +     + +

    + An idea or plan for a change. These are usually only listed in STATUS when the change is substantial, significantly impacts the API, or is likely to be controversial. Votes are being requested early so as to uncover conflicts before too much work is done. +

    +     + +

    + A specific set of changes to the current product in the form of input to the patch command (a diff output). +

    +     + +

    + A one-line summary of a change that has been committed to the repository since the last public release. +

    +

    + + All product changes to the currently active repository are subject to lazy consensus. All product changes to a prior-branch (old version) repository require consensus before the change is committed. +

    + +     +
    +
    + +

    + Ideas must be review-then-commit; patches can be commit-then-review. With a commit-then-review process, we trust that the developer doing the commit has a high degree of confidence in the change. Doubtful changes, new features, and large-scale overhauls need to be discussed before being committed to a repository. Any change that affects the semantics of arguments to configurable directives, significantly adds to the runtime size of the program, or changes the semantics of an existing API function must receive consensus approval on the mailing list before being committed. + +

    +

    + Each developer is responsible for notifying the mailing list and adding an action item to STATUS when they have an idea for a new feature or major change to propose for the product. The distributed nature of the Apache project requires an advance notice of 48 hours in order to properly review a major change -- consensus approval of either the concept or a specific patch is required before the change can be committed. Note that a member might veto the concept (with an adequate explanation), but later rescind that veto if a specific patch satisfies their objections. No advance notice is required to commit singular bug fixes. + +

    +

    + Related changes should be committed as a group, or very closely together. Half-completed projects should not be committed unless doing so is necessary to pass the baton to another developer who has agreed to complete the project in short order. All code changes must be successfully compiled on the developer's platform before being committed. + +

    +

    + The current source code tree should be capable of complete compilation at all times. However, it is sometimes impossible for a developer on one platform to avoid breaking some other platform when a change is committed, particularly when completing the change requires access to a special development tool on that other platform. If it is anticipated that a given change will break some other platform, the committer must indicate that in the commit log. + +

    +

    + The committer is responsible for the quality of any third-party code or documentation they commit to the repository. All software committed to the repository must be covered by the Apache LICENSE or contain a copyright and license that allows redistribution under the same conditions as the Apache LICENSE. + +

    +

    + A committed change must be reversed if it is vetoed by one of the voting members and the veto conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The veto must be rescinded before the change can be included in any public release. + +

    +
    +
    + +

    + When a specific change to the software is proposed for discussion or voting on the mailing list, it should be presented in the form of input to the patch command. When sent to the mailing list, the message should contain a Subject beginning with [PATCH] and a distinctive one-line summary corresponding to the action item for that patch. Afterwords, the patch summary in the STATUS file should be updated to point to the Message-ID of that message. + +

    +

    + The patch should be created by using the diff -u command from the original software file(s) to the modified software file(s). E.g., +

    +

    + + diff -u James.java.orig James.java >> patchfile.txt + +

    +

    + All patches necessary to address an action item should be concatenated within a single patch message. If later modification of the patch proves necessary, the entire new patch should be posted and not just the difference between two patches. The STATUS file entry should then be updated to point to the new patch message. + +

    +

    + The completed patchfile should produce no errors or prompts when the command, +

    +

    + + patch -s < patchfile +

    +

    + + is issued in the target repository. +

    +
    + +     diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index e0f7ffc29e5..050b91194e0 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -21,6 +21,7 @@ Read all the news in full in the News Archive
    Or click the titles to read the full story + Apr/2007 - Apache JAMES Project Guidelines published
    Feb/2007 - jSPF-0.9b4 released
    Feb/2007 - Feathercast features JAMES
    Jan/2007 - Mailet API to become sub-project
    diff --git a/src/site/xdoc/newsarchive.xml b/src/site/xdoc/newsarchive.xml index 5d55063bd52..884ebeb448a 100644 --- a/src/site/xdoc/newsarchive.xml +++ b/src/site/xdoc/newsarchive.xml @@ -12,6 +12,8 @@ +

    Apr/2007 - Apache JAMES Project Guidelines published

     +

    The James PMC has approved - for the first time - a set of guidelines for the project. These guidelines are intended to reflect and summarize well-known practices in our community. They include "... definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the Apache JAMES products."

    Feb/2007 - jSPF-0.9b4 released

    James PMC is proud to announce the availability of the fourth beta of jspf 0.9. This version pass all tests in the last official release of the spf testsuite.

    Feb/2007 - Feathercast features James

     From e38baf8accba01f0ae902bb0f2165772f8a3f6a8 Mon Sep 17 00:00:00 2001 From: bago Date: Tue, 17 Apr 2007 21:42:59 +0000 Subject: [PATCH 029/541] Add few steps to HOWTO for website generation git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@529778 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO.txt | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/HOWTO.txt b/HOWTO.txt index f2f447d6433..62eab5227e2 100644 --- a/HOWTO.txt +++ b/HOWTO.txt @@ -3,7 +3,9 @@ How to build and publish the website: 1. Install Apache Maven 2 and make its binary 'mvn' available on your PATH. 2. Execute 'mvn site' 3. Test the built site in your browser from target/site -4. If everything looks OK, copy target/site to the site/server subfolder -5. Commit changes to SVN -6. svn-up on minotaur -7. Wait for the changes to replicate to the Apache web server +4. If everything looks OK, copy target/site to the checkout of james/site/trunk/www folder +5. If you are on windows make sure endlines are LF only. +6. Commit changes to SVN +7. Review generated pages on svn.apache.org/repos/asf/james/site/trunk/www +8. svn-up on minotaur +9. Wait for the changes to replicate to the Apache web server From 316236c4b62d18719bf2d5126390d52fb57fb172 Mon Sep 17 00:00:00 2001 From: bago Date: Tue, 17 Apr 2007 21:43:39 +0000 Subject: [PATCH 030/541] Fix xml syntax error from last FAQ entry. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@529780 13f79535-47bb-0310-9956-ffa450edef68 --- server/src/site/xdoc/FAQ.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/server/src/site/xdoc/FAQ.xml b/server/src/site/xdoc/FAQ.xml index 91ef004ddfc..0a5e0edac11 100644 --- a/server/src/site/xdoc/FAQ.xml +++ b/server/src/site/xdoc/FAQ.xml @@ -319,7 +319,7 @@ match as follows (in precedence order):

    Sun's JVM Internet address lookup uses a cache which is unbounded and doesn't time out.
    -This is obviously not great for a long running process like a mail server so we have introduced a system property networkaddress.cache.ttl that is used by the distributed phoenix start-up scripts, at startup, to override the java 1.4 Security.setProperty("networkaddress.cache.ttl").
    By default this is set to 300 seconds.

    +This is obviously not great for a long running process like a mail server so we have introduced a system property networkaddress.cache.ttl that is used by the distributed phoenix start-up scripts, at startup, to override the java 1.4 Security.setProperty("networkaddress.cache.ttl").
    By default this is set to 300 seconds.

    This workaround will only be present if you use James as distributed. If you use James in any other container, including different versions of Phoenix, you will need to ensure that you make a similar configuration change to allow the internet address cache to perform acceptably.

    James 2.3 has this workaround and it requires it to operate acceptably. Future versions of James will continue to have the workaround in place but will *not* require it. This will provide continued support for any mailets which you may deploy from other sources which might continue to use Sun's InetAddress class for DNS resolution.

    We are not currently aware of the behaviour of this cache in other JVM implementations, nor of the effect, if any, which this change might have on them

    From f33c3f59f2ac898b8d121b85d8c682269de5d9d0 Mon Sep 17 00:00:00 2001 From: norman Date: Thu, 19 Apr 2007 09:20:28 +0000 Subject: [PATCH 031/541] Update site for james 2.3.1rc1 release. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@530346 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/index.xml | 1 + src/site/xdoc/newsarchive.xml | 2 ++ 2 files changed, 3 insertions(+) diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index 050b91194e0..c1fc8a1318a 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -21,6 +21,7 @@ Read all the news in full in the     News Archive
    Or click the titles to read the full story + Apr/2007 - JAMES Server 2.3.1 RC1 Released
    Apr/2007 - Apache JAMES Project Guidelines published
    Feb/2007 - jSPF-0.9b4 released
    Feb/2007 - Feathercast features JAMES
    diff --git a/src/site/xdoc/newsarchive.xml b/src/site/xdoc/newsarchive.xml index 884ebeb448a..e512a9b3ed4 100644 --- a/src/site/xdoc/newsarchive.xml +++ b/src/site/xdoc/newsarchive.xml @@ -12,6 +12,8 @@ +

    Feb/2007 - JAMES Server 2.3.1 RC1 released

     +

    James PMC is proud to announce the availability of the frist release canidat of JAMES Server 2.3.1. This release is maintenance release. See the changelog for more detail.

    Apr/2007 - Apache JAMES Project Guidelines published

    The James PMC has approved - for the first time - a set of guidelines for the project. These guidelines are intended to reflect and summarize well-known practices in our community. They include "... definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the Apache JAMES products."

    Feb/2007 - jSPF-0.9b4 released

     From c9414a0b31a58399d0d7e634fc445fc44fb61b7c Mon Sep 17 00:00:00 2001 From: norman Date: Thu, 19 Apr 2007 10:21:28 +0000 Subject: [PATCH 032/541] Fix wrong month git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@530360 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/newsarchive.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/site/xdoc/newsarchive.xml b/src/site/xdoc/newsarchive.xml index e512a9b3ed4..ac94c318a44 100644 --- a/src/site/xdoc/newsarchive.xml +++ b/src/site/xdoc/newsarchive.xml @@ -12,7 +12,7 @@ -

    Feb/2007 - JAMES Server 2.3.1 RC1 released

     +

    Apr/2007 - JAMES Server 2.3.1 RC1 released

    James PMC is proud to announce the availability of the frist release canidat of JAMES Server 2.3.1. This release is maintenance release. See the changelog for more detail.

    Apr/2007 - Apache JAMES Project Guidelines published

    The James PMC has approved - for the first time - a set of guidelines for the project. These guidelines are intended to reflect and summarize well-known practices in our community. They include "... definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the Apache JAMES products."

    From f226e9a26f2dfb2151fc9a0fcf8b6e37bf371502 Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 19 Apr 2007 11:56:58 +0000 Subject: [PATCH 033/541] Introduced a download page for unstable VOTED releases (RC/Betas). Removed the "Test Builds" link as we are always voting for releases and test builds should be only referenced on dev mailing list (by ASF policy). Added 2.3.1 documentation link (so we can start publishing the 2.3.1 docs). Small refactoring to the download page. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@530388 13f79535-47bb-0310-9956-ffa450edef68 --- server/src/site/site.xml | 4 + src/site/resources/downloadunstable.cgi | 6 + src/site/site.xml | 2 +- src/site/xdoc/download.xml | 31 ++-- src/site/xdoc/downloadunstable.xml | 210 ++++++++++++++++++++++++ 5 files changed, 240 insertions(+), 13 deletions(-) create mode 100644 src/site/resources/downloadunstable.cgi create mode 100644 src/site/xdoc/downloadunstable.xml diff --git a/server/src/site/site.xml b/server/src/site/site.xml index 4f9ecbe8be5..26da0b51358 100644 --- a/server/src/site/site.xml +++ b/server/src/site/site.xml @@ -44,7 +44,11 @@ + + diff --git a/src/site/resources/downloadunstable.cgi b/src/site/resources/downloadunstable.cgi new file mode 100644 index 00000000000..b8652e2635f --- /dev/null +++ b/src/site/resources/downloadunstable.cgi @@ -0,0 +1,6 @@ +#!/bin/sh +# Wrapper script around mirrors.cgi script +# (we must change to that directory in order for python to pick up the +# python includes correctly) +cd /www/www.apache.org/dyn/mirrors +/www/www.apache.org/dyn/mirrors/mirrors.cgi $* diff --git a/src/site/site.xml b/src/site/site.xml index 970c3e5303f..42c75c5f558 100644 --- a/src/site/site.xml +++ b/src/site/site.xml @@ -69,7 +69,7 @@ - + diff --git a/src/site/xdoc/download.xml b/src/site/xdoc/download.xml index 2fc16df8ace..6ba2406e66a 100644 --- a/src/site/xdoc/download.xml +++ b/src/site/xdoc/download.xml @@ -23,6 +23,7 @@ Download +

    Use the links below to download the Apache James Mail Server from one of @@ -35,7 +36,9 @@ distribution site and its mirrors. Older releases are available from the archive download site.

    -
    +
    + +

    [if-any logo] [end] @@ -62,7 +65,7 @@ Other mirrors: +[if-any http] + [for http][end] +[end] +[if-any ftp] + [for ftp][end] +[end] +[if-any backup] + [for backup][end] +[end] + + + + +

    You may also consult the complete +list of mirrors.

    + +     + +
    + +

    This release has many enhancements and bug fixes over the previous +release. See the Change Log +for a detailed list of changes.

    + + + +
    + +
    + + + +
    + + + +

    It is essential that you verify the integrity of the downloaded +files using the PGP or MD5 signatures.

    + +

    The PGP signatures can be verified using PGP or GPG. First +download the KEYS +as well as the asc signature file for the particular +distribution. Make sure you get these files from the main distribution +directory, rather than from a mirror. Then verify the signatures +using

    + +

    +% pgpk -a KEYS
    +% pgpv james-version.tar.gz.asc
    +     +or
    + +% pgp -ka KEYS
    +% pgp james-version.tar.gz.asc
    +     +or
    + +% gpg --import KEYS
    +% gpg --verify james-version.tar.gz.asc +

    + +     + +
    + +

    The software listed above represents the latest unstable builds +available from the Apache JAMES Project. +You can download Stable Releases here. +Unstable releases are announced on the General mailing list (general@james.apache.org). + +

    +

    + +

    The JAMES project also provides +Nighly Builds: +periodic snapshots during development. Generally, these are considered +stable snapshots, but they have not undergone as much testing as a +Release Build, nor have they been voted upon for release by the +developer community. These are simply convenient test builds. +Sometimes the purpose for a Nightly Build could be soliciting feedback on +a specific change. +

    + + +
    + + + From 8a8b7d44be6dedb46723b91eedfd010defc141e2 Mon Sep 17 00:00:00 2001 From: bago Date: Wed, 25 Apr 2007 15:07:25 +0000 Subject: [PATCH 034/541] Add an "hack" to out custom skin's site.vm so that every download* page will have an additional javascript to add google analytics tracking to file downloads. Downloads *clicks* will now be tracked as if they where pages placed in the /downloads/ folder. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@532380 13f79535-47bb-0310-9956-ffa450edef68 --- .../src/main/resources/META-INF/maven/site.vm | 55 +++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/maven-skin/src/main/resources/META-INF/maven/site.vm b/maven-skin/src/main/resources/META-INF/maven/site.vm index ce116cdc4da..e73f19c97df 100644 --- a/maven-skin/src/main/resources/META-INF/maven/site.vm +++ b/maven-skin/src/main/resources/META-INF/maven/site.vm @@ -336,5 +336,60 @@ _uacct = "UA-1384591-1"; urchinTracker(); + #if ( $currentFileName.toLowerCase().startsWith("download") ) + + #end From 23d1de774be18dfadab7713ce78463ac535ce49d Mon Sep 17 00:00:00 2001 From: bago Date: Wed, 25 Apr 2007 15:10:31 +0000 Subject: [PATCH 035/541] Minor fix: removed spaces behind velocity directives git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@532382 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/src/main/resources/META-INF/maven/site.vm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/maven-skin/src/main/resources/META-INF/maven/site.vm b/maven-skin/src/main/resources/META-INF/maven/site.vm index e73f19c97df..ce39af748f2 100644 --- a/maven-skin/src/main/resources/META-INF/maven/site.vm +++ b/maven-skin/src/main/resources/META-INF/maven/site.vm @@ -336,7 +336,7 @@ _uacct = "UA-1384591-1"; urchinTracker(); - #if ( $currentFileName.toLowerCase().startsWith("download") ) +#if ( $currentFileName.toLowerCase().startsWith("download") ) - #end +#end From 573553f13900e9d4a679b7fd0f8d3fabda68d0d4 Mon Sep 17 00:00:00 2001 From: bago Date: Wed, 25 Apr 2007 19:24:54 +0000 Subject: [PATCH 036/541] The mirror choosing script replaces any simple word in square bracket and was breaking the new javascript. Added a "0+" in front of each index in square bracket. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@532445 13f79535-47bb-0310-9956-ffa450edef68 --- .../src/main/resources/META-INF/maven/site.vm | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/maven-skin/src/main/resources/META-INF/maven/site.vm b/maven-skin/src/main/resources/META-INF/maven/site.vm index ce39af748f2..7f09167e47a 100644 --- a/maven-skin/src/main/resources/META-INF/maven/site.vm +++ b/maven-skin/src/main/resources/META-INF/maven/site.vm @@ -342,15 +342,17 @@ var hrefs = document.getElementsByTagName('a'); var extensions = ["gz","bz2","zip","jar","asc","sar"]; for (var l = 0; l < hrefs.length; l++) { - if (hrefs[l] != "") { - var path = hrefs[l].pathname; - var external = hrefs[l].hostname != location.host; + // 0+ is a workaround for download.cgi script by ASF that + // is not happy with simple words in square brackets + if (hrefs[0+l] != "") { + var path = hrefs[0+l].pathname; + var external = hrefs[0+l].hostname != location.host; if (external) { var splitted = path.split('.'); - var ext = splitted[splitted.length-1]; + var ext = splitted[0+splitted.length-1]; for (var e = 0; e < extensions.length; e++) { - if (extensions[e] == ext) { - startListening(hrefs[l],"click",trackDownloads); + if (extensions[0+e] == ext) { + startListening(hrefs[0+l],"click",trackDownloads); } } } From e79787eb6e19d5391b915ad82b5816cdfa9fd4d2 Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 26 Apr 2007 23:19:32 +0000 Subject: [PATCH 037/541] Changed the main james-project pom.xml to always try to include NOTICE.txt and LICENSE.txt into the META-INF of the generated artifacts. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@532906 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 109 +++++++++++++++++++++++++++++++++----------------------- 1 file changed, 65 insertions(+), 44 deletions(-) diff --git a/pom.xml b/pom.xml index 87567ddb3d3..d89ea8eaddc 100644 --- a/pom.xml +++ b/pom.xml @@ -1,23 +1,23 @@ - - + + 4.0.0 org.apache.james james-project @@ -61,7 +61,7 @@ bago Stefano Bagnara - apache at bago.org + bago at apache.org 2 Developer @@ -80,7 +80,7 @@ serge Serge Knystautas sergek at lokitech.com - + Developer @@ -89,7 +89,7 @@ benrdf Bernd Fondermann bf_jak at brainlounge.de - + Developer @@ -98,16 +98,18 @@ sbrewin Steve Brewin sbrewin at synsys.com - + Developer hilmer - Søren Hilmer + + + Soren Hilmer sh at widetrail.dk - + Developer @@ -116,7 +118,7 @@ noel Noel J. Bergman noel at devtech.com - + Developer @@ -125,7 +127,7 @@ danny Danny Angus danny at apache.org - + Developer @@ -133,13 +135,26 @@ adc Alan D. Cabrera + list at toolazydogs.com -8 + + Developer + + + + vincenzo + Vincenzo Gianferrari Pini + vincenzo.gianferraripini at praxis.it + + + Developer + rdonkin Robert Burrell Donkin rdonkin at apache.org - + Developer @@ -196,20 +211,6 @@ true - apache.snapshots Apache Snapshot Repository @@ -229,7 +230,26 @@ http://mail-archives.apache.org/mod_mbox/james-site-dev/ - + + ${basedir} + + NOTICE.txt + LICENSE.txt + + META-INF + + + + + + + --> + \ No newline at end of file From c93e6cea1fb80fccc7a438349e50d2626b329e56 Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 28 Apr 2007 14:12:04 +0000 Subject: [PATCH 038/541] Introduced a further "parent" as a common parent for james-project and maven-skin. As we use maven-skin as the skin for james-project then james-project could not be the parent for maven-skin, so I had to add one more pom. Added a "local" profile to disable remote repositories at all for dependencies resolution. Added a first attempt of a "release" profile to automatically gpg sign artifacts. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@533346 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO.txt | 34 +++- maven-skin/LICENSE.txt | 177 +++++++++++++++++++ maven-skin/NOTICE.txt | 9 + maven-skin/pom.xml | 21 +-- parent/pom.xml | 361 +++++++++++++++++++++++++++++++++++++++ parent/src/site/site.xml | 45 +++++ pom.xml | 218 ++--------------------- 7 files changed, 636 insertions(+), 229 deletions(-) create mode 100644 maven-skin/LICENSE.txt create mode 100644 maven-skin/NOTICE.txt create mode 100644 parent/pom.xml create mode 100644 parent/src/site/site.xml diff --git a/HOWTO.txt b/HOWTO.txt index 62eab5227e2..1ff68563e16 100644 --- a/HOWTO.txt +++ b/HOWTO.txt @@ -1,11 +1,27 @@ How to build and publish the website: -1. Install Apache Maven 2 and make its binary 'mvn' available on your PATH. -2. Execute 'mvn site' -3. Test the built site in your browser from target/site -4. If everything looks OK, copy target/site to the checkout of james/site/trunk/www folder -5. If you are on windows make sure endlines are LF only. -6. Commit changes to SVN -7. Review generated pages on svn.apache.org/repos/asf/james/site/trunk/www -8. svn-up on minotaur -9. Wait for the changes to replicate to the Apache web server + 1. Install Apache Maven 2.0.6 and make its binary 'mvn' available on your PATH. + 2. Execute 'mvn -Plocal install'. This will generate the artifacts and install them without + trying to remove them from remote repositories ("local" profile). + 3. Execute 'mvn -Plocal site'. This will generate the website for each module. + 4. Test the built site in your browser from target/site + 5. If everything looks OK, copy target/site to the checkout of james/site/trunk/www folder + server/target/site to the checkout of james/site/trunk/www/server folder + server/2.2.0/target/site to the checkout of james/site/trunk/www/server/2.2.0 folder + 6. If you are on windows make sure endlines are LF only. + 7. Commit changes to SVN + 8. Review generated pages on svn.apache.org/repos/asf/james/site/trunk/www + 9. svn-up on minotaur +10. Wait for the changes to replicate to the Apache web server or setup 140.211.11.10:80 as + a proxy to review the changes (described here: http://www.apache.org/dev/project-site.html) + +The logical tree of the poms is the following + +james-parent (parent/pom.xml) is the main parent. +|- maven-skin (maven-skin/pom.xml) is our skin +'- james-project (pom.xml) + '- james-server-root (server/pom.xml) is the parent pom for JAMES server. + '- james-server-2.2.0 (server/2.2.0/pom.xml) is the static website for old 2.2.0 documentation. + +The "james-parent" artifact is needed because "james-project" uses the maven-skin but they needed +to share some common data so they cannot depend on each-other but on a third "parent" pom. diff --git a/maven-skin/LICENSE.txt b/maven-skin/LICENSE.txt new file mode 100644 index 00000000000..ade750b16ba --- /dev/null +++ b/maven-skin/LICENSE.txt @@ -0,0 +1,177 @@ + + Apache License + Version 2.0, January 2004 + http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the Work, but + excluding communication that is conspicuously marked or otherwise + designated in writing by the copyright owner as "Not a Contribution." + + "Contributor" shall mean Licensor and any individual or Legal Entity + on behalf of whom a Contribution has been received by Licensor and + subsequently incorporated within the Work. + + 2. Grant of Copyright License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + copyright license to reproduce, prepare Derivative Works of, + publicly display, publicly perform, sublicense, and distribute the + Work and such Derivative Works in Source or Object form. + + 3. Grant of Patent License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + (except as stated in this section) patent license to make, have made, + use, offer to sell, sell, import, and otherwise transfer the Work, + where such license applies only to those patent claims licensable + by such Contributor that are necessarily infringed by their + Contribution(s) alone or by combination of their Contribution(s) + with the Work to which such Contribution(s) was submitted. If You + institute patent litigation against any entity (including a + cross-claim or counterclaim in a lawsuit) alleging that the Work + or a Contribution incorporated within the Work constitutes direct + or contributory patent infringement, then any patent licenses + granted to You under this License for that Work shall terminate + as of the date such litigation is filed. + + 4. Redistribution. You may reproduce and distribute copies of the + Work or Derivative Works thereof in any medium, with or without + modifications, and in Source or Object form, provided that You + meet the following conditions: + + (a) You must give any other recipients of the Work or + Derivative Works a copy of this License; and + + (b) You must cause any modified files to carry prominent notices + stating that You changed the files; and + + (c) You must retain, in the Source form of any Derivative Works + that You distribute, all copyright, patent, trademark, and + attribution notices from the Source form of the Work, + excluding those notices that do not pertain to any part of + the Derivative Works; and + + (d) If the Work includes a "NOTICE" text file as part of its + distribution, then any Derivative Works that You distribute must + include a readable copy of the attribution notices contained + within such NOTICE file, excluding those notices that do not + pertain to any part of the Derivative Works, in at least one + of the following places: within a NOTICE text file distributed + as part of the Derivative Works; within the Source form or + documentation, if provided along with the Derivative Works; or, + within a display generated by the Derivative Works, if and + wherever such third-party notices normally appear. The contents + of the NOTICE file are for informational purposes only and + do not modify the License. You may add Your own attribution + notices within Derivative Works that You distribute, alongside + or as an addendum to the NOTICE text from the Work, provided + that such additional attribution notices cannot be construed + as modifying the License. + + You may add Your own copyright statement to Your modifications and + may provide additional or different license terms and conditions + for use, reproduction, or distribution of Your modifications, or + for any such Derivative Works as a whole, provided Your use, + reproduction, and distribution of the Work otherwise complies with + the conditions stated in this License. + + 5. Submission of Contributions. Unless You explicitly state otherwise, + any Contribution intentionally submitted for inclusion in the Work + by You to the Licensor shall be under the terms and conditions of + this License, without any additional terms or conditions. + Notwithstanding the above, nothing herein shall supersede or modify + the terms of any separate license agreement you may have executed + with Licensor regarding such Contributions. + + 6. Trademarks. This License does not grant permission to use the trade + names, trademarks, service marks, or product names of the Licensor, + except as required for reasonable and customary use in describing the + origin of the Work and reproducing the content of the NOTICE file. + + 7. Disclaimer of Warranty. Unless required by applicable law or + agreed to in writing, Licensor provides the Work (and each + Contributor provides its Contributions) on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + implied, including, without limitation, any warranties or conditions + of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A + PARTICULAR PURPOSE. You are solely responsible for determining the + appropriateness of using or redistributing the Work and assume any + risks associated with Your exercise of permissions under this License. + + 8. Limitation of Liability. In no event and under no legal theory, + whether in tort (including negligence), contract, or otherwise, + unless required by applicable law (such as deliberate and grossly + negligent acts) or agreed to in writing, shall any Contributor be + liable to You for damages, including any direct, indirect, special, + incidental, or consequential damages of any character arising as a + result of this License or out of the use or inability to use the + Work (including but not limited to damages for loss of goodwill, + work stoppage, computer failure or malfunction, or any and all + other commercial damages or losses), even if such Contributor + has been advised of the possibility of such damages. + + 9. Accepting Warranty or Additional Liability. While redistributing + the Work or Derivative Works thereof, You may choose to offer, + and charge a fee for, acceptance of support, warranty, indemnity, + or other liability obligations and/or rights consistent with this + License. However, in accepting such obligations, You may act only + on Your own behalf and on Your sole responsibility, not on behalf + of any other Contributor, and only if You agree to indemnify, + defend, and hold each Contributor harmless for any liability + incurred by, or claims asserted against, such Contributor by reason + of your accepting any such warranty or additional liability. + + END OF TERMS AND CONDITIONS diff --git a/maven-skin/NOTICE.txt b/maven-skin/NOTICE.txt new file mode 100644 index 00000000000..7caa16604d5 --- /dev/null +++ b/maven-skin/NOTICE.txt @@ -0,0 +1,9 @@ + ================================================================= + == NOTICE file for use with the Apache License, Version 2.0, == + ================================================================= + + Apache JAMES Site Maven2 Skin + Copyright 2007 The Apache Software Foundation + + This product includes software developed at + The Apache Software Foundation (http://www.apache.org/). diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index d5fc06ca6df..2b3603a1636 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -26,24 +26,19 @@ JAMES Skin Apache JAMES Official Maven2 Site Skin + + org.apache.james + james-parent + 1.1-SNAPSHOT + ../parent/pom.xml + + + - - - apache.snapshots - Apache Development Snapshot Repository - scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository - maven-skin-website scp://minotaur.apache.org/www/james.apache.org/maven-skin - diff --git a/parent/pom.xml b/parent/pom.xml new file mode 100644 index 00000000000..c4d385585bd --- /dev/null +++ b/parent/pom.xml @@ -0,0 +1,361 @@ + + + + 4.0.0 + org.apache.james + james-parent + Apache JAMES Parent POM + 1.1-SNAPSHOT + + The Apache JAMES Parent POM + + + + 2.0.5 + + + http://james.apache.org/ + 2006 + pom + + + + + + The Apache Software Foundation + http://www.apache.org + + + + + Apache License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.html + repo + + + + + JIRA + http://issues.apache.org/jira/browse/JAMES + + + + + bago + Stefano Bagnara + bago at apache.org + 2 + + Developer + + + + norman + Norman Maurer + norman at apache.org + 2 + + Developer + + + + serge + Serge Knystautas + sergek at lokitech.com + + + Developer + + + + benrdf + Bernd Fondermann + bf_jak at brainlounge.de + + + Developer + + + + sbrewin + Steve Brewin + sbrewin at synsys.com + + + Developer + + + + hilmer + + + Soren Hilmer + sh at widetrail.dk + + + Developer + + + + noel + Noel J. Bergman + noel at devtech.com + + + Developer + + + + danny + Danny Angus + danny at apache.org + + + Developer + + + + adc + Alan D. Cabrera + list at toolazydogs.com + -8 + + Developer + + + + vincenzo + Vincenzo Gianferrari Pini + vincenzo.gianferraripini at praxis.it + + + Developer + + + + rdonkin + Robert Burrell Donkin + rdonkin at apache.org + + + Developer + + + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/parent + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/parent + http://svn.apache.org/viewvc/james/project/trunk/parent + + + + + apache.releases + Apache Release Distribution Repository + scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository + + + apache.snapshots + Apache Development Snapshot Repository + scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository + + + + james-parent-website + scp://minotaur.apache.org/www/james.apache.org/parent/ + + + + + + + never + + + false + + maven-central + maven-central + http://repo1.maven.org/maven2 + + + + + + central + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + true + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + true + + + + + + + + src/main/resources + + + + ${basedir} + + NOTICE.txt + LICENSE.txt + + META-INF + + + + + + + + local + + + central + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + false + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + false + + + + + + + release + + + + + maven-gpg-plugin + 1.0-alpha-3 + + ${gpg.passphrase} + + + + sign-artifacts + verify + + sign + + + + + + + true + maven-deploy-plugin + 2.3 + + ${deploy.altRepository} + true + + + + org.apache.maven.plugins + maven-source-plugin + 2.0.2 + + + attach-sources + + jar + + + + + + org.apache.maven.plugins + maven-javadoc-plugin + 2.2 + + + attach-javadocs + + jar + + + + + + + + + + + + + \ No newline at end of file diff --git a/parent/src/site/site.xml b/parent/src/site/site.xml new file mode 100644 index 00000000000..b9433e8f3a7 --- /dev/null +++ b/parent/src/site/site.xml @@ -0,0 +1,45 @@ + + + + + + James Project + images/james-project-logo.gif + http://james.apache.org/index.html + + + + The Apache Software Foundation + images/asf-logo-reduced.gif + http://www.apache.org/index.html + + + + + org.apache.maven.skins + maven-default-skin + 1.0 + + + + + + diff --git a/pom.xml b/pom.xml index d89ea8eaddc..e4f108870ff 100644 --- a/pom.xml +++ b/pom.xml @@ -26,9 +26,19 @@ The Apache JAMES Project + + + org.apache.james + james-parent + 1.1-SNAPSHOT + ./parent/pom.xml + + + + 2.0.5 + - maven-skin server @@ -39,128 +49,11 @@ - - The Apache Software Foundation - http://www.apache.org - - - - - Apache License, Version 2.0 - http://www.apache.org/licenses/LICENSE-2.0.html - repo - - - JIRA http://issues.apache.org/jira/browse/JAMES - - - bago - Stefano Bagnara - bago at apache.org - 2 - - Developer - - - - norman - Norman Maurer - norman at apache.org - 2 - - Developer - - - - serge - Serge Knystautas - sergek at lokitech.com - - - Developer - - - - benrdf - Bernd Fondermann - bf_jak at brainlounge.de - - - Developer - - - - sbrewin - Steve Brewin - sbrewin at synsys.com - - - Developer - - - - hilmer - - - Soren Hilmer - sh at widetrail.dk - - - Developer - - - - noel - Noel J. Bergman - noel at devtech.com - - - Developer - - - - danny - Danny Angus - danny at apache.org - - - Developer - - - - adc - Alan D. Cabrera - list at toolazydogs.com - -8 - - Developer - - - - vincenzo - Vincenzo Gianferrari Pini - vincenzo.gianferraripini at praxis.it - - - Developer - - - - rdonkin - Robert Burrell Donkin - rdonkin at apache.org - - - Developer - - - - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk scm:svn:https://svn.apache.org/repos/asf/james/project/trunk @@ -168,16 +61,6 @@ - - apache.releases - Apache Release Distribution Repository - scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository - - - apache.snapshots - Apache Development Snapshot Repository - scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository - james-website @@ -185,42 +68,6 @@ - - - - never - - - false - - maven-central - maven-central - http://repo1.maven.org/maven2 - - - - - - central - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - true - - - true - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - - Apache James Website Developement @@ -231,47 +78,4 @@ - - - - src/main/resources - - - - ${basedir} - - NOTICE.txt - LICENSE.txt - - META-INF - - - - - - - \ No newline at end of file From f3a614e3df7881964634d2d0fc6d7512420379de Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 28 Apr 2007 14:39:07 +0000 Subject: [PATCH 039/541] Changed repositories names so that central still refer to the original central repository and simply disabled it by default. The previous "central" has been renamed "apache.releases". Removed declaration of pluginRepositories so to fallback to standard repository from maven. Updated HOWTO to include some more needed step. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@533349 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO.txt | 23 +++++++++++++---------- parent/pom.xml | 22 ++++++++++++++++++++++ pom.xml | 6 +----- 3 files changed, 36 insertions(+), 15 deletions(-) diff --git a/HOWTO.txt b/HOWTO.txt index 1ff68563e16..a676c321c7a 100644 --- a/HOWTO.txt +++ b/HOWTO.txt @@ -1,18 +1,21 @@ How to build and publish the website: 1. Install Apache Maven 2.0.6 and make its binary 'mvn' available on your PATH. - 2. Execute 'mvn -Plocal install'. This will generate the artifacts and install them without - trying to remove them from remote repositories ("local" profile). - 3. Execute 'mvn -Plocal site'. This will generate the website for each module. - 4. Test the built site in your browser from target/site - 5. If everything looks OK, copy target/site to the checkout of james/site/trunk/www folder + 2. Enter parent folder and execute 'mvn -Plocal install'. This will generate the + artifacts and install them without trying to remove them from remote repositories + (by using the "local" profile defined in the pom.xml). + 3. Enter the maven-skin folder and execute 'mvn -Plocal install'. + 4. Return to the root and execute 'mvn -Plocal site'. This will generate the website for + each module. + 5. Test the built site in your browser from target/site + 6. If everything looks OK, copy target/site to the checkout of james/site/trunk/www folder server/target/site to the checkout of james/site/trunk/www/server folder server/2.2.0/target/site to the checkout of james/site/trunk/www/server/2.2.0 folder - 6. If you are on windows make sure endlines are LF only. - 7. Commit changes to SVN - 8. Review generated pages on svn.apache.org/repos/asf/james/site/trunk/www - 9. svn-up on minotaur -10. Wait for the changes to replicate to the Apache web server or setup 140.211.11.10:80 as + 7. If you are on windows make sure endlines are LF only. + 8. Commit changes to SVN + 9. Review generated pages on svn.apache.org/repos/asf/james/site/trunk/www +10. svn-up on minotaur +11. Wait for the changes to replicate to the Apache web server or setup 140.211.11.10:80 as a proxy to review the changes (described here: http://www.apache.org/dev/project-site.html) The logical tree of the poms is the following diff --git a/parent/pom.xml b/parent/pom.xml index c4d385585bd..c98d7f96fed 100644 --- a/parent/pom.xml +++ b/parent/pom.xml @@ -184,6 +184,7 @@ + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases Apache Main M2 Repository http://people.apache.org/repo/m2-ibiblio-rsync-repository @@ -247,6 +259,16 @@ central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases Apache Main M2 Repository http://people.apache.org/repo/m2-ibiblio-rsync-repository diff --git a/pom.xml b/pom.xml index e4f108870ff..cc97bb199e9 100644 --- a/pom.xml +++ b/pom.xml @@ -31,13 +31,9 @@ org.apache.james james-parent 1.1-SNAPSHOT - ./parent/pom.xml + parent/pom.xml - - 2.0.5 - - server From 63de3921ce5e317175c93c0e7decf485e5235cc8 Mon Sep 17 00:00:00 2001 From: norman Date: Sun, 29 Apr 2007 16:08:15 +0000 Subject: [PATCH 040/541] Update website to reflect release of james server 2.3.1 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@533517 13f79535-47bb-0310-9956-ffa450edef68 --- server/src/site/xdoc/index.xml | 10 +++++----- src/site/xdoc/index.xml | 1 + src/site/xdoc/newsarchive.xml | 2 ++ 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/server/src/site/xdoc/index.xml b/server/src/site/xdoc/index.xml index b956db59d18..d9846903f96 100644 --- a/server/src/site/xdoc/index.xml +++ b/server/src/site/xdoc/index.xml @@ -31,12 +31,12 @@

    - Latest and Stable: James v2.3.0 + Latest and Stable: James v2.3.1
    -James v2.3.0 is the current best release. Both binary and source distributions are available.

    -

    James v2.3.0 is a major update to the James platform, with many new features, functional improvements, and bug fixes. -See the Change Log for a detailed list of changes. All -users are urged to upgrade to v2.3.0 as soon as possible.

    +James v2.3.1 is the current best release. Both binary and source distributions are available.

    +

    James v2.3.1 is a bugfix release to the James platform, with importent bugfixes. +See the Change Log for a detailed list of bugfixes. All +users are urged to upgrade to v2.3.1 as soon as possible.

    Any bugs found in James are dealt with promptly. Please provide feedback on the james-user and james-dev mailing lists.

    Get your hands on the latest versions.. diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index c1fc8a1318a..5a85097ae26 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -21,6 +21,7 @@ Read all the news in full in the News Archive
    Or click the titles to read the full story + Apr/2007 - JAMES Server 2.3.1 Final Released
    Apr/2007 - JAMES Server 2.3.1 RC1 Released
    Apr/2007 - Apache JAMES Project Guidelines published
    Feb/2007 - jSPF-0.9b4 released
    diff --git a/src/site/xdoc/newsarchive.xml b/src/site/xdoc/newsarchive.xml index ac94c318a44..df5e8da740b 100644 --- a/src/site/xdoc/newsarchive.xml +++ b/src/site/xdoc/newsarchive.xml @@ -12,6 +12,8 @@ +

    Oct/2006 - JAMES Server 2.3.1 Final Released

    +

    James PMC is proud to announce the availability of the final release of JAMES Server 2.3.1. This is the bugfix released of 2.3.0. More informations on what's fixed since the last releas, can be found in the changelog.

    Apr/2007 - JAMES Server 2.3.1 RC1 released

    James PMC is proud to announce the availability of the frist release canidat of JAMES Server 2.3.1. This release is maintenance release. See the changelog for more detail.

    Apr/2007 - Apache JAMES Project Guidelines published

     From c90494f6271ae7a79d66e883008ad4be0a1af1fd Mon Sep 17 00:00:00 2001 From: norman Date: Sun, 29 Apr 2007 16:44:20 +0000 Subject: [PATCH 041/541] More modify to reflect 2.3.1 final git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@533523 13f79535-47bb-0310-9956-ffa450edef68 --- server/src/site/site.xml | 2 +- src/site/xdoc/download.xml | 26 +++++++++++++------------- src/site/xdoc/downloadunstable.xml | 3 ++- 3 files changed, 16 insertions(+), 15 deletions(-) diff --git a/server/src/site/site.xml b/server/src/site/site.xml index 26da0b51358..e0108c116f4 100644 --- a/server/src/site/site.xml +++ b/server/src/site/site.xml @@ -48,7 +48,7 @@ --> - + diff --git a/src/site/xdoc/download.xml b/src/site/xdoc/download.xml index 6ba2406e66a..54ee313a7a0 100644 --- a/src/site/xdoc/download.xml +++ b/src/site/xdoc/download.xml @@ -67,11 +67,11 @@ list of mirrors.

    -
    +

    This release has many enhancements and bug fixes over the previous release. See the Change Log +href="server/2.3.1changelog.html">Change Log for a detailed list of changes. Some of the earlier defects could turn a James mail server into an Open Relay. All users of James are urged to upgrade to James v2.3.0 as soon as possible.

    @@ -79,28 +79,28 @@ possible.

    • Binary (Unix TAR): james-2.3.0.tar.gz [PGP]
      • +href="[preferred]/james/server/binaries/james-2.3.1.tar.gz">james-2.3.1.tar.gz [PGP]
    • Binary (ZIP Format): james-2.3.0.zip [PGP]
      • +href="[preferred]/james/server/binaries/james-2.3.1.zip">james-2.3.1.zip [PGP]
    • Source (Unix TAR): james-2.3.0-src.tar.gz [PGP]
      • +href="[preferred]/james/server/source/james-2.3.1-src.tar.gz">james-2.3.1-src.tar.gz [PGP]
    • Source (ZIP Format): james-2.3.0-src.zip [james-2.3.1-src.zip [PGP]
    • Source with Avalon Phoenix binaries (Unix TAR): james-with-phoenix-2.3.0-src.tar.gz [PGP]
      • +href="[preferred]/james/server/source/james-with-phoenix-2.3.1-src.tar.gz">james-with-phoenix-2.3.1-src.tar.gz [PGP]
    • Source with Avalon Phoenix binaries (ZIP Format): james-with-phoenix-2.3.0-src.zip [PGP]
      • +href="[preferred]/james/server/source/james-with-phoenix-2.3.1-src.zip">james-with-phoenix-2.3.1-src.zip [PGP]
    • Other diff --git a/src/site/xdoc/downloadunstable.xml b/src/site/xdoc/downloadunstable.xml index 2d2a5f1f222..adbca68537f 100644 --- a/src/site/xdoc/downloadunstable.xml +++ b/src/site/xdoc/downloadunstable.xml @@ -66,7 +66,7 @@ Other mirrors: list of mirrors.

      + +
      +

      Apache JAMES server 2.3.1 has been released an no new unstable releases have been released. +Please go to the stable releases download page to download it. +

      +
      From 33cb958cd4b1c21b4884476dfdc90e4c5582fc1e Mon Sep 17 00:00:00 2001 From: bago Date: Sun, 29 Apr 2007 19:28:02 +0000 Subject: [PATCH 046/541] Fix again download urls: sooner or later we'll do it right ;-) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@533550 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/xdoc/download.xml | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/src/site/xdoc/download.xml b/src/site/xdoc/download.xml index 79354b3aa98..d8088c76619 100644 --- a/src/site/xdoc/download.xml +++ b/src/site/xdoc/download.xml @@ -79,39 +79,39 @@ possible.

      From 2dd7c3016235f09024f8573410ddc7cd5c24329d Mon Sep 17 00:00:00 2001 From: danny Date: Tue, 8 May 2007 15:18:03 +0000 Subject: [PATCH 047/541] add mailet sub-project links git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536220 13f79535-47bb-0310-9956-ffa450edef68 --- src/site/site.xml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/site/site.xml b/src/site/site.xml index 42c75c5f558..8f5fee1ffd1 100644 --- a/src/site/site.xml +++ b/src/site/site.xml @@ -41,6 +41,7 @@ + @@ -49,6 +50,7 @@ + From 6a8da57a8b546c1820763dd98076518308d8984b Mon Sep 17 00:00:00 2001 From: bago Date: Tue, 8 May 2007 22:29:57 +0000 Subject: [PATCH 048/541] Changed james m2 skin to use remote resources plugin (to include NOTICE/LICENSE in generated jar) Changed few references to mailet api new place. Updated parent to remove usage of "resources" link to NOTICE/LICENSE in favor of custom remote resource plugins to be added in child projects. Fixed some typo in newsarchive. Updated the HOWTO to reflect the remote-resources needs. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536357 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO.txt | 2 +- maven-skin/LICENSE.txt | 177 --------------------- maven-skin/NOTICE.txt | 9 -- maven-skin/README.txt | 15 ++ maven-skin/pom.xml | 24 +++ parent/pom.xml | 60 +------ server/2.2.0/src/site/xdoc/mailet_api.xml | 3 - server/src/site/xdoc/FAQ.xml | 6 +- server/src/site/xdoc/design_objectives.xml | 2 +- server/src/site/xdoc/index.xml | 2 +- src/site/xdoc/index.xml | 1 + src/site/xdoc/mail.xml | 2 +- src/site/xdoc/newsarchive.xml | 12 +- 13 files changed, 56 insertions(+), 259 deletions(-) delete mode 100644 maven-skin/LICENSE.txt delete mode 100644 maven-skin/NOTICE.txt create mode 100644 maven-skin/README.txt diff --git a/HOWTO.txt b/HOWTO.txt index a676c321c7a..c9b1580dc8a 100644 --- a/HOWTO.txt +++ b/HOWTO.txt @@ -4,7 +4,7 @@ How to build and publish the website: 2. Enter parent folder and execute 'mvn -Plocal install'. This will generate the artifacts and install them without trying to remove them from remote repositories (by using the "local" profile defined in the pom.xml). - 3. Enter the maven-skin folder and execute 'mvn -Plocal install'. + 3. Enter the maven-skin folder and execute 'mvn install'. 4. Return to the root and execute 'mvn -Plocal site'. This will generate the website for each module. 5. Test the built site in your browser from target/site diff --git a/maven-skin/LICENSE.txt b/maven-skin/LICENSE.txt deleted file mode 100644 index ade750b16ba..00000000000 --- a/maven-skin/LICENSE.txt +++ /dev/null @@ -1,177 +0,0 @@ - - Apache License - Version 2.0, January 2004 - http://www.apache.org/licenses/ - - TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION - - 1. Definitions. - - "License" shall mean the terms and conditions for use, reproduction, - and distribution as defined by Sections 1 through 9 of this document. - - "Licensor" shall mean the copyright owner or entity authorized by - the copyright owner that is granting the License. - - "Legal Entity" shall mean the union of the acting entity and all - other entities that control, are controlled by, or are under common - control with that entity. For the purposes of this definition, - "control" means (i) the power, direct or indirect, to cause the - direction or management of such entity, whether by contract or - otherwise, or (ii) ownership of fifty percent (50%) or more of the - outstanding shares, or (iii) beneficial ownership of such entity. - - "You" (or "Your") shall mean an individual or Legal Entity - exercising permissions granted by this License. - - "Source" form shall mean the preferred form for making modifications, - including but not limited to software source code, documentation - source, and configuration files. - - "Object" form shall mean any form resulting from mechanical - transformation or translation of a Source form, including but - not limited to compiled object code, generated documentation, - and conversions to other media types. - - "Work" shall mean the work of authorship, whether in Source or - Object form, made available under the License, as indicated by a - copyright notice that is included in or attached to the work - (an example is provided in the Appendix below). - - "Derivative Works" shall mean any work, whether in Source or Object - form, that is based on (or derived from) the Work and for which the - editorial revisions, annotations, elaborations, or other modifications - represent, as a whole, an original work of authorship. For the purposes - of this License, Derivative Works shall not include works that remain - separable from, or merely link (or bind by name) to the interfaces of, - the Work and Derivative Works thereof. - - "Contribution" shall mean any work of authorship, including - the original version of the Work and any modifications or additions - to that Work or Derivative Works thereof, that is intentionally - submitted to Licensor for inclusion in the Work by the copyright owner - or by an individual or Legal Entity authorized to submit on behalf of - the copyright owner. For the purposes of this definition, "submitted" - means any form of electronic, verbal, or written communication sent - to the Licensor or its representatives, including but not limited to - communication on electronic mailing lists, source code control systems, - and issue tracking systems that are managed by, or on behalf of, the - Licensor for the purpose of discussing and improving the Work, but - excluding communication that is conspicuously marked or otherwise - designated in writing by the copyright owner as "Not a Contribution." - - "Contributor" shall mean Licensor and any individual or Legal Entity - on behalf of whom a Contribution has been received by Licensor and - subsequently incorporated within the Work. - - 2. Grant of Copyright License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - copyright license to reproduce, prepare Derivative Works of, - publicly display, publicly perform, sublicense, and distribute the - Work and such Derivative Works in Source or Object form. - - 3. Grant of Patent License. Subject to the terms and conditions of - this License, each Contributor hereby grants to You a perpetual, - worldwide, non-exclusive, no-charge, royalty-free, irrevocable - (except as stated in this section) patent license to make, have made, - use, offer to sell, sell, import, and otherwise transfer the Work, - where such license applies only to those patent claims licensable - by such Contributor that are necessarily infringed by their - Contribution(s) alone or by combination of their Contribution(s) - with the Work to which such Contribution(s) was submitted. If You - institute patent litigation against any entity (including a - cross-claim or counterclaim in a lawsuit) alleging that the Work - or a Contribution incorporated within the Work constitutes direct - or contributory patent infringement, then any patent licenses - granted to You under this License for that Work shall terminate - as of the date such litigation is filed. - - 4. Redistribution. You may reproduce and distribute copies of the - Work or Derivative Works thereof in any medium, with or without - modifications, and in Source or Object form, provided that You - meet the following conditions: - - (a) You must give any other recipients of the Work or - Derivative Works a copy of this License; and - - (b) You must cause any modified files to carry prominent notices - stating that You changed the files; and - - (c) You must retain, in the Source form of any Derivative Works - that You distribute, all copyright, patent, trademark, and - attribution notices from the Source form of the Work, - excluding those notices that do not pertain to any part of - the Derivative Works; and - - (d) If the Work includes a "NOTICE" text file as part of its - distribution, then any Derivative Works that You distribute must - include a readable copy of the attribution notices contained - within such NOTICE file, excluding those notices that do not - pertain to any part of the Derivative Works, in at least one - of the following places: within a NOTICE text file distributed - as part of the Derivative Works; within the Source form or - documentation, if provided along with the Derivative Works; or, - within a display generated by the Derivative Works, if and - wherever such third-party notices normally appear. The contents - of the NOTICE file are for informational purposes only and - do not modify the License. You may add Your own attribution - notices within Derivative Works that You distribute, alongside - or as an addendum to the NOTICE text from the Work, provided - that such additional attribution notices cannot be construed - as modifying the License. - - You may add Your own copyright statement to Your modifications and - may provide additional or different license terms and conditions - for use, reproduction, or distribution of Your modifications, or - for any such Derivative Works as a whole, provided Your use, - reproduction, and distribution of the Work otherwise complies with - the conditions stated in this License. - - 5. Submission of Contributions. Unless You explicitly state otherwise, - any Contribution intentionally submitted for inclusion in the Work - by You to the Licensor shall be under the terms and conditions of - this License, without any additional terms or conditions. - Notwithstanding the above, nothing herein shall supersede or modify - the terms of any separate license agreement you may have executed - with Licensor regarding such Contributions. - - 6. Trademarks. This License does not grant permission to use the trade - names, trademarks, service marks, or product names of the Licensor, - except as required for reasonable and customary use in describing the - origin of the Work and reproducing the content of the NOTICE file. - - 7. Disclaimer of Warranty. Unless required by applicable law or - agreed to in writing, Licensor provides the Work (and each - Contributor provides its Contributions) on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or - implied, including, without limitation, any warranties or conditions - of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A - PARTICULAR PURPOSE. You are solely responsible for determining the - appropriateness of using or redistributing the Work and assume any - risks associated with Your exercise of permissions under this License. - - 8. Limitation of Liability. In no event and under no legal theory, - whether in tort (including negligence), contract, or otherwise, - unless required by applicable law (such as deliberate and grossly - negligent acts) or agreed to in writing, shall any Contributor be - liable to You for damages, including any direct, indirect, special, - incidental, or consequential damages of any character arising as a - result of this License or out of the use or inability to use the - Work (including but not limited to damages for loss of goodwill, - work stoppage, computer failure or malfunction, or any and all - other commercial damages or losses), even if such Contributor - has been advised of the possibility of such damages. - - 9. Accepting Warranty or Additional Liability. While redistributing - the Work or Derivative Works thereof, You may choose to offer, - and charge a fee for, acceptance of support, warranty, indemnity, - or other liability obligations and/or rights consistent with this - License. However, in accepting such obligations, You may act only - on Your own behalf and on Your sole responsibility, not on behalf - of any other Contributor, and only if You agree to indemnify, - defend, and hold each Contributor harmless for any liability - incurred by, or claims asserted against, such Contributor by reason - of your accepting any such warranty or additional liability. - - END OF TERMS AND CONDITIONS diff --git a/maven-skin/NOTICE.txt b/maven-skin/NOTICE.txt deleted file mode 100644 index 7caa16604d5..00000000000 --- a/maven-skin/NOTICE.txt +++ /dev/null @@ -1,9 +0,0 @@ - ================================================================= - == NOTICE file for use with the Apache License, Version 2.0, == - ================================================================= - - Apache JAMES Site Maven2 Skin - Copyright 2007 The Apache Software Foundation - - This product includes software developed at - The Apache Software Foundation (http://www.apache.org/). diff --git a/maven-skin/README.txt b/maven-skin/README.txt new file mode 100644 index 00000000000..a6793cf97c9 --- /dev/null +++ b/maven-skin/README.txt @@ -0,0 +1,15 @@ + ============================ + Apache JAMES Website M2 Skin + ============================ + +This is the maven skin for JAMES products deplyed at http://james.apache.org + +This release include the google analytic javascript code at the bottom of every +generated page and specifically to page starting with "download" it will also add +a javascript to add tracking of "clicks" over the download links. + +Links to external website and having extensions in "gz","bz2","zip","jar","asc", +"sar" will automatically be monitored. + +If you are using SNAPSHOT versions of this skin, please remember to "mvn install" +the skin before creating websites for JAMES products. \ No newline at end of file diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 2b3603a1636..c687a47a2f5 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -41,6 +41,10 @@ + + + true + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/maven-skin @@ -48,4 +52,24 @@ http://svn.apache.org/viewvc/james/project/trunk/maven-skin + + + + maven-remote-resources-plugin + + + + process + + + + org.apache:apache-jar-resource-bundle:1.2 + + + + + + + + \ No newline at end of file diff --git a/parent/pom.xml b/parent/pom.xml index c98d7f96fed..f5d7905a865 100644 --- a/parent/pom.xml +++ b/parent/pom.xml @@ -28,7 +28,7 @@ - 2.0.5 + 2.0.6 http://james.apache.org/ @@ -184,22 +184,6 @@ - - central @@ -235,23 +219,6 @@ - - - - src/main/resources - - - - ${basedir} - - NOTICE.txt - LICENSE.txt - - META-INF - - - - @@ -355,29 +322,4 @@ - - \ No newline at end of file diff --git a/server/2.2.0/src/site/xdoc/mailet_api.xml b/server/2.2.0/src/site/xdoc/mailet_api.xml index 489ab7e6401..820e13958a2 100644 --- a/server/2.2.0/src/site/xdoc/mailet_api.xml +++ b/server/2.2.0/src/site/xdoc/mailet_api.xml @@ -40,9 +40,6 @@ in a message under evaluation.

      or pass the message to an external API or component. This can include delivering a message to its destination repository or SMTP server.

      The Mailet API is currently in its second revision. Although, the Mailet API is expected to undergo substantial changes in the near future, it is our aim that existing Mailets that abided purely by the prior Mailet API interfaces will continue to run with the revised specification.

      -

      James bundles a number of Matchers and Mailets in its distribution. Descriptions of provided matchers can be found here, while descriptions of provided mailets can be found here.

      diff --git a/server/src/site/xdoc/FAQ.xml b/server/src/site/xdoc/FAQ.xml index 0a5e0edac11..5a02e141b73 100644 --- a/server/src/site/xdoc/FAQ.xml +++ b/server/src/site/xdoc/FAQ.xml @@ -122,7 +122,7 @@ <sqlFile>file://conf/sqlResources.xml</sqlFile> </repository> -

      Database users will also need to ensure that they have configured a data-source named to match the destination URL

      +

      Database users will also need to ensure that they have configured a data-source named to match the destination URL

      Using the filesystem:-

      <repository name="list-james" @@ -180,7 +180,7 @@ -

      James v2.1+ includes a new mailet for database users, JDBCVirtualUserTable, that mimics some of the sendmail capabilities of the same name.

      +

      James v2.1+ includes a new mailet for database users, JDBCVirtualUserTable, that mimics some of the sendmail capabilities of the same name.

      JDBCVirtualUserTable does not provide any administation tools. You'll have to create and maintain the database table yourself. The standard configuration is as follows:

      @@ -225,7 +225,7 @@ match as follows (in precedence order):

      We are largely reliant on what Avalon is doing in terms of classloading, but here are a few tips and suggestions:

      • Stick jars in the james/lib directory and add them to the classpath in run.bat or run.sh.
        • -
      • Instructions for including classes for custom mailets and matchers can be found here and here respectively..
        • +
      • Instructions for including classes for custom mailets and matchers can be found here and here respectively..
      Eventually we hope to support mailet reloading and a special lib and classes directory within the james directory that custom mailets can load from, but for now these are hopefully some useful tips.

      diff --git a/server/src/site/xdoc/design_objectives.xml b/server/src/site/xdoc/design_objectives.xml index a373e108d46..d8f7863321a 100644 --- a/server/src/site/xdoc/design_objectives.xml +++ b/server/src/site/xdoc/design_objectives.xml @@ -57,7 +57,7 @@ systems. Examples of the services a Mailet might provide include: a mail-to-fax or mail-to-phone transformer, a filter, a language translator, a mailing list manager, etc. Several Mailets are included in the JAMES - distribution (see documentation).

      + distribution (see documentation).

      Resource abstraction diff --git a/server/src/site/xdoc/index.xml b/server/src/site/xdoc/index.xml index d9846903f96..666b457e9e8 100644 --- a/server/src/site/xdoc/index.xml +++ b/server/src/site/xdoc/index.xml @@ -61,7 +61,7 @@ users are urged to upgrade to v2.3.1 as soon as possible.

      Mailet Engine Stable - 1.2 + 2.3 0.95 diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml index 5a85097ae26..53fed6b3c9f 100644 --- a/src/site/xdoc/index.xml +++ b/src/site/xdoc/index.xml @@ -21,6 +21,7 @@ Read all the news in full in the News Archive
      Or click the titles to read the full story + Apr/2007 - JAMES Server 2.3.1 Final Released
      Apr/2007 - JAMES Server 2.3.1 RC1 Released
      Apr/2007 - Apache JAMES Project Guidelines published
      diff --git a/src/site/xdoc/mail.xml b/src/site/xdoc/mail.xml index eaa61bf806e..deb8aa449db 100644 --- a/src/site/xdoc/mail.xml +++ b/src/site/xdoc/mail.xml @@ -241,7 +241,7 @@ all. Do not send mail to this list with James software problems Unsubscribe Guidelines

      -

      This is the public list for the Mailet API subproject, discussing all Mailet API design and implementation related topics. Questions about using Mailets and their configuration should be addressed to the server-user list.

      +

      This is the public list for the Mailet API subproject, discussing all Mailet API design and implementation related topics. Questions about using Mailets and their configuration should be addressed to the server-user list.
    diff --git a/src/site/xdoc/newsarchive.xml b/src/site/xdoc/newsarchive.xml index 508cbb0e391..db154c9190d 100644 --- a/src/site/xdoc/newsarchive.xml +++ b/src/site/xdoc/newsarchive.xml @@ -11,11 +11,15 @@ - -

    Apr/2007 - JAMES Server 2.3.1 Final Released

    -

    James PMC is proud to announce the availability of the final release of JAMES Server 2.3.1. This is the bugfix released of 2.3.0. More informations on what's fixed since the last releas, can be found in the changelog.

    + + +

    Apr/2007 - JAMES Server 2.3.1 Final Released

    +

    James PMC is proud to announce the availability of the final release of JAMES Server 2.3.1. More informations on what has been fixed since the 2.3.0 release can be found in the changelog.

    Apr/2007 - JAMES Server 2.3.1 RC1 released

     -

    James PMC is proud to announce the availability of the frist release canidat of JAMES Server 2.3.1. This release is maintenance release. See the changelog for more detail.

    +

    James PMC is proud to announce the availability of the first release candidate of JAMES Server 2.3.1. This release is maintenance release. See the changelog for more detail.

    Apr/2007 - Apache JAMES Project Guidelines published

    The James PMC has approved - for the first time - a set of guidelines for the project. These guidelines are intended to reflect and summarize well-known practices in our community. They include "... definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the Apache JAMES products."

    Feb/2007 - jSPF-0.9b4 released

     From 3e4770313c3723350f959cab9f806f0e824da598 Mon Sep 17 00:00:00 2001 From: bago Date: Tue, 8 May 2007 22:31:00 +0000 Subject: [PATCH 049/541] Ignored resources git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536359 13f79535-47bb-0310-9956-ffa450edef68 From 714fddc78fd746ac66f6877c42ddcc5efd741ab6 Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 10 May 2007 16:20:21 +0000 Subject: [PATCH 050/541] Refactoring james-project layout to make poms tree consistent with folder tree. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536916 13f79535-47bb-0310-9956-ffa450edef68 From 5c1750e9cb88926b931dca268aa1fd05f91ccb9e Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 10 May 2007 16:21:17 +0000 Subject: [PATCH 051/541] Refactoring james-project layout to make poms tree consistent with folder tree. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536917 13f79535-47bb-0310-9956-ffa450edef68 --- {server => project/server}/2.2.0/pom.xml | 0 .../src/site/resources/images/asf-logo-reduced.gif | Bin .../src/site/resources/images/james-server-logo.gif | Bin {server => project/server}/2.2.0/src/site/site.xml | 0 .../server}/2.2.0/src/site/xdoc/adding_users.xml | 0 .../2.2.0/src/site/xdoc/build_instructions.xml | 0 .../server}/2.2.0/src/site/xdoc/changelog.xml | 0 .../server}/2.2.0/src/site/xdoc/custom_mailet.xml | 0 .../server}/2.2.0/src/site/xdoc/custom_matcher.xml | 0 .../2.2.0/src/site/xdoc/dns_configuration.xml | 0 .../2.2.0/src/site/xdoc/fetchmail_configuration.xml | 0 .../2.2.0/src/site/xdoc/fetchpop_configuration.xml | 0 .../server}/2.2.0/src/site/xdoc/index.xml | 0 .../src/site/xdoc/installation_instructions.xml | 0 .../server}/2.2.0/src/site/xdoc/mailet_api.xml | 0 .../server}/2.2.0/src/site/xdoc/mailing_lists.xml | 0 .../2.2.0/src/site/xdoc/nntp_configuration.xml | 0 .../2.2.0/src/site/xdoc/pop3_configuration.xml | 0 .../2.2.0/src/site/xdoc/provided_mailets.xml | 0 .../2.2.0/src/site/xdoc/provided_matchers.xml | 0 .../src/site/xdoc/remotemanager_configuration.xml | 0 .../server}/2.2.0/src/site/xdoc/repositories.xml | 0 .../src/site/xdoc/serverwide_configuration.xml | 0 .../server}/2.2.0/src/site/xdoc/smtp_auth.xml | 0 .../2.2.0/src/site/xdoc/smtp_configuration.xml | 0 .../server}/2.2.0/src/site/xdoc/spoolmanager.xml | 0 .../src/site/xdoc/spoolmanager_configuration.xml | 0 .../server}/2.2.0/src/site/xdoc/summary.xml | 0 .../server}/2.2.0/src/site/xdoc/usingTLS.xml | 0 .../server}/2.2.0/src/site/xdoc/using_database.xml | 0 {server => project/server}/pom.xml | 0 .../server}/src/site/resources/css/site.css | 0 .../src/site/resources/images/asf-logo-reduced.gif | Bin .../src/site/resources/images/james-server-logo.gif | Bin .../resources/images/james_config_load_balance.png | Bin .../resources/images/james_config_secondary.png | Bin .../resources/images/james_config_smart_host.png | Bin .../src/site/resources/rfclist/basic/rfc0822.txt | 0 .../src/site/resources/rfclist/basic/rfc1123.txt | 0 .../src/site/resources/rfclist/basic/rfc2045.txt | 0 .../src/site/resources/rfclist/basic/rfc2046.txt | 0 .../src/site/resources/rfclist/basic/rfc2822.txt | 0 .../src/site/resources/rfclist/imap4/rfc1731.txt | 0 .../src/site/resources/rfclist/imap4/rfc2060.txt | 0 .../src/site/resources/rfclist/imap4/rfc2086.txt | 0 .../src/site/resources/rfclist/imap4/rfc2087.txt | 0 .../src/site/resources/rfclist/imap4/rfc2088.txt | 0 .../src/site/resources/rfclist/imap4/rfc2177.txt | 0 .../src/site/resources/rfclist/imap4/rfc2180.txt | 0 .../src/site/resources/rfclist/imap4/rfc2192.txt | 0 .../src/site/resources/rfclist/imap4/rfc2193.txt | 0 .../src/site/resources/rfclist/imap4/rfc2195.txt | 0 .../src/site/resources/rfclist/imap4/rfc2221.txt | 0 .../src/site/resources/rfclist/imap4/rfc2342.txt | 0 .../src/site/resources/rfclist/imap4/rfc2359.txt | 0 .../src/site/resources/rfclist/imap4/rfc2595.txt | 0 .../src/site/resources/rfclist/imap4/rfc2683.txt | 0 .../src/site/resources/rfclist/ldap/rfc2251.txt | 0 .../src/site/resources/rfclist/ldap/rfc2252.txt | 0 .../src/site/resources/rfclist/ldap/rfc2253.txt | 0 .../src/site/resources/rfclist/ldap/rfc2254.txt | 0 .../src/site/resources/rfclist/ldap/rfc2255.txt | 0 .../src/site/resources/rfclist/ldap/rfc2256.txt | 0 .../src/site/resources/rfclist/ldap/rfc2829.txt | 0 .../src/site/resources/rfclist/ldap/rfc2830.txt | 0 .../src/site/resources/rfclist/ldap/rfc3377.txt | 0 .../rfclist/nntp/draft-ietf-nntpext-base-13.txt | 0 .../src/site/resources/rfclist/nntp/rfc0977.txt | 0 .../src/site/resources/rfclist/nntp/rfc1036.txt | 0 .../src/site/resources/rfclist/nntp/rfc2980.txt | 0 .../src/site/resources/rfclist/pop3/rfc1725.txt | 0 .../src/site/resources/rfclist/pop3/rfc1734.txt | 0 .../src/site/resources/rfclist/pop3/rfc1939.txt | 0 .../src/site/resources/rfclist/smtp/rfc0821.txt | 0 .../src/site/resources/rfclist/smtp/rfc0974.txt | 0 .../src/site/resources/rfclist/smtp/rfc1652.txt | 0 .../src/site/resources/rfclist/smtp/rfc1830.txt | 0 .../src/site/resources/rfclist/smtp/rfc1869.txt | 0 .../src/site/resources/rfclist/smtp/rfc1870.txt | 0 .../src/site/resources/rfclist/smtp/rfc1891.txt | 0 .../src/site/resources/rfclist/smtp/rfc1893.txt | 0 .../src/site/resources/rfclist/smtp/rfc1985.txt | 0 .../src/site/resources/rfclist/smtp/rfc2034.txt | 0 .../src/site/resources/rfclist/smtp/rfc2142.txt | 0 .../src/site/resources/rfclist/smtp/rfc2197.txt | 0 .../src/site/resources/rfclist/smtp/rfc2554.txt | 0 .../src/site/resources/rfclist/smtp/rfc2821.txt | 0 {server => project/server}/src/site/site.xml | 0 {server => project/server}/src/site/xdoc/FAQ.xml | 0 .../src/site/xdoc/archive/announcement_2_1.xml | 0 .../src/site/xdoc/archive/architecture_v1_2.xml | 0 .../src/site/xdoc/archive/architecture_v2_0.xml | 0 .../src/site/xdoc/archive/configuration_v2_0.xml | 0 .../src/site/xdoc/archive/document_archive.xml | 0 .../server}/src/site/xdoc/archive/install.xml | 0 .../src/site/xdoc/archive/usingJDBC_v2.0.xml | 0 .../src/site/xdoc/archive/usingLDAP_v1_2.xml | 0 .../server}/src/site/xdoc/archive/usingTLS_v1_2.xml | 0 .../server}/src/site/xdoc/design_objectives.xml | 0 {server => project/server}/src/site/xdoc/index.xml | 0 .../server}/src/site/xdoc/james_and_sendmail.xml | 0 .../server}/src/site/xdoc/rfclist.xml | 0 {server => project/server}/src/site/xdoc/todo.xml | 0 103 files changed, 0 insertions(+), 0 deletions(-) rename {server => project/server}/2.2.0/pom.xml (100%) rename {server => project/server}/2.2.0/src/site/resources/images/asf-logo-reduced.gif (100%) rename {server => project/server}/2.2.0/src/site/resources/images/james-server-logo.gif (100%) rename {server => project/server}/2.2.0/src/site/site.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/adding_users.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/build_instructions.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/changelog.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/custom_mailet.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/custom_matcher.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/dns_configuration.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/fetchmail_configuration.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/fetchpop_configuration.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/index.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/installation_instructions.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/mailet_api.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/mailing_lists.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/nntp_configuration.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/pop3_configuration.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/provided_mailets.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/provided_matchers.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/remotemanager_configuration.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/repositories.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/serverwide_configuration.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/smtp_auth.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/smtp_configuration.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/spoolmanager.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/spoolmanager_configuration.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/summary.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/usingTLS.xml (100%) rename {server => project/server}/2.2.0/src/site/xdoc/using_database.xml (100%) rename {server => project/server}/pom.xml (100%) rename {server => project/server}/src/site/resources/css/site.css (100%) rename {server => project/server}/src/site/resources/images/asf-logo-reduced.gif (100%) rename {server => project/server}/src/site/resources/images/james-server-logo.gif (100%) rename {server => project/server}/src/site/resources/images/james_config_load_balance.png (100%) rename {server => project/server}/src/site/resources/images/james_config_secondary.png (100%) rename {server => project/server}/src/site/resources/images/james_config_smart_host.png (100%) rename {server => project/server}/src/site/resources/rfclist/basic/rfc0822.txt (100%) rename {server => project/server}/src/site/resources/rfclist/basic/rfc1123.txt (100%) rename {server => project/server}/src/site/resources/rfclist/basic/rfc2045.txt (100%) rename {server => project/server}/src/site/resources/rfclist/basic/rfc2046.txt (100%) rename {server => project/server}/src/site/resources/rfclist/basic/rfc2822.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc1731.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2060.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2086.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2087.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2088.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2177.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2180.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2192.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2193.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2195.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2221.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2342.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2359.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2595.txt (100%) rename {server => project/server}/src/site/resources/rfclist/imap4/rfc2683.txt (100%) rename {server => project/server}/src/site/resources/rfclist/ldap/rfc2251.txt (100%) rename {server => project/server}/src/site/resources/rfclist/ldap/rfc2252.txt (100%) rename {server => project/server}/src/site/resources/rfclist/ldap/rfc2253.txt (100%) rename {server => project/server}/src/site/resources/rfclist/ldap/rfc2254.txt (100%) rename {server => project/server}/src/site/resources/rfclist/ldap/rfc2255.txt (100%) rename {server => project/server}/src/site/resources/rfclist/ldap/rfc2256.txt (100%) rename {server => project/server}/src/site/resources/rfclist/ldap/rfc2829.txt (100%) rename {server => project/server}/src/site/resources/rfclist/ldap/rfc2830.txt (100%) rename {server => project/server}/src/site/resources/rfclist/ldap/rfc3377.txt (100%) rename {server => project/server}/src/site/resources/rfclist/nntp/draft-ietf-nntpext-base-13.txt (100%) rename {server => project/server}/src/site/resources/rfclist/nntp/rfc0977.txt (100%) rename {server => project/server}/src/site/resources/rfclist/nntp/rfc1036.txt (100%) rename {server => project/server}/src/site/resources/rfclist/nntp/rfc2980.txt (100%) rename {server => project/server}/src/site/resources/rfclist/pop3/rfc1725.txt (100%) rename {server => project/server}/src/site/resources/rfclist/pop3/rfc1734.txt (100%) rename {server => project/server}/src/site/resources/rfclist/pop3/rfc1939.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc0821.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc0974.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc1652.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc1830.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc1869.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc1870.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc1891.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc1893.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc1985.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc2034.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc2142.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc2197.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc2554.txt (100%) rename {server => project/server}/src/site/resources/rfclist/smtp/rfc2821.txt (100%) rename {server => project/server}/src/site/site.xml (100%) rename {server => project/server}/src/site/xdoc/FAQ.xml (100%) rename {server => project/server}/src/site/xdoc/archive/announcement_2_1.xml (100%) rename {server => project/server}/src/site/xdoc/archive/architecture_v1_2.xml (100%) rename {server => project/server}/src/site/xdoc/archive/architecture_v2_0.xml (100%) rename {server => project/server}/src/site/xdoc/archive/configuration_v2_0.xml (100%) rename {server => project/server}/src/site/xdoc/archive/document_archive.xml (100%) rename {server => project/server}/src/site/xdoc/archive/install.xml (100%) rename {server => project/server}/src/site/xdoc/archive/usingJDBC_v2.0.xml (100%) rename {server => project/server}/src/site/xdoc/archive/usingLDAP_v1_2.xml (100%) rename {server => project/server}/src/site/xdoc/archive/usingTLS_v1_2.xml (100%) rename {server => project/server}/src/site/xdoc/design_objectives.xml (100%) rename {server => project/server}/src/site/xdoc/index.xml (100%) rename {server => project/server}/src/site/xdoc/james_and_sendmail.xml (100%) rename {server => project/server}/src/site/xdoc/rfclist.xml (100%) rename {server => project/server}/src/site/xdoc/todo.xml (100%) diff --git a/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml similarity index 100% rename from server/2.2.0/pom.xml rename to project/server/2.2.0/pom.xml diff --git a/server/2.2.0/src/site/resources/images/asf-logo-reduced.gif b/project/server/2.2.0/src/site/resources/images/asf-logo-reduced.gif similarity index 100% rename from server/2.2.0/src/site/resources/images/asf-logo-reduced.gif rename to project/server/2.2.0/src/site/resources/images/asf-logo-reduced.gif diff --git a/server/2.2.0/src/site/resources/images/james-server-logo.gif b/project/server/2.2.0/src/site/resources/images/james-server-logo.gif similarity index 100% rename from server/2.2.0/src/site/resources/images/james-server-logo.gif rename to project/server/2.2.0/src/site/resources/images/james-server-logo.gif diff --git a/server/2.2.0/src/site/site.xml b/project/server/2.2.0/src/site/site.xml similarity index 100% rename from server/2.2.0/src/site/site.xml rename to project/server/2.2.0/src/site/site.xml diff --git a/server/2.2.0/src/site/xdoc/adding_users.xml b/project/server/2.2.0/src/site/xdoc/adding_users.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/adding_users.xml rename to project/server/2.2.0/src/site/xdoc/adding_users.xml diff --git a/server/2.2.0/src/site/xdoc/build_instructions.xml b/project/server/2.2.0/src/site/xdoc/build_instructions.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/build_instructions.xml rename to project/server/2.2.0/src/site/xdoc/build_instructions.xml diff --git a/server/2.2.0/src/site/xdoc/changelog.xml b/project/server/2.2.0/src/site/xdoc/changelog.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/changelog.xml rename to project/server/2.2.0/src/site/xdoc/changelog.xml diff --git a/server/2.2.0/src/site/xdoc/custom_mailet.xml b/project/server/2.2.0/src/site/xdoc/custom_mailet.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/custom_mailet.xml rename to project/server/2.2.0/src/site/xdoc/custom_mailet.xml diff --git a/server/2.2.0/src/site/xdoc/custom_matcher.xml b/project/server/2.2.0/src/site/xdoc/custom_matcher.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/custom_matcher.xml rename to project/server/2.2.0/src/site/xdoc/custom_matcher.xml diff --git a/server/2.2.0/src/site/xdoc/dns_configuration.xml b/project/server/2.2.0/src/site/xdoc/dns_configuration.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/dns_configuration.xml rename to project/server/2.2.0/src/site/xdoc/dns_configuration.xml diff --git a/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml b/project/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/fetchmail_configuration.xml rename to project/server/2.2.0/src/site/xdoc/fetchmail_configuration.xml diff --git a/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml b/project/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/fetchpop_configuration.xml rename to project/server/2.2.0/src/site/xdoc/fetchpop_configuration.xml diff --git a/server/2.2.0/src/site/xdoc/index.xml b/project/server/2.2.0/src/site/xdoc/index.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/index.xml rename to project/server/2.2.0/src/site/xdoc/index.xml diff --git a/server/2.2.0/src/site/xdoc/installation_instructions.xml b/project/server/2.2.0/src/site/xdoc/installation_instructions.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/installation_instructions.xml rename to project/server/2.2.0/src/site/xdoc/installation_instructions.xml diff --git a/server/2.2.0/src/site/xdoc/mailet_api.xml b/project/server/2.2.0/src/site/xdoc/mailet_api.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/mailet_api.xml rename to project/server/2.2.0/src/site/xdoc/mailet_api.xml diff --git a/server/2.2.0/src/site/xdoc/mailing_lists.xml b/project/server/2.2.0/src/site/xdoc/mailing_lists.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/mailing_lists.xml rename to project/server/2.2.0/src/site/xdoc/mailing_lists.xml diff --git a/server/2.2.0/src/site/xdoc/nntp_configuration.xml b/project/server/2.2.0/src/site/xdoc/nntp_configuration.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/nntp_configuration.xml rename to project/server/2.2.0/src/site/xdoc/nntp_configuration.xml diff --git a/server/2.2.0/src/site/xdoc/pop3_configuration.xml b/project/server/2.2.0/src/site/xdoc/pop3_configuration.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/pop3_configuration.xml rename to project/server/2.2.0/src/site/xdoc/pop3_configuration.xml diff --git a/server/2.2.0/src/site/xdoc/provided_mailets.xml b/project/server/2.2.0/src/site/xdoc/provided_mailets.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/provided_mailets.xml rename to project/server/2.2.0/src/site/xdoc/provided_mailets.xml diff --git a/server/2.2.0/src/site/xdoc/provided_matchers.xml b/project/server/2.2.0/src/site/xdoc/provided_matchers.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/provided_matchers.xml rename to project/server/2.2.0/src/site/xdoc/provided_matchers.xml diff --git a/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml b/project/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/remotemanager_configuration.xml rename to project/server/2.2.0/src/site/xdoc/remotemanager_configuration.xml diff --git a/server/2.2.0/src/site/xdoc/repositories.xml b/project/server/2.2.0/src/site/xdoc/repositories.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/repositories.xml rename to project/server/2.2.0/src/site/xdoc/repositories.xml diff --git a/server/2.2.0/src/site/xdoc/serverwide_configuration.xml b/project/server/2.2.0/src/site/xdoc/serverwide_configuration.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/serverwide_configuration.xml rename to project/server/2.2.0/src/site/xdoc/serverwide_configuration.xml diff --git a/server/2.2.0/src/site/xdoc/smtp_auth.xml b/project/server/2.2.0/src/site/xdoc/smtp_auth.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/smtp_auth.xml rename to project/server/2.2.0/src/site/xdoc/smtp_auth.xml diff --git a/server/2.2.0/src/site/xdoc/smtp_configuration.xml b/project/server/2.2.0/src/site/xdoc/smtp_configuration.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/smtp_configuration.xml rename to project/server/2.2.0/src/site/xdoc/smtp_configuration.xml diff --git a/server/2.2.0/src/site/xdoc/spoolmanager.xml b/project/server/2.2.0/src/site/xdoc/spoolmanager.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/spoolmanager.xml rename to project/server/2.2.0/src/site/xdoc/spoolmanager.xml diff --git a/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml b/project/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml rename to project/server/2.2.0/src/site/xdoc/spoolmanager_configuration.xml diff --git a/server/2.2.0/src/site/xdoc/summary.xml b/project/server/2.2.0/src/site/xdoc/summary.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/summary.xml rename to project/server/2.2.0/src/site/xdoc/summary.xml diff --git a/server/2.2.0/src/site/xdoc/usingTLS.xml b/project/server/2.2.0/src/site/xdoc/usingTLS.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/usingTLS.xml rename to project/server/2.2.0/src/site/xdoc/usingTLS.xml diff --git a/server/2.2.0/src/site/xdoc/using_database.xml b/project/server/2.2.0/src/site/xdoc/using_database.xml similarity index 100% rename from server/2.2.0/src/site/xdoc/using_database.xml rename to project/server/2.2.0/src/site/xdoc/using_database.xml diff --git a/server/pom.xml b/project/server/pom.xml similarity index 100% rename from server/pom.xml rename to project/server/pom.xml diff --git a/server/src/site/resources/css/site.css b/project/server/src/site/resources/css/site.css similarity index 100% rename from server/src/site/resources/css/site.css rename to project/server/src/site/resources/css/site.css diff --git a/server/src/site/resources/images/asf-logo-reduced.gif b/project/server/src/site/resources/images/asf-logo-reduced.gif similarity index 100% rename from server/src/site/resources/images/asf-logo-reduced.gif rename to project/server/src/site/resources/images/asf-logo-reduced.gif diff --git a/server/src/site/resources/images/james-server-logo.gif b/project/server/src/site/resources/images/james-server-logo.gif similarity index 100% rename from server/src/site/resources/images/james-server-logo.gif rename to project/server/src/site/resources/images/james-server-logo.gif diff --git a/server/src/site/resources/images/james_config_load_balance.png b/project/server/src/site/resources/images/james_config_load_balance.png similarity index 100% rename from server/src/site/resources/images/james_config_load_balance.png rename to project/server/src/site/resources/images/james_config_load_balance.png diff --git a/server/src/site/resources/images/james_config_secondary.png b/project/server/src/site/resources/images/james_config_secondary.png similarity index 100% rename from server/src/site/resources/images/james_config_secondary.png rename to project/server/src/site/resources/images/james_config_secondary.png diff --git a/server/src/site/resources/images/james_config_smart_host.png b/project/server/src/site/resources/images/james_config_smart_host.png similarity index 100% rename from server/src/site/resources/images/james_config_smart_host.png rename to project/server/src/site/resources/images/james_config_smart_host.png diff --git a/server/src/site/resources/rfclist/basic/rfc0822.txt b/project/server/src/site/resources/rfclist/basic/rfc0822.txt similarity index 100% rename from server/src/site/resources/rfclist/basic/rfc0822.txt rename to project/server/src/site/resources/rfclist/basic/rfc0822.txt diff --git a/server/src/site/resources/rfclist/basic/rfc1123.txt b/project/server/src/site/resources/rfclist/basic/rfc1123.txt similarity index 100% rename from server/src/site/resources/rfclist/basic/rfc1123.txt rename to project/server/src/site/resources/rfclist/basic/rfc1123.txt diff --git a/server/src/site/resources/rfclist/basic/rfc2045.txt b/project/server/src/site/resources/rfclist/basic/rfc2045.txt similarity index 100% rename from server/src/site/resources/rfclist/basic/rfc2045.txt rename to project/server/src/site/resources/rfclist/basic/rfc2045.txt diff --git a/server/src/site/resources/rfclist/basic/rfc2046.txt b/project/server/src/site/resources/rfclist/basic/rfc2046.txt similarity index 100% rename from server/src/site/resources/rfclist/basic/rfc2046.txt rename to project/server/src/site/resources/rfclist/basic/rfc2046.txt diff --git a/server/src/site/resources/rfclist/basic/rfc2822.txt b/project/server/src/site/resources/rfclist/basic/rfc2822.txt similarity index 100% rename from server/src/site/resources/rfclist/basic/rfc2822.txt rename to project/server/src/site/resources/rfclist/basic/rfc2822.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc1731.txt b/project/server/src/site/resources/rfclist/imap4/rfc1731.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc1731.txt rename to project/server/src/site/resources/rfclist/imap4/rfc1731.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2060.txt b/project/server/src/site/resources/rfclist/imap4/rfc2060.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2060.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2060.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2086.txt b/project/server/src/site/resources/rfclist/imap4/rfc2086.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2086.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2086.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2087.txt b/project/server/src/site/resources/rfclist/imap4/rfc2087.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2087.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2087.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2088.txt b/project/server/src/site/resources/rfclist/imap4/rfc2088.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2088.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2088.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2177.txt b/project/server/src/site/resources/rfclist/imap4/rfc2177.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2177.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2177.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2180.txt b/project/server/src/site/resources/rfclist/imap4/rfc2180.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2180.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2180.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2192.txt b/project/server/src/site/resources/rfclist/imap4/rfc2192.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2192.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2192.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2193.txt b/project/server/src/site/resources/rfclist/imap4/rfc2193.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2193.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2193.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2195.txt b/project/server/src/site/resources/rfclist/imap4/rfc2195.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2195.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2195.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2221.txt b/project/server/src/site/resources/rfclist/imap4/rfc2221.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2221.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2221.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2342.txt b/project/server/src/site/resources/rfclist/imap4/rfc2342.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2342.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2342.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2359.txt b/project/server/src/site/resources/rfclist/imap4/rfc2359.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2359.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2359.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2595.txt b/project/server/src/site/resources/rfclist/imap4/rfc2595.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2595.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2595.txt diff --git a/server/src/site/resources/rfclist/imap4/rfc2683.txt b/project/server/src/site/resources/rfclist/imap4/rfc2683.txt similarity index 100% rename from server/src/site/resources/rfclist/imap4/rfc2683.txt rename to project/server/src/site/resources/rfclist/imap4/rfc2683.txt diff --git a/server/src/site/resources/rfclist/ldap/rfc2251.txt b/project/server/src/site/resources/rfclist/ldap/rfc2251.txt similarity index 100% rename from server/src/site/resources/rfclist/ldap/rfc2251.txt rename to project/server/src/site/resources/rfclist/ldap/rfc2251.txt diff --git a/server/src/site/resources/rfclist/ldap/rfc2252.txt b/project/server/src/site/resources/rfclist/ldap/rfc2252.txt similarity index 100% rename from server/src/site/resources/rfclist/ldap/rfc2252.txt rename to project/server/src/site/resources/rfclist/ldap/rfc2252.txt diff --git a/server/src/site/resources/rfclist/ldap/rfc2253.txt b/project/server/src/site/resources/rfclist/ldap/rfc2253.txt similarity index 100% rename from server/src/site/resources/rfclist/ldap/rfc2253.txt rename to project/server/src/site/resources/rfclist/ldap/rfc2253.txt diff --git a/server/src/site/resources/rfclist/ldap/rfc2254.txt b/project/server/src/site/resources/rfclist/ldap/rfc2254.txt similarity index 100% rename from server/src/site/resources/rfclist/ldap/rfc2254.txt rename to project/server/src/site/resources/rfclist/ldap/rfc2254.txt diff --git a/server/src/site/resources/rfclist/ldap/rfc2255.txt b/project/server/src/site/resources/rfclist/ldap/rfc2255.txt similarity index 100% rename from server/src/site/resources/rfclist/ldap/rfc2255.txt rename to project/server/src/site/resources/rfclist/ldap/rfc2255.txt diff --git a/server/src/site/resources/rfclist/ldap/rfc2256.txt b/project/server/src/site/resources/rfclist/ldap/rfc2256.txt similarity index 100% rename from server/src/site/resources/rfclist/ldap/rfc2256.txt rename to project/server/src/site/resources/rfclist/ldap/rfc2256.txt diff --git a/server/src/site/resources/rfclist/ldap/rfc2829.txt b/project/server/src/site/resources/rfclist/ldap/rfc2829.txt similarity index 100% rename from server/src/site/resources/rfclist/ldap/rfc2829.txt rename to project/server/src/site/resources/rfclist/ldap/rfc2829.txt diff --git a/server/src/site/resources/rfclist/ldap/rfc2830.txt b/project/server/src/site/resources/rfclist/ldap/rfc2830.txt similarity index 100% rename from server/src/site/resources/rfclist/ldap/rfc2830.txt rename to project/server/src/site/resources/rfclist/ldap/rfc2830.txt diff --git a/server/src/site/resources/rfclist/ldap/rfc3377.txt b/project/server/src/site/resources/rfclist/ldap/rfc3377.txt similarity index 100% rename from server/src/site/resources/rfclist/ldap/rfc3377.txt rename to project/server/src/site/resources/rfclist/ldap/rfc3377.txt diff --git a/server/src/site/resources/rfclist/nntp/draft-ietf-nntpext-base-13.txt b/project/server/src/site/resources/rfclist/nntp/draft-ietf-nntpext-base-13.txt similarity index 100% rename from server/src/site/resources/rfclist/nntp/draft-ietf-nntpext-base-13.txt rename to project/server/src/site/resources/rfclist/nntp/draft-ietf-nntpext-base-13.txt diff --git a/server/src/site/resources/rfclist/nntp/rfc0977.txt b/project/server/src/site/resources/rfclist/nntp/rfc0977.txt similarity index 100% rename from server/src/site/resources/rfclist/nntp/rfc0977.txt rename to project/server/src/site/resources/rfclist/nntp/rfc0977.txt diff --git a/server/src/site/resources/rfclist/nntp/rfc1036.txt b/project/server/src/site/resources/rfclist/nntp/rfc1036.txt similarity index 100% rename from server/src/site/resources/rfclist/nntp/rfc1036.txt rename to project/server/src/site/resources/rfclist/nntp/rfc1036.txt diff --git a/server/src/site/resources/rfclist/nntp/rfc2980.txt b/project/server/src/site/resources/rfclist/nntp/rfc2980.txt similarity index 100% rename from server/src/site/resources/rfclist/nntp/rfc2980.txt rename to project/server/src/site/resources/rfclist/nntp/rfc2980.txt diff --git a/server/src/site/resources/rfclist/pop3/rfc1725.txt b/project/server/src/site/resources/rfclist/pop3/rfc1725.txt similarity index 100% rename from server/src/site/resources/rfclist/pop3/rfc1725.txt rename to project/server/src/site/resources/rfclist/pop3/rfc1725.txt diff --git a/server/src/site/resources/rfclist/pop3/rfc1734.txt b/project/server/src/site/resources/rfclist/pop3/rfc1734.txt similarity index 100% rename from server/src/site/resources/rfclist/pop3/rfc1734.txt rename to project/server/src/site/resources/rfclist/pop3/rfc1734.txt diff --git a/server/src/site/resources/rfclist/pop3/rfc1939.txt b/project/server/src/site/resources/rfclist/pop3/rfc1939.txt similarity index 100% rename from server/src/site/resources/rfclist/pop3/rfc1939.txt rename to project/server/src/site/resources/rfclist/pop3/rfc1939.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc0821.txt b/project/server/src/site/resources/rfclist/smtp/rfc0821.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc0821.txt rename to project/server/src/site/resources/rfclist/smtp/rfc0821.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc0974.txt b/project/server/src/site/resources/rfclist/smtp/rfc0974.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc0974.txt rename to project/server/src/site/resources/rfclist/smtp/rfc0974.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc1652.txt b/project/server/src/site/resources/rfclist/smtp/rfc1652.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc1652.txt rename to project/server/src/site/resources/rfclist/smtp/rfc1652.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc1830.txt b/project/server/src/site/resources/rfclist/smtp/rfc1830.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc1830.txt rename to project/server/src/site/resources/rfclist/smtp/rfc1830.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc1869.txt b/project/server/src/site/resources/rfclist/smtp/rfc1869.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc1869.txt rename to project/server/src/site/resources/rfclist/smtp/rfc1869.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc1870.txt b/project/server/src/site/resources/rfclist/smtp/rfc1870.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc1870.txt rename to project/server/src/site/resources/rfclist/smtp/rfc1870.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc1891.txt b/project/server/src/site/resources/rfclist/smtp/rfc1891.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc1891.txt rename to project/server/src/site/resources/rfclist/smtp/rfc1891.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc1893.txt b/project/server/src/site/resources/rfclist/smtp/rfc1893.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc1893.txt rename to project/server/src/site/resources/rfclist/smtp/rfc1893.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc1985.txt b/project/server/src/site/resources/rfclist/smtp/rfc1985.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc1985.txt rename to project/server/src/site/resources/rfclist/smtp/rfc1985.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc2034.txt b/project/server/src/site/resources/rfclist/smtp/rfc2034.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc2034.txt rename to project/server/src/site/resources/rfclist/smtp/rfc2034.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc2142.txt b/project/server/src/site/resources/rfclist/smtp/rfc2142.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc2142.txt rename to project/server/src/site/resources/rfclist/smtp/rfc2142.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc2197.txt b/project/server/src/site/resources/rfclist/smtp/rfc2197.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc2197.txt rename to project/server/src/site/resources/rfclist/smtp/rfc2197.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc2554.txt b/project/server/src/site/resources/rfclist/smtp/rfc2554.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc2554.txt rename to project/server/src/site/resources/rfclist/smtp/rfc2554.txt diff --git a/server/src/site/resources/rfclist/smtp/rfc2821.txt b/project/server/src/site/resources/rfclist/smtp/rfc2821.txt similarity index 100% rename from server/src/site/resources/rfclist/smtp/rfc2821.txt rename to project/server/src/site/resources/rfclist/smtp/rfc2821.txt diff --git a/server/src/site/site.xml b/project/server/src/site/site.xml similarity index 100% rename from server/src/site/site.xml rename to project/server/src/site/site.xml diff --git a/server/src/site/xdoc/FAQ.xml b/project/server/src/site/xdoc/FAQ.xml similarity index 100% rename from server/src/site/xdoc/FAQ.xml rename to project/server/src/site/xdoc/FAQ.xml diff --git a/server/src/site/xdoc/archive/announcement_2_1.xml b/project/server/src/site/xdoc/archive/announcement_2_1.xml similarity index 100% rename from server/src/site/xdoc/archive/announcement_2_1.xml rename to project/server/src/site/xdoc/archive/announcement_2_1.xml diff --git a/server/src/site/xdoc/archive/architecture_v1_2.xml b/project/server/src/site/xdoc/archive/architecture_v1_2.xml similarity index 100% rename from server/src/site/xdoc/archive/architecture_v1_2.xml rename to project/server/src/site/xdoc/archive/architecture_v1_2.xml diff --git a/server/src/site/xdoc/archive/architecture_v2_0.xml b/project/server/src/site/xdoc/archive/architecture_v2_0.xml similarity index 100% rename from server/src/site/xdoc/archive/architecture_v2_0.xml rename to project/server/src/site/xdoc/archive/architecture_v2_0.xml diff --git a/server/src/site/xdoc/archive/configuration_v2_0.xml b/project/server/src/site/xdoc/archive/configuration_v2_0.xml similarity index 100% rename from server/src/site/xdoc/archive/configuration_v2_0.xml rename to project/server/src/site/xdoc/archive/configuration_v2_0.xml diff --git a/server/src/site/xdoc/archive/document_archive.xml b/project/server/src/site/xdoc/archive/document_archive.xml similarity index 100% rename from server/src/site/xdoc/archive/document_archive.xml rename to project/server/src/site/xdoc/archive/document_archive.xml diff --git a/server/src/site/xdoc/archive/install.xml b/project/server/src/site/xdoc/archive/install.xml similarity index 100% rename from server/src/site/xdoc/archive/install.xml rename to project/server/src/site/xdoc/archive/install.xml diff --git a/server/src/site/xdoc/archive/usingJDBC_v2.0.xml b/project/server/src/site/xdoc/archive/usingJDBC_v2.0.xml similarity index 100% rename from server/src/site/xdoc/archive/usingJDBC_v2.0.xml rename to project/server/src/site/xdoc/archive/usingJDBC_v2.0.xml diff --git a/server/src/site/xdoc/archive/usingLDAP_v1_2.xml b/project/server/src/site/xdoc/archive/usingLDAP_v1_2.xml similarity index 100% rename from server/src/site/xdoc/archive/usingLDAP_v1_2.xml rename to project/server/src/site/xdoc/archive/usingLDAP_v1_2.xml diff --git a/server/src/site/xdoc/archive/usingTLS_v1_2.xml b/project/server/src/site/xdoc/archive/usingTLS_v1_2.xml similarity index 100% rename from server/src/site/xdoc/archive/usingTLS_v1_2.xml rename to project/server/src/site/xdoc/archive/usingTLS_v1_2.xml diff --git a/server/src/site/xdoc/design_objectives.xml b/project/server/src/site/xdoc/design_objectives.xml similarity index 100% rename from server/src/site/xdoc/design_objectives.xml rename to project/server/src/site/xdoc/design_objectives.xml diff --git a/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml similarity index 100% rename from server/src/site/xdoc/index.xml rename to project/server/src/site/xdoc/index.xml diff --git a/server/src/site/xdoc/james_and_sendmail.xml b/project/server/src/site/xdoc/james_and_sendmail.xml similarity index 100% rename from server/src/site/xdoc/james_and_sendmail.xml rename to project/server/src/site/xdoc/james_and_sendmail.xml diff --git a/server/src/site/xdoc/rfclist.xml b/project/server/src/site/xdoc/rfclist.xml similarity index 100% rename from server/src/site/xdoc/rfclist.xml rename to project/server/src/site/xdoc/rfclist.xml diff --git a/server/src/site/xdoc/todo.xml b/project/server/src/site/xdoc/todo.xml similarity index 100% rename from server/src/site/xdoc/todo.xml rename to project/server/src/site/xdoc/todo.xml From 9c2af32f1a98c3d38e1a3d12cc0dfb1ce405fb28 Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 10 May 2007 16:21:27 +0000 Subject: [PATCH 052/541] Refactoring james-project layout to make poms tree consistent with folder tree. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536918 13f79535-47bb-0310-9956-ffa450edef68 --- {src => project/src}/site/resources/css/site.css | 0 {src => project/src}/site/resources/download.cgi | 0 .../src}/site/resources/downloadunstable.cgi | 0 {src => project/src}/site/resources/favicon.ico | Bin .../src}/site/resources/images/asf-logo-reduced.gif | Bin .../site/resources/images/james-project-logo.gif | Bin {src => project/src}/site/resources/robots.txt | 0 {src => project/src}/site/site.xml | 0 {src => project/src}/site/xdoc/code-standards.xml | 0 {src => project/src}/site/xdoc/contribute.xml | 0 {src => project/src}/site/xdoc/download.xml | 0 {src => project/src}/site/xdoc/downloadunstable.xml | 0 {src => project/src}/site/xdoc/guidelines.xml | 0 {src => project/src}/site/xdoc/index.xml | 0 {src => project/src}/site/xdoc/license.xml | 0 {src => project/src}/site/xdoc/mail.xml | 0 {src => project/src}/site/xdoc/newsarchive.xml | 0 {src => project/src}/site/xdoc/weare.xml | 0 18 files changed, 0 insertions(+), 0 deletions(-) rename {src => project/src}/site/resources/css/site.css (100%) rename {src => project/src}/site/resources/download.cgi (100%) rename {src => project/src}/site/resources/downloadunstable.cgi (100%) rename {src => project/src}/site/resources/favicon.ico (100%) rename {src => project/src}/site/resources/images/asf-logo-reduced.gif (100%) rename {src => project/src}/site/resources/images/james-project-logo.gif (100%) rename {src => project/src}/site/resources/robots.txt (100%) rename {src => project/src}/site/site.xml (100%) rename {src => project/src}/site/xdoc/code-standards.xml (100%) rename {src => project/src}/site/xdoc/contribute.xml (100%) rename {src => project/src}/site/xdoc/download.xml (100%) rename {src => project/src}/site/xdoc/downloadunstable.xml (100%) rename {src => project/src}/site/xdoc/guidelines.xml (100%) rename {src => project/src}/site/xdoc/index.xml (100%) rename {src => project/src}/site/xdoc/license.xml (100%) rename {src => project/src}/site/xdoc/mail.xml (100%) rename {src => project/src}/site/xdoc/newsarchive.xml (100%) rename {src => project/src}/site/xdoc/weare.xml (100%) diff --git a/src/site/resources/css/site.css b/project/src/site/resources/css/site.css similarity index 100% rename from src/site/resources/css/site.css rename to project/src/site/resources/css/site.css diff --git a/src/site/resources/download.cgi b/project/src/site/resources/download.cgi similarity index 100% rename from src/site/resources/download.cgi rename to project/src/site/resources/download.cgi diff --git a/src/site/resources/downloadunstable.cgi b/project/src/site/resources/downloadunstable.cgi similarity index 100% rename from src/site/resources/downloadunstable.cgi rename to project/src/site/resources/downloadunstable.cgi diff --git a/src/site/resources/favicon.ico b/project/src/site/resources/favicon.ico similarity index 100% rename from src/site/resources/favicon.ico rename to project/src/site/resources/favicon.ico diff --git a/src/site/resources/images/asf-logo-reduced.gif b/project/src/site/resources/images/asf-logo-reduced.gif similarity index 100% rename from src/site/resources/images/asf-logo-reduced.gif rename to project/src/site/resources/images/asf-logo-reduced.gif diff --git a/src/site/resources/images/james-project-logo.gif b/project/src/site/resources/images/james-project-logo.gif similarity index 100% rename from src/site/resources/images/james-project-logo.gif rename to project/src/site/resources/images/james-project-logo.gif diff --git a/src/site/resources/robots.txt b/project/src/site/resources/robots.txt similarity index 100% rename from src/site/resources/robots.txt rename to project/src/site/resources/robots.txt diff --git a/src/site/site.xml b/project/src/site/site.xml similarity index 100% rename from src/site/site.xml rename to project/src/site/site.xml diff --git a/src/site/xdoc/code-standards.xml b/project/src/site/xdoc/code-standards.xml similarity index 100% rename from src/site/xdoc/code-standards.xml rename to project/src/site/xdoc/code-standards.xml diff --git a/src/site/xdoc/contribute.xml b/project/src/site/xdoc/contribute.xml similarity index 100% rename from src/site/xdoc/contribute.xml rename to project/src/site/xdoc/contribute.xml diff --git a/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml similarity index 100% rename from src/site/xdoc/download.xml rename to project/src/site/xdoc/download.xml diff --git a/src/site/xdoc/downloadunstable.xml b/project/src/site/xdoc/downloadunstable.xml similarity index 100% rename from src/site/xdoc/downloadunstable.xml rename to project/src/site/xdoc/downloadunstable.xml diff --git a/src/site/xdoc/guidelines.xml b/project/src/site/xdoc/guidelines.xml similarity index 100% rename from src/site/xdoc/guidelines.xml rename to project/src/site/xdoc/guidelines.xml diff --git a/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml similarity index 100% rename from src/site/xdoc/index.xml rename to project/src/site/xdoc/index.xml diff --git a/src/site/xdoc/license.xml b/project/src/site/xdoc/license.xml similarity index 100% rename from src/site/xdoc/license.xml rename to project/src/site/xdoc/license.xml diff --git a/src/site/xdoc/mail.xml b/project/src/site/xdoc/mail.xml similarity index 100% rename from src/site/xdoc/mail.xml rename to project/src/site/xdoc/mail.xml diff --git a/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml similarity index 100% rename from src/site/xdoc/newsarchive.xml rename to project/src/site/xdoc/newsarchive.xml diff --git a/src/site/xdoc/weare.xml b/project/src/site/xdoc/weare.xml similarity index 100% rename from src/site/xdoc/weare.xml rename to project/src/site/xdoc/weare.xml From f904f4690016d6e4babff23cc7bdc875966bc0b6 Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 10 May 2007 16:21:39 +0000 Subject: [PATCH 053/541] Refactoring james-project layout to make poms tree consistent with folder tree. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536919 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml => project/pom.xml | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename pom.xml => project/pom.xml (100%) diff --git a/pom.xml b/project/pom.xml similarity index 100% rename from pom.xml rename to project/pom.xml From 9c48e7786a781db5c1ddd61d79308388820ca182 Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 10 May 2007 16:22:07 +0000 Subject: [PATCH 054/541] Refactoring james-project layout to make poms tree consistent with folder tree. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536920 13f79535-47bb-0310-9956-ffa450edef68 --- {parent/src => src}/site/site.xml | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename {parent/src => src}/site/site.xml (100%) diff --git a/parent/src/site/site.xml b/src/site/site.xml similarity index 100% rename from parent/src/site/site.xml rename to src/site/site.xml From 488a2378b42176156a2c8f54c409a42f21b6ee89 Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 10 May 2007 16:22:14 +0000 Subject: [PATCH 055/541] Refactoring james-project layout to make poms tree consistent with folder tree. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536921 13f79535-47bb-0310-9956-ffa450edef68 --- parent/pom.xml => pom.xml | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename parent/pom.xml => pom.xml (100%) diff --git a/parent/pom.xml b/pom.xml similarity index 100% rename from parent/pom.xml rename to pom.xml From 900f692019b7f3ec443dd62b5089a071454ad1df Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 10 May 2007 16:40:42 +0000 Subject: [PATCH 056/541] Refactoring james-project layout to make poms tree consistent with folder tree. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536929 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO.txt | 34 +- maven-skin/pom.xml | 2 +- pom.xml | 31 +- project/pom.xml | 8 +- .../jars/maven-default-skin-1.0.jar | Bin 0 -> 8168 bytes .../poms/maven-default-skin-1.0.pom | 324 ++++++++++++++++++ 6 files changed, 376 insertions(+), 23 deletions(-) create mode 100644 stage/org.apache.maven.skins/jars/maven-default-skin-1.0.jar create mode 100644 stage/org.apache.maven.skins/poms/maven-default-skin-1.0.pom diff --git a/HOWTO.txt b/HOWTO.txt index c9b1580dc8a..327890c4f10 100644 --- a/HOWTO.txt +++ b/HOWTO.txt @@ -1,21 +1,25 @@ How to build and publish the website: 1. Install Apache Maven 2.0.6 and make its binary 'mvn' available on your PATH. - 2. Enter parent folder and execute 'mvn -Plocal install'. This will generate the - artifacts and install them without trying to remove them from remote repositories - (by using the "local" profile defined in the pom.xml). - 3. Enter the maven-skin folder and execute 'mvn install'. - 4. Return to the root and execute 'mvn -Plocal site'. This will generate the website for - each module. - 5. Test the built site in your browser from target/site - 6. If everything looks OK, copy target/site to the checkout of james/site/trunk/www folder - server/target/site to the checkout of james/site/trunk/www/server folder - server/2.2.0/target/site to the checkout of james/site/trunk/www/server/2.2.0 folder - 7. If you are on windows make sure endlines are LF only. - 8. Commit changes to SVN - 9. Review generated pages on svn.apache.org/repos/asf/james/site/trunk/www -10. svn-up on minotaur -11. Wait for the changes to replicate to the Apache web server or setup 140.211.11.10:80 as + 2. run "mvn -U -Plocal,parent clean install site:stage -DstagingDirectory={path}". + - the -U will force mvn to update plugins (check new installed skin when building + the project site. + - the -Plocal will force mvn to not lookup remote maven repositories for standard + dependencies. + - the -Pparent will add the local "stage" repository to the build (this is needed + so that the site generation for the parent folder will find the default maven + skin (this is only a workaround: the default skin is not used). + - install is needed because the site generated in the project module will search + for an installed skin. + 3. Test the built site in your browser from the {path} folder + 4. If everything looks OK, copy the {path} folder to the checkout of james/site/trunk/www + folder. + 5. If you are on windows make sure endlines are LF only + hint: running "ant" from james/site/trunk/ will do this (this will take a lot). + 6. Commit changes to SVN + 7. Review generated pages on svn.apache.org/repos/asf/james/site/trunk/www + 8. svn-up on minotaur + 9. Wait for the changes to replicate to the Apache web server or setup 140.211.11.10:80 as a proxy to review the changes (described here: http://www.apache.org/dev/project-site.html) The logical tree of the poms is the following diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index c687a47a2f5..c82bb61f8ce 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -30,7 +30,7 @@ org.apache.james james-parent 1.1-SNAPSHOT - ../parent/pom.xml + ../pom.xml diff --git a/pom.xml b/pom.xml index f5d7905a865..3aa539c5a15 100644 --- a/pom.xml +++ b/pom.xml @@ -30,6 +30,11 @@ 2.0.6 + + + maven-skin + project + http://james.apache.org/ 2006 @@ -161,9 +166,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/parent - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/parent - http://svn.apache.org/viewvc/james/project/trunk/parent + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk @@ -220,6 +225,26 @@ + + + parent + + + local-james-parent-stage + Apache JAMES parent stage repository folder + file://${basedir}/stage + legacy + + true + ignore + + + true + ignore + + + + local diff --git a/project/pom.xml b/project/pom.xml index cc97bb199e9..c8b6610b332 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -31,7 +31,7 @@ org.apache.james james-parent 1.1-SNAPSHOT - parent/pom.xml + ../pom.xml @@ -51,9 +51,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk - http://svn.apache.org/viewvc/james/project/trunk + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/project + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/project + http://svn.apache.org/viewvc/james/project/trunk/project diff --git a/stage/org.apache.maven.skins/jars/maven-default-skin-1.0.jar b/stage/org.apache.maven.skins/jars/maven-default-skin-1.0.jar new file mode 100644 index 0000000000000000000000000000000000000000..48697b52845f353f560d628f9bdc2665df01ae7f GIT binary patch literal 8168 zcmcI}1yqz<_de1}cM3`?DP4kybji@&4Bd@@lp+I2cS%YJA~|$O!+?N*g!BNCLpQ(S zUX}ad{nq-g^{xM5z3)3~*!wx>?Ad$2XFvP791`*!gsXvPozMN(ho86G@TY==su-(` zq9ptCpJM0;xNxyiug23B_`h9mAs`U`Q%pfjQASciMU_oKGA*+EPAdnY#G(J0xbMAO zHkU7YX-~xP9@^3KR&$T%(fha_c?wy~t4i|TLdySAGLYsLnL%~kKVo8-W4px740-Ojzm(jF00 z5w9e{_IOdVqBDR-3ZEjBPMN*Sqk zp#5Uasw`!|cK~>wlkLrdoUs_9vmA|TRj25KJ1}YHWeIMg9oBm@%?^bt(JyX!A~2G& ziBgEs%c__?#*lngC)pS3j^5>^GHIOLrnwsPo#K|c4B$gWKU1J3R>fX-OVKVrhwXa; zZIox0C`3~Cg1sJmON^gD2KCc^7{G45gO<7n*%IYljumixN&ikP3&+sQ=B+7t1+~-uTrVIRdW%~@4f#fq;T{@#%jK>H@e^TBU5fdE8canxwB15J6chFq+dTJmUx&XVe!(* z{J_$psFpQr)`&VyUfGq>YT3mr*@Tj!V?v12NlANCMNM1o5h0@e52usat+^L4MRf_g zCtr}5_s8Dd6~uvsTTG zrlG56>2jKeF{S+BlTEKT1=ne19#+R9gi4&^)epDCpD0slX1s3Y)%+B>1 zF$J|vQj&oR^@H21hAem4aes3zkJ=M(v9qiN;_r0yw=p7=XL}bB5fFCZxrFT67?vjX zb_QlnPWDa)&bBseKudGyLznW8@{7P(;1L7?@$&L=Yl(R3Gh=O(k_%79im`swQ^oIh z*e*EPE_5AN?~Y=}Of?M2_v!1`QVu|zBMpp&GRAeOq6CCn%RPfqYLGbvJhH!e9>C<* zmlDQr$1Wvk_A^$6X}F-i-FBgxvlMQP@eHb~2^OqDS*t;|0waeC9AgL^-{C*r;XkGs z2e*xTz8J58!b1C&h-{aLZJ@+9i^MDo_+4|0lZ;Gyova?x&wSG&`|dx=4VM)Jv23LD z6&Ljvp8$r^?Y4&XbGl?10qIbWz z2^K870cOr~{Fg0hXNEg27{ksYCXxNXj)xVNgJk8iT+nxi$$6<|p~ALAo}&!VFxNe; z$(r(mH^95m5TRUO-^&*9mO-8F&*ERk62i6; zo7O;MH*#vbDmgZ(a@F}%mapGRfRtqPY@zKn2@chZ)9tyfnWiSc%ZvTBu>^L5mySIg zcR~@@m6<_VQjMBNx*lXD z<9$ppGTe<1+>|JVxCl~{2#+@#V%-Q0X6!~cHF#*~!!Obspm(rKTT0;+W?9SR*VQ?X&PpI3sC zQ<28gY-`hCXOA~P-83ClGpmKduy~%;{-Sd2F=$0;?}nzqVC8+9{JI=>6|Kwo*dDSa zf~pbuZ~A<$Ql48AuU3WR>eQh;5bLDMI!|cH=r`}elTnxc8H4ZO9PgHk@4;vcECM5f zKEr)Hoxoy|QEtnn9ErM#yb}GI)xA%)%j%o;AKeCWdFt392F`{H7t9m~df&ZPCL*%= z4pM7exBI5smN)MTdbPih3cAf*tTMla=zBXse=PJ?XBgD(uYW#HVW07ZZ+T;E ztEutD>GAOz&g)3T&cW86#;=t=y?G_Vg7$6QOF9vo!fp%A-9pWV{piNufyYx^X0et^_NFWr`6O=zL&=s zpD!=Ykx(BXIX;0gV$dRq;{{@eAcYd39!z6NDD<;_P`GWmdRySpgJNBg&3?z=VEJQ| zK2LwJjF#7iygZkW*?A1-*$@d~`yy94a-yRYFz@g^Z|=uFh$~Nb#9O)jDC>DlblE<` zg$Q}*wnMaqv1nQxafj`~(!62kXo2b|oyNTYv>! zT9~eNG@kBrd+Q&rXz-}_T^8I8zr(XM#SK?4&?=sDLLbu1iaG_q!V%=3lDn+Yi@8C3giLfe=R)3MoXqQ4H=YuBjDs)>JV zRoB*&`!cSpE@ja6O?>)`LO(=CaYkBQPHMPcMOWrgCX+WLofU+=-jzHt`pI0eJ9Se+ ziVsYG%2&F<=Uy%1wefk105qnn13o{9zkA3>Ca`MjRpYXoZ8k|=`WgU?`~&ZvGG zl~B9gTwMGzHMQHiV#1 zVhNz)n}}by?GIs4g(tC0d4Kjv7)>2!V9H*-EH@G}mXOlx>dkN#J^aLpjrgfKK_B4$ zdPDfv7%pf@n#1M^%ss=PGS!KFa`SoZR}t?5wGQFkAejz*3G)5ddJ7EXXrn90W2?2M z??*Qs9s5<+L`Z5@SF)^eAn8rM^RP9cbg-2_(ZmIPa^o?1>37lnZslEh4Ob=g#2@r2Y_6vXE zXLifz@~q6Lq;M5=#@S9(EEH7h8(9_$0r3?t+_j&;ubZyzZscTVX$Sn%wSOksnMc6m zlHj5keEeRJ72_dmQkmgcE79qgjiCBi^*ghnyy9dO&=|E6^QIL%2#yb&C*SIdI$d04 zFJgNE=Ve%mg~4lI`zUko60~nm*Pb2`pTZO!mtg>-Q!TcWGR;MwsIDT!sL7r|g)OHnwF|Yx<^!MXq{{VS`1G_@iZVwQJb0H_hlXSy8W}pv)pLZhgQC%%^5mlx=zlEYur_ zJ<}?66qMTlmd_2CXB*f;fljV^VX6a!iD&S0{MTjA?2aY*g0|8JQBCG_B5UCSDikga zv|d_Td!=A-y1FDVg}|4c<+LH^;&2C=LIASe=jP6B_bvS~8Xq?p9e32=HouGV!7G$A zA)jwz<$Z(hkac06MQ(0wK?6WeGOMU~c0XA_n=@L_X{h!SfO#Ut{HxmC3{f1?ddwRC zc_m^=)K{FScX81O88O$LDSDEVb+jk>llUjJQFaMbBx+NVRE)DhjBzk?P6*cA4`SBv zlwML?wy6#(g36Jxm{K*S$22Ylb=jaN7&;EmX93=x1o7rk9Dbr(xyjKzkTV5OeJZ;W z)GB=F4|8o}vnfSvr=3E%O4b~g&z??%gbHyi2|dzlTC1nAOa<>PSIBkF6YnKXL1;;i zB^RYsv`b?hcLHe%;u2u8ntYrbnn*X?4U_#l-XJ`KUKIdWjKj~vznz)8yQQ6}z5D;) z(?7)2@CXMLi{uH)%0lNIwY8ild2xLQN@o`<CESASjcCeXIfrI zW#sh5M^=vD&pTn{#!WB{#Xq*g2U_@BDox=(%o>cMXeR?oV6%1rePXjsBTgqW?Xh}% zvu%+=GbD_TRlwNRGs+zd{O2}8ew#QaflM}C>Fdx+46}gz_tLqqMkEQ9W9N>ZuA-EN z>2r*D)h@gVoRgM-W+fU%IYi5SJqVvYU_KAXhw1j5(P1iV6W@M$hbLl?r1TSD^jQd^ z!M#v({-R}tDU3JeN3R?RgR6|ZDD4ZYalkK^-{Ve9Czj_n&$Ta2PKd3*aOq9sdV`c@ zER;=)&dFnO!i?t(9}7@X;ymq~Ld|3dY?;E%9Iv=5^WgdYM}qX_0ol>xg=h*4lo)sv z+0U3mhIz*#5!Fknxc0E`$P79dR0kUs_bWcL2-pw0e1rEk0}D0sNFhnl^BF)hfjT6T z7hOZuq*P@$44~f3-xGx%tDcr=4hSuit$Gv@rM96)gM(D*CGbS-u{i(JfqNw~0`d@q zCze}fU(Rzm=etu`9Mah6HnfsbI0`Ax(!#%`=}|9jztiqBM;3Z~mzWQBqL_Pz`gH#j zu7OzoT|*_#@O@fkOH@&WsD#aEodKYUt1rrje#Zk-ca;KuBUG^MKpWLZZ=BCIHJ_(IdXs6j&c2%4B>WT$wqGtCxW@@Zx|oX1r_5$u6C09eU^yslBkp zSbiwKF7YbJkP2U>gPT5ofEq5~d5^`T=;XG9K5^K772Qkw zWIVxRk)&o%G3w``@ADxF@j<8>YE7j*aijTUP_Dj5Q=y+KZFET+^t$+gT9P?a>7a$j z;I7QaQd$XbFq}Yv%#*9{TFBEOs@Ak92HT19TY>lGFnj_$<=MQNHoM#V>BL&And^bh zw=PR+7Xpi6@dHX`)HTnFiF%Qv|2 zkUCMh#`orWk3C3xMg2XksgbgA)8EnHyUendlmZFd(mS~r(tVDQdmb95FoF9TSb++3 zOQ(R=S>yx@X591;l*eUJElPZxOOip-^8Gx0B4slAgF0K{DO?WBose_3_Oa7Fu*Z;j z{gR2;Hm6pIFDI>zSAqT!3rLyITEVS?YXOUS<(W13_#*=arGYK=mzsN)$80Q`Ed*zw z4$XZ>KB=i;P?k1YA2JHDMA~qZoT%{HL`nRXMi!}AKCl@|;x_U~<^n3~h@6G>i#0XT zPHY_?!@`oOC)u0C$}3}BCek(f72eqR4dmmJTf0W}flm5eNM3A{4=7{HCMI;Stp=&7 zyDQ1-G>#8FIUhOLFjTU|<$f-xh>_}g-&0no6`ts_Z-=a09V|ZW%IKnT;xV@tt4;08 z7nxV=P%EuRj8JYvKz61RHyJ-^WHL-|RHVpJPyP-*{2eYT3Z)N0RNH}x0&mQht? z4G%jB;%zYe1}RM5c!?fsHoNmbI?P9{mz|QO<8P*UaNn_qlw8WYh}(pTNFgb%gAW~& zbfPg#w?5uXR!tE|OIRnrL`9h*SkBXao*no}=WE9$BUlYK6FK1*#Q|*ie!V!rCj1chA~QlRHt%)vcn2|l@K>Y9L*B&xKFO-D z{bg0D>DIrmLb>uRQlB0u8Yw&xOi)-}9O3>_G_)QUkfqy~v{w&|)gUaw)72;|Zv0f` zW|YF}7DVMP`TjB#w@U2fxrXB=LY+yrLs94L2;sL=&^0S8PExiv@=%jkN2WZ6L_d_9 zPSSz6qB=+emXnrMWFFIL=jxpklpJ+?M1gf@KJs&)dVA9*d(?q#P3;?TugcY^Y{iP+ zrbblcXojN|#Y5DmHv41*kSW$1l9IHFBrWPcxj=l=_dby5c3<@Do8xG=Fn6|lL7rtb zMG^GSJ*=s_i0?H!oqi%g6|Xbu)?1cptwgg4kk(HkNtAEGwo_9bMN(ns5*kZZ)1=|q zXDgqq*;OoZ7-gc<%JOujfQoKQDV zoDg1*^?87M0H9E=-CY~3eM}GV5NJmZLs-RT7c{hwkAWY<1=x2I%UdA=0-;2^PV~fa zrg`)X2?%j7+g()v!}xN}vMypf^}6uQ-9jWp`tMyc_zvL%7hyx}>iPSicCGgBU9>CV ztC8c+2*3YU`$tdh8sX2D(^XUI?{PITIlMFXcZ=$JsaKu5Uouxu_#y1)xY7`YYy56m z{Zjh(rqwUC9Dk#q)7)rbU9a=ssrzeyRQR(0g~-1NaFg!71}H%J4e%%VeG}#;HFyp4 z8T~(D{z(+xM7hc8T%#yq{3pr{j^`%O%^La|=ppuh0^O*nZvx${j;?`{aDM~+N3C>? z@aJLws=D}lT=_)`-amZtSFQ2OKmJs{sy42byZ%)EueHa2$GoaOt}!w3|5(s}!Ti@+ zkD97LAf0^cIZE|hpf6s&0vuTk351YE0?K&$ymqS6l0>*{^rNhIE`-+}H F_&-1U + + maven-skins + org.apache.maven.skins + 2 + + 4.0.0 + org.apache.maven.skins + maven-default-skin + Maven Default Skin + 1.0 + Maven Default Skin + http://maven.apache.org/skins/maven-default-skin + + jira + http://jira.codehaus.org/browse/MNG + + + continuum + http://maven.zones.apache.org:8080/continuum + + + +
    notifications@maven.apache.org
    +     +     +     +     + 2002 + + + Maven Announcements List + announce-subscribe@maven.apache.org + announce-unsubscribe@maven.apache.org + announce@maven.apache.org + http://mail-archives.apache.org/mod_mbox/maven-announce/ + + + Maven Issues List + issues-subscribe@maven.apache.org + issues-unsubscribe@maven.apache.org + issues@maven.apache.org + http://mail-archives.apache.org/mod_mbox/maven-issues/ + + + Maven Notifications List + notifications-subscribe@maven.apache.org + notifications-unsubscribe@maven.apache.org + notifications@maven.apache.org + http://mail-archives.apache.org/mod_mbox/maven-notifications/ + + + + + jvanzyl + Jason van Zyl + jason@maven.org + ASF + + PMC Chair + + -5 + + + brett + Brett Porter + brett@apache.org + ASF + + PMC Member + + +10 + + + evenisse + Emmanuel Venisse + evenisse@apache.org + ASF + + PMC Member + + + + kenney + Kenney Westerhof + kenney@apache.org + Neonics + + PMC Member + + + + snicoll + Stephane Nicoll + snicoll@apache.org + ASF + + PMC Member + + +1 + + + vmassol + Vincent Massol + vmassol@apache.org + ASF + + PMC Member + + +1 + + + fgiust + Fabrizio Giustina + fgiust@apache.org + openmind + + PMC Member + + +1 + + + epunzalan + Edwin Punzalan + epunzalan@mergere.com + Mergere + + Committer + + +8 + + + mperham + Mike Perham + mperham@gmail.com + Webify Solutions + + Committer + + -6 + + + jdcasey + John Casey + jdcasey@apache.org + ASF + + PMC Member + + -5 + + + trygvis + Trygve Laugstol + trygvis@apache.org + ASF + + PMC Member + + +1 + + + vsiveton + Vincent Siveton + vsiveton@apache.org + ASF + + Committer + + -5 + + + + + The Apache Software License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.txt + repo + + + + scm:svn:http://svn.apache.org/repos/asf/maven/skins/trunk/maven-default-skin + scm:svn:https://svn.apache.org/repos/asf/maven/skins/trunk/maven-default-skin + http://svn.apache.org/viewcvs.cgi/maven/skins/trunk/maven-default-skin + + + Apache Software Foundation + http://www.apache.org/ + + + c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\src\main\java + src/main/scripts + c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\src\test\java + c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\target\classes + c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\target\test-classes + + + c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\src\main\resources + + + + + c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\src\test\resources + + + c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\target + maven-default-skin-1.0 + + + + maven-release-plugin + + https://svn.apache.org/repos/asf/maven/skins/tags + + + + + + + maven-deploy-plugin + 2.2 + true + + true + + + + maven-javadoc-plugin + 2.0-beta-3 + + + attach-javadocs + + jar + + + + true + + + maven-source-plugin + 2.0.1 + + + attach-sources + + jar + + + + true + + + maven-resources-plugin + 2.1 + + + maven-compiler-plugin + 2.0.1 + + + maven-surefire-plugin + 2.2-SNAPSHOT + + + maven-jar-plugin + 2.0 + + + maven-install-plugin + 2.1 + + + + + + + false + + apache.snapshots + Apache Snapshot Repository + http://svn.apache.org/maven-snapshot-repository + + + + false + + central + Maven Repository Switchboard + http://repo1.maven.org/maven2 + + + + + + never + + + false + + central + Maven Plugin Repository + http://repo1.maven.org/maven2 + + + + target/site + + + + apache.releases + Apache Release Distribution Repository + scp://minotaur.apache.org/www/www.apache.org/dist/maven-repository + + + apache.snapshots + Apache Development Snapshot Repository + scp://minotaur.apache.org/www/cvs.apache.org/maven-snapshot-repository + + + website + scp://minotaur.apache.org/www/maven.apache.org/skins/maven-default-skin + + +     \ No newline at end of file From 32d7a9cee84c04bee2f9a53108d918e3d217d60b Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 10 May 2007 16:55:15 +0000 Subject: [PATCH 057/541] Add developers and contributors from mime4j and jspf (we only mantain a single list for the whole JAMES project) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@536937 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/pom.xml b/pom.xml index 3aa539c5a15..dcc701a2ecc 100644 --- a/pom.xml +++ b/pom.xml @@ -163,8 +163,43 @@ Developer + + niklas + Niklas Therning + niklas(at)apache(dot)org + Trillian AB + + + jcheng + Joe Cheng + joe(at)joecheng(dot)com + + + Former author to the mime4j product + + + + + + Rob Oxspring + + + Contributed to the mime4j product + + + + + Roger Fullerton + + + Wrote spfjava, the first spf implementation in java + + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk scm:svn:https://svn.apache.org/repos/asf/james/project/trunk From 5e9539261726906c8d192efdb41bd45c51c60b39 Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 10 May 2007 23:05:10 +0000 Subject: [PATCH 058/541] svn ignores for eclipse/m2 work dir git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@537034 13f79535-47bb-0310-9956-ffa450edef68 From f9ca0fb2afd02ce7cc02d50e4255709bca6f10af Mon Sep 17 00:00:00 2001 From: bago Date: Fri, 11 May 2007 11:28:55 +0000 Subject: [PATCH 059/541] Added a missing jar for "offline" build. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@537164 13f79535-47bb-0310-9956-ffa450edef68 --- .../jars/apache-jar-resource-bundle-1.2.jar | Bin 0 -> 10867 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/stage/org.apache/jars/apache-jar-resource-bundle-1.2.jar diff --git a/maven-skin/stage/org.apache/jars/apache-jar-resource-bundle-1.2.jar b/maven-skin/stage/org.apache/jars/apache-jar-resource-bundle-1.2.jar new file mode 100644 index 0000000000000000000000000000000000000000..2d2c1b4aad0c3bfa065a7e0a8ed5d65f105f4051 GIT binary patch literal 10867 zcmeHNby!r}*B(G>q#K6r9=fFjB!_NLkZu?n5kXRsk}gFF>5v>61S#nd1Ox_#MnI&b zKDhT9pZEUmAK&l!{&UZBVxF_tyVgEypLL#hpI1W#eg#I}BYlnGxRFl_{ z;ZlMqfHnT=h5<;s?8axQWo&(U+5d7Q`nj8$3`9vmUR#G-O<_;%U7xB77xyr>3K#pp zyTM8=o-zJ;1e8;Gpqo>LOBMrtDMv4Xgrk+w2bK}3MW~{s?UBh|LPU9;Af8`~*q^XZ zYwz-kGQYcWE1YdAR}>X5h{&`o!7+9%&kt=kEUeL_(FE`caF#Rau;ckzT;Sh;iiI5}2Uly&!Ovi>z7UA{4X z4K2lfl>zmhcPh2IKy0_sYK_;mm2ArW{a__*Wv&4*mokLQi@jf^N2z*IOG7#t>5+NF zhvWJ%k#)bXu(gxpa38UT^+d#n)oix5vO)CxJ}_Cbf(LIF2Tw>A1nv9q{=DsBzC?!+ zNB}_jH2{F%=ZGQdI!ZU?xxJi9w1<`7@DSY})Hhk9*2|BIP`?-dg0`E8v$<>8E7C(r zNoynFtU)Qcde)VAthq|`aA_vqU0ZqKbP)Fi5ee?p>?s;hlYU9rK_Ky|NjH-Ls#mBP zPpzy{9Xt!zO$jxvm}&YXA3b6Q*L|i5Qm1gNSkiF#!ahqeha zTvGfbG?wQ`O1Z%`_{xyR9VyDEr!{9Lx*)D3j_anPgbt*5@y4&Fl=76psYEpIR>puG zuJscKpyi_+;51K^Ymt4AF}zf&$Nw=T;yui>VA-mFIB;rDwAs9XeW{i6xNT^SAY)Q* zgAZa{X*t8Gsz0H}ubiHzWT>*IJhpw%g)y+hD;KdX#C!{|R$xO|Aluo&2t7p4WK?ZX zJUjdF02I-p{%FD)Pj_T6o2re6;{im(q{dpp&hkmAo9tK2M#r~x3`V6i9TxnPshH7} zac(fz04X!`zmp>M#k>bZ;1mA%O;_D+IDDpnF4m8l}8mzVI?>1 znvTr?BL|gWJJi_qPC3UV{emR z(Dm)I?Es_5&UNL+CPP!M?PTGiY9DWR7RlnW>u%on?|HlLFK`8z4r%N6?Vrtl4#z#h z#yqm;F4ZX!zYz#^K5uv6-(yL`tc_P=Fk%wtZB;_IGG?*Ve>CDjTt-k`ao3{|Pj7!h z$Kuf)(%VFm#&*I6P2{`x=rZ$NRdgTq%M|PO$TlM%Pdu5$P-J7~nAi@5 z%q)7<-%_eBZA)u<&GfkW=wN>vY$uMgZ2ksaW^o>^T@C%w}j(URU!Gx+TS-h%XLmBo`sZRe2+>0!oI&l*J9N$$N-mLtgR++jaP_R_|k>qqJl)L+*i?r_eNH-n}@1m`fUqYa;*Ux_v>*0o4_&_ z^nu~)kgu()TN*ek&PD88ovy2U77qjtMlo487gR=4Trn89asxlL^WH@+UpuWZGDM1% zP@L^nBm6A&CKq{_2&FthGQqMVG|<@$%}1miWDKO9u+$U9GBECzl`#gxk#Vx9t)|}$ zl;dSlwP%pR<0G5(%l8-kdw}}A>*(e1U;}= zwob7t?vsEB>bLAOk7q(*<#TJ$HIs@-@nv;JM8U_1Y37^oydLjK73ANzfU ze9a9I3BihV8!D6U1QLkKRb4#M8#2D062+iE#^b+$J1UMF_j%HqwiO%8DD552IjJ2E;ssaW)P(G$td5okv*E*pV=p^h6 z5SQ?|_EBb7J}ur)lGv7^eV5P(zfl$OY05s1kXX*@1NGwl?A8>)6u8~z&sO8N-@#L@ zZql-AMy{N{gt1 zV-Dq9MGT349gS32noY(??=?L!6kRxf0)dAk=&fTQt6Ug&j_D<(Cuz+Q=YUWE^O2>> z$yhs8fm~;x9y$oSuB4rj(e9WKp8|n`F0+s|!y;6MjFf)pScqK*7!V;qo#xqv?OUgutvNjCqi%IC&l!o{xSR=-UW z5Q}?kzpIa-G3s*xyase_`q<|>?sFFlVK1g1631HHc)N=^!X&cYgq%zH!_Xvmq!}5Pi_Y zXwXZQ;XOnCZ6s54bMfP>2n1?qevFW3lmzbMKzl&I@dG5yCsdQX_~;Uv2gR{w%o$i} zt&+fo-e#BbSph1M%;G1L2we_PLEFbuM=z0bdd!{@kXvQ&rYFQmZOYJC`uWf>E0z77 zXGf%;2tJsNvfaT)IuDGK(^Kz@CJjMx3*RW>${%EODa@F=8&ir=?aZAd_*Lpa7AF>H zAtq)uWUMFS%yh0wy8=3l)G4R0t$7Pew&ameuv1u4KP8s{%QGB0kD*XkYZ`MSn^k1_ z!>`@SKcZ~aR5R<$bg7Qd;1gZJizYrDCeTLZRqf1+BV*OJRk)uQqQHPi0s98&x_Pz| z$!~`m#Bt-*0GqMeNK3Adl&cq$0h?1J#S_)Tma9BDa51N%H8ET@(4G0)vTY2gVb|;! z9EFg(H7V(`gD!+C=+&pKxfj%F4daaH_!NO9dTa+!CyLcab|jwGrRo3%8TeuyoU!e z-efE@H|iblh18Lauo4;{a*^Mx$XFY&s;SgPVKl(^ai3_{_6AT;(Qr?TIHw@LY{gO; zuh7%-7pL;9dZfgw0QmjoC4Qf zC5X!YnC&>zL%lC8E~i7|mE-+qpSSk0o^HF*-m~~{d?OZWbFws*DASs%Dq6vL%t1(O zq>d?>K)j#AwmN25Nzba3v1ff(A|Ib`M`jhHGkH>w(EVe(&6aW-8XpA{RgLy>!bh;u z6tDwB=sw|Cf=rj?hUE(-9hi;hktF(_QY^yv29-3XDN9D%QFDYruXNFcRAO_n?joz34t}uD7ThuUIqZWK)Sj0 z_Kqk{nR2QCl1~>8#bbD*uqeaG%)%;r^iWhhLDnZsdxxCTL7O9g3l%B|h;r=T9(Jh$sw*@Ptg-L0|@?S=0C`{2&SW@L*<}q{cs3A}ai3klDjz_{zZAvaX5X9!~#Sjv9NNTTo zr(H12(ao8J92?S?{Of(B@yyQt~4~cusB@a!t_K`h1U$nVJrb$ID_C0b3yOpBGN*Nb-LT?aC zaZdDk@_gz-oW%&!eCq7#oSnVv+0uABGQHu{=zKZTpg4f!!JX35z)!Z#NC6#d`6?{K zAso6w%xdIv?poxo>i{+G)W;O`_ka~jjlSTb;m^*Pj_zs=R2gwh-|zv^}B zAHd@W=|#t}de}#y20D2Jfa%ph#WNQc*LReq{X|>$f!h<6(>98%v^D;Tf!D%p>V4=| zLeWCrrh-?_MoGReqOUJLb;R$%6Z4r;(YYAr~>>1PjHVI%a=zW&e@ETED=li$XKpf~n!EO=P z&V2AztUAo=i>U=npH7_bV|N2wLUy3Rq=V!;vnHI%#hA9CfsJ*0^u+6&Y?7a1>(xj1 zk6!OgZPc{N_GR))pyn#AEWOUOE^VE*m-j)|xJA)hs^cH=tSgK942Q_OaBFA$sQ{iu zrI3ubxlq(|S$r4Y(DLAS$z?|K5-H&3mJuWwi{RbtDGQd45=#NHDSpC?fm<$B9%^17 z0@2zQk{5KP7ZgDPZLDi5sw}fF8RgXDUvgrds*>GfHszPJXm@XpcUreiR~{cK-2s}t z9ZwyGRdLa2(!L*l%$9k}Vbm%0IVB47P5tP8c3jQKQP}SCe2;?I5E56cBSp`tWaQf? zLJFoLfo1yo2Ks|dXt!Fx&Mpga2&uWO>vl$f2)~^&@KV{Q1(%#&$&XBJb7!R7tfvk{ zqjs`c<7ltn%7P?A3KZhRj*W`)pvb^$jN-xPXfABTa?6{^cWm&FZ21<7X6ddGz9`)O z`WoWL&0VT`7=F|&os=zew9Sp`xiOX}mPLw(DZQIb-7MbS>*XaJ34`MVuEgxpC#3o5 z0bG$ugmA$5M|M&y*sPF2=!|p%odu#M($<>hv0I(dZ2p&C;A||K8YOo|5LBQ}0qdE0 zNyxYa=tTEa)-U+kt=i(2kwrT5qi%v>zku|qU2Md z(n&Wl4hNf{U#aU(?C+lu=;SfoX&-tHr#{c*CyI|6gUq?Ms|240y&^lhP;5cjWv(nq zOv}f6m|=_Efkjy|9gXKIjhV&i(dBY*Y^Ma@`1HkOkMsiRKeO}ywV3sdoqPCr{HEu> z>G^MZ{+pivrsu!u`EPpuo1Xus=fCOsZ+iZlp8uxjzv=mJdj9`P&kMuFMJF#mntLMu z^6~sH(ZeM>ua1*(c*BDgx_wT(T_+0)=M$PN;o|amLR??oP?6Yy$7#WF{p8RSE!4E8 zZ^AoPTB73>OG(Ao%7h7@8-iW4)Fm_+N!l+dMMY@DFmC$EGIKmb`9xJGug#op>u3l5 zsMTH7;UsvoS-Y42O?_eV&I{LLEC;?92oHqs#|*c;cNVWhw#ZCitIPryc#U6E4Yx!B znCJE%dYVcVEBl^OpMYxlQsqQkchirBl?B~tc`HCA34xnDV!hq^McKF%B2Ra_pFLUJpDA;Jio6~{9T(v@w1BHPjQP2)P~#K)!f3?>buV6?{T#<%Z!a z?6P>PBo^sn)dH9iOAPMZXjzX{MQo;ES&qcDv{|u&rfoghs!2kd$rpue{51sLwZd?T zzFWzPr3a9U>~Qn$FmRlB-(IdyJ?xwuXsjwI9#hP!BiaPjY!m|C$J)2!KZ=Nu{qVeH z3G7?rZKcHtuyjzi4^U$u9hQE~;1nWO)e&%t71Nt$dYH}maK#banJ$EH+w}3}XPK11 zv8VjvMXYB{i?8WeI+6H^`yIdoIjguvkrz#KyZ7bqt>3rjA~$9iiVH95zcDi?;h%nt z!HGl9Ss9NfmXQrQyim1`bS=Bi7F`|3-osXuE!1CSE?s0lONdpiC&>DS`px||?PA%+_0gzK6r2R!w_sp zi$lfH^&jhCSK6;;a{FYL%Vc_AZa4p%q`E>~T&lkP{P~WxQlNXSGe|5?p; zIjGBq2iTIiI(`?2{V@Ayb=y_vtCkbQa=HI*_LJ7_2f{z=(Ec$0!*R>c2;Wp`-=hB0 z{ja*TKaH>4Z~oo*pHyl;qWNdp*bl&Gm(TF`@q8DN{c8WKeCdb19?DPl-`8&>4G5vuv_OCeqT3Wxk_~+vK&B^8TWBj*J|HZ{$rS`{7!T3Y%`Rfz^!_z6# bf8puJ^RJ Date: Sun, 20 May 2007 14:05:16 +0000 Subject: [PATCH 060/541] [maven-release-plugin] prepare release james-parent-1.1 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@539879 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 14 ++++++-------- pom.xml | 8 ++++---- project/pom.xml | 10 +++++----- project/server/2.2.0/pom.xml | 12 ++++++------ project/server/pom.xml | 12 ++++++------ 5 files changed, 27 insertions(+), 29 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index c82bb61f8ce..278c4382a10 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -1,6 +1,4 @@ - + - + 4.0.0 org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.0-SNAPSHOT + 1.0 Apache JAMES Server 2.2.0 Documentation @@ -30,16 +30,16 @@ org.apache.james james-server-root - 1.0-SNAPSHOT + 1.0 http://james.apache.org/server/2.2.0/ 2006 - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/server/2.2.0 - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/server/2.2.0 - http://svn.apache.org/viewvc/james/project/trunk/server/2.2.0 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/server/2.2.0 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/server/2.2.0 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.1/server/2.2.0 diff --git a/project/server/pom.xml b/project/server/pom.xml index 6d510df41c2..0e02c9f7b9b 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -17,12 +17,12 @@ specific language governing permissions and limitations under the License. --> - + 4.0.0 org.apache.james james-server-root JAMES Server - 1.0-SNAPSHOT + 1.0 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.1-SNAPSHOT + 1.1 2.2.0 @@ -39,9 +39,9 @@ 2006 - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk/server - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk/server - http://svn.apache.org/viewvc/james/project/trunk/server + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/server + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/server + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.1/server From 1b48e1b62b84049633c1f90bb9fa7e7b2f147d61 Mon Sep 17 00:00:00 2001 From: bago Date: Sun, 20 May 2007 14:46:22 +0000 Subject: [PATCH 061/541] Removed scm informations from children poms: it was not correct for server and server-2.2.0 poms, and maybe we don't need them anymore with the new project layout. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@539882 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 11 ++--------- pom.xml | 8 ++++---- project/pom.xml | 11 ++--------- project/server/2.2.0/pom.xml | 12 ++---------- project/server/pom.xml | 10 ++-------- 5 files changed, 12 insertions(+), 40 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 278c4382a10..bc4f9de5c27 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,15 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.1 + 1.1-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.1 - ../pom.xml + 1.1-SNAPSHOT @@ -44,12 +43,6 @@ true - - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/maven-skin - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/maven-skin - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.1/maven-skin - - diff --git a/pom.xml b/pom.xml index 04bb4e183ce..dcc701a2ecc 100644 --- a/pom.xml +++ b/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.1 + 1.1-SNAPSHOT The Apache JAMES Parent POM @@ -201,9 +201,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.1 + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk diff --git a/project/pom.xml b/project/pom.xml index 45e28d3a25e..6d43be932d1 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.1 + 1.1-SNAPSHOT The Apache JAMES Project @@ -30,8 +30,7 @@ org.apache.james james-parent - 1.1 - ../pom.xml + 1.1-SNAPSHOT @@ -50,12 +49,6 @@ http://issues.apache.org/jira/browse/JAMES - - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/project - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/project - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.1/project - - diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index a889724a2f7..9ece330f9fb 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.0 + 1.0-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,19 +30,11 @@ org.apache.james james-server-root - 1.0 + 1.0-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 - - - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/server/2.2.0 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/server/2.2.0 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.1/server/2.2.0 - - - james-server-website diff --git a/project/server/pom.xml b/project/server/pom.xml index 0e02c9f7b9b..5f6d353cf2a 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.0 + 1.0-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.1 + 1.1-SNAPSHOT 2.2.0 @@ -38,12 +38,6 @@ http://james.apache.org/server/ 2006 - - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/server - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1/server - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.1/server - - james-server-website From f01170ffc0c11a23241e5f9ac62ff7ddac34ad5e Mon Sep 17 00:00:00 2001 From: bago Date: Sun, 20 May 2007 14:58:33 +0000 Subject: [PATCH 062/541] [maven-release-plugin] prepare release james-parent-1.1 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@539884 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index bc4f9de5c27..d8f19e047cf 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.1-SNAPSHOT + 1.1 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.1-SNAPSHOT + 1.1 diff --git a/pom.xml b/pom.xml index dcc701a2ecc..04bb4e183ce 100644 --- a/pom.xml +++ b/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.1-SNAPSHOT + 1.1 The Apache JAMES Parent POM @@ -201,9 +201,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk - http://svn.apache.org/viewvc/james/project/trunk + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.1 diff --git a/project/pom.xml b/project/pom.xml index 6d43be932d1..d614469292e 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.1-SNAPSHOT + 1.1 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.1-SNAPSHOT + 1.1 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 9ece330f9fb..dcd063a08b7 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.0-SNAPSHOT + 1.0 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.0-SNAPSHOT + 1.0 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 5f6d353cf2a..c95db1aa6a0 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.0-SNAPSHOT + 1.0 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.1-SNAPSHOT + 1.1 2.2.0 From ce4e9a57638fa6d765cffb1a675376acf1bf64fa Mon Sep 17 00:00:00 2001 From: bago Date: Sun, 20 May 2007 14:58:55 +0000 Subject: [PATCH 063/541] [maven-release-plugin] prepare for next development iteration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@539886 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index d8f19e047cf..c05a3ded833 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.1 + 1.2-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.1 + 1.2-SNAPSHOT diff --git a/pom.xml b/pom.xml index 04bb4e183ce..cee163ecf02 100644 --- a/pom.xml +++ b/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.1 + 1.2-SNAPSHOT The Apache JAMES Parent POM @@ -201,9 +201,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.1 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.1 + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk diff --git a/project/pom.xml b/project/pom.xml index d614469292e..499033bf012 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.1 + 1.2-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.1 + 1.2-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index dcd063a08b7..800ba9a05dc 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.0 + 1.1-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.0 + 1.1-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index c95db1aa6a0..613b6729940 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.0 + 1.1-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.1 + 1.2-SNAPSHOT 2.2.0 From 119865ca06ff1f8a0f2f85411e3bd0c40024878f Mon Sep 17 00:00:00 2001 From: norman Date: Fri, 25 May 2007 11:00:55 +0000 Subject: [PATCH 064/541] Add HOWTO for using maven for releasing james-project/james-mime4j/james-jspf git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@541615 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO_RELEASE.txt | 70 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 HOWTO_RELEASE.txt diff --git a/HOWTO_RELEASE.txt b/HOWTO_RELEASE.txt new file mode 100644 index 00000000000..db9ab4ce9a8 --- /dev/null +++ b/HOWTO_RELEASE.txt @@ -0,0 +1,70 @@ +Howto release via maven release plugin: + + 1 One time setup steps: + Windows: + 1 Create and install a SSH key + 1 Install PuTTY + 2 Use PuttyGen to create a SSH key and export the key as openssh key + 3 Use PuTTY to ssh to people.apache.org + 4 Create a ~/.ssh folder + 5 Use pscp your SSH public key to ~/authorized_keys + 6 Configure putty to use your private key and save the session + 7 Check you can login people.apache.org with your key + + 2 Install cygwin + 1 Install CygWin + 2 Use ssh to login to people.apache.org . This is needed to get the correct entry in your known_hosts file + 3 Copy the known_hosts file to your $(homedir)/.ssh/ + + Linux / Unix: + 1 Create and install a SSH key + 1 Install ssh ( this should be installed by default on must linux / unix systems) + 2 Use "ssh-keygen -t dsa" to generate a new private/public key + 3 Use ssh to login people.apache.org and add the content of "~/.ssh/id_dsa.pub" (local) to "~/.ssh/authorited_keys" (people.apache.org) + 4 Check you can login people.apache.org via your private key + + + + + General: + 1 Install Apache Maven 2.0.6 and make its binary 'mvn' available on your PATH. + + 2 Create a settings.xml in your .m2 directory with the following content: + + + + + people.apache.org + $(USERNAME) + $(PRIVATE_KEY) + $(PASSPRASE) + 775 + 644 + + + + + release + + people.apache.org::default::scp://people.apache.org/home/$(USERNAME)/public_html/staging-repository + + + + + + Replace $(USERNAME) with the username you use to login people.apache.org, $(PRIVATE_KEY) with the path to your private openssh key and $(PASSPRASE) with your passphrase. + Just remoe the passphrase config option if your private key is not encrypted with one. + + + 2 Do the release with maven: + + This steps will build, sign and upload the releases + + General: + 1 Move to the root folder of the project: + 2 Use ' mvn -Plocal,release release:prepare -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) -Darguments="-Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) " ' to prepare the release + 3 Use ' mvn -Plocal,release release:perfom -Dgoals=deploy -Darguments="-Dgoals=deploy" ' to finally perfom all needed steps to finish the release stuff + + Now all should be done the next time with only this two maven commands \ No newline at end of file From 71c08520e79cf9259ec189df35d0289ff127a9d6 Mon Sep 17 00:00:00 2001 From: bago Date: Tue, 29 May 2007 22:56:08 +0000 Subject: [PATCH 065/541] svn:ignore for project/target. delete unused stage folder. updated website to reflect mailet api news and mime4j news. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@542689 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 2 +- project/src/site/xdoc/download.xml | 40 +++++++++++++++++++++- project/src/site/xdoc/downloadunstable.xml | 6 ++++ project/src/site/xdoc/index.xml | 15 ++++---- project/src/site/xdoc/newsarchive.xml | 6 ++-- 5 files changed, 57 insertions(+), 12 deletions(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 8f5fee1ffd1..50df25a4307 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -34,7 +34,7 @@ org.apache.james maven-skin - 1.1-SNAPSHOT + 1.2-SNAPSHOT diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index d8088c76619..5d0e5921104 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -118,7 +118,7 @@ Binaries
    -
    +
      @@ -152,8 +152,46 @@ Binaries
    +     + + +
    + + +
    +

    It is essential that you verify the integrity of the downloaded diff --git a/project/src/site/xdoc/downloadunstable.xml b/project/src/site/xdoc/downloadunstable.xml index bc60b24f231..447e250d462 100644 --- a/project/src/site/xdoc/downloadunstable.xml +++ b/project/src/site/xdoc/downloadunstable.xml @@ -160,6 +160,12 @@ href="http://www.apache.org/dist/james/jspf/beta/src/jspf-0.9b4-src.zip.asc">PGP

    +
    +

    Apache Mime4J 0.3 has been released an no new unstable releases have been released. +Please go to the stable releases download page to download it. +

    +
    +

    It is essential that you verify the integrity of the downloaded diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 53fed6b3c9f..1dd55872256 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -5,23 +5,24 @@ JAMES Project Web Team -

    -
    - -
    -
    -
    +

    The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

    JAMES is organized into subprojects with JAMES Server and the Mailet API as their core.

    Apache JAMES is a project of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.

    The ASF maintains other Java projects which may also be of interest. These are detailed on the ASF Projects page.

    We recommended that users of JAMES products subscribe to the JAMES users mailing list.

    +
    +
    + +
    +
    Read all the news in full in the News Archive
    Or click the titles to read the full story - + May/2007 - Apache Mime4J 0.3 Final Released
    + May/2007 - Mailet API sub-project lives
    Apr/2007 - JAMES Server 2.3.1 Final Released
    Apr/2007 - JAMES Server 2.3.1 RC1 Released
    Apr/2007 - Apache JAMES Project Guidelines published
    diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index db154c9190d..1b019f1366c 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -12,10 +12,10 @@ - +

    Following the decision the PMC have taken few months ago the Apache Mailet API project is now independent of JAMES Server and has its own webpage and itw own source repository.

    Apr/2007 - JAMES Server 2.3.1 Final Released

    James PMC is proud to announce the availability of the final release of JAMES Server 2.3.1. More informations on what has been fixed since the 2.3.0 release can be found in the changelog.

    Apr/2007 - JAMES Server 2.3.1 RC1 released

     From b307ad7d1111f7657194514b20dcfcc00619abbf Mon Sep 17 00:00:00 2001 From: bago Date: Wed, 30 May 2007 16:47:10 +0000 Subject: [PATCH 066/541] English fixes git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@542872 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/newsarchive.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 1b019f1366c..adfc43d2552 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -15,7 +15,7 @@

    May/2007 - Apache Mime4J 0.3 Final Released

    After almost 2 years the Apache JAMES team is proud to announce the availability of Apache Mime4J 0.3. This is the first release under the ASF umbrella.

    May/2007 - Mailet API sub-project lives

     -

    Following the decision the PMC have taken few months ago the Apache Mailet API project is now independent of JAMES Server and has its own webpage and itw own source repository.

    +

    Following a decision taken by the James PMC a few months ago, the Apache Mailet API project is now independent of JAMES Server and has its own webpage and its own source repository.

    Apr/2007 - JAMES Server 2.3.1 Final Released

    James PMC is proud to announce the availability of the final release of JAMES Server 2.3.1. More informations on what has been fixed since the 2.3.0 release can be found in the changelog.

    Apr/2007 - JAMES Server 2.3.1 RC1 released

     From 0bb33925cc1da54d3938a44b71baa5b79319b7f8 Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 20 Sep 2007 13:59:27 +0000 Subject: [PATCH 067/541] Preparing a james-project-1.2 depending on james-parent-1.1 and maven-skin-1.1 (not sure this will work). The problem is that the james-project-1.1 has been released with a dependency on maven-skin-1.1-SNAPSHOT and doesn't work fine. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@577752 13f79535-47bb-0310-9956-ffa450edef68 --- project/pom.xml | 2 +- project/src/site/site.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/project/pom.xml b/project/pom.xml index 499033bf012..3e791283d44 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.2-SNAPSHOT + 1.1 diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 50df25a4307..c47c6d4f42f 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -34,7 +34,7 @@ org.apache.james maven-skin - 1.2-SNAPSHOT + 1.1 From be821a4a3f7b4cc4bc1dd8e1a5e65550e3a6de7f Mon Sep 17 00:00:00 2001 From: norman Date: Fri, 21 Sep 2007 11:14:36 +0000 Subject: [PATCH 068/541] [maven-release-plugin] prepare release james-project-1.2 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@578063 13f79535-47bb-0310-9956-ffa450edef68 --- project/pom.xml | 8 +++++++- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 3 files changed, 11 insertions(+), 5 deletions(-) diff --git a/project/pom.xml b/project/pom.xml index 3e791283d44..4b2e41dee2f 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.2-SNAPSHOT + 1.2 The Apache JAMES Project @@ -67,4 +67,10 @@ + + + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-project-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-project-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-project-1.2 + \ No newline at end of file diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 800ba9a05dc..711f8b0004c 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.1-SNAPSHOT + 1.1 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.1-SNAPSHOT + 1.1 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 613b6729940..571193c8b8d 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.1-SNAPSHOT + 1.1 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.2-SNAPSHOT + 1.2 2.2.0 From c7f8259106109eaf3a5f7e4c642111c964b76b13 Mon Sep 17 00:00:00 2001 From: norman Date: Fri, 21 Sep 2007 11:14:49 +0000 Subject: [PATCH 069/541] [maven-release-plugin] prepare for next development iteration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@578066 13f79535-47bb-0310-9956-ffa450edef68 --- project/pom.xml | 9 +-------- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 3 files changed, 5 insertions(+), 12 deletions(-) diff --git a/project/pom.xml b/project/pom.xml index 4b2e41dee2f..36d2356641a 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.2 + 1.3-SNAPSHOT The Apache JAMES Project @@ -66,11 +66,4 @@ http://mail-archives.apache.org/mod_mbox/james-site-dev/ - - - - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-project-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-project-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-project-1.2 - \ No newline at end of file diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 711f8b0004c..047f812bfd9 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.1 + 1.2-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.1 + 1.2-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 571193c8b8d..89cf8315272 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.1 + 1.2-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.2 + 1.3-SNAPSHOT 2.2.0 From 771384118391158a2fd9183f9c360e3b39f8def1 Mon Sep 17 00:00:00 2001 From: bago Date: Fri, 21 Sep 2007 14:40:21 +0000 Subject: [PATCH 070/541] Updated the HOWTO_RELEASE based on the last issues found when preparing. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@578146 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO_RELEASE.txt | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/HOWTO_RELEASE.txt b/HOWTO_RELEASE.txt index db9ab4ce9a8..d6dd4a5a23c 100644 --- a/HOWTO_RELEASE.txt +++ b/HOWTO_RELEASE.txt @@ -20,9 +20,24 @@ Howto release via maven release plugin: 1 Create and install a SSH key 1 Install ssh ( this should be installed by default on must linux / unix systems) 2 Use "ssh-keygen -t dsa" to generate a new private/public key - 3 Use ssh to login people.apache.org and add the content of "~/.ssh/id_dsa.pub" (local) to "~/.ssh/authorited_keys" (people.apache.org) + 3 Use ssh to login people.apache.org and add the content of "~/.ssh/id_dsa.pub" (local) to "~/.ssh/authorized_keys" (people.apache.org) 4 Check you can login people.apache.org via your private key - + + 2 Some linux version (e.g: kubuntu 7) uses an hashed version of the known_hosts file. + This file is not understood by maven. So the easiest thing is to run an interactive maven command + using the ssh access to people.apache.org. + mvn deploy:deploy-file + \ -Durl=scp://people.apache.org/home/(YOURHOME)/public_html/a-random-repository + \ -DrepositoryId=a_random.id + \ -Dfile=path_to_a_local_file.jar + \ -DgroupId=org.some.group + \ -DartifactId=your-artifact + \ -Dversion=1.0 + \ -Dpackaging=jar + This will try connecting via ssh to people.apache.org and interactively will ask you to accept the new + host key. + Run this a second time and it HAVE TO work without asking anything. If it keep asking to accept + the key for an unknown host you will not be able to make the release. @@ -65,6 +80,8 @@ Howto release via maven release plugin: General: 1 Move to the root folder of the project: 2 Use ' mvn -Plocal,release release:prepare -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) -Darguments="-Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) " ' to prepare the release - 3 Use ' mvn -Plocal,release release:perfom -Dgoals=deploy -Darguments="-Dgoals=deploy" ' to finally perfom all needed steps to finish the release stuff + 3 Use ' mvn -Plocal,release release:perform -Dgoals=deploy -Darguments="-Dgoals=deploy" ' to finally perfom all needed steps to finish the release stuff + 4 If the step 3 does not work try this more verbose + ' mvn -Plocal,release release:perform -Dgoals=deploy -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) -Darguments="-Dgoals=deploy -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE)" ' Now all should be done the next time with only this two maven commands \ No newline at end of file From 7403def5afb3be1098ec99566670741c2f14de03 Mon Sep 17 00:00:00 2001 From: norman Date: Fri, 21 Sep 2007 17:39:00 +0000 Subject: [PATCH 071/541] Fix some typos Add more documentation about needed steps for getting the right metadata. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@578210 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO.txt | 2 +- HOWTO_RELEASE.txt | 19 ++++++++++++++----- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/HOWTO.txt b/HOWTO.txt index 327890c4f10..53ff24ca883 100644 --- a/HOWTO.txt +++ b/HOWTO.txt @@ -1,6 +1,6 @@ How to build and publish the website: - 1. Install Apache Maven 2.0.6 and make its binary 'mvn' available on your PATH. + 1. Install Apache Maven 2.0.6+ and make its binary 'mvn' available on your PATH. 2. run "mvn -U -Plocal,parent clean install site:stage -DstagingDirectory={path}". - the -U will force mvn to update plugins (check new installed skin when building the project site. diff --git a/HOWTO_RELEASE.txt b/HOWTO_RELEASE.txt index d6dd4a5a23c..dc27006a53b 100644 --- a/HOWTO_RELEASE.txt +++ b/HOWTO_RELEASE.txt @@ -27,7 +27,7 @@ Howto release via maven release plugin: This file is not understood by maven. So the easiest thing is to run an interactive maven command using the ssh access to people.apache.org. mvn deploy:deploy-file - \ -Durl=scp://people.apache.org/home/(YOURHOME)/public_html/a-random-repository + \ -Durl=scp://people.apache.org/home/$(YOURHOME)/public_html/a-random-repository \ -DrepositoryId=a_random.id \ -Dfile=path_to_a_local_file.jar \ -DgroupId=org.some.group @@ -42,9 +42,9 @@ Howto release via maven release plugin: General: - 1 Install Apache Maven 2.0.6 and make its binary 'mvn' available on your PATH. + 1 Install Apache Maven 2.0.6+ and make its binary 'mvn' available on your PATH. - 2 Create a settings.xml in your .m2 directory with the following content: + 2 Create a settings.xml in your .m2 directory with the following content: Replace $(USERNAME) with the username you use to login people.apache.org, $(PRIVATE_KEY) with the path to your private openssh key and $(PASSPRASE) with your passphrase. - Just remoe the passphrase config option if your private key is not encrypted with one. + Just remove the passphrase config option if your private key is not encrypted with one. 2 Do the release with maven: - This steps will build, sign and upload the releases + This steps will build, sign and upload the releases + Prepare: + 1 Login to minotaur (people.apache.org) via ssh. + 2 Clean up your staging-repository via: 'rm -r ~/staging-repository/org/apache/james/*' + If this fails, you have probally not the needed directory structure in place. Create it via: 'mkdir -p ~/staging-repository/org/apache/james/' + 3 Copy the "old" published builds to staging-repository (this is needed to get the right meta data) via: + 'cp -r /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/james/* ~/staging-repository/org/apache/james/' + + + General: 1 Move to the root folder of the project: 2 Use ' mvn -Plocal,release release:prepare -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) -Darguments="-Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) " ' to prepare the release From 1762ecc4d5e196245ecba3a5e19d862fc1e61315 Mon Sep 17 00:00:00 2001 From: norman Date: Fri, 21 Sep 2007 18:43:56 +0000 Subject: [PATCH 072/541] More typo's corrected Add docu about copy artifacts to maven repo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@578223 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO_RELEASE.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/HOWTO_RELEASE.txt b/HOWTO_RELEASE.txt index dc27006a53b..eb36ab9a07a 100644 --- a/HOWTO_RELEASE.txt +++ b/HOWTO_RELEASE.txt @@ -54,7 +54,7 @@ Howto release via maven release plugin: people.apache.org $(USERNAME) $(PRIVATE_KEY) - $(PASSPRASE) + $(PASSPHRASE) 775 644 @@ -69,7 +69,7 @@ Howto release via maven release plugin: - Replace $(USERNAME) with the username you use to login people.apache.org, $(PRIVATE_KEY) with the path to your private openssh key and $(PASSPRASE) with your passphrase. + Replace $(USERNAME) with the username you use to login people.apache.org, $(PRIVATE_KEY) with the path to your private openssh key and $(PASSPHRASE) with your passphrase. Just remove the passphrase config option if your private key is not encrypted with one. @@ -93,4 +93,14 @@ Howto release via maven release plugin: 4 If the step 3 does not work try this more verbose ' mvn -Plocal,release release:perform -Dgoals=deploy -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) -Darguments="-Dgoals=deploy -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE)" ' - Now all should be done the next time with only this two maven commands \ No newline at end of file + Now all should be done the next time with only this two maven commands + + + 3 Publish the release as maven artifact + + This steps will make the artifact's aviable in maven repositories. Get sure the VOTE has passed and the release should get official + + Publish: + 1 Copy the artifact's the maven repo via: 'cp -r ~/staging-repository/org/apache/james/* /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/james/' + 2 Get some coffee and wait till the artifact's get synced across the mirrors (this can take some time). + \ No newline at end of file From 857a5748e003adc6dfb9c81511f21d9a17399959 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 25 Sep 2007 07:09:57 +0000 Subject: [PATCH 073/541] Add news for new jspf release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@579099 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 3 ++- project/src/site/xdoc/newsarchive.xml | 8 +++++--- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 1dd55872256..dbed725a4ff 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -21,8 +21,9 @@ Read all the news in full in the News Archive
    Or click the titles to read the full story + Sept/2007 - jSPF-0.9b5 released
    May/2007 - Apache Mime4J 0.3 Final Released
    - May/2007 - Mailet API sub-project lives
    + May/2007 - Mailet API sub-project lives
    Apr/2007 - JAMES Server 2.3.1 Final Released
    Apr/2007 - JAMES Server 2.3.1 RC1 Released
    Apr/2007 - Apache JAMES Project Guidelines published
    diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index adfc43d2552..3a9f842d923 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -11,11 +11,13 @@ - + +

    Sept/2007 - jSPF-0.9b5 released

     +

    James PMC is proud to announce the availability of jSPF-0.9b5. This release supports asynchron processing and is fully RFC4408 conform.

    May/2007 - Apache Mime4J 0.3 Final Released

    After almost 2 years the Apache JAMES team is proud to announce the availability of Apache Mime4J 0.3. This is the first release under the ASF umbrella.

    -

    May/2007 - Mailet API sub-project lives

     -

    Following a decision taken by the James PMC a few months ago, the Apache Mailet API project is now independent of JAMES Server and has its own webpage and its own source repository.

    +

    May/2007 - Mailet API sub-project lives

     +

    Following a decision taken by the James PMC a few months ago, the Apache Mailet API project is now independent of JAMES Server and has its own webpage and its own source repository.

    Apr/2007 - JAMES Server 2.3.1 Final Released

    James PMC is proud to announce the availability of the final release of JAMES Server 2.3.1. More informations on what has been fixed since the 2.3.0 release can be found in the changelog.

    Apr/2007 - JAMES Server 2.3.1 RC1 released

     From bc092825d5422a43e5f0441b9081a55de2e2d3b5 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 25 Sep 2007 07:12:37 +0000 Subject: [PATCH 074/541] update template to reflect new jspf release (missed before) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@579100 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/downloadunstable.xml | 446 ++++++++++----------- 1 file changed, 223 insertions(+), 223 deletions(-) diff --git a/project/src/site/xdoc/downloadunstable.xml b/project/src/site/xdoc/downloadunstable.xml index 447e250d462..ffb76bdf44f 100644 --- a/project/src/site/xdoc/downloadunstable.xml +++ b/project/src/site/xdoc/downloadunstable.xml @@ -1,223 +1,223 @@ - - - - - Apache James Mail Server Project - Download - - - -
    - -

    Use the links below to download the Apache JAMES products from one of -our mirrors. You must verify the -integrity of the downloaded files using signatures downloaded from -our main distribution directory.

    - -

    Only current recommended releases are available on the main -distribution site and its mirrors. Older releases are available from -the archive download -site.

    - -
    - - - -

    [if-any logo] -[end] -The currently selected mirror is [preferred]. If you encounter a -problem with this mirror, please select another mirror. If all -mirrors are failing, there are backup mirrors (at the end of -the mirrors list) that should be available.

    - -
    -Other mirrors: - -
    - -

    You may also consult the complete -list of mirrors.

    - -     - -
    -

    Apache JAMES server 2.3.1 has been released an no new unstable releases have been released. -Please go to the stable releases download page to download it. -

    -
    - - -
    - - - -
    - -
    -

    Apache Mime4J 0.3 has been released an no new unstable releases have been released. -Please go to the stable releases download page to download it. -

    -
    - - - -

    It is essential that you verify the integrity of the downloaded -files using the PGP or MD5 signatures.

    - -

    The PGP signatures can be verified using PGP or GPG. First -download the KEYS -as well as the asc signature file for the particular -distribution. Make sure you get these files from the main distribution -directory, rather than from a mirror. Then verify the signatures -using

    - -

    -% pgpk -a KEYS
    -% pgpv james-version.tar.gz.asc
    -     -or
    - -% pgp -ka KEYS
    -% pgp james-version.tar.gz.asc
    -     -or
    - -% gpg --import KEYS
    -% gpg --verify james-version.tar.gz.asc -

    - -     - -
    - -

    The software listed above represents the latest unstable builds -available from the Apache JAMES Project. -You can download Stable Releases here. -Unstable releases are announced on the General mailing list (general@james.apache.org). - -

    -

    - -

    The JAMES project also provides -Nighly Builds: -periodic snapshots during development. Generally, these are considered -stable snapshots, but they have not undergone as much testing as a -Release Build, nor have they been voted upon for release by the -developer community. These are simply convenient test builds. -Sometimes the purpose for a Nightly Build could be soliciting feedback on -a specific change. -

    - - -
    - - -     + + + + + Apache James Mail Server Project + Download + + + +
    + +

    Use the links below to download the Apache JAMES products from one of +our mirrors. You must verify the +integrity of the downloaded files using signatures downloaded from +our main distribution directory.

    + +

    Only current recommended releases are available on the main +distribution site and its mirrors. Older releases are available from +the archive download +site.

    + +
    + + + +

    [if-any logo] +[end] +The currently selected mirror is [preferred]. If you encounter a +problem with this mirror, please select another mirror. If all +mirrors are failing, there are backup mirrors (at the end of +the mirrors list) that should be available.

    + +
    +Other mirrors: + +
    + +

    You may also consult the complete +list of mirrors.

    + +     + +
    +

    Apache JAMES server 2.3.1 has been released an no new unstable releases have been released. +Please go to the stable releases download page to download it. +

    +
    + + +
    + + + +
    + +
    +

    Apache Mime4J 0.3 has been released an no new unstable releases have been released. +Please go to the stable releases download page to download it. +

    +
    + + + +

    It is essential that you verify the integrity of the downloaded +files using the PGP or MD5 signatures.

    + +

    The PGP signatures can be verified using PGP or GPG. First +download the KEYS +as well as the asc signature file for the particular +distribution. Make sure you get these files from the main distribution +directory, rather than from a mirror. Then verify the signatures +using

    + +

    +% pgpk -a KEYS
    +% pgpv james-version.tar.gz.asc
    +     +or
    + +% pgp -ka KEYS
    +% pgp james-version.tar.gz.asc
    +     +or
    + +% gpg --import KEYS
    +% gpg --verify james-version.tar.gz.asc +

    + +     + +
    + +

    The software listed above represents the latest unstable builds +available from the Apache JAMES Project. +You can download Stable Releases here. +Unstable releases are announced on the General mailing list (general@james.apache.org). + +

    +

    + +

    The JAMES project also provides +Nighly Builds: +periodic snapshots during development. Generally, these are considered +stable snapshots, but they have not undergone as much testing as a +Release Build, nor have they been voted upon for release by the +developer community. These are simply convenient test builds. +Sometimes the purpose for a Nightly Build could be soliciting feedback on +a specific change. +

    + + +
    + + +     From 0eb5a03dc3f6675e1ed32ee2f8e34a6eecae4f87 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 25 Sep 2007 07:18:47 +0000 Subject: [PATCH 075/541] Small fix for upcomming jspf release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@579103 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/downloadunstable.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/downloadunstable.xml b/project/src/site/xdoc/downloadunstable.xml index ffb76bdf44f..11b44a2a43e 100644 --- a/project/src/site/xdoc/downloadunstable.xml +++ b/project/src/site/xdoc/downloadunstable.xml @@ -122,7 +122,7 @@ Binaries
    --> -
    +
      From 9016135b0ca48995828d9631e259108a3ac35864 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 25 Sep 2007 10:20:36 +0000 Subject: [PATCH 076/541] Fix spelling and version number git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@579171 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/downloadunstable.xml | 30 +++++++++++----------- project/src/site/xdoc/index.xml | 2 +- project/src/site/xdoc/newsarchive.xml | 4 +-- 3 files changed, 18 insertions(+), 18 deletions(-) diff --git a/project/src/site/xdoc/downloadunstable.xml b/project/src/site/xdoc/downloadunstable.xml index 11b44a2a43e..2e8f269652a 100644 --- a/project/src/site/xdoc/downloadunstable.xml +++ b/project/src/site/xdoc/downloadunstable.xml @@ -122,37 +122,37 @@ Binaries
    --> -
    +
    • Binary (JAR): jspf-0.9b5.jar [PGP]
      • +href="[preferred]/james/jspf/beta/bin/jspf-0.9.5.jar">jspf-0.9.5.jar [PGP]
    • Binary (ZIP Format): jspf-0.9b5-bin.zip [PGP]
      • +href="[preferred]/james/jspf/beta/bin/jspf-0.9.5-bin.zip">jspf-0.9.5-bin.zip [PGP]
    • Binary (Unix TAR.GZ): jspf-0.9b5-bin.tar.gz [PGP]
      • +href="[preferred]/james/jspf/beta/bin/jspf-0.9.5-bin.tar.gz">jspf-0.9.5-bin.tar.gz [PGP]
    • Binary (Unix TAR.BZ2): jspf-0.9b5-bin.tar.bz2 [PGP]
      • +href="[preferred]/james/jspf/beta/bin/jspf-0.9.5-bin.tar.bz2">jspf-0.9.5-bin.tar.bz2 [PGP]
    • Source (Unix TAR.GZ): jspf-0.9b5-src.tar.gz [PGP]
      • +href="[preferred]/james/jspf/beta/src/jspf-0.9.5-src.tar.gz">jspf-0.9.5-src.tar.gz [PGP]
    • Source (Unix TAR.BZ2): jspf-0.9b5-src.tar.bz2 [PGP]
      • +href="[preferred]/james/jspf/beta/src/jspf-0.9.5-src.tar.bz2">jspf-0.9.5-src.tar.bz2 [PGP]
    • Source (ZIP Format): jspf-0.9b5-src.zip [PGP]
      • +href="[preferred]/james/jspf/beta/src/jspf-0.9.5-src.zip">jspf-0.9.5-src.zip [PGP]
    • Other Binaries
      • diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index dbed725a4ff..aa8e22049eb 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -21,7 +21,7 @@ Read all the news in full in the News Archive
      Or click the titles to read the full story - Sept/2007 - jSPF-0.9b5 released
      + Sept/2007 - jSPF-0.9.5 released
      May/2007 - Apache Mime4J 0.3 Final Released
      May/2007 - Mailet API sub-project lives
      Apr/2007 - JAMES Server 2.3.1 Final Released
      diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 3a9f842d923..0d77fd5cb01 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -12,8 +12,8 @@ -

      Sept/2007 - jSPF-0.9b5 released

       -

      James PMC is proud to announce the availability of jSPF-0.9b5. This release supports asynchron processing and is fully RFC4408 conform.

      +

      Sept/2007 - jSPF-0.9.5 released

       +

      We are proud to announce the availability release of APACHE jSPF-0.9.5. This release spots an initial support for asynchronous processing and is fully RFC4408 compliant.

      May/2007 - Apache Mime4J 0.3 Final Released

      After almost 2 years the Apache JAMES team is proud to announce the availability of Apache Mime4J 0.3. This is the first release under the ASF umbrella.

      May/2007 - Mailet API sub-project lives

       From e2977d92699e528f42e22633d5ff72c5f4c0a9c1 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 25 Sep 2007 10:26:02 +0000 Subject: [PATCH 077/541] fix some minor error again.. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@579177 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/downloadunstable.xml | 28 +++++++++++----------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/project/src/site/xdoc/downloadunstable.xml b/project/src/site/xdoc/downloadunstable.xml index 2e8f269652a..9e93b7bab4b 100644 --- a/project/src/site/xdoc/downloadunstable.xml +++ b/project/src/site/xdoc/downloadunstable.xml @@ -127,32 +127,32 @@ Binaries
      • Binary (JAR): jspf-0.9.5.jar [PGP]
        • +href="[preferred]/james/jspf/beta/bin/jspf-0.9.5.jar">apache-jspf-0.9.5.jar [PGP]
      • Binary (ZIP Format): jspf-0.9.5-bin.zip [PGP]
        • +href="[preferred]/james/jspf/beta/bin/jspf-0.9.5-bin.zip">apache-jspf-0.9.5-bin.zip [PGP]
      • Binary (Unix TAR.GZ): jspf-0.9.5-bin.tar.gz [PGP]
        • +href="[preferred]/james/jspf/beta/bin/jspf-0.9.5-bin.tar.gz">apache-jspf-0.9.5-bin.tar.gz [PGP]
      • Binary (Unix TAR.BZ2): jspf-0.9.5-bin.tar.bz2 [PGP]
        • +href="[preferred]/james/jspf/beta/bin/jspf-0.9.5-bin.tar.bz2">apache-jspf-0.9.5-bin.tar.bz2 [PGP]
      • Source (Unix TAR.GZ): jspf-0.9.5-src.tar.gz [PGP]
        • +href="[preferred]/james/jspf/beta/src/jspf-0.9.5-src.tar.gz">apache-jspf-0.9.5-src.tar.gz [PGP]
      • Source (Unix TAR.BZ2): jspf-0.9.5-src.tar.bz2 [PGP]
        • +href="[preferred]/james/jspf/beta/src/jspf-0.9.5-src.tar.bz2">apache-jspf-0.9.5-src.tar.bz2 [PGP]
      • Source (ZIP Format): jspf-0.9.5-src.zip [PGP]
        • +href="[preferred]/james/jspf/beta/src/jspf-0.9.5-src.zip">apache-jspf-0.9.5-src.zip [PGP]
      • Other Binaries
        • From 2f8a5bc7e1cb67d9f098ed62d202c0055dc5287b Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 25 Sep 2007 13:16:24 +0000 Subject: [PATCH 078/541] Hopefully the last fixes for jspf release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@579233 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/downloadunstable.xml | 14 +++++++------- project/src/site/xdoc/newsarchive.xml | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/project/src/site/xdoc/downloadunstable.xml b/project/src/site/xdoc/downloadunstable.xml index 9e93b7bab4b..317fe12ec99 100644 --- a/project/src/site/xdoc/downloadunstable.xml +++ b/project/src/site/xdoc/downloadunstable.xml @@ -127,31 +127,31 @@ Binaries From 68accfeef9926b8a569f7c17f36bbc955f24a385 Mon Sep 17 00:00:00 2001 From: bago Date: Mon, 5 Nov 2007 15:19:00 +0000 Subject: [PATCH 080/541] Added "required" foundation links to our main menu. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@592039 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index c47c6d4f42f..4a0bb4c0ccd 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -50,7 +50,7 @@ - + @@ -91,7 +91,13 @@ - + + + + + + + From 824443a6243c861cd6f938dd6841629e8030ed75 Mon Sep 17 00:00:00 2001 From: danny Date: Wed, 19 Mar 2008 16:50:41 +0000 Subject: [PATCH 081/541] News about James GSOC ideas git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@638934 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 3 +++ project/src/site/xdoc/newsarchive.xml | 9 +++++++++ 2 files changed, 12 insertions(+) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index aa8e22049eb..143ca65f39c 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -20,6 +20,9 @@
        Read all the news in full in the News Archive
        Or click the titles to read the full story + + Mar/2008 - James publishes project ideas for Google Summer of Code '08
        +         Sept/2007 - jSPF-0.9.5 released
        May/2007 - Apache Mime4J 0.3 Final Released
        diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 871eded64c5..cd6b3c6a1bf 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -11,6 +11,15 @@ + +

        Mar/2008 - James publishes project ideas for Google Summer of Code '08

         +

        The James Team are delighted to announce that we're proposing two project ideas for Google Summer of Code (GSOC) 2008. The project Ideas are set out on the Apache GSOC wiki here.

        +

        In brief they are:
        + 1) Develop a VERP Mailet to allow James to write VERP modified return addresses on outbound messages, and an inbound mailet/matcher to identify VERP bounces and invoke configurable "do something" code. +
        + And
        + 2) James' provided mailing list manager is fine for small closed groups, but lacks the functionality of a more robust MLM, the project is to add some all or more of the following features subscriber and message moderation, double opt-in and bounce handling.

        +

        Sept/2007 - jSPF-0.9.5 released

        We are proud to announce the availability of APACHE jSPF-0.9.5. This release brings initial support for asynchronous processing and is fully RFC4408 compliant.

        From 5fc899dd1c04ae745b62cc2b7c7c79f483341e3f Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 20 Mar 2008 17:19:39 +0000 Subject: [PATCH 082/541] minor fix to month abbreviation (Sept => Sep) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@639371 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 143ca65f39c..9d04cdac920 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -24,7 +24,7 @@ Mar/2008 - James publishes project ideas for Google Summer of Code '08
         - Sept/2007 - jSPF-0.9.5 released
        + Sep/2007 - jSPF-0.9.5 released
        May/2007 - Apache Mime4J 0.3 Final Released
        May/2007 - Mailet API sub-project lives
        Apr/2007 - JAMES Server 2.3.1 Final Released
        From 51a5791499fd81b2e67fd05dc3f4f83a410dd26c Mon Sep 17 00:00:00 2001 From: norman Date: Sat, 5 Apr 2008 08:47:36 +0000 Subject: [PATCH 083/541] Remove whitespace because of the NPE which happen with whitespace git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@645044 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO_RELEASE.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/HOWTO_RELEASE.txt b/HOWTO_RELEASE.txt index eb36ab9a07a..9b85efe5688 100644 --- a/HOWTO_RELEASE.txt +++ b/HOWTO_RELEASE.txt @@ -88,7 +88,7 @@ Howto release via maven release plugin: General: 1 Move to the root folder of the project: - 2 Use ' mvn -Plocal,release release:prepare -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) -Darguments="-Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) " ' to prepare the release + 2 Use ' mvn -Plocal,release release:prepare -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) -Darguments="-Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE)" ' to prepare the release 3 Use ' mvn -Plocal,release release:perform -Dgoals=deploy -Darguments="-Dgoals=deploy" ' to finally perfom all needed steps to finish the release stuff 4 If the step 3 does not work try this more verbose ' mvn -Plocal,release release:perform -Dgoals=deploy -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) -Darguments="-Dgoals=deploy -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE)" ' From dabdccf4ee6975c4eee76a807eeecf2b5e72e18a Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 8 Apr 2008 18:34:42 +0000 Subject: [PATCH 084/541] Add new news section which reflect 0.9.6 release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@646024 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 1 + project/src/site/xdoc/newsarchive.xml | 7 +++++++ 2 files changed, 8 insertions(+) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 9d04cdac920..2e4f108172f 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -21,6 +21,7 @@ Read all the news in full in the News Archive
        Or click the titles to read the full story + Apr/2007 - jSPF-0.9.6 released
        Mar/2008 - James publishes project ideas for Google Summer of Code '08
         diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index cd6b3c6a1bf..97a5f811915 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -20,6 +20,13 @@ And
        2) James' provided mailing list manager is fine for small closed groups, but lacks the functionality of a more robust MLM, the project is to add some all or more of the following features subscriber and message moderation, double opt-in and bounce handling.

         + + + +

        Apr/2008 - jSPF-0.9.6 released

         +

        We are proud to announce the availability release of APACHE jSPF-0.9.6. This release fix two possible NullPointerExceptions and handle the "exp=" modifier correctly.

        + +

        Sept/2007 - jSPF-0.9.5 released

        We are proud to announce the availability of APACHE jSPF-0.9.5. This release brings initial support for asynchronous processing and is fully RFC4408 compliant.

        From 9bbe999126a6fd44d885801ab1c5b930f0f23453 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 8 Apr 2008 21:32:15 +0000 Subject: [PATCH 085/541] Fix subsections git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@646084 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/newsarchive.xml | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 97a5f811915..a8247d87a0f 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -12,6 +12,9 @@ +

        Apr/2008 - jSPF-0.9.6 released

         +

        We are proud to announce the availability release of APACHE jSPF-0.9.6. This release fix two possible NullPointerExceptions and handle the "exp=" modifier correctly.

        +

        Mar/2008 - James publishes project ideas for Google Summer of Code '08

        The James Team are delighted to announce that we're proposing two project ideas for Google Summer of Code (GSOC) 2008. The project Ideas are set out on the Apache GSOC wiki here.

        In brief they are:
        @@ -21,12 +24,6 @@ 2) James' provided mailing list manager is fine for small closed groups, but lacks the functionality of a more robust MLM, the project is to add some all or more of the following features subscriber and message moderation, double opt-in and bounce handling.

         - - -

        Apr/2008 - jSPF-0.9.6 released

         -

        We are proud to announce the availability release of APACHE jSPF-0.9.6. This release fix two possible NullPointerExceptions and handle the "exp=" modifier correctly.

        - -

        Sept/2007 - jSPF-0.9.5 released

        We are proud to announce the availability of APACHE jSPF-0.9.5. This release brings initial support for asynchronous processing and is fully RFC4408 compliant.

        From f6529dfc691c636a546a82c90ae96ee6b6a3a79a Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 8 Apr 2008 21:43:30 +0000 Subject: [PATCH 086/541] Add jspf 0.9.6 to download page Fix typo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@646089 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 30 ++++++++++++++++++++++ project/src/site/xdoc/downloadunstable.xml | 11 ++++++-- 2 files changed, 39 insertions(+), 2 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 5d0e5921104..90e0eb92fae 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -191,6 +191,36 @@ href="[preferred]/james/mime4j/">Other Files (javadoc.jar, sha1 checksums...
        +
        + + + +
        + diff --git a/project/src/site/xdoc/downloadunstable.xml b/project/src/site/xdoc/downloadunstable.xml index af111c11a4c..6f6d0db04e7 100644 --- a/project/src/site/xdoc/downloadunstable.xml +++ b/project/src/site/xdoc/downloadunstable.xml @@ -68,7 +68,7 @@ list of mirrors.
        -

        Apache JAMES server 2.3.1 has been released an no new unstable releases have been released. +

        Apache JAMES server 2.3.1 has been released and no new unstable releases have been released. Please go to the stable releases download page to download it.

        @@ -122,6 +122,13 @@ Binaries
    --> +
    +

    Apache JAMES jSPF 0.9.6 has been released and no new unstable releases have been released. +Please go to the stable releases download page to download it. +

    +
    + +

    Apache Mime4J 0.3 has been released an no new unstable releases have been released. Please go to the stable releases download page to download it. From 39dcfa7b4eb946e8a4dc6e823d6ab289a1fa6384 Mon Sep 17 00:00:00 2001 From: bago Date: Wed, 9 Apr 2008 09:39:30 +0000 Subject: [PATCH 087/541] Fix year in jSPF news. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@646244 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 2e4f108172f..662cfd1626a 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -21,7 +21,7 @@ Read all the news in full in the News Archive
    Or click the titles to read the full story - Apr/2007 - jSPF-0.9.6 released
    + Apr/2008 - jSPF-0.9.6 released
    Mar/2008 - James publishes project ideas for Google Summer of Code '08
     From 25a761f7c52397a45646c9b5c6fd3e01bf8eb1ea Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 5 Aug 2008 21:28:29 +0000 Subject: [PATCH 088/541] Corrected host name git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@682954 13f79535-47bb-0310-9956-ffa450edef68 --- project/pom.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/project/pom.xml b/project/pom.xml index 36d2356641a..90b9dca3371 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -53,7 +53,7 @@ james-website - scp://minotaur.apache.org/www/james.apache.org/ + scp://people.apache.org/www/james.apache.org/ @@ -66,4 +66,4 @@ http://mail-archives.apache.org/mod_mbox/james-site-dev/ - \ No newline at end of file + From b12aee80615ca35112642f918e252a448c0f88f1 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 5 Aug 2008 21:29:31 +0000 Subject: [PATCH 089/541] Corrected host name git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@682957 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index cee163ecf02..e40d0adab78 100644 --- a/pom.xml +++ b/pom.xml @@ -220,7 +220,7 @@ james-parent-website - scp://minotaur.apache.org/www/james.apache.org/parent/ + scp://people.apache.org/www/james.apache.org/parent/ @@ -382,4 +382,4 @@ - \ No newline at end of file + From 65c8d832530f135e866dd0aed617c1c1e04b498f Mon Sep 17 00:00:00 2001 From: bago Date: Wed, 6 Aug 2008 12:15:36 +0000 Subject: [PATCH 090/541] Updated internal dependencies. Fix mave-site-plugin to 2.0-beta5 because newer plugins create issues (bad bannerLeft inheritance, bad site.xml descriptor deployed). git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@683243 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 11 +++++++++++ project/pom.xml | 2 +- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 2 +- project/src/site/site.xml | 2 +- src/site/site.xml | 2 +- 6 files changed, 17 insertions(+), 6 deletions(-) diff --git a/pom.xml b/pom.xml index e40d0adab78..1c066352de3 100644 --- a/pom.xml +++ b/pom.xml @@ -48,6 +48,17 @@ http://www.apache.org + + + + + maven-site-plugin + 2.0-beta-5 + + + + + Apache License, Version 2.0 diff --git a/project/pom.xml b/project/pom.xml index 90b9dca3371..dbaffe190b1 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.1 + 1.2-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 047f812bfd9..9f933baa2f5 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -34,11 +34,11 @@ http://james.apache.org/server/2.2.0/ 2006 - + james-server-website - scp://minotaur.apache.org/www/james.apache.org/server/2.2.0/ + scp://people.apache.org/www/james.apache.org/server/2.2.0/ \ No newline at end of file diff --git a/project/server/pom.xml b/project/server/pom.xml index 89cf8315272..8930873f3c0 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -41,7 +41,7 @@ james-server-website - scp://minotaur.apache.org/www/james.apache.org/server/ + scp://people.apache.org/www/james.apache.org/server/ diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 4a0bb4c0ccd..067248b1403 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -34,7 +34,7 @@ org.apache.james maven-skin - 1.1 + 1.2-SNAPSHOT diff --git a/src/site/site.xml b/src/site/site.xml index b9433e8f3a7..d46ec8b3955 100644 --- a/src/site/site.xml +++ b/src/site/site.xml @@ -20,7 +20,7 @@ - James Project + James Parent images/james-project-logo.gif http://james.apache.org/index.html From 3be2f9cf21274906def264ab2751be26c7bab025 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Wed, 6 Aug 2008 18:53:13 +0000 Subject: [PATCH 091/541] Change from Mailet API to Mailets in preparation for sorting out mailet products build. Disingenuous apologies for adding purple prose. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@683367 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 4 ++-- project/src/site/xdoc/index.xml | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 067248b1403..0d4465f0d7e 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -41,7 +41,7 @@ - + @@ -50,7 +50,7 @@

    - + diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 662cfd1626a..a294d779cf4 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -7,7 +7,8 @@

    The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

    -

    JAMES is organized into subprojects with JAMES Server and the Mailet API as their core.

    +

    JAMES is organized into subprojects with JAMES Server and the Mailet API as their core. Mailets are a mail processing component + system (similar to servlets). JAMES is an advanced, fully featured, mailet-enabled mail server.

    Apache JAMES is a project of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.

    The ASF maintains other Java projects which may also be of interest. These are detailed on the ASF Projects page.

    We recommended that users of JAMES products subscribe to the JAMES users mailing list.

    From 0d7354f79d3e2cf120d0bbb6331c6b96489a5e5a Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 7 Aug 2008 13:43:18 +0000 Subject: [PATCH 092/541] update minotaur=>people url for maven-skin make project to depend on release 1.2 skin and not the internal snapshot. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@683616 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 2 +- project/src/site/site.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index c05a3ded833..83343df239d 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -34,7 +34,7 @@ maven-skin-website - scp://minotaur.apache.org/www/james.apache.org/maven-skin + scp://people.apache.org/www/james.apache.org/maven-skin diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 0d4465f0d7e..4315ef9ecdc 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -34,7 +34,7 @@ org.apache.james maven-skin - 1.2-SNAPSHOT + 1.1 From f3b4e126201733292c0f63afd2185e27baef573d Mon Sep 17 00:00:00 2001 From: olegk Date: Thu, 21 Aug 2008 21:01:28 +0000 Subject: [PATCH 093/541] Updated the main project site for Mime4j 0.4 release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@687862 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 32 +++++++++++----------- project/src/site/xdoc/downloadunstable.xml | 2 +- project/src/site/xdoc/index.xml | 3 +- project/src/site/xdoc/newsarchive.xml | 10 +++++++ 4 files changed, 29 insertions(+), 18 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 90e0eb92fae..129ae4f8d88 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -155,34 +155,34 @@ Binaries -
    +
    • Binary (Unix TAR): apache-mime4j-0.3-bin.tar.gz [PGP][MD5]
      • +href="[preferred]/james/mime4j/apache-mime4j-0.4-bin.tar.gz">apache-mime4j-0.4-bin.tar.gz [PGP][MD5]
    • Binary (ZIP Format): apache-mime4j-0.3-bin.zip [PGP][MD5]
      • +href="[preferred]/james/mime4j/apache-mime4j-0.4-bin.zip">apache-mime4j-0.4-bin.zip [PGP][MD5]
    • Source (Unix TAR): apache-mime4j-0.3-src.tar.gz [PGP][MD5]
      • +href="[preferred]/james/mime4j/apache-mime4j-0.4-src.tar.gz">apache-mime4j-0.4-src.tar.gz [PGP][MD5]
    • Source (ZIP Format): apache-mime4j-0.3-src.zip [PGP][MD5]
      • +href="[preferred]/james/mime4j/apache-mime4j-0.4-src.zip">apache-mime4j-0.4-src.zip [PGP][MD5]
    • Binary (JAR library only): apache-mime4j-0.3.jar [PGP][MD5]
      • +href="[preferred]/james/mime4j/apache-mime4j-0.4.jar">apache-mime4j-0.4.jar [PGP][MD5]
    • Other Files (javadoc.jar, sha1 checksums...)
      • diff --git a/project/src/site/xdoc/downloadunstable.xml b/project/src/site/xdoc/downloadunstable.xml index 6f6d0db04e7..e204a859f10 100644 --- a/project/src/site/xdoc/downloadunstable.xml +++ b/project/src/site/xdoc/downloadunstable.xml @@ -160,7 +160,7 @@ href="http://www.apache.org/dist/james/jspf/beta/src/apache-jspf-0.9.5-src.zip.a
    -->
    -

    Apache Mime4J 0.3 has been released an no new unstable releases have been released. +

    Apache Mime4J 0.4 has been released an no new unstable releases have been released. Please go to the stable releases download page to download it.

    diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index a294d779cf4..2b2d4144f5e 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -22,12 +22,13 @@ Read all the news in full in the News Archive
    Or click the titles to read the full story + Aug/2008 - Mime4j-0.4 released
    Apr/2008 - jSPF-0.9.6 released
    Mar/2008 - James publishes project ideas for Google Summer of Code '08
     Sep/2007 - jSPF-0.9.5 released
    - May/2007 - Apache Mime4J 0.3 Final Released
    + May/2007 - Apache Mime4J 0.3 Released
    May/2007 - Mailet API sub-project lives
    Apr/2007 - JAMES Server 2.3.1 Final Released
    Apr/2007 - JAMES Server 2.3.1 RC1 Released
    diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index a8247d87a0f..2f56f373013 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -12,6 +12,16 @@ +

    Aug/2008 - Mime4j released

     +

    We are proud to announce the availability of APACHE Mime4j-0.4. This release brings a number of significant improvements in terms of supported capabilities, flexibility and performance:

    +
      +
    • Revised and improved public API with support for pull parsing
      • +
    • Support for parsing of 'headless' messages transmitted using non SMTP transports such as HTTP
      • +
    • Reduced external dependencies. Mime4j is no longer directly dependent on log4j and commons-io
      • +
    • Improved parsing performance (up to 10x for large messages)
      • +
    • More comprehensive header parsing including support for RFC1864, RFC2045, RFC2183, RFC2557 and RFC3066
      • +
    • Revised packaging and exception hierarchy. MimeException now extends IOException
      • +

    Apr/2008 - jSPF-0.9.6 released

    We are proud to announce the availability release of APACHE jSPF-0.9.6. This release fix two possible NullPointerExceptions and handle the "exp=" modifier correctly.

    From 39dc0515d97da36d5d8d5fe82e56d5c8ac585555 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Sat, 23 Aug 2008 16:45:57 +0000 Subject: [PATCH 094/541] More content git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@688363 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 68 ++++++++++++++++++++++++++++++--- 1 file changed, 62 insertions(+), 6 deletions(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 2b2d4144f5e..62ca14ab007 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -6,12 +6,68 @@
    -

    The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news.

    -

    JAMES is organized into subprojects with JAMES Server and the Mailet API as their core. Mailets are a mail processing component - system (similar to servlets). JAMES is an advanced, fully featured, mailet-enabled mail server.

    -

    Apache JAMES is a project of The Apache Software Foundation (ASF) which encourages a collaborative, consensus-based development process under an open software license.

    -

    The ASF maintains other Java projects which may also be of interest. These are detailed on the ASF Projects page.

    -

    We recommended that users of JAMES products subscribe to the JAMES users mailing list.

    +

    +The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news. +

    + +

    +Apache projects are developed in an +open +collaborative manner. All +are welcome. +

    +We recommend that +

    + +     + +

    +The JAMES project contains many products, classified by subproject: +

    +
      +
    • JAMES Server is an advanced fully functioned +integrated mail server. It is a mailet container and delegates mail processing to mailets +(independent processing agents). Most of these mailets are +available through products in the mailets subproject. +The following protocols are supported: + +
      • +
    • The Mailet subproject collects products +related to mailets (mail processing components analogous to servlets). These are independent of the +JAMES server and can be reused in any mailet container. +
        +
      • The Mailet API specifies mailets
        • +
      • The Mailet Basic Toolkit +collects utilities and lightweight frameworks useful for developing and testing mailets
        • +
      • Standard Mailets collects +general processing mailets with limited dependencies
        • +
      • Crypto Mailets collects +mailets which perform cryptographic processing such as signing, encrypting, +decrypting and signature verification.
        • +
      +
      • +
    • jSPF implements +SPF
      • +
    • Mime4J parses MIME typed documents (including +- but not limited to - mail). APIs similar to DOM, SAX and pull parsers are exposed.
      • +
    • jSieve implements the +Sieve mail filtering language
      • +
    • Postage generates mail traffic suitable +for stress testing mail servers
      • +
    +
    From 95f8a614703d1526a2dc57a498a794bd82a3f153 Mon Sep 17 00:00:00 2001 From: bago Date: Mon, 25 Aug 2008 13:16:51 +0000 Subject: [PATCH 095/541] Homepage layout improvement attempt. Moved the news summary to the apachecon box. Only a very short summary of the last 3-4 news is expected to be there to link the full story in the news page. Also removed the subproject list from the left menu (we already have it in the top bar and in the main page content now). Changed the "Product" title to a section title instead of a subsection. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@688717 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/resources/css/site.css | 27 +++++++++++++ project/src/site/site.xml | 11 +----- project/src/site/xdoc/index.xml | 52 ++++++++----------------- 3 files changed, 44 insertions(+), 46 deletions(-) diff --git a/project/src/site/resources/css/site.css b/project/src/site/resources/css/site.css index b9279090553..dce4fafbb20 100644 --- a/project/src/site/resources/css/site.css +++ b/project/src/site/resources/css/site.css @@ -1,3 +1,30 @@ +#newsbox { + margin: 20px 0px 0px 20px; + padding: 10px; + border: 1px solid #ccc; + background-color: white; + background-image: url(../images/button-top.gif); + background-repeat: repeat-x; + width: 260px; +} +#newsboxspacer { + float: right; + margin: 0px 0px 10px 10px; + background-color: white; +} + +#newsbox ul { + padding-left: 15px; +} + +#newsbox div { + margin-left: 0px; +} + +#newsbox li { + margin-bottom: 5px; +} + #apacheconbox { margin: 20px 0px 0px 20px; padding: 10px; diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 4315ef9ecdc..4d0324a6227 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -40,22 +40,13 @@ - - - - - - - - - - + diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 62ca14ab007..6ba36449e68 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -5,6 +5,20 @@ JAMES Project Web Team +
    +
    + + + Read all the news in full in the News Archive
    +     +
    + +
    +

    The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news. @@ -23,7 +37,8 @@ We recommend that

  • Developers subscribe to the appropriate development mailing list
    • - +
    +

    The JAMES project contains many products, classified by subproject:

    @@ -67,41 +82,6 @@ decrypting and signature verification.
  • Postage generates mail traffic suitable for stress testing mail servers
    • - -
    -
    -
    - -
    -
    -
    - Read all the news in full in the News Archive
    - Or click the titles to read the full story - - Aug/2008 - Mime4j-0.4 released
    - Apr/2008 - jSPF-0.9.6 released
    - Mar/2008 - James publishes project ideas for Google Summer of Code '08
    -     - - Sep/2007 - jSPF-0.9.5 released
    - May/2007 - Apache Mime4J 0.3 Released
    - May/2007 - Mailet API sub-project lives
    - Apr/2007 - JAMES Server 2.3.1 Final Released
    - Apr/2007 - JAMES Server 2.3.1 RC1 Released
    - Apr/2007 - Apache JAMES Project Guidelines published
    - Feb/2007 - jSPF-0.9b4 released
    - Feb/2007 - Feathercast features JAMES
    - Jan/2007 - Mailet API to become sub-project
    -

    -     - - Oct/2006 - JAMES Server 2.3.0 Final Released
    - Sep/2006 - jSPF 0.9 b3 Released
    - Aug/2006 - JAMES Server 2.3.0 RC3 Released
    - Aug/2006 - JAMES Products website revamped
    - Jul/2006 - JAMES Server 2.3.0 on the way
    - Jul/2006 - New project JAMES jSPF
    -
    From 56c2f9ef17b75be6c63c0b1d6a3991d7edc3ce39 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 26 Aug 2008 21:32:46 +0000 Subject: [PATCH 096/541] Added news of JSieve 0.2 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@689240 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 6 +++++- project/src/site/xdoc/newsarchive.xml | 6 ++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 6ba36449e68..31c717f6e9b 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -9,7 +9,11 @@
    diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 2f56f373013..7500e3de28a 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -12,6 +12,12 @@
    +

    Aug/2008 - Apache JSieve 0.2 released

     +

    The Apache JAMES Project is pleased to announce the first public release of + Apache JSieve an implementation + of RFC3028 - Sieve: A Mail Filtering Language + for Java. +

    Aug/2008 - Mime4j released

    We are proud to announce the availability of APACHE Mime4j-0.4. This release brings a number of significant improvements in terms of supported capabilities, flexibility and performance:

      From 1918c32a1427c9bae232695f10c196ee3cd7bcb2 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 26 Aug 2008 21:38:26 +0000 Subject: [PATCH 097/541] Added downloads git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@689245 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 34 ++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 129ae4f8d88..0cb8adec6ea 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -220,7 +220,41 @@ href="http://www.apache.org/dist/james/jspf/source/apache-jspf-0.9.6-src.zip.asc
    +
    + + +
    From e9d67e62036fa728a0e37beeeb089cf6082bc6a1 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Wed, 27 Aug 2008 16:55:06 +0000 Subject: [PATCH 098/541] Added source jar and javadocs. Removed Other files (better not to encourage users to download checksums from mirrors.). git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@689522 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 0cb8adec6ea..c2f85f7fa54 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -244,13 +244,20 @@ href="[preferred]/james/apache-jsieve/0.2/apache-jsieve-0.2-src.zip">apache-jsie href="http://www.apache.org/dist/james/apache-jsieve/0.2/apache-jsieve-0.2-src.zip.asc">PGP][MD5] -
  • Binary (JAR library only): JAR library only: apache-jsieve-0.2.jar [PGP][MD5]
    • -
  • Other Files (javadoc.jar, sha1 checksums...)
    • +
  • Javadocs only (for IDEs): apache-jsieve-0.2-javadoc.jar [PGP][MD5]
    • + +
  • Source JAR only (for IDEs): apache-jsieve-0.2-sources.jar [PGP][MD5]
    • From 7a8de4df1a1eaccc06e9371b949766f0695ae4b2 Mon Sep 17 00:00:00 2001 From: olegk Date: Thu, 16 Oct 2008 18:40:41 +0000 Subject: [PATCH 099/541] Updated project web site for Mime4j 0.5 release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@705320 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 32 +++++++++++++-------------- project/src/site/xdoc/newsarchive.xml | 5 ++++- 2 files changed, 20 insertions(+), 17 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index c2f85f7fa54..38f265805b9 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -155,34 +155,34 @@ Binaries     -
    +
    • Binary (Unix TAR): apache-mime4j-0.4-bin.tar.gz [PGP][MD5]
      • +href="[preferred]/james/mime4j/apache-mime4j-0.5-bin.tar.gz">apache-mime4j-0.5-bin.tar.gz [PGP][MD5]
    • Binary (ZIP Format): apache-mime4j-0.4-bin.zip [PGP][MD5]
      • +href="[preferred]/james/mime4j/apache-mime4j-0.5-bin.zip">apache-mime4j-0.5-bin.zip [PGP][MD5]
    • Source (Unix TAR): apache-mime4j-0.4-src.tar.gz [PGP][MD5]
      • +href="[preferred]/james/mime4j/apache-mime4j-0.5-src.tar.gz">apache-mime4j-0.5-src.tar.gz [PGP][MD5]
    • Source (ZIP Format): apache-mime4j-0.4-src.zip [PGP][MD5]
      • +href="[preferred]/james/mime4j/apache-mime4j-0.5-src.zip">apache-mime4j-0.5-src.zip [PGP][MD5]
    • Binary (JAR library only): apache-mime4j-0.4.jar [PGP][MD5]
      • +href="[preferred]/james/mime4j/apache-mime4j-0.5.jar">apache-mime4j-0.5.jar [PGP][MD5]
    • Other Files (javadoc.jar, sha1 checksums...)
      • diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 7500e3de28a..ec21e44799b 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -12,13 +12,16 @@ +

      October/2008 - Mime4j 0.5 released

       +

      We are proud to announce the availability of APACHE Mime4j-0.5. This release addresses a number of important issues discovered since 0.4. In particular, it improves Mime4j ability to deal with malformed data streams including those intentionally crafted to cause excessive CPU and memory utilization that can lead to DoS condition

      +

      This release also fixes a serious bug that can prevent Mime4j from correctly processing binary content

      Aug/2008 - Apache JSieve 0.2 released

      The Apache JAMES Project is pleased to announce the first public release of Apache JSieve an implementation of RFC3028 - Sieve: A Mail Filtering Language for Java.

      -

      Aug/2008 - Mime4j released

       +

      Aug/2008 - Mime4j 0.4 released

      We are proud to announce the availability of APACHE Mime4j-0.4. This release brings a number of significant improvements in terms of supported capabilities, flexibility and performance:

      • Revised and improved public API with support for pull parsing
        • From c8bbaa9640794bfe38a013eff8a2fcfbc73b3485 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 11 Nov 2008 22:37:24 +0000 Subject: [PATCH 100/541] [maven-release-plugin] prepare release james-parent-1.2 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@713204 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 +- pom.xml | 791 +++++++++++++++++------------------ project/pom.xml | 4 +- project/server/2.2.0/pom.xml | 4 +- project/server/pom.xml | 4 +- 5 files changed, 403 insertions(+), 404 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 83343df239d..5131a89ff44 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.2-SNAPSHOT + 1.2 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.2-SNAPSHOT + 1.2 diff --git a/pom.xml b/pom.xml index 1c066352de3..14e9fc20651 100644 --- a/pom.xml +++ b/pom.xml @@ -1,396 +1,395 @@ - - - - 4.0.0 - org.apache.james - james-parent - Apache JAMES Parent POM - 1.2-SNAPSHOT - - The Apache JAMES Parent POM - - - - 2.0.6 - - - - maven-skin - project - - - http://james.apache.org/ - 2006 - pom - - - - - - The Apache Software Foundation - http://www.apache.org - - - - - - - maven-site-plugin - 2.0-beta-5 - - - - - - - - Apache License, Version 2.0 - http://www.apache.org/licenses/LICENSE-2.0.html - repo - - - - - JIRA - http://issues.apache.org/jira/browse/JAMES - - - - - bago - Stefano Bagnara - bago at apache.org - 2 - - Developer - - - - norman - Norman Maurer - norman at apache.org - 2 - - Developer - - - - serge - Serge Knystautas - sergek at lokitech.com - - - Developer - - - - benrdf - Bernd Fondermann - bf_jak at brainlounge.de - - - Developer - - - - sbrewin - Steve Brewin - sbrewin at synsys.com - - - Developer - - - - hilmer - - - Soren Hilmer - sh at widetrail.dk - - - Developer - - - - noel - Noel J. Bergman - noel at devtech.com - - - Developer - - - - danny - Danny Angus - danny at apache.org - - - Developer - - - - adc - Alan D. Cabrera - list at toolazydogs.com - -8 - - Developer - - - - vincenzo - Vincenzo Gianferrari Pini - vincenzo.gianferraripini at praxis.it - - - Developer - - - - rdonkin - Robert Burrell Donkin - rdonkin at apache.org - - - Developer - - - - niklas - Niklas Therning - niklas(at)apache(dot)org - Trillian AB - - - jcheng - Joe Cheng - joe(at)joecheng(dot)com - - - Former author to the mime4j product - - - - - - - - Rob Oxspring - - - Contributed to the mime4j product - - - - - Roger Fullerton - - - Wrote spfjava, the first spf implementation in java - - - - - - - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk - http://svn.apache.org/viewvc/james/project/trunk - - - - - apache.releases - Apache Release Distribution Repository - scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository - - - apache.snapshots - Apache Development Snapshot Repository - scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository - - - - james-parent-website - scp://people.apache.org/www/james.apache.org/parent/ - - - - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - true - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - true - - - - - - - - parent - - - local-james-parent-stage - Apache JAMES parent stage repository folder - file://${basedir}/stage - legacy - - true - ignore - - - true - ignore - - - - - - - local - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - false - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - false - - - - - - - release - - - - - maven-gpg-plugin - 1.0-alpha-3 - - ${gpg.passphrase} - - - - sign-artifacts - verify - - sign - - - - - - - true - maven-deploy-plugin - 2.3 - - ${deploy.altRepository} - true - - - - org.apache.maven.plugins - maven-source-plugin - 2.0.2 - - - attach-sources - - jar - - - - - - org.apache.maven.plugins - maven-javadoc-plugin - 2.2 - - - attach-javadocs - - jar - - - - - - - - - - - + + + 4.0.0 + org.apache.james + james-parent + Apache JAMES Parent POM + 1.2 + + The Apache JAMES Parent POM + + + + 2.0.6 + + + + maven-skin + project + + + http://james.apache.org/ + 2006 + pom + + + + + + The Apache Software Foundation + http://www.apache.org + + + + + + + maven-site-plugin + 2.0-beta-5 + + + + + + + + Apache License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.html + repo + + + + + JIRA + http://issues.apache.org/jira/browse/JAMES + + + + + bago + Stefano Bagnara + bago at apache.org + 2 + + Developer + + + + norman + Norman Maurer + norman at apache.org + 2 + + Developer + + + + serge + Serge Knystautas + sergek at lokitech.com + + + Developer + + + + benrdf + Bernd Fondermann + bf_jak at brainlounge.de + + + Developer + + + + sbrewin + Steve Brewin + sbrewin at synsys.com + + + Developer + + + + hilmer + + + Soren Hilmer + sh at widetrail.dk + + + Developer + + + + noel + Noel J. Bergman + noel at devtech.com + + + Developer + + + + danny + Danny Angus + danny at apache.org + + + Developer + + + + adc + Alan D. Cabrera + list at toolazydogs.com + -8 + + Developer + + + + vincenzo + Vincenzo Gianferrari Pini + vincenzo.gianferraripini at praxis.it + + + Developer + + + + rdonkin + Robert Burrell Donkin + rdonkin at apache.org + + + Developer + + + + niklas + Niklas Therning + niklas(at)apache(dot)org + Trillian AB + + + jcheng + Joe Cheng + joe(at)joecheng(dot)com + + + Former author to the mime4j product + + + + + + + + Rob Oxspring + + + Contributed to the mime4j product + + + + + Roger Fullerton + + + Wrote spfjava, the first spf implementation in java + + + + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + + + + + apache.releases + Apache Release Distribution Repository + scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository + + + apache.snapshots + Apache Development Snapshot Repository + scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository + + + + james-parent-website + scp://people.apache.org/www/james.apache.org/parent/ + + + + + + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + true + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + true + + + + + + + + parent + + + local-james-parent-stage + Apache JAMES parent stage repository folder + file://${basedir}/stage + legacy + + true + ignore + + + true + ignore + + + + + + + local + + + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + false + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + false + + + + + + + release + + + + + maven-gpg-plugin + 1.0-alpha-3 + + ${gpg.passphrase} + + + + sign-artifacts + verify + + sign + + + + + + + true + maven-deploy-plugin + 2.3 + + ${deploy.altRepository} + true + + + + org.apache.maven.plugins + maven-source-plugin + 2.0.2 + + + attach-sources + + jar + + + + + + org.apache.maven.plugins + maven-javadoc-plugin + 2.2 + + + attach-javadocs + + jar + + + + + + + + + + + \ No newline at end of file diff --git a/project/pom.xml b/project/pom.xml index dbaffe190b1..1f32352a929 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.3-SNAPSHOT + 1.3 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.2-SNAPSHOT + 1.2 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 9f933baa2f5..418c3a679f7 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.2-SNAPSHOT + 1.2 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.2-SNAPSHOT + 1.2 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 8930873f3c0..3ff296ef41f 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.2-SNAPSHOT + 1.2 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.3-SNAPSHOT + 1.3 2.2.0 From a1ec5d05b64e05448287814ce3ac19be195f463b Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 11 Nov 2008 22:48:06 +0000 Subject: [PATCH 101/541] Reverted 713204 after maven release plugin failed to complete tagging. Will adjust and try again. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@713210 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 +- pom.xml | 791 ++++++++++++++++++----------------- project/pom.xml | 4 +- project/server/2.2.0/pom.xml | 4 +- project/server/pom.xml | 4 +- 5 files changed, 404 insertions(+), 403 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 5131a89ff44..83343df239d 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.2 + 1.2-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.2 + 1.2-SNAPSHOT diff --git a/pom.xml b/pom.xml index 14e9fc20651..1c066352de3 100644 --- a/pom.xml +++ b/pom.xml @@ -1,395 +1,396 @@ - - - 4.0.0 - org.apache.james - james-parent - Apache JAMES Parent POM - 1.2 - - The Apache JAMES Parent POM - - - - 2.0.6 - - - - maven-skin - project - - - http://james.apache.org/ - 2006 - pom - - - - - - The Apache Software Foundation - http://www.apache.org - - - - - - - maven-site-plugin - 2.0-beta-5 - - - - - - - - Apache License, Version 2.0 - http://www.apache.org/licenses/LICENSE-2.0.html - repo - - - - - JIRA - http://issues.apache.org/jira/browse/JAMES - - - - - bago - Stefano Bagnara - bago at apache.org - 2 - - Developer - - - - norman - Norman Maurer - norman at apache.org - 2 - - Developer - - - - serge - Serge Knystautas - sergek at lokitech.com - - - Developer - - - - benrdf - Bernd Fondermann - bf_jak at brainlounge.de - - - Developer - - - - sbrewin - Steve Brewin - sbrewin at synsys.com - - - Developer - - - - hilmer - - - Soren Hilmer - sh at widetrail.dk - - - Developer - - - - noel - Noel J. Bergman - noel at devtech.com - - - Developer - - - - danny - Danny Angus - danny at apache.org - - - Developer - - - - adc - Alan D. Cabrera - list at toolazydogs.com - -8 - - Developer - - - - vincenzo - Vincenzo Gianferrari Pini - vincenzo.gianferraripini at praxis.it - - - Developer - - - - rdonkin - Robert Burrell Donkin - rdonkin at apache.org - - - Developer - - - - niklas - Niklas Therning - niklas(at)apache(dot)org - Trillian AB - - - jcheng - Joe Cheng - joe(at)joecheng(dot)com - - - Former author to the mime4j product - - - - - - - - Rob Oxspring - - - Contributed to the mime4j product - - - - - Roger Fullerton - - - Wrote spfjava, the first spf implementation in java - - - - - - - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 - - - - - apache.releases - Apache Release Distribution Repository - scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository - - - apache.snapshots - Apache Development Snapshot Repository - scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository - - - - james-parent-website - scp://people.apache.org/www/james.apache.org/parent/ - - - - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - true - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - true - - - - - - - - parent - - - local-james-parent-stage - Apache JAMES parent stage repository folder - file://${basedir}/stage - legacy - - true - ignore - - - true - ignore - - - - - - - local - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - false - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - false - - - - - - - release - - - - - maven-gpg-plugin - 1.0-alpha-3 - - ${gpg.passphrase} - - - - sign-artifacts - verify - - sign - - - - - - - true - maven-deploy-plugin - 2.3 - - ${deploy.altRepository} - true - - - - org.apache.maven.plugins - maven-source-plugin - 2.0.2 - - - attach-sources - - jar - - - - - - org.apache.maven.plugins - maven-javadoc-plugin - 2.2 - - - attach-javadocs - - jar - - - - - - - - - - - \ No newline at end of file + + + + 4.0.0 + org.apache.james + james-parent + Apache JAMES Parent POM + 1.2-SNAPSHOT + + The Apache JAMES Parent POM + + + + 2.0.6 + + + + maven-skin + project + + + http://james.apache.org/ + 2006 + pom + + + + + + The Apache Software Foundation + http://www.apache.org + + + + + + + maven-site-plugin + 2.0-beta-5 + + + + + + + + Apache License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.html + repo + + + + + JIRA + http://issues.apache.org/jira/browse/JAMES + + + + + bago + Stefano Bagnara + bago at apache.org + 2 + + Developer + + + + norman + Norman Maurer + norman at apache.org + 2 + + Developer + + + + serge + Serge Knystautas + sergek at lokitech.com + + + Developer + + + + benrdf + Bernd Fondermann + bf_jak at brainlounge.de + + + Developer + + + + sbrewin + Steve Brewin + sbrewin at synsys.com + + + Developer + + + + hilmer + + + Soren Hilmer + sh at widetrail.dk + + + Developer + + + + noel + Noel J. Bergman + noel at devtech.com + + + Developer + + + + danny + Danny Angus + danny at apache.org + + + Developer + + + + adc + Alan D. Cabrera + list at toolazydogs.com + -8 + + Developer + + + + vincenzo + Vincenzo Gianferrari Pini + vincenzo.gianferraripini at praxis.it + + + Developer + + + + rdonkin + Robert Burrell Donkin + rdonkin at apache.org + + + Developer + + + + niklas + Niklas Therning + niklas(at)apache(dot)org + Trillian AB + + + jcheng + Joe Cheng + joe(at)joecheng(dot)com + + + Former author to the mime4j product + + + + + + + + Rob Oxspring + + + Contributed to the mime4j product + + + + + Roger Fullerton + + + Wrote spfjava, the first spf implementation in java + + + + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk + + + + + apache.releases + Apache Release Distribution Repository + scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository + + + apache.snapshots + Apache Development Snapshot Repository + scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository + + + + james-parent-website + scp://people.apache.org/www/james.apache.org/parent/ + + + + + + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + true + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + true + + + + + + + + parent + + + local-james-parent-stage + Apache JAMES parent stage repository folder + file://${basedir}/stage + legacy + + true + ignore + + + true + ignore + + + + + + + local + + + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + false + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + false + + + + + + + release + + + + + maven-gpg-plugin + 1.0-alpha-3 + + ${gpg.passphrase} + + + + sign-artifacts + verify + + sign + + + + + + + true + maven-deploy-plugin + 2.3 + + ${deploy.altRepository} + true + + + + org.apache.maven.plugins + maven-source-plugin + 2.0.2 + + + attach-sources + + jar + + + + + + org.apache.maven.plugins + maven-javadoc-plugin + 2.2 + + + attach-javadocs + + jar + + + + + + + + + + + diff --git a/project/pom.xml b/project/pom.xml index 1f32352a929..dbaffe190b1 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.3 + 1.3-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.2 + 1.2-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 418c3a679f7..9f933baa2f5 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.2 + 1.2-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.2 + 1.2-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 3ff296ef41f..8930873f3c0 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.2 + 1.2-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.3 + 1.3-SNAPSHOT 2.2.0 From f9e73d6245d1f25829ff3edb0e1aefb70cbc3f39 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 11 Nov 2008 22:49:35 +0000 Subject: [PATCH 102/541] [maven-release-plugin] prepare release james-parent-1.3 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@713212 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 +- pom.xml | 791 +++++++++++++++++------------------ project/pom.xml | 4 +- project/server/2.2.0/pom.xml | 4 +- project/server/pom.xml | 4 +- 5 files changed, 403 insertions(+), 404 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 83343df239d..e39389a002e 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.2-SNAPSHOT + 1.3 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.2-SNAPSHOT + 1.3 diff --git a/pom.xml b/pom.xml index 1c066352de3..6e866b4a973 100644 --- a/pom.xml +++ b/pom.xml @@ -1,396 +1,395 @@ - - - - 4.0.0 - org.apache.james - james-parent - Apache JAMES Parent POM - 1.2-SNAPSHOT - - The Apache JAMES Parent POM - - - - 2.0.6 - - - - maven-skin - project - - - http://james.apache.org/ - 2006 - pom - - - - - - The Apache Software Foundation - http://www.apache.org - - - - - - - maven-site-plugin - 2.0-beta-5 - - - - - - - - Apache License, Version 2.0 - http://www.apache.org/licenses/LICENSE-2.0.html - repo - - - - - JIRA - http://issues.apache.org/jira/browse/JAMES - - - - - bago - Stefano Bagnara - bago at apache.org - 2 - - Developer - - - - norman - Norman Maurer - norman at apache.org - 2 - - Developer - - - - serge - Serge Knystautas - sergek at lokitech.com - - - Developer - - - - benrdf - Bernd Fondermann - bf_jak at brainlounge.de - - - Developer - - - - sbrewin - Steve Brewin - sbrewin at synsys.com - - - Developer - - - - hilmer - - - Soren Hilmer - sh at widetrail.dk - - - Developer - - - - noel - Noel J. Bergman - noel at devtech.com - - - Developer - - - - danny - Danny Angus - danny at apache.org - - - Developer - - - - adc - Alan D. Cabrera - list at toolazydogs.com - -8 - - Developer - - - - vincenzo - Vincenzo Gianferrari Pini - vincenzo.gianferraripini at praxis.it - - - Developer - - - - rdonkin - Robert Burrell Donkin - rdonkin at apache.org - - - Developer - - - - niklas - Niklas Therning - niklas(at)apache(dot)org - Trillian AB - - - jcheng - Joe Cheng - joe(at)joecheng(dot)com - - - Former author to the mime4j product - - - - - - - - Rob Oxspring - - - Contributed to the mime4j product - - - - - Roger Fullerton - - - Wrote spfjava, the first spf implementation in java - - - - - - - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk - http://svn.apache.org/viewvc/james/project/trunk - - - - - apache.releases - Apache Release Distribution Repository - scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository - - - apache.snapshots - Apache Development Snapshot Repository - scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository - - - - james-parent-website - scp://people.apache.org/www/james.apache.org/parent/ - - - - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - true - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - true - - - - - - - - parent - - - local-james-parent-stage - Apache JAMES parent stage repository folder - file://${basedir}/stage - legacy - - true - ignore - - - true - ignore - - - - - - - local - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - false - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - false - - - - - - - release - - - - - maven-gpg-plugin - 1.0-alpha-3 - - ${gpg.passphrase} - - - - sign-artifacts - verify - - sign - - - - - - - true - maven-deploy-plugin - 2.3 - - ${deploy.altRepository} - true - - - - org.apache.maven.plugins - maven-source-plugin - 2.0.2 - - - attach-sources - - jar - - - - - - org.apache.maven.plugins - maven-javadoc-plugin - 2.2 - - - attach-javadocs - - jar - - - - - - - - - - - + + + 4.0.0 + org.apache.james + james-parent + Apache JAMES Parent POM + 1.3 + + The Apache JAMES Parent POM + + + + 2.0.6 + + + + maven-skin + project + + + http://james.apache.org/ + 2006 + pom + + + + + + The Apache Software Foundation + http://www.apache.org + + + + + + + maven-site-plugin + 2.0-beta-5 + + + + + + + + Apache License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.html + repo + + + + + JIRA + http://issues.apache.org/jira/browse/JAMES + + + + + bago + Stefano Bagnara + bago at apache.org + 2 + + Developer + + + + norman + Norman Maurer + norman at apache.org + 2 + + Developer + + + + serge + Serge Knystautas + sergek at lokitech.com + + + Developer + + + + benrdf + Bernd Fondermann + bf_jak at brainlounge.de + + + Developer + + + + sbrewin + Steve Brewin + sbrewin at synsys.com + + + Developer + + + + hilmer + + + Soren Hilmer + sh at widetrail.dk + + + Developer + + + + noel + Noel J. Bergman + noel at devtech.com + + + Developer + + + + danny + Danny Angus + danny at apache.org + + + Developer + + + + adc + Alan D. Cabrera + list at toolazydogs.com + -8 + + Developer + + + + vincenzo + Vincenzo Gianferrari Pini + vincenzo.gianferraripini at praxis.it + + + Developer + + + + rdonkin + Robert Burrell Donkin + rdonkin at apache.org + + + Developer + + + + niklas + Niklas Therning + niklas(at)apache(dot)org + Trillian AB + + + jcheng + Joe Cheng + joe(at)joecheng(dot)com + + + Former author to the mime4j product + + + + + + + + Rob Oxspring + + + Contributed to the mime4j product + + + + + Roger Fullerton + + + Wrote spfjava, the first spf implementation in java + + + + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.3 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.3 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.3 + + + + + apache.releases + Apache Release Distribution Repository + scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository + + + apache.snapshots + Apache Development Snapshot Repository + scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository + + + + james-parent-website + scp://people.apache.org/www/james.apache.org/parent/ + + + + + + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + true + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + true + + + + + + + + parent + + + local-james-parent-stage + Apache JAMES parent stage repository folder + file://${basedir}/stage + legacy + + true + ignore + + + true + ignore + + + + + + + local + + + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + false + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + false + + + + + + + release + + + + + maven-gpg-plugin + 1.0-alpha-3 + + ${gpg.passphrase} + + + + sign-artifacts + verify + + sign + + + + + + + true + maven-deploy-plugin + 2.3 + + ${deploy.altRepository} + true + + + + org.apache.maven.plugins + maven-source-plugin + 2.0.2 + + + attach-sources + + jar + + + + + + org.apache.maven.plugins + maven-javadoc-plugin + 2.2 + + + attach-javadocs + + jar + + + + + + + + + + + \ No newline at end of file diff --git a/project/pom.xml b/project/pom.xml index dbaffe190b1..6efa42141d1 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.3-SNAPSHOT + 1.3 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.2-SNAPSHOT + 1.3 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 9f933baa2f5..87436cea6f3 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.2-SNAPSHOT + 1.3 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.2-SNAPSHOT + 1.3 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 8930873f3c0..a8fe646c582 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.2-SNAPSHOT + 1.3 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.3-SNAPSHOT + 1.3 2.2.0 From 4f13bb8c384806beb2879a9a56c7fcbc42891d14 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 11 Nov 2008 22:53:07 +0000 Subject: [PATCH 103/541] Reverted 713212 after maven release plugin failed to complete tagging. Giving up current attempt. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@713213 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 +- pom.xml | 791 ++++++++++++++++++----------------- project/pom.xml | 4 +- project/server/2.2.0/pom.xml | 4 +- project/server/pom.xml | 4 +- 5 files changed, 404 insertions(+), 403 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index e39389a002e..83343df239d 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.3 + 1.2-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.3 + 1.2-SNAPSHOT diff --git a/pom.xml b/pom.xml index 6e866b4a973..1c066352de3 100644 --- a/pom.xml +++ b/pom.xml @@ -1,395 +1,396 @@ - - - 4.0.0 - org.apache.james - james-parent - Apache JAMES Parent POM - 1.3 - - The Apache JAMES Parent POM - - - - 2.0.6 - - - - maven-skin - project - - - http://james.apache.org/ - 2006 - pom - - - - - - The Apache Software Foundation - http://www.apache.org - - - - - - - maven-site-plugin - 2.0-beta-5 - - - - - - - - Apache License, Version 2.0 - http://www.apache.org/licenses/LICENSE-2.0.html - repo - - - - - JIRA - http://issues.apache.org/jira/browse/JAMES - - - - - bago - Stefano Bagnara - bago at apache.org - 2 - - Developer - - - - norman - Norman Maurer - norman at apache.org - 2 - - Developer - - - - serge - Serge Knystautas - sergek at lokitech.com - - - Developer - - - - benrdf - Bernd Fondermann - bf_jak at brainlounge.de - - - Developer - - - - sbrewin - Steve Brewin - sbrewin at synsys.com - - - Developer - - - - hilmer - - - Soren Hilmer - sh at widetrail.dk - - - Developer - - - - noel - Noel J. Bergman - noel at devtech.com - - - Developer - - - - danny - Danny Angus - danny at apache.org - - - Developer - - - - adc - Alan D. Cabrera - list at toolazydogs.com - -8 - - Developer - - - - vincenzo - Vincenzo Gianferrari Pini - vincenzo.gianferraripini at praxis.it - - - Developer - - - - rdonkin - Robert Burrell Donkin - rdonkin at apache.org - - - Developer - - - - niklas - Niklas Therning - niklas(at)apache(dot)org - Trillian AB - - - jcheng - Joe Cheng - joe(at)joecheng(dot)com - - - Former author to the mime4j product - - - - - - - - Rob Oxspring - - - Contributed to the mime4j product - - - - - Roger Fullerton - - - Wrote spfjava, the first spf implementation in java - - - - - - - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.3 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.3 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.3 - - - - - apache.releases - Apache Release Distribution Repository - scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository - - - apache.snapshots - Apache Development Snapshot Repository - scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository - - - - james-parent-website - scp://people.apache.org/www/james.apache.org/parent/ - - - - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - true - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - true - - - - - - - - parent - - - local-james-parent-stage - Apache JAMES parent stage repository folder - file://${basedir}/stage - legacy - - true - ignore - - - true - ignore - - - - - - - local - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - false - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - false - - - - - - - release - - - - - maven-gpg-plugin - 1.0-alpha-3 - - ${gpg.passphrase} - - - - sign-artifacts - verify - - sign - - - - - - - true - maven-deploy-plugin - 2.3 - - ${deploy.altRepository} - true - - - - org.apache.maven.plugins - maven-source-plugin - 2.0.2 - - - attach-sources - - jar - - - - - - org.apache.maven.plugins - maven-javadoc-plugin - 2.2 - - - attach-javadocs - - jar - - - - - - - - - - - \ No newline at end of file + + + + 4.0.0 + org.apache.james + james-parent + Apache JAMES Parent POM + 1.2-SNAPSHOT + + The Apache JAMES Parent POM + + + + 2.0.6 + + + + maven-skin + project + + + http://james.apache.org/ + 2006 + pom + + + + + + The Apache Software Foundation + http://www.apache.org + + + + + + + maven-site-plugin + 2.0-beta-5 + + + + + + + + Apache License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.html + repo + + + + + JIRA + http://issues.apache.org/jira/browse/JAMES + + + + + bago + Stefano Bagnara + bago at apache.org + 2 + + Developer + + + + norman + Norman Maurer + norman at apache.org + 2 + + Developer + + + + serge + Serge Knystautas + sergek at lokitech.com + + + Developer + + + + benrdf + Bernd Fondermann + bf_jak at brainlounge.de + + + Developer + + + + sbrewin + Steve Brewin + sbrewin at synsys.com + + + Developer + + + + hilmer + + + Soren Hilmer + sh at widetrail.dk + + + Developer + + + + noel + Noel J. Bergman + noel at devtech.com + + + Developer + + + + danny + Danny Angus + danny at apache.org + + + Developer + + + + adc + Alan D. Cabrera + list at toolazydogs.com + -8 + + Developer + + + + vincenzo + Vincenzo Gianferrari Pini + vincenzo.gianferraripini at praxis.it + + + Developer + + + + rdonkin + Robert Burrell Donkin + rdonkin at apache.org + + + Developer + + + + niklas + Niklas Therning + niklas(at)apache(dot)org + Trillian AB + + + jcheng + Joe Cheng + joe(at)joecheng(dot)com + + + Former author to the mime4j product + + + + + + + + Rob Oxspring + + + Contributed to the mime4j product + + + + + Roger Fullerton + + + Wrote spfjava, the first spf implementation in java + + + + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk + + + + + apache.releases + Apache Release Distribution Repository + scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository + + + apache.snapshots + Apache Development Snapshot Repository + scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository + + + + james-parent-website + scp://people.apache.org/www/james.apache.org/parent/ + + + + + + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + true + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + true + + + + + + + + parent + + + local-james-parent-stage + Apache JAMES parent stage repository folder + file://${basedir}/stage + legacy + + true + ignore + + + true + ignore + + + + + + + local + + + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + false + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + false + + + + + + + release + + + + + maven-gpg-plugin + 1.0-alpha-3 + + ${gpg.passphrase} + + + + sign-artifacts + verify + + sign + + + + + + + true + maven-deploy-plugin + 2.3 + + ${deploy.altRepository} + true + + + + org.apache.maven.plugins + maven-source-plugin + 2.0.2 + + + attach-sources + + jar + + + + + + org.apache.maven.plugins + maven-javadoc-plugin + 2.2 + + + attach-javadocs + + jar + + + + + + + + + + + diff --git a/project/pom.xml b/project/pom.xml index 6efa42141d1..dbaffe190b1 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.3 + 1.3-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.3 + 1.2-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 87436cea6f3..9f933baa2f5 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.3 + 1.2-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.3 + 1.2-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index a8fe646c582..8930873f3c0 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.3 + 1.2-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.3 + 1.3-SNAPSHOT 2.2.0 From b3d76674ac41f74892ed30b7915a297883637c6b Mon Sep 17 00:00:00 2001 From: rdonkin Date: Wed, 12 Nov 2008 20:59:23 +0000 Subject: [PATCH 104/541] [maven-release-plugin] prepare release james-parent-1.2 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@713507 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 +- pom.xml | 791 +++++++++++++++++------------------ project/pom.xml | 4 +- project/server/2.2.0/pom.xml | 4 +- project/server/pom.xml | 4 +- 5 files changed, 403 insertions(+), 404 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 83343df239d..5131a89ff44 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.2-SNAPSHOT + 1.2 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.2-SNAPSHOT + 1.2 diff --git a/pom.xml b/pom.xml index 1c066352de3..14e9fc20651 100644 --- a/pom.xml +++ b/pom.xml @@ -1,396 +1,395 @@ - - - - 4.0.0 - org.apache.james - james-parent - Apache JAMES Parent POM - 1.2-SNAPSHOT - - The Apache JAMES Parent POM - - - - 2.0.6 - - - - maven-skin - project - - - http://james.apache.org/ - 2006 - pom - - - - - - The Apache Software Foundation - http://www.apache.org - - - - - - - maven-site-plugin - 2.0-beta-5 - - - - - - - - Apache License, Version 2.0 - http://www.apache.org/licenses/LICENSE-2.0.html - repo - - - - - JIRA - http://issues.apache.org/jira/browse/JAMES - - - - - bago - Stefano Bagnara - bago at apache.org - 2 - - Developer - - - - norman - Norman Maurer - norman at apache.org - 2 - - Developer - - - - serge - Serge Knystautas - sergek at lokitech.com - - - Developer - - - - benrdf - Bernd Fondermann - bf_jak at brainlounge.de - - - Developer - - - - sbrewin - Steve Brewin - sbrewin at synsys.com - - - Developer - - - - hilmer - - - Soren Hilmer - sh at widetrail.dk - - - Developer - - - - noel - Noel J. Bergman - noel at devtech.com - - - Developer - - - - danny - Danny Angus - danny at apache.org - - - Developer - - - - adc - Alan D. Cabrera - list at toolazydogs.com - -8 - - Developer - - - - vincenzo - Vincenzo Gianferrari Pini - vincenzo.gianferraripini at praxis.it - - - Developer - - - - rdonkin - Robert Burrell Donkin - rdonkin at apache.org - - - Developer - - - - niklas - Niklas Therning - niklas(at)apache(dot)org - Trillian AB - - - jcheng - Joe Cheng - joe(at)joecheng(dot)com - - - Former author to the mime4j product - - - - - - - - Rob Oxspring - - - Contributed to the mime4j product - - - - - Roger Fullerton - - - Wrote spfjava, the first spf implementation in java - - - - - - - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk - http://svn.apache.org/viewvc/james/project/trunk - - - - - apache.releases - Apache Release Distribution Repository - scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository - - - apache.snapshots - Apache Development Snapshot Repository - scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository - - - - james-parent-website - scp://people.apache.org/www/james.apache.org/parent/ - - - - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - true - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - true - - - - - - - - parent - - - local-james-parent-stage - Apache JAMES parent stage repository folder - file://${basedir}/stage - legacy - - true - ignore - - - true - ignore - - - - - - - local - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - false - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - false - - - - - - - release - - - - - maven-gpg-plugin - 1.0-alpha-3 - - ${gpg.passphrase} - - - - sign-artifacts - verify - - sign - - - - - - - true - maven-deploy-plugin - 2.3 - - ${deploy.altRepository} - true - - - - org.apache.maven.plugins - maven-source-plugin - 2.0.2 - - - attach-sources - - jar - - - - - - org.apache.maven.plugins - maven-javadoc-plugin - 2.2 - - - attach-javadocs - - jar - - - - - - - - - - - + + + 4.0.0 + org.apache.james + james-parent + Apache JAMES Parent POM + 1.2 + + The Apache JAMES Parent POM + + + + 2.0.6 + + + + maven-skin + project + + + http://james.apache.org/ + 2006 + pom + + + + + + The Apache Software Foundation + http://www.apache.org + + + + + + + maven-site-plugin + 2.0-beta-5 + + + + + + + + Apache License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.html + repo + + + + + JIRA + http://issues.apache.org/jira/browse/JAMES + + + + + bago + Stefano Bagnara + bago at apache.org + 2 + + Developer + + + + norman + Norman Maurer + norman at apache.org + 2 + + Developer + + + + serge + Serge Knystautas + sergek at lokitech.com + + + Developer + + + + benrdf + Bernd Fondermann + bf_jak at brainlounge.de + + + Developer + + + + sbrewin + Steve Brewin + sbrewin at synsys.com + + + Developer + + + + hilmer + + + Soren Hilmer + sh at widetrail.dk + + + Developer + + + + noel + Noel J. Bergman + noel at devtech.com + + + Developer + + + + danny + Danny Angus + danny at apache.org + + + Developer + + + + adc + Alan D. Cabrera + list at toolazydogs.com + -8 + + Developer + + + + vincenzo + Vincenzo Gianferrari Pini + vincenzo.gianferraripini at praxis.it + + + Developer + + + + rdonkin + Robert Burrell Donkin + rdonkin at apache.org + + + Developer + + + + niklas + Niklas Therning + niklas(at)apache(dot)org + Trillian AB + + + jcheng + Joe Cheng + joe(at)joecheng(dot)com + + + Former author to the mime4j product + + + + + + + + Rob Oxspring + + + Contributed to the mime4j product + + + + + Roger Fullerton + + + Wrote spfjava, the first spf implementation in java + + + + + + + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + + + + + apache.releases + Apache Release Distribution Repository + scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository + + + apache.snapshots + Apache Development Snapshot Repository + scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository + + + + james-parent-website + scp://people.apache.org/www/james.apache.org/parent/ + + + + + + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + true + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + true + + + + + + + + parent + + + local-james-parent-stage + Apache JAMES parent stage repository folder + file://${basedir}/stage + legacy + + true + ignore + + + true + ignore + + + + + + + local + + + central + http://repo1.maven.org/maven2 + + false + + + false + + + + apache.releases + Apache Main M2 Repository + http://people.apache.org/repo/m2-ibiblio-rsync-repository + + false + + + false + + + + apache.snapshots + Apache Snapshot Repository + http://people.apache.org/repo/m2-snapshot-repository + + false + + + false + + + + + + + release + + + + + maven-gpg-plugin + 1.0-alpha-3 + + ${gpg.passphrase} + + + + sign-artifacts + verify + + sign + + + + + + + true + maven-deploy-plugin + 2.3 + + ${deploy.altRepository} + true + + + + org.apache.maven.plugins + maven-source-plugin + 2.0.2 + + + attach-sources + + jar + + + + + + org.apache.maven.plugins + maven-javadoc-plugin + 2.2 + + + attach-javadocs + + jar + + + + + + + + + + + \ No newline at end of file diff --git a/project/pom.xml b/project/pom.xml index dbaffe190b1..1f32352a929 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.3-SNAPSHOT + 1.3 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.2-SNAPSHOT + 1.2 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 9f933baa2f5..418c3a679f7 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.2-SNAPSHOT + 1.2 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.2-SNAPSHOT + 1.2 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 8930873f3c0..3ff296ef41f 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.2-SNAPSHOT + 1.2 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.3-SNAPSHOT + 1.3 2.2.0 From 11e92cad502b3ed94b8913560a4b2ce4c82a44f3 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Wed, 12 Nov 2008 21:10:10 +0000 Subject: [PATCH 105/541] Update pom version numbers git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@713511 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 4 ++-- project/pom.xml | 2 +- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 5131a89ff44..fcd93f43c81 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,7 +20,7 @@ 4.0.0 org.apache.james maven-skin - 1.2 + 1.3-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin @@ -63,4 +63,4 @@ - \ No newline at end of file + diff --git a/pom.xml b/pom.xml index 14e9fc20651..26c285f6cb2 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.2 + 1.3-SNAPSHOT The Apache JAMES Parent POM @@ -392,4 +392,4 @@ - \ No newline at end of file + diff --git a/project/pom.xml b/project/pom.xml index 1f32352a929..0572cc42ab5 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.3 + 1.4-SNAPSHOT The Apache JAMES Project diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 418c3a679f7..41e544eada3 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.2 + 1.3-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -41,4 +41,4 @@ scp://people.apache.org/www/james.apache.org/server/2.2.0/ - \ No newline at end of file + diff --git a/project/server/pom.xml b/project/server/pom.xml index 3ff296ef41f..c99cddf9013 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.2 + 1.3-SNAPSHOT Apache JAMES Server @@ -85,4 +85,4 @@ - \ No newline at end of file + From 120c2fc39f92942967dd754281878896c825fe48 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Mon, 5 Jan 2009 22:54:05 +0000 Subject: [PATCH 106/541] Add news of release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@731757 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 115 +++++++++++++++++--------- project/src/site/xdoc/index.xml | 4 + project/src/site/xdoc/newsarchive.xml | 9 ++ 3 files changed, 90 insertions(+), 38 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 38f265805b9..db4d59f267e 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -24,9 +24,9 @@ -
        +
        -

        Use the links below to download the Apache JAMES Mail Server from one of +

        Use the links below to download the product from one of our mirrors. You must verify the integrity of the downloaded files using signatures downloaded from our main distribution directory.

        @@ -36,7 +36,13 @@ distribution site and its mirrors. Older releases are available from the archive download site.

        -
        + @@ -66,8 +72,39 @@ Other mirrors: -[if-any http] - [for http][end] -[end] -[if-any ftp] - [for ftp][end] -[end] -[if-any backup] - [for backup][end] -[end] - - - - -

        You may also consult the complete -list of mirrors.

        - -         - -
        -

        Apache JAMES server 2.3.1 has been released and no new unstable releases have been released. -Please go to the stable releases download page to download it. -

        -
        - - -
        -

        Apache JAMES jSPF 0.9.6 has been released and no new unstable releases have been released. -Please go to the stable releases download page to download it. -

        -
        - - -
        -

        Apache Mime4J 0.4 has been released an no new unstable releases have been released. -Please go to the stable releases download page to download it. -

        -
        - - - -

        It is essential that you verify the integrity of the downloaded -files using the PGP or MD5 signatures.

        - -

        The PGP signatures can be verified using PGP or GPG. First -download the KEYS -as well as the asc signature file for the particular -distribution. Make sure you get these files from the main distribution -directory, rather than from a mirror. Then verify the signatures -using

        - -

        -% pgpk -a KEYS
        -% pgpv james-version.tar.gz.asc
        -         -or
        - -% pgp -ka KEYS
        -% pgp james-version.tar.gz.asc
        -         -or
        - -% gpg --import KEYS
        -% gpg --verify james-version.tar.gz.asc -

        - -         - -
        - -

        The software listed above represents the latest unstable builds -available from the Apache JAMES Project. -You can download Stable Releases here. -Unstable releases are announced on the General mailing list (general@james.apache.org). - -

        -

        - -

        The JAMES project also provides -Nighly Builds: -periodic snapshots during development. Generally, these are considered -stable snapshots, but they have not undergone as much testing as a -Release Build, nor have they been voted upon for release by the -developer community. These are simply convenient test builds. -Sometimes the purpose for a Nightly Build could be soliciting feedback on -a specific change. -

        - - -
        - - - diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index c215192da8f..92cc5a7af13 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -83,7 +83,7 @@

        Sept/2007 - jSPF-0.9.5 released

         -

        We are proud to announce the availability of APACHE jSPF-0.9.5. This release brings initial support for asynchronous processing and is fully RFC4408 compliant.

        +

        We are proud to announce the availability of APACHE jSPF-0.9.5. This release brings initial support for asynchronous processing and is fully RFC4408 compliant.

        May/2007 - Apache Mime4J 0.3 Final Released

        After almost 2 years the Apache JAMES team is proud to announce the availability of Apache Mime4J 0.3. This is the first release under the ASF umbrella.

        May/2007 - Mailet API sub-project lives

         From 0cc5f99987df609cc33e52942cff1f24f9974ecf Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 14 May 2009 14:52:47 +0000 Subject: [PATCH 121/541] Added crypto mailets download git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@774799 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 39 ++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 103014f616e..90d8672b07e 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -43,6 +43,7 @@ site.

      • Apache JSieve
      • Apache Mailet
      • Apache Mailet Base
        • +
      • Apache Crypto Mailets
      • The MailetDoc Plugin for Maven is available from the standard repositories
      @@ -372,6 +373,44 @@ href="http://www.apache.org/dist/james/apache-mailet-base/1.0/apache-mailet-base
    +
    +

    Apache Crypto Mailets 1.0 is the latest stable version:

    + + +
    +

    The software listed above represents the latest Release Build From 83061fe96be574a19f3eb411418dcb29e25565ac Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 14 May 2009 16:17:45 +0000 Subject: [PATCH 122/541] Consolidate coding standards into contribution git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@774838 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 1 - project/src/site/xdoc/code-standards.xml | 97 ------------------------ project/src/site/xdoc/contribute.xml | 67 ++++++++++++++++ 3 files changed, 67 insertions(+), 98 deletions(-) delete mode 100644 project/src/site/xdoc/code-standards.xml diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 34604c8a5c5..acd3c36f0ec 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -57,7 +57,6 @@ -

    diff --git a/project/src/site/xdoc/code-standards.xml b/project/src/site/xdoc/code-standards.xml deleted file mode 100644 index c1343f7258e..00000000000 --- a/project/src/site/xdoc/code-standards.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Coding Standards - Serge Knystautas - - - - -
    - -

    - Submissions to the James project must follow the coding conventions - outlined in this document. James developers - are asked to follow coding conventions already present in the code. - (For example, if the existing code has the bracket on - the same line as the if statement, then all subsequent code - should also follow that convention.) Anything not - explicitly mentioned in this document should adhere to the - official - Sun - Java Coding Conventions. -

    - -

    - Developers who commit code that does not follow - the coding conventions outlined in this document will be - responsible for fixing their own code. -

    - -

    -1. Spaces between parentheses are optional. The preference is to exclude -extra spaces. Both of these conventions are acceptable: -

    - -

    - -

    - -

    -2. Four spaces. NO tabs. Period. The James -mailing list receives cvs commit messages that are almost impossible -to read if tabs are used. -

    - -

    -In Emacs-speak, this translates to the following command: - -(setq-default tab-width 4 indent-tabs-mode nil) -

    - -

    -3. Use Unix linefeeds for all .java source code files. Only platform-specific -files (e.g. .bat files for Windows) should contain non-Unix linefeeds. -

    - -

    -4. Javadoc must exist on all methods. Contributing -a missing javadoc for any method, class, variable, etc., will be GREATLY -appreciated as this will help to improve the James project. -

    - -

    -5. The Jakarta Apache/James License MUST be placed -at the top of every file. -

    - -
    - - -     diff --git a/project/src/site/xdoc/contribute.xml b/project/src/site/xdoc/contribute.xml index b433172d7d0..8e223298db1 100644 --- a/project/src/site/xdoc/contribute.xml +++ b/project/src/site/xdoc/contribute.xml @@ -106,6 +106,73 @@ happy to receive good documentation.

    + +
    + +

    + Submissions to the James project must follow the coding conventions + outlined in this document. James developers + are asked to follow coding conventions already present in the code. + (For example, if the existing code has the bracket on + the same line as the if statement, then all subsequent code + should also follow that convention.) Anything not + explicitly mentioned in this document should adhere to the + official + Sun + Java Coding Conventions. +

    + +

    + Developers who commit code that does not follow + the coding conventions outlined in this document will be + responsible for fixing their own code. +

    + +

    + 1. Spaces between parentheses are optional. The preference is to exclude + extra spaces. Both of these conventions are acceptable: +

    + +

    + +

    + +

    + 2. Four spaces. NO tabs. Period. The James + mailing list receives commit messages that are almost impossible + to read if tabs are used. +

    + +

    + In Emacs-speak, this translates to the following command: + + (setq-default tab-width 4 indent-tabs-mode nil) +

    + +

    + 3. Use Unix linefeeds for all .java source code files. Only platform-specific + files (e.g. .bat files for Windows) should contain non-Unix linefeeds. +

    + +

    + 4. Javadoc must exist on all methods. Contributing + a missing javadoc for any method, class, variable, etc., will be GREATLY + appreciated as this will help to improve the James project. +

    + +

    + 5. The standard Apache boilerplace MUST be placed + at the top of every file. +

    + +
    From e4926a8cc303b39de554f39ce08dbaba33678161 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Fri, 15 May 2009 14:43:27 +0000 Subject: [PATCH 123/541] Fixed typos git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@775167 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/mail.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/project/src/site/xdoc/mail.xml b/project/src/site/xdoc/mail.xml index edcd81f4f4c..2b01cdd6889 100644 --- a/project/src/site/xdoc/mail.xml +++ b/project/src/site/xdoc/mail.xml @@ -135,12 +135,12 @@ list and send your messages to that mailing list only. Do not send your messages to multiple mailing lists. The reason is that people may be subscribed to one list and not to the other. Therefore, some people will only see part of the conversation.

    -

    First, find out the particular email adress to which ezmlm is sending. The email headers are visible in Microsoft Outlook via the messages menu "View | Options". + 

             Microsoft Mail Internet Headers Version 2.0
         ...
@@ -154,6 +154,7 @@ only see part of the conversation. 
    
         Return-Path: server-user-return-12345-john=host.domain@james.apache.org
         ...
    +

    The Return-Path header contains the email address which is subscribed.

    To stop subscription for the address john@host.domain , send an email to 

    server-dev-unsubscribe-john=host.domain@james.apache.org
    From 427d63c7b422b44e43dbed9ce2c577b0a7108ff8 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Sat, 23 May 2009 19:43:55 +0000 Subject: [PATCH 124/541] Add links to candidate git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@777997 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/site.xml | 1 + project/server/src/site/xdoc/index.xml | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/project/server/src/site/site.xml b/project/server/src/site/site.xml index 4876b0f7d85..97ce9154af2 100644 --- a/project/server/src/site/site.xml +++ b/project/server/src/site/site.xml @@ -45,6 +45,7 @@ + diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index 3cbef156a3f..ef4040cf67c 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -45,6 +45,12 @@ Any bugs found in James are dealt with promptly. Please provide +

    + A bug fix point release currently in preparation. See release notes + for details. +

    +

    The James 3.0 code base has many From 4e9524836cb4f7725d054b9fc5042cdb7fbdd73a Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 06:02:52 +0000 Subject: [PATCH 125/541] Inherit from latest version of Apache master pom git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785917 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/pom.xml b/pom.xml index 26c285f6cb2..1dbfcfffbbf 100644 --- a/pom.xml +++ b/pom.xml @@ -25,7 +25,13 @@ The Apache JAMES Parent POM - + + + org.apache + apache + 6 + + 2.0.6 From 0441539c6c564b681eea75e71e6dfd1839678d18 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 06:07:58 +0000 Subject: [PATCH 126/541] Update list of developers. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785918 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/pom.xml b/pom.xml index 1dbfcfffbbf..f7bafffbebb 100644 --- a/pom.xml +++ b/pom.xml @@ -195,6 +195,24 @@ + + mwiederkehr + Markus Wiederkehr + mwiederkehr at apache.org + + + PMC Member + + + + olegk + Oleg Kalnichevski + olegk at apache.org + + + PMC Member + + From d3812e7df26fbb0b3099473697983f5393afb93d Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 06:12:58 +0000 Subject: [PATCH 127/541] Order links alphabetically git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785919 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index acd3c36f0ec..fce5f850920 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -40,13 +40,13 @@ - - + - - + + +

    From 0b78b79648a92878bd86bf06725aad039863ea38 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 06:14:33 +0000 Subject: [PATCH 128/541] Add IMAP to the list of products git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785920 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index fce5f850920..32705ac2e25 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -40,6 +40,7 @@ + From 158a7a1d3fac683da2cbb6e8efda8119fb033d2f Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 06:23:52 +0000 Subject: [PATCH 129/541] Add Oleg and Markus to list of developers git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785921 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/weare.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/project/src/site/xdoc/weare.xml b/project/src/site/xdoc/weare.xml index d7a8abd97ea..9c6c46b27c0 100644 --- a/project/src/site/xdoc/weare.xml +++ b/project/src/site/xdoc/weare.xml @@ -64,6 +64,12 @@

    Robert Burrell Donkin (rdonkin at apache.org) [RBD]

    +

    + Markus Wiederkehr (mwiederkehr at apache.org) +

    +

    + Oleg Kalnichevski (olegk at apache.org) +

    From b22ecdf8c8d534fd3f4e8d15bbe68b2fba0f11e1 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 06:51:28 +0000 Subject: [PATCH 130/541] Altered emphasis on the front page to target two separate audiences: developers and mail administrators git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785927 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 36 ++++++++++++++++++++++++--------- 1 file changed, 26 insertions(+), 10 deletions(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index e8d81f209f1..ceb5073ee4f 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -49,7 +49,8 @@

    -The Apache JAMES Project delivers a rich set of open source solutions, written in Java, related to internet mail and news. +The Apache JAMES Project delivers a rich set of open source modules and libraries, written in Java, +related to internet mail and news which build into an advanced enterprise mail server.

    @@ -66,16 +67,27 @@ We recommend that

    -
    +
    +

    -The JAMES project contains many products, classified by subproject: + James Server is a stable, mature and production ready email server.

    +     + +

    + Developers looking for a modular mail platform on which to build should start by + looking at the modules and libraries used to compose James Server 3.x. +

    +
      +
    • JAMES Server 3
        -
      • JAMES Server is an advanced fully functioned -integrated mail server. It is a mailet container and delegates mail processing to mailets -(independent processing agents). Most of these mailets are -available through products in the mailets subproject. -The following protocols are supported: +
      • Is an advanced fully functioned integrated mail server
        • +
      • Is a mailet container, delegating to independent processing agents known as mailets
        • +
      • Is modular
        • +
      • Supports Spring and is moving towards OSGi
        • +
      • Retains the mature, production ready Apache Excalibur +components used by Avalon
        • +
      • Supports the following protocols:
        • SMTP
          • @@ -84,7 +96,10 @@ The following protocols are supported:
        • POP3
        • -IMAP (experimental)
          • +IMAP +(see the IMAP sub-project) +
        +
    • The Mailet subproject collects products @@ -112,6 +127,7 @@ for stress testing mail servers
    • MPT is a scripted functional test tool suitable for testing mail protocols.
    -
    + +
    From 71fcec9df374a9ad066801ae18f74cbe24339302 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 06:53:09 +0000 Subject: [PATCH 131/541] Update to latest skin git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785929 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 32705ac2e25..cc03b2ce785 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -34,7 +34,7 @@ org.apache.james maven-skin - 1.1 + 1.2 From e120903b5fe2e104202495d1ac0f48227265a07c Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 07:01:39 +0000 Subject: [PATCH 132/541] Use latest snapshot of parent git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785931 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/pom.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/server/pom.xml b/project/server/pom.xml index c99cddf9013..bf6fa767b3e 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -30,7 +30,7 @@ org.apache.james james-project - 1.3 + 1.4-SNAPSHOT 2.2.0 From dee1464c017597750c3d5f6ca2eb130698b577b5 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 07:02:52 +0000 Subject: [PATCH 133/541] Use latest snapshot of parent git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785933 13f79535-47bb-0310-9956-ffa450edef68 --- project/pom.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/pom.xml b/project/pom.xml index 0572cc42ab5..4436fa81493 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.2 + 1.3-SNAPSHOT From 85969122aee68b6ca78cbc170bd5a88b33c739c3 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 07:08:38 +0000 Subject: [PATCH 134/541] Inherit 'Apache Software Foundation' menu git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785934 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index cc03b2ce785..12765ee3cfe 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -66,7 +66,7 @@ - + From 93a072a94d84049c3b2104a371cfad56488f14e4 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 09:14:54 +0000 Subject: [PATCH 135/541] Rework server landing page git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@785975 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 143 ++++++++++++++++++++----- 1 file changed, 114 insertions(+), 29 deletions(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index ef4040cf67c..e94877e650c 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -20,49 +20,129 @@ Overview - James Project Web Team + James Project Team - +
    - -

    -James v2.3.1 is the current best release. Both binary and source distributions are available. -

    -James v2.3.1 is a bugfix release to the James platform, with importent bugfixes. -See the Change Log for a detailed list of bugfixes. All -users are urged to upgrade to v2.3.1 as soon as possible. -

    -Any bugs found in James are dealt with promptly. Please provide feedback. -

    - Get your hands on the latest versions.. -
    We put significant milestones, and potential release candidates in the download area. -
    Whilst the quality of these versions cannot be guaranteed they may contain important bug fixes and cool new features.
    -

    -     - +

    - A bug fix point release currently in preparation. See release notes - for details. + James 2 is a mature, production ready code stream with minimal development. + Use of the latest stable release is recommended.

    + +
      +
    • Is the latest official stable release
      • +
    • Is a bugfix release. + See the Change Log for details. +
      • +
    +     + +
      +
    • + Is a bug fix point release currently in preparation. See release notes + for details. +
      • +
    • + Release candidates are available. Note that these + are not official releases and are intended for evaluation by expert users only. +
    • + Feedback welcomed either through the mailing lists + or JIRA. +
      • +
    +     + +
      +
    • Is a + Proposed + minor revision upgrading to Java 1.5 and adding support for Java 1.6. +
    • + Some libraries developed for + James 3 may be added, + allowing access to their features. +
    • + Feedback welcomed either through the mailing lists + or JIRA. +
      • +
    +

    -The James 3.0 code base has many +The James 3 code base has many new features and major revisions to the architecture are ongoing.

    It is recommended only for advanced users who are willing to accept that development is ongoing and that they may need to participate actively. -Users are strongly recommended to subscribe to the server-dev mailing list. +Users are strongly recommended to subscribe to the server-dev +mailing list.

    + +
      +
    • Is a proposed milestone release allowing a preview of the James 3.0 features +
    • + Feedback welcomed either through the mailing lists + or JIRA. +
      • +
    +     - +
    +
    @@ -142,8 +222,13 @@ Users are strongly recommended to subscribe to the server-dev mailing list. + + + + + +
    Item2.2 2.2
    IMAPOkay3.03.0
    -
    From e4a5cecbf1083344d2f20a7e7aa80a28d2c6eb01 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 15:21:39 +0000 Subject: [PATCH 136/541] Announce Apache JSieve 0.3 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@786119 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 44 +++++++++++++-------------- project/src/site/xdoc/index.xml | 4 +++ project/src/site/xdoc/newsarchive.xml | 9 ++++++ 3 files changed, 35 insertions(+), 22 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 90d8672b07e..508e8dc72d6 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -260,43 +260,43 @@ href="http://www.apache.org/dist/james/jspf/source/apache-jspf-0.9.6-src.zip.asc
    -

    Apache JSieve 0.2 is the latest stable version:

    +

    Apache JSieve 0.3 is the latest stable version:

    diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index ceb5073ee4f..1c78486ad39 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -9,6 +9,10 @@
      +
    • Jun/2009 - +
    • May/2009 - diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 92cc5a7af13..b2901951519 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -12,6 +12,15 @@
    +

    Jun/2009 - Apache JSieve 0.3 released

     +

    The Apache JAMES Project is pleased to announce that the third release of + Apache JSieve - an implementation of the + Sieve mail filtering language - + is now available for download. This is the first + modular release and includes a filtering mailet. + See the release notes + for more details. +

    May/2009 - Apache Crypto Mailets 1.0 released

    The Apache JAMES Project is pleased to announce the first independent release of Apache Cryptographic Mailets (previous versions From af21086fc60c00b6cfc749d69c708fa94576bdc3 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 15:23:48 +0000 Subject: [PATCH 137/541] Update to latest pom git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@786120 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/2.2.0/pom.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 41e544eada3..9fab48c7d88 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.2 + 1.3-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 From 41ac50af6ae0795e33b5651b2dbde0fb50d10b69 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 15:48:30 +0000 Subject: [PATCH 138/541] Move around some menu items, change some menu naming and inherit top level information about the project. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@786133 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 12765ee3cfe..4bdc06f982e 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -50,22 +50,23 @@ -

    - + + + + + + + + + - - - - - - From 06b51ca3ff438b60ac0a2c1f080743bfc2f9f2ec Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 16:01:21 +0000 Subject: [PATCH 139/541] Consolidate menus to improve 2.2.0 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@786140 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/site.xml | 11 +++-------- project/server/src/site/xdoc/index.xml | 3 +++ 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/project/server/src/site/site.xml b/project/server/src/site/site.xml index 97ce9154af2..971f5a2a1a5 100644 --- a/project/server/src/site/site.xml +++ b/project/server/src/site/site.xml @@ -39,11 +39,12 @@ - + + - + @@ -52,11 +53,5 @@ - - - - - - diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index e94877e650c..1e1c88beb7d 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -230,5 +230,8 @@ Users are strongly recommended to subscribe to the server-dev
    +
    +

    See here

    +
    From 39784379737f1a02b4b3483dc05d0f040a8618fc Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 18 Jun 2009 16:30:08 +0000 Subject: [PATCH 140/541] Uncomment out description git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@786152 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index 1e1c88beb7d..848cd3c8e20 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -22,10 +22,11 @@ Overview James Project Team - +

    From a399b2acb3cddce6fdf76d2db527bfa1eae2ccbc Mon Sep 17 00:00:00 2001 From: rdonkin Date: Fri, 19 Jun 2009 10:40:20 +0000 Subject: [PATCH 141/541] James now uses Hudson for continuous integration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@786444 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/pom.xml b/pom.xml index f7bafffbebb..083214774c8 100644 --- a/pom.xml +++ b/pom.xml @@ -53,6 +53,11 @@ http://www.apache.org + + hudson + http://hudson.zones.apache.org/hudson/view/James/ + + From 04c5e9b0fb1565a23e54f8565e3a64c706f7d3e9 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Fri, 19 Jun 2009 11:19:25 +0000 Subject: [PATCH 142/541] Add extensive list of mailing lists to project parent git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@786458 13f79535-47bb-0310-9956-ffa450edef68 --- project/pom.xml | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/project/pom.xml b/project/pom.xml index 4436fa81493..a9bbc8cbda8 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -59,7 +59,35 @@ - Apache James Website Developement + Server Development (including components) + server-dev-subscribe@james.apache.org + server-dev-unsubscribe@james.apache.org + server-dev@james.apache.org + http://mail-archives.apache.org/mod_mbox/james-server-dev/ + + + Server User + server-user-subscribe@james.apache.org + server-user-unsubscribe@james.apache.org + server-user@james.apache.org + http://mail-archives.apache.org/mod_mbox/james-server-user/ + + + Mime4J + mime4j-dev-subscribe@james.apache.org + mime4j-dev-unsubscribe@james.apache.org + mime4j-dev@james.apache.org + http://mail-archives.apache.org/mod_mbox/james-mime4j-dev/ + + + General + general-subscribe@james.apache.org + general-unsubscribe@james.apache.org + general@james.apache.org + http://mail-archives.apache.org/mod_mbox/james-general/ + + + Website Development site-dev-subscribe@james.apache.org site-dev-unsubscribe@james.apache.org site-dev@james.apache.org From fa9ee08cd01fd5f466f9bdb6d1002acc9a1ac056 Mon Sep 17 00:00:00 2001 From: norman Date: Thu, 25 Jun 2009 12:12:05 +0000 Subject: [PATCH 143/541] add jspf 0.9.7 release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@788338 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 24 +++++++++++++----------- project/src/site/xdoc/index.xml | 1 + project/src/site/xdoc/newsarchive.xml | 4 ++++ 3 files changed, 18 insertions(+), 11 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 508e8dc72d6..f9cc9d54564 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -231,28 +231,30 @@ href="[preferred]/james/mime4j/">Other Files (javadoc.jar, sha1 checksums...

    -

    Apache James jSPF 0.9.6 is the latest jSPF stable version:

    +

    Apache James jSPF 0.9.7 is the latest jSPF stable version:

    • Binary (JAR): apache-jspf-0.9.6.jar [PGP]
      • +href="[preferred]/james/jspf/binaries/apache-jspf-resolver-0.9.7.jar">apache-jspf-resolver-0.9.7.jar [PGP]apache-jspf-tester-0.9.7.jar [PGP]
    • Binary (ZIP Format): apache-jspf-0.9.6-bin.zip [PGP]
      • +href="[preferred]/james/jspf/binaries/apache-jspf-0.9.7-bin.zip">apache-jspf-0.9.7-bin.zip [PGP]
    • Binary (Unix TAR.GZ): apache-jspf-0.9.6-bin.tar.gz [PGP]
      • +href="[preferred]/james/jspf/binaries/apache-jspf-0.9.7-bin.tar.gz">apache-jspf-0.9.7-bin.tar.gz [PGP]
    • Source (Unix TAR.GZ): apache-jspf-0.9.6-src.tar.gz [PGP]
      • +href="[preferred]/james/jspf/source/apache-jspf-0.9.7-src.tar.gz">apache-jspf-0.9.7-src.tar.gz [PGP]
    • Source (ZIP Format): apache-jspf-0.9.6-src.zip [PGP]
      • +href="[preferred]/james/jspf/source/apache-jspf-0.9.7-src.zip">apache-jspf-0.9.7-src.zip [PGP]
    • Other Binaries
      • diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 1c78486ad39..780938787eb 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -10,6 +10,7 @@
      • Jun/2009 -
        • diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index b2901951519..13ede9655e3 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -12,6 +12,10 @@ +

        Jun/2009 - Apache jSPF 0.9.7 released

         +

        The Apache JAMES Project is pleased to announce a new + Apache jSPF release which included some critical bug fixes. +

        Jun/2009 - Apache JSieve 0.3 released

        The Apache JAMES Project is pleased to announce that the third release of Apache JSieve - an implementation of the From a8ba32565263f7c4000ddc1e39a2f0d9a767e317 Mon Sep 17 00:00:00 2001 From: norman Date: Thu, 25 Jun 2009 12:16:16 +0000 Subject: [PATCH 144/541] ups... copy and paste error git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@788340 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/newsarchive.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 13ede9655e3..4832cc2923e 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -14,7 +14,7 @@

        Jun/2009 - Apache jSPF 0.9.7 released

        The Apache JAMES Project is pleased to announce a new - Apache jSPF release which included some critical bug fixes. + Apache jSPF release which included some critical bug fixes.

        Jun/2009 - Apache JSieve 0.3 released

        The Apache JAMES Project is pleased to announce that the third release of From 0b4df416cebfc6329d2da9798025590f36862a91 Mon Sep 17 00:00:00 2001 From: norman Date: Thu, 25 Jun 2009 12:42:53 +0000 Subject: [PATCH 145/541] Fix layout git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@788343 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index f9cc9d54564..a90a4c630b2 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -234,9 +234,11 @@ href="[preferred]/james/mime4j/">Other Files (javadoc.jar, sha1 checksums...

        Apache James jSPF 0.9.7 is the latest jSPF stable version:

          -
        • Binary (JAR): Binary Resolver (JAR): apache-jspf-resolver-0.9.7.jar [PGP]PGP]
          • + +
        • Binary Tester (JAR): apache-jspf-tester-0.9.7.jar [PGP]
          • From 5a986e0594fdd3d58930d67260bec6726361bfde Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 2 Jul 2009 12:34:51 +0000 Subject: [PATCH 146/541] Prepare for MPT 1.0 release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@790564 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 37 +++++++++++++++++++++++++++ project/src/site/xdoc/index.xml | 4 +++ project/src/site/xdoc/newsarchive.xml | 8 ++++++ 3 files changed, 49 insertions(+) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index a90a4c630b2..578e8b76ee7 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -45,6 +45,7 @@ site.

        • Apache Mailet Base
        • Apache Crypto Mailets
        • The MailetDoc Plugin for Maven is available from the standard repositories
          • +
        • Apache MPT
        @@ -412,7 +413,43 @@ href="http://www.apache.org/dist/james/apache-crypto-mailets/1.0/apache-crypto-m href="http://www.apache.org/dist/james/apache-crypto-mailets/1.0/apache-crypto-mailets-1.0.jar.md5">MD5]
      +
    + +
    +

    Apache MPT 1.0 is the latest stable version:

    +
    diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 780938787eb..24df062af7b 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -9,6 +9,10 @@
    +

    Jul/2009 - Apache MPT 1.0 released

     +

    The Apache JAMES project is pleased to announced the first release of + Apache MPT - a functional testing + library particularly suitable for line protocols based on ASCII. These + protocols are common in mail but the library may be useful more widely. + See the release notes + for more details. +

    Jun/2009 - Apache jSPF 0.9.7 released

    The Apache JAMES Project is pleased to announce a new Apache jSPF release which included some critical bug fixes. From a9b82914402a1403ed5c04c0871505feb352e678 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Mon, 6 Jul 2009 11:35:16 +0000 Subject: [PATCH 147/541] Correct MPT release number git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@791444 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 38 +++++++++++++-------------- project/src/site/xdoc/index.xml | 2 +- project/src/site/xdoc/newsarchive.xml | 9 ++++--- 3 files changed, 25 insertions(+), 24 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 578e8b76ee7..d06f9390f1c 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -416,38 +416,38 @@ href="http://www.apache.org/dist/james/apache-crypto-mailets/1.0/apache-crypto-m

    -

    Apache MPT 1.0 is the latest stable version:

    +

    Apache MPT 0.1 is the latest stable version:

    diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 24df062af7b..769e58dba5d 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -10,7 +10,7 @@
    • Jul/2009 -
    • Jun/2009 -
        diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index b847c725011..26b42e9ce97 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -12,12 +12,13 @@ -

        Jul/2009 - Apache MPT 1.0 released

         -

        The Apache JAMES project is pleased to announced the first release of +

        Jul/2009 - Apache MPT 0.1 released

        +

        The Apache JAMES project is pleased to announced that the first release of Apache MPT - a functional testing - library particularly suitable for line protocols based on ASCII. These + library particularly suitable for line protocols based on ASCII - is now + available. These protocols are common in mail but the library may be useful more widely. - See the release notes + See the release notes for more details.

        Jun/2009 - Apache jSPF 0.9.7 released

         From 4d356d9751e8e1c3d32d419b4cde6c1b35d34715 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 7 Jul 2009 08:21:29 +0000 Subject: [PATCH 148/541] Fixed download url typos git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@791747 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/newsarchive.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 26b42e9ce97..9084988b9d5 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -16,7 +16,7 @@

        The Apache JAMES project is pleased to announced that the first release of Apache MPT - a functional testing library particularly suitable for line protocols based on ASCII - is now - available. These + available. These protocols are common in mail but the library may be useful more widely. See the release notes for more details. @@ -29,7 +29,7 @@

        The Apache JAMES Project is pleased to announce that the third release of Apache JSieve - an implementation of the Sieve mail filtering language - - is now available for download. This is the first + is now available for download. This is the first modular release and includes a filtering mailet. See the release notes for more details. From ce88aff00a3603797f4f880c046421c3d5b831bb Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 7 Jul 2009 08:45:33 +0000 Subject: [PATCH 149/541] Source and jars not available since MPT is modular git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@791751 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index d06f9390f1c..89872b1f861 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -439,17 +439,8 @@ href="[preferred]/james/apache-james-mpt/apache-james-mpt/0.1/apache-james-mpt-0 href="http://www.apache.org/dist/james/apache-james-mpt/apache-james-mpt/0.1/apache-james-mpt-0.1-src.zip.asc">PGP][MD5] -

      • Source (Jar Format): apache-james-mpt-0.1-sources.jar [PGP][MD5]
        • - -
      • JAR library only: apache-james-mpt-0.1.jar [PGP][MD5]
        • - -
      +
    • Jars (including source and javadocs) for the modules are distributed through the standard +Maven repositories.
    From 2db09f8f03d9b5c93592da6801249b1c79077331 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 7 Jul 2009 08:47:52 +0000 Subject: [PATCH 150/541] Correct typo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@791752 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 89872b1f861..64c17c84a1b 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -420,7 +420,7 @@ href="http://www.apache.org/dist/james/apache-crypto-mailets/1.0/apache-crypto-m
    • Binary (Unix TAR): apache-james-mpt-0.1.tar.gz [apache-james-mpt-0.1.tar.gz [PGP][MD5]
      • From 0a48fea38485dcb918e0f227157d3cc9171b628f Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 23 Jul 2009 13:13:47 +0000 Subject: [PATCH 151/541] Remove local staging repositories git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@797057 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 93 ------------------------------ project/src/site/xdoc/download.xml | 1 + 2 files changed, 1 insertion(+), 93 deletions(-) diff --git a/pom.xml b/pom.xml index 083214774c8..c85207f8f9a 100644 --- a/pom.xml +++ b/pom.xml @@ -263,100 +263,7 @@ - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - true - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - true - - - - - - - parent - - - local-james-parent-stage - Apache JAMES parent stage repository folder - file://${basedir}/stage - legacy - - true - ignore - - - true - ignore - - - - - - - local - - - central - http://repo1.maven.org/maven2 - - false - - - false - - - - apache.releases - Apache Main M2 Repository - http://people.apache.org/repo/m2-ibiblio-rsync-repository - - false - - - false - - - - apache.snapshots - Apache Snapshot Repository - http://people.apache.org/repo/m2-snapshot-repository - - false - - - false - - - - release diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 64c17c84a1b..90c7880be49 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -441,6 +441,7 @@ href="http://www.apache.org/dist/james/apache-james-mpt/apache-james-mpt/0.1/apa
    • Jars (including source and javadocs) for the modules are distributed through the standard Maven repositories.
      • +
    From e744436d84ce3f27bd6ff3ec8f188cb58e1ea162 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 23 Jul 2009 13:25:42 +0000 Subject: [PATCH 152/541] All James documents should be UTF-8 encoded git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@797063 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/pom.xml b/pom.xml index c85207f8f9a..16742096248 100644 --- a/pom.xml +++ b/pom.xml @@ -31,6 +31,10 @@ apache 6 + + + UTF-8 + 2.0.6 From 518956c4ad4b3136d2ac9e479705dc61cef61327 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 23 Jul 2009 13:28:43 +0000 Subject: [PATCH 153/541] Inherit latest parent git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@797064 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index fcd93f43c81..f6e5b3500f3 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -27,7 +27,7 @@ org.apache.james james-parent - 1.2 + 1.3-SNAPSHOT From ba58cf89e1bbfed4733df08da2533dccbc70fd9c Mon Sep 17 00:00:00 2001 From: rdonkin Date: Thu, 23 Jul 2009 13:34:53 +0000 Subject: [PATCH 154/541] Remove stage directories git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@797068 13f79535-47bb-0310-9956-ffa450edef68 --- .../jars/apache-jar-resource-bundle-1.2.jar | Bin 10867 -> 0 bytes .../jars/maven-default-skin-1.0.jar | Bin 8168 -> 0 bytes .../poms/maven-default-skin-1.0.pom | 324 ------------------ 3 files changed, 324 deletions(-) delete mode 100644 maven-skin/stage/org.apache/jars/apache-jar-resource-bundle-1.2.jar delete mode 100644 stage/org.apache.maven.skins/jars/maven-default-skin-1.0.jar delete mode 100644 stage/org.apache.maven.skins/poms/maven-default-skin-1.0.pom diff --git a/maven-skin/stage/org.apache/jars/apache-jar-resource-bundle-1.2.jar b/maven-skin/stage/org.apache/jars/apache-jar-resource-bundle-1.2.jar deleted file mode 100644 index 2d2c1b4aad0c3bfa065a7e0a8ed5d65f105f4051..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 10867 zcmeHNby!r}*B(G>q#K6r9=fFjB!_NLkZu?n5kXRsk}gFF>5v>61S#nd1Ox_#MnI&b zKDhT9pZEUmAK&l!{&UZBVxF_tyVgEypLL#hpI1W#eg#I}BYlnGxRFl_{ z;ZlMqfHnT=h5<;s?8axQWo&(U+5d7Q`nj8$3`9vmUR#G-O<_;%U7xB77xyr>3K#pp zyTM8=o-zJ;1e8;Gpqo>LOBMrtDMv4Xgrk+w2bK}3MW~{s?UBh|LPU9;Af8`~*q^XZ zYwz-kGQYcWE1YdAR}>X5h{&`o!7+9%&kt=kEUeL_(FE`caF#Rau;ckzT;Sh;iiI5}2Uly&!Ovi>z7UA{4X z4K2lfl>zmhcPh2IKy0_sYK_;mm2ArW{a__*Wv&4*mokLQi@jf^N2z*IOG7#t>5+NF zhvWJ%k#)bXu(gxpa38UT^+d#n)oix5vO)CxJ}_Cbf(LIF2Tw>A1nv9q{=DsBzC?!+ zNB}_jH2{F%=ZGQdI!ZU?xxJi9w1<`7@DSY})Hhk9*2|BIP`?-dg0`E8v$<>8E7C(r zNoynFtU)Qcde)VAthq|`aA_vqU0ZqKbP)Fi5ee?p>?s;hlYU9rK_Ky|NjH-Ls#mBP zPpzy{9Xt!zO$jxvm}&YXA3b6Q*L|i5Qm1gNSkiF#!ahqeha zTvGfbG?wQ`O1Z%`_{xyR9VyDEr!{9Lx*)D3j_anPgbt*5@y4&Fl=76psYEpIR>puG zuJscKpyi_+;51K^Ymt4AF}zf&$Nw=T;yui>VA-mFIB;rDwAs9XeW{i6xNT^SAY)Q* zgAZa{X*t8Gsz0H}ubiHzWT>*IJhpw%g)y+hD;KdX#C!{|R$xO|Aluo&2t7p4WK?ZX zJUjdF02I-p{%FD)Pj_T6o2re6;{im(q{dpp&hkmAo9tK2M#r~x3`V6i9TxnPshH7} zac(fz04X!`zmp>M#k>bZ;1mA%O;_D+IDDpnF4m8l}8mzVI?>1 znvTr?BL|gWJJi_qPC3UV{emR z(Dm)I?Es_5&UNL+CPP!M?PTGiY9DWR7RlnW>u%on?|HlLFK`8z4r%N6?Vrtl4#z#h z#yqm;F4ZX!zYz#^K5uv6-(yL`tc_P=Fk%wtZB;_IGG?*Ve>CDjTt-k`ao3{|Pj7!h z$Kuf)(%VFm#&*I6P2{`x=rZ$NRdgTq%M|PO$TlM%Pdu5$P-J7~nAi@5 z%q)7<-%_eBZA)u<&GfkW=wN>vY$uMgZ2ksaW^o>^T@C%w}j(URU!Gx+TS-h%XLmBo`sZRe2+>0!oI&l*J9N$$N-mLtgR++jaP_R_|k>qqJl)L+*i?r_eNH-n}@1m`fUqYa;*Ux_v>*0o4_&_ z^nu~)kgu()TN*ek&PD88ovy2U77qjtMlo487gR=4Trn89asxlL^WH@+UpuWZGDM1% zP@L^nBm6A&CKq{_2&FthGQqMVG|<@$%}1miWDKO9u+$U9GBECzl`#gxk#Vx9t)|}$ zl;dSlwP%pR<0G5(%l8-kdw}}A>*(e1U;}= zwob7t?vsEB>bLAOk7q(*<#TJ$HIs@-@nv;JM8U_1Y37^oydLjK73ANzfU ze9a9I3BihV8!D6U1QLkKRb4#M8#2D062+iE#^b+$J1UMF_j%HqwiO%8DD552IjJ2E;ssaW)P(G$td5okv*E*pV=p^h6 z5SQ?|_EBb7J}ur)lGv7^eV5P(zfl$OY05s1kXX*@1NGwl?A8>)6u8~z&sO8N-@#L@ zZql-AMy{N{gt1 zV-Dq9MGT349gS32noY(??=?L!6kRxf0)dAk=&fTQt6Ug&j_D<(Cuz+Q=YUWE^O2>> z$yhs8fm~;x9y$oSuB4rj(e9WKp8|n`F0+s|!y;6MjFf)pScqK*7!V;qo#xqv?OUgutvNjCqi%IC&l!o{xSR=-UW z5Q}?kzpIa-G3s*xyase_`q<|>?sFFlVK1g1631HHc)N=^!X&cYgq%zH!_Xvmq!}5Pi_Y zXwXZQ;XOnCZ6s54bMfP>2n1?qevFW3lmzbMKzl&I@dG5yCsdQX_~;Uv2gR{w%o$i} zt&+fo-e#BbSph1M%;G1L2we_PLEFbuM=z0bdd!{@kXvQ&rYFQmZOYJC`uWf>E0z77 zXGf%;2tJsNvfaT)IuDGK(^Kz@CJjMx3*RW>${%EODa@F=8&ir=?aZAd_*Lpa7AF>H zAtq)uWUMFS%yh0wy8=3l)G4R0t$7Pew&ameuv1u4KP8s{%QGB0kD*XkYZ`MSn^k1_ z!>`@SKcZ~aR5R<$bg7Qd;1gZJizYrDCeTLZRqf1+BV*OJRk)uQqQHPi0s98&x_Pz| z$!~`m#Bt-*0GqMeNK3Adl&cq$0h?1J#S_)Tma9BDa51N%H8ET@(4G0)vTY2gVb|;! z9EFg(H7V(`gD!+C=+&pKxfj%F4daaH_!NO9dTa+!CyLcab|jwGrRo3%8TeuyoU!e z-efE@H|iblh18Lauo4;{a*^Mx$XFY&s;SgPVKl(^ai3_{_6AT;(Qr?TIHw@LY{gO; zuh7%-7pL;9dZfgw0QmjoC4Qf zC5X!YnC&>zL%lC8E~i7|mE-+qpSSk0o^HF*-m~~{d?OZWbFws*DASs%Dq6vL%t1(O zq>d?>K)j#AwmN25Nzba3v1ff(A|Ib`M`jhHGkH>w(EVe(&6aW-8XpA{RgLy>!bh;u z6tDwB=sw|Cf=rj?hUE(-9hi;hktF(_QY^yv29-3XDN9D%QFDYruXNFcRAO_n?joz34t}uD7ThuUIqZWK)Sj0 z_Kqk{nR2QCl1~>8#bbD*uqeaG%)%;r^iWhhLDnZsdxxCTL7O9g3l%B|h;r=T9(Jh$sw*@Ptg-L0|@?S=0C`{2&SW@L*<}q{cs3A}ai3klDjz_{zZAvaX5X9!~#Sjv9NNTTo zr(H12(ao8J92?S?{Of(B@yyQt~4~cusB@a!t_K`h1U$nVJrb$ID_C0b3yOpBGN*Nb-LT?aC zaZdDk@_gz-oW%&!eCq7#oSnVv+0uABGQHu{=zKZTpg4f!!JX35z)!Z#NC6#d`6?{K zAso6w%xdIv?poxo>i{+G)W;O`_ka~jjlSTb;m^*Pj_zs=R2gwh-|zv^}B zAHd@W=|#t}de}#y20D2Jfa%ph#WNQc*LReq{X|>$f!h<6(>98%v^D;Tf!D%p>V4=| zLeWCrrh-?_MoGReqOUJLb;R$%6Z4r;(YYAr~>>1PjHVI%a=zW&e@ETED=li$XKpf~n!EO=P z&V2AztUAo=i>U=npH7_bV|N2wLUy3Rq=V!;vnHI%#hA9CfsJ*0^u+6&Y?7a1>(xj1 zk6!OgZPc{N_GR))pyn#AEWOUOE^VE*m-j)|xJA)hs^cH=tSgK942Q_OaBFA$sQ{iu zrI3ubxlq(|S$r4Y(DLAS$z?|K5-H&3mJuWwi{RbtDGQd45=#NHDSpC?fm<$B9%^17 z0@2zQk{5KP7ZgDPZLDi5sw}fF8RgXDUvgrds*>GfHszPJXm@XpcUreiR~{cK-2s}t z9ZwyGRdLa2(!L*l%$9k}Vbm%0IVB47P5tP8c3jQKQP}SCe2;?I5E56cBSp`tWaQf? zLJFoLfo1yo2Ks|dXt!Fx&Mpga2&uWO>vl$f2)~^&@KV{Q1(%#&$&XBJb7!R7tfvk{ zqjs`c<7ltn%7P?A3KZhRj*W`)pvb^$jN-xPXfABTa?6{^cWm&FZ21<7X6ddGz9`)O z`WoWL&0VT`7=F|&os=zew9Sp`xiOX}mPLw(DZQIb-7MbS>*XaJ34`MVuEgxpC#3o5 z0bG$ugmA$5M|M&y*sPF2=!|p%odu#M($<>hv0I(dZ2p&C;A||K8YOo|5LBQ}0qdE0 zNyxYa=tTEa)-U+kt=i(2kwrT5qi%v>zku|qU2Md z(n&Wl4hNf{U#aU(?C+lu=;SfoX&-tHr#{c*CyI|6gUq?Ms|240y&^lhP;5cjWv(nq zOv}f6m|=_Efkjy|9gXKIjhV&i(dBY*Y^Ma@`1HkOkMsiRKeO}ywV3sdoqPCr{HEu> z>G^MZ{+pivrsu!u`EPpuo1Xus=fCOsZ+iZlp8uxjzv=mJdj9`P&kMuFMJF#mntLMu z^6~sH(ZeM>ua1*(c*BDgx_wT(T_+0)=M$PN;o|amLR??oP?6Yy$7#WF{p8RSE!4E8 zZ^AoPTB73>OG(Ao%7h7@8-iW4)Fm_+N!l+dMMY@DFmC$EGIKmb`9xJGug#op>u3l5 zsMTH7;UsvoS-Y42O?_eV&I{LLEC;?92oHqs#|*c;cNVWhw#ZCitIPryc#U6E4Yx!B znCJE%dYVcVEBl^OpMYxlQsqQkchirBl?B~tc`HCA34xnDV!hq^McKF%B2Ra_pFLUJpDA;Jio6~{9T(v@w1BHPjQP2)P~#K)!f3?>buV6?{T#<%Z!a z?6P>PBo^sn)dH9iOAPMZXjzX{MQo;ES&qcDv{|u&rfoghs!2kd$rpue{51sLwZd?T zzFWzPr3a9U>~Qn$FmRlB-(IdyJ?xwuXsjwI9#hP!BiaPjY!m|C$J)2!KZ=Nu{qVeH z3G7?rZKcHtuyjzi4^U$u9hQE~;1nWO)e&%t71Nt$dYH}maK#banJ$EH+w}3}XPK11 zv8VjvMXYB{i?8WeI+6H^`yIdoIjguvkrz#KyZ7bqt>3rjA~$9iiVH95zcDi?;h%nt z!HGl9Ss9NfmXQrQyim1`bS=Bi7F`|3-osXuE!1CSE?s0lONdpiC&>DS`px||?PA%+_0gzK6r2R!w_sp zi$lfH^&jhCSK6;;a{FYL%Vc_AZa4p%q`E>~T&lkP{P~WxQlNXSGe|5?p; zIjGBq2iTIiI(`?2{V@Ayb=y_vtCkbQa=HI*_LJ7_2f{z=(Ec$0!*R>c2;Wp`-=hB0 z{ja*TKaH>4Z~oo*pHyl;qWNdp*bl&Gm(TF`@q8DN{c8WKeCdb19?DPl-`8&>4G5vuv_OCeqT3Wxk_~+vK&B^8TWBj*J|HZ{$rS`{7!T3Y%`Rfz^!_z6# bf8puJ^RJ?Ad$2XFvP791`*!gsXvPozMN(ho86G@TY==su-(` zq9ptCpJM0;xNxyiug23B_`h9mAs`U`Q%pfjQASciMU_oKGA*+EPAdnY#G(J0xbMAO zHkU7YX-~xP9@^3KR&$T%(fha_c?wy~t4i|TLdySAGLYsLnL%~kKVo8-W4px740-Ojzm(jF00 z5w9e{_IOdVqBDR-3ZEjBPMN*Sqk zp#5Uasw`!|cK~>wlkLrdoUs_9vmA|TRj25KJ1}YHWeIMg9oBm@%?^bt(JyX!A~2G& ziBgEs%c__?#*lngC)pS3j^5>^GHIOLrnwsPo#K|c4B$gWKU1J3R>fX-OVKVrhwXa; zZIox0C`3~Cg1sJmON^gD2KCc^7{G45gO<7n*%IYljumixN&ikP3&+sQ=B+7t1+~-uTrVIRdW%~@4f#fq;T{@#%jK>H@e^TBU5fdE8canxwB15J6chFq+dTJmUx&XVe!(* z{J_$psFpQr)`&VyUfGq>YT3mr*@Tj!V?v12NlANCMNM1o5h0@e52usat+^L4MRf_g zCtr}5_s8Dd6~uvsTTG zrlG56>2jKeF{S+BlTEKT1=ne19#+R9gi4&^)epDCpD0slX1s3Y)%+B>1 zF$J|vQj&oR^@H21hAem4aes3zkJ=M(v9qiN;_r0yw=p7=XL}bB5fFCZxrFT67?vjX zb_QlnPWDa)&bBseKudGyLznW8@{7P(;1L7?@$&L=Yl(R3Gh=O(k_%79im`swQ^oIh z*e*EPE_5AN?~Y=}Of?M2_v!1`QVu|zBMpp&GRAeOq6CCn%RPfqYLGbvJhH!e9>C<* zmlDQr$1Wvk_A^$6X}F-i-FBgxvlMQP@eHb~2^OqDS*t;|0waeC9AgL^-{C*r;XkGs z2e*xTz8J58!b1C&h-{aLZJ@+9i^MDo_+4|0lZ;Gyova?x&wSG&`|dx=4VM)Jv23LD z6&Ljvp8$r^?Y4&XbGl?10qIbWz z2^K870cOr~{Fg0hXNEg27{ksYCXxNXj)xVNgJk8iT+nxi$$6<|p~ALAo}&!VFxNe; z$(r(mH^95m5TRUO-^&*9mO-8F&*ERk62i6; zo7O;MH*#vbDmgZ(a@F}%mapGRfRtqPY@zKn2@chZ)9tyfnWiSc%ZvTBu>^L5mySIg zcR~@@m6<_VQjMBNx*lXD z<9$ppGTe<1+>|JVxCl~{2#+@#V%-Q0X6!~cHF#*~!!Obspm(rKTT0;+W?9SR*VQ?X&PpI3sC zQ<28gY-`hCXOA~P-83ClGpmKduy~%;{-Sd2F=$0;?}nzqVC8+9{JI=>6|Kwo*dDSa zf~pbuZ~A<$Ql48AuU3WR>eQh;5bLDMI!|cH=r`}elTnxc8H4ZO9PgHk@4;vcECM5f zKEr)Hoxoy|QEtnn9ErM#yb}GI)xA%)%j%o;AKeCWdFt392F`{H7t9m~df&ZPCL*%= z4pM7exBI5smN)MTdbPih3cAf*tTMla=zBXse=PJ?XBgD(uYW#HVW07ZZ+T;E ztEutD>GAOz&g)3T&cW86#;=t=y?G_Vg7$6QOF9vo!fp%A-9pWV{piNufyYx^X0et^_NFWr`6O=zL&=s zpD!=Ykx(BXIX;0gV$dRq;{{@eAcYd39!z6NDD<;_P`GWmdRySpgJNBg&3?z=VEJQ| zK2LwJjF#7iygZkW*?A1-*$@d~`yy94a-yRYFz@g^Z|=uFh$~Nb#9O)jDC>DlblE<` zg$Q}*wnMaqv1nQxafj`~(!62kXo2b|oyNTYv>! zT9~eNG@kBrd+Q&rXz-}_T^8I8zr(XM#SK?4&?=sDLLbu1iaG_q!V%=3lDn+Yi@8C3giLfe=R)3MoXqQ4H=YuBjDs)>JV zRoB*&`!cSpE@ja6O?>)`LO(=CaYkBQPHMPcMOWrgCX+WLofU+=-jzHt`pI0eJ9Se+ ziVsYG%2&F<=Uy%1wefk105qnn13o{9zkA3>Ca`MjRpYXoZ8k|=`WgU?`~&ZvGG zl~B9gTwMGzHMQHiV#1 zVhNz)n}}by?GIs4g(tC0d4Kjv7)>2!V9H*-EH@G}mXOlx>dkN#J^aLpjrgfKK_B4$ zdPDfv7%pf@n#1M^%ss=PGS!KFa`SoZR}t?5wGQFkAejz*3G)5ddJ7EXXrn90W2?2M z??*Qs9s5<+L`Z5@SF)^eAn8rM^RP9cbg-2_(ZmIPa^o?1>37lnZslEh4Ob=g#2@r2Y_6vXE zXLifz@~q6Lq;M5=#@S9(EEH7h8(9_$0r3?t+_j&;ubZyzZscTVX$Sn%wSOksnMc6m zlHj5keEeRJ72_dmQkmgcE79qgjiCBi^*ghnyy9dO&=|E6^QIL%2#yb&C*SIdI$d04 zFJgNE=Ve%mg~4lI`zUko60~nm*Pb2`pTZO!mtg>-Q!TcWGR;MwsIDT!sL7r|g)OHnwF|Yx<^!MXq{{VS`1G_@iZVwQJb0H_hlXSy8W}pv)pLZhgQC%%^5mlx=zlEYur_ zJ<}?66qMTlmd_2CXB*f;fljV^VX6a!iD&S0{MTjA?2aY*g0|8JQBCG_B5UCSDikga zv|d_Td!=A-y1FDVg}|4c<+LH^;&2C=LIASe=jP6B_bvS~8Xq?p9e32=HouGV!7G$A zA)jwz<$Z(hkac06MQ(0wK?6WeGOMU~c0XA_n=@L_X{h!SfO#Ut{HxmC3{f1?ddwRC zc_m^=)K{FScX81O88O$LDSDEVb+jk>llUjJQFaMbBx+NVRE)DhjBzk?P6*cA4`SBv zlwML?wy6#(g36Jxm{K*S$22Ylb=jaN7&;EmX93=x1o7rk9Dbr(xyjKzkTV5OeJZ;W z)GB=F4|8o}vnfSvr=3E%O4b~g&z??%gbHyi2|dzlTC1nAOa<>PSIBkF6YnKXL1;;i zB^RYsv`b?hcLHe%;u2u8ntYrbnn*X?4U_#l-XJ`KUKIdWjKj~vznz)8yQQ6}z5D;) z(?7)2@CXMLi{uH)%0lNIwY8ild2xLQN@o`<CESASjcCeXIfrI zW#sh5M^=vD&pTn{#!WB{#Xq*g2U_@BDox=(%o>cMXeR?oV6%1rePXjsBTgqW?Xh}% zvu%+=GbD_TRlwNRGs+zd{O2}8ew#QaflM}C>Fdx+46}gz_tLqqMkEQ9W9N>ZuA-EN z>2r*D)h@gVoRgM-W+fU%IYi5SJqVvYU_KAXhw1j5(P1iV6W@M$hbLl?r1TSD^jQd^ z!M#v({-R}tDU3JeN3R?RgR6|ZDD4ZYalkK^-{Ve9Czj_n&$Ta2PKd3*aOq9sdV`c@ zER;=)&dFnO!i?t(9}7@X;ymq~Ld|3dY?;E%9Iv=5^WgdYM}qX_0ol>xg=h*4lo)sv z+0U3mhIz*#5!Fknxc0E`$P79dR0kUs_bWcL2-pw0e1rEk0}D0sNFhnl^BF)hfjT6T z7hOZuq*P@$44~f3-xGx%tDcr=4hSuit$Gv@rM96)gM(D*CGbS-u{i(JfqNw~0`d@q zCze}fU(Rzm=etu`9Mah6HnfsbI0`Ax(!#%`=}|9jztiqBM;3Z~mzWQBqL_Pz`gH#j zu7OzoT|*_#@O@fkOH@&WsD#aEodKYUt1rrje#Zk-ca;KuBUG^MKpWLZZ=BCIHJ_(IdXs6j&c2%4B>WT$wqGtCxW@@Zx|oX1r_5$u6C09eU^yslBkp zSbiwKF7YbJkP2U>gPT5ofEq5~d5^`T=;XG9K5^K772Qkw zWIVxRk)&o%G3w``@ADxF@j<8>YE7j*aijTUP_Dj5Q=y+KZFET+^t$+gT9P?a>7a$j z;I7QaQd$XbFq}Yv%#*9{TFBEOs@Ak92HT19TY>lGFnj_$<=MQNHoM#V>BL&And^bh zw=PR+7Xpi6@dHX`)HTnFiF%Qv|2 zkUCMh#`orWk3C3xMg2XksgbgA)8EnHyUendlmZFd(mS~r(tVDQdmb95FoF9TSb++3 zOQ(R=S>yx@X591;l*eUJElPZxOOip-^8Gx0B4slAgF0K{DO?WBose_3_Oa7Fu*Z;j z{gR2;Hm6pIFDI>zSAqT!3rLyITEVS?YXOUS<(W13_#*=arGYK=mzsN)$80Q`Ed*zw z4$XZ>KB=i;P?k1YA2JHDMA~qZoT%{HL`nRXMi!}AKCl@|;x_U~<^n3~h@6G>i#0XT zPHY_?!@`oOC)u0C$}3}BCek(f72eqR4dmmJTf0W}flm5eNM3A{4=7{HCMI;Stp=&7 zyDQ1-G>#8FIUhOLFjTU|<$f-xh>_}g-&0no6`ts_Z-=a09V|ZW%IKnT;xV@tt4;08 z7nxV=P%EuRj8JYvKz61RHyJ-^WHL-|RHVpJPyP-*{2eYT3Z)N0RNH}x0&mQht? z4G%jB;%zYe1}RM5c!?fsHoNmbI?P9{mz|QO<8P*UaNn_qlw8WYh}(pTNFgb%gAW~& zbfPg#w?5uXR!tE|OIRnrL`9h*SkBXao*no}=WE9$BUlYK6FK1*#Q|*ie!V!rCj1chA~QlRHt%)vcn2|l@K>Y9L*B&xKFO-D z{bg0D>DIrmLb>uRQlB0u8Yw&xOi)-}9O3>_G_)QUkfqy~v{w&|)gUaw)72;|Zv0f` zW|YF}7DVMP`TjB#w@U2fxrXB=LY+yrLs94L2;sL=&^0S8PExiv@=%jkN2WZ6L_d_9 zPSSz6qB=+emXnrMWFFIL=jxpklpJ+?M1gf@KJs&)dVA9*d(?q#P3;?TugcY^Y{iP+ zrbblcXojN|#Y5DmHv41*kSW$1l9IHFBrWPcxj=l=_dby5c3<@Do8xG=Fn6|lL7rtb zMG^GSJ*=s_i0?H!oqi%g6|Xbu)?1cptwgg4kk(HkNtAEGwo_9bMN(ns5*kZZ)1=|q zXDgqq*;OoZ7-gc<%JOujfQoKQDV zoDg1*^?87M0H9E=-CY~3eM}GV5NJmZLs-RT7c{hwkAWY<1=x2I%UdA=0-;2^PV~fa zrg`)X2?%j7+g()v!}xN}vMypf^}6uQ-9jWp`tMyc_zvL%7hyx}>iPSicCGgBU9>CV ztC8c+2*3YU`$tdh8sX2D(^XUI?{PITIlMFXcZ=$JsaKu5Uouxu_#y1)xY7`YYy56m z{Zjh(rqwUC9Dk#q)7)rbU9a=ssrzeyRQR(0g~-1NaFg!71}H%J4e%%VeG}#;HFyp4 z8T~(D{z(+xM7hc8T%#yq{3pr{j^`%O%^La|=ppuh0^O*nZvx${j;?`{aDM~+N3C>? z@aJLws=D}lT=_)`-amZtSFQ2OKmJs{sy42byZ%)EueHa2$GoaOt}!w3|5(s}!Ti@+ zkD97LAf0^cIZE|hpf6s&0vuTk351YE0?K&$ymqS6l0>*{^rNhIE`-+}H F_&-1U - - maven-skins - org.apache.maven.skins - 2 - - 4.0.0 - org.apache.maven.skins - maven-default-skin - Maven Default Skin - 1.0 - Maven Default Skin - http://maven.apache.org/skins/maven-default-skin - - jira - http://jira.codehaus.org/browse/MNG - - - continuum - http://maven.zones.apache.org:8080/continuum - - - -
    notifications@maven.apache.org
    -     -     -     -     - 2002 - - - Maven Announcements List - announce-subscribe@maven.apache.org - announce-unsubscribe@maven.apache.org - announce@maven.apache.org - http://mail-archives.apache.org/mod_mbox/maven-announce/ - - - Maven Issues List - issues-subscribe@maven.apache.org - issues-unsubscribe@maven.apache.org - issues@maven.apache.org - http://mail-archives.apache.org/mod_mbox/maven-issues/ - - - Maven Notifications List - notifications-subscribe@maven.apache.org - notifications-unsubscribe@maven.apache.org - notifications@maven.apache.org - http://mail-archives.apache.org/mod_mbox/maven-notifications/ - - - - - jvanzyl - Jason van Zyl - jason@maven.org - ASF - - PMC Chair - - -5 - - - brett - Brett Porter - brett@apache.org - ASF - - PMC Member - - +10 - - - evenisse - Emmanuel Venisse - evenisse@apache.org - ASF - - PMC Member - - - - kenney - Kenney Westerhof - kenney@apache.org - Neonics - - PMC Member - - - - snicoll - Stephane Nicoll - snicoll@apache.org - ASF - - PMC Member - - +1 - - - vmassol - Vincent Massol - vmassol@apache.org - ASF - - PMC Member - - +1 - - - fgiust - Fabrizio Giustina - fgiust@apache.org - openmind - - PMC Member - - +1 - - - epunzalan - Edwin Punzalan - epunzalan@mergere.com - Mergere - - Committer - - +8 - - - mperham - Mike Perham - mperham@gmail.com - Webify Solutions - - Committer - - -6 - - - jdcasey - John Casey - jdcasey@apache.org - ASF - - PMC Member - - -5 - - - trygvis - Trygve Laugstol - trygvis@apache.org - ASF - - PMC Member - - +1 - - - vsiveton - Vincent Siveton - vsiveton@apache.org - ASF - - Committer - - -5 - - - - - The Apache Software License, Version 2.0 - http://www.apache.org/licenses/LICENSE-2.0.txt - repo - - - - scm:svn:http://svn.apache.org/repos/asf/maven/skins/trunk/maven-default-skin - scm:svn:https://svn.apache.org/repos/asf/maven/skins/trunk/maven-default-skin - http://svn.apache.org/viewcvs.cgi/maven/skins/trunk/maven-default-skin - - - Apache Software Foundation - http://www.apache.org/ - - - c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\src\main\java - src/main/scripts - c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\src\test\java - c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\target\classes - c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\target\test-classes - - - c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\src\main\resources - - - - - c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\src\test\resources - - - c:\home\brett\scm\maven\skins\maven-default-skin\target\checkout\target - maven-default-skin-1.0 - - - - maven-release-plugin - - https://svn.apache.org/repos/asf/maven/skins/tags - - - - - - - maven-deploy-plugin - 2.2 - true - - true - - - - maven-javadoc-plugin - 2.0-beta-3 - - - attach-javadocs - - jar - - - - true - - - maven-source-plugin - 2.0.1 - - - attach-sources - - jar - - - - true - - - maven-resources-plugin - 2.1 - - - maven-compiler-plugin - 2.0.1 - - - maven-surefire-plugin - 2.2-SNAPSHOT - - - maven-jar-plugin - 2.0 - - - maven-install-plugin - 2.1 - - - - - - - false - - apache.snapshots - Apache Snapshot Repository - http://svn.apache.org/maven-snapshot-repository - - - - false - - central - Maven Repository Switchboard - http://repo1.maven.org/maven2 - - - - - - never - - - false - - central - Maven Plugin Repository - http://repo1.maven.org/maven2 - - - - target/site - - - - apache.releases - Apache Release Distribution Repository - scp://minotaur.apache.org/www/www.apache.org/dist/maven-repository - - - apache.snapshots - Apache Development Snapshot Repository - scp://minotaur.apache.org/www/cvs.apache.org/maven-snapshot-repository - - - website - scp://minotaur.apache.org/www/maven.apache.org/skins/maven-default-skin - - -     \ No newline at end of file From 7637c7f38def822df0fb2fef167e630beff5935f Mon Sep 17 00:00:00 2001 From: rdonkin Date: Mon, 3 Aug 2009 14:33:23 +0000 Subject: [PATCH 155/541] Add link to continuous integration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@800407 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 4bdc06f982e..c825f483b0a 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -54,6 +54,7 @@ + From 8aaf0688d931ff78ab3980d51ea0dc368a43a7be Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 11 Aug 2009 08:39:48 +0000 Subject: [PATCH 156/541] The 2.0 version of the site plugin seems to work fine. So, inherit from parent pom. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@803029 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 6 ------ 1 file changed, 6 deletions(-) diff --git a/pom.xml b/pom.xml index 16742096248..b44e1e0096a 100644 --- a/pom.xml +++ b/pom.xml @@ -64,12 +64,6 @@ - - - maven-site-plugin - 2.0-beta-5 - - From 509aff1a06092619a3320e0a51b8e0952674cfdc Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 11 Aug 2009 08:48:54 +0000 Subject: [PATCH 157/541] Inherit from parent pom git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@803036 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index f6e5b3500f3..c9e285975c7 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -44,23 +44,6 @@ - - - maven-remote-resources-plugin - - - - process - - - - org.apache:apache-jar-resource-bundle:1.2 - - - - - - From b4caa007cc5ea326744fbefdc233bd633597250b Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 11 Aug 2009 08:52:16 +0000 Subject: [PATCH 158/541] Correct continuous integration meta-data by inheriting git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@803037 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/pom.xml | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/project/server/pom.xml b/project/server/pom.xml index bf6fa767b3e..c172bc52cbc 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -50,18 +50,6 @@ http://issues.apache.org/jira/browse/JAMES - - continuum - - - mail - - -
    server-dev@james.apache.org
    -     -     -     - Server User List From 80a877e08bd5fe80c537359ee8a69b859c95e04b Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 11 Aug 2009 08:53:13 +0000 Subject: [PATCH 159/541] Inherit issue managment meta-data git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@803038 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/pom.xml | 5 ----- 1 file changed, 5 deletions(-) diff --git a/project/server/pom.xml b/project/server/pom.xml index c172bc52cbc..9a68ae7c0e4 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -44,11 +44,6 @@ scp://people.apache.org/www/james.apache.org/server/ - - - jira - http://issues.apache.org/jira/browse/JAMES - From c487d66f3e4c168d76dcc9a283ad1cd90c778f87 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Wed, 19 Aug 2009 10:32:42 +0000 Subject: [PATCH 160/541] Switch to standard apache release profile git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@805738 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 63 +-------------------------------------------------------- 1 file changed, 1 insertion(+), 62 deletions(-) diff --git a/pom.xml b/pom.xml index b44e1e0096a..c717b706993 100644 --- a/pom.xml +++ b/pom.xml @@ -262,68 +262,7 @@ - - - release - - - - - maven-gpg-plugin - 1.0-alpha-3 - - ${gpg.passphrase} - - - - sign-artifacts - verify - - sign - - - - - - - true - maven-deploy-plugin - 2.3 - - ${deploy.altRepository} - true - - - - org.apache.maven.plugins - maven-source-plugin - 2.0.2 - - - attach-sources - - jar - - - - - - org.apache.maven.plugins - maven-javadoc-plugin - 2.2 - - - attach-javadocs - - jar - - - - - - - - + From 4b35fd2b0363cd4c34ae92f38faa71b67155e7a0 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Mon, 31 Aug 2009 12:31:12 +0000 Subject: [PATCH 161/541] Update site for Apache James 2.3.2 release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@809557 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 25 ++------- project/src/site/xdoc/download.xml | 78 +++++--------------------- project/src/site/xdoc/index.xml | 4 ++ project/src/site/xdoc/newsarchive.xml | 10 ++++ 4 files changed, 34 insertions(+), 83 deletions(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index 848cd3c8e20..e0988389eb5 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -82,26 +82,13 @@ James 2 is a mature, production ready code stream with minimal development. Use of the latest stable release is recommended.

    - -
      -
    • Is the latest official stable release
      • -
    • Is a bugfix release. - See the Change Log for details. -
      • -
    -     - -
      -
    • - Is a bug fix point release currently in preparation. See release notes - for details. -
      • + +
        +
      • Is the latest official stable release and is available for download + here.
      • - Release candidates are available. Note that these - are not official releases and are intended for evaluation by expert users only. -
      • - Feedback welcomed either through the mailing lists - or JIRA. + Is a bug fix point release. + See release notes for details.
      diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 90c7880be49..558fca34f64 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -108,11 +108,11 @@ using

    - +

    This release has many enhancements and bug fixes over the previous release. See the Change Log +href="http://james.apache.org/server/2.3.2/release-notes.html">Release Notes for a detailed list of changes. Some of the earlier defects could turn a JAMES mail server into an Open Relay. All users of JAMES Server are urged to upgrade to version v2.3.1 as soon as possible.

    @@ -120,77 +120,27 @@ possible.

    - - - - + +

    +Are now archived. +
    diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 769e58dba5d..5aad33eb7b0 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -9,6 +9,10 @@
      +
    • Aug/2009 - +
    • Jul/2009 - diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 9084988b9d5..844210d9dd0 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -12,6 +12,16 @@
    +

    Aug/2009 - Apache James 2.3.2 Released

     +

    + The Apache JAMES project is pleased to announce that Apache James 2.3.2 + is now + available. + This is a minor bug fix release. + See the + Release Notes + for more details. Upgrading is recommended for users of previous 2.x releases. +

    Jul/2009 - Apache MPT 0.1 released

    The Apache JAMES project is pleased to announced that the first release of Apache MPT - a functional testing From 88717e5b3191769c213de0db822e4b074a7b19ae Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 1 Sep 2009 13:20:04 +0000 Subject: [PATCH 162/541] Fix typo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@810021 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 558fca34f64..fcd3e27dd00 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -125,7 +125,7 @@ href="http://www.apache.org/dist/james/server/apache-james-2.3.2.tar.gz.asc">PGP

  • Binary (ZIP Format): james-binary-2.3.2.zip [PGP]
    • +href="http://www.apache.org/dist/james/server/apache-james-2.3.2.zip.asc">PGP]
  • Source (Unix TAR): james-2.3.2-src.tar.gz [ Date: Tue, 1 Sep 2009 13:23:02 +0000 Subject: [PATCH 163/541] Maven now uses an underscore for names (not space). git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@810023 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 16 ++++++++-------- project/src/site/xdoc/newsarchive.xml | 6 +++--- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index fcd3e27dd00..4ceb8f10cfb 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -37,15 +37,15 @@ the archive download site.

    diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 844210d9dd0..fb8cffd4957 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -16,7 +16,7 @@

    The Apache JAMES project is pleased to announce that Apache James 2.3.2 is now - available. + available. This is a minor bug fix release. See the Release Notes @@ -26,7 +26,7 @@

    The Apache JAMES project is pleased to announced that the first release of Apache MPT - a functional testing library particularly suitable for line protocols based on ASCII - is now - available. These + available. These protocols are common in mail but the library may be useful more widely. See the release notes for more details. @@ -39,7 +39,7 @@

    The Apache JAMES Project is pleased to announce that the third release of Apache JSieve - an implementation of the Sieve mail filtering language - - is now available for download. This is the first + is now available for download. This is the first modular release and includes a filtering mailet. See the release notes for more details. From 2ca085a7b6f8a4eb94ee8416d0f36dba843e7aa2 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 1 Sep 2009 13:59:53 +0000 Subject: [PATCH 164/541] Use absolute URLs git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@810059 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index c825f483b0a..6acb8ed008f 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -39,33 +39,33 @@ - - - - - - - - - + + + + + + + + +

    - + - - - - - + + + + + - - + + From 2ac26cfdd8746fb5e13179bef247e3864a8fa804 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Tue, 1 Sep 2009 14:12:09 +0000 Subject: [PATCH 165/541] Maven now uses an underscore for names (not space). git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@810064 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 4ceb8f10cfb..bec380789ab 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -27,7 +27,7 @@

    Use the links below to download the product from one of -our mirrors. You must verify the +our mirrors. You must verify the integrity of the downloaded files using signatures downloaded from our main distribution directory.

    From 11d49355d9a9b6d8b1b862237fc11a3113fc306e Mon Sep 17 00:00:00 2001 From: rdonkin Date: Wed, 2 Sep 2009 09:13:05 +0000 Subject: [PATCH 166/541] Specify latest release of Maven site plugin. Revert to relative URLs for links even though this means that - for me - Maven stuffs up the URL rewriting it does when staging... git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@810429 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 7 +++++++ project/src/site/site.xml | 14 +++++++------- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/pom.xml b/pom.xml index c717b706993..ac02912b7ce 100644 --- a/pom.xml +++ b/pom.xml @@ -64,6 +64,13 @@ + + + org.apache.maven.plugins + maven-site-plugin + 2.0.1 + + diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 6acb8ed008f..b94dbd6e951 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -58,14 +58,14 @@
    - - - - - + + + + + - - + + From 8117847cb1c42e913cde302db7131ec3a2ca03b6 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Wed, 16 Sep 2009 10:28:43 +0000 Subject: [PATCH 167/541] [maven-release-plugin] prepare release 1.3RC1 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@815709 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index c9e285975c7..cad394fce0a 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.3-SNAPSHOT + 1.3RC1 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.3-SNAPSHOT + 1.3RC1 diff --git a/pom.xml b/pom.xml index ac02912b7ce..1fa55bd4ebd 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.3-SNAPSHOT + 1.3RC1 The Apache JAMES Parent POM @@ -245,9 +245,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/1.3RC1 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/1.3RC1 + http://svn.apache.org/viewvc/james/project/tags/1.3RC1 diff --git a/project/pom.xml b/project/pom.xml index a9bbc8cbda8..b265914cd80 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.4-SNAPSHOT + 1.4RC1 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.3-SNAPSHOT + 1.3RC1 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 9fab48c7d88..db1f0e32113 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.3-SNAPSHOT + 1.3RC1 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.3-SNAPSHOT + 1.3RC1 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 9a68ae7c0e4..81b823a47e0 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.3-SNAPSHOT + 1.3RC1 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.4-SNAPSHOT + 1.4RC1 2.2.0 From fc8e3cdde7f41eb7f95c48490133580fd0caaeac Mon Sep 17 00:00:00 2001 From: rdonkin Date: Wed, 16 Sep 2009 10:32:45 +0000 Subject: [PATCH 168/541] [maven-release-plugin] prepare for next development iteration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@815712 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index cad394fce0a..f7396c28b80 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.3RC1 + 1.3RC2-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.3RC1 + 1.3RC2-SNAPSHOT diff --git a/pom.xml b/pom.xml index 1fa55bd4ebd..b80cde9803b 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.3RC1 + 1.3RC2-SNAPSHOT The Apache JAMES Parent POM @@ -245,9 +245,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/1.3RC1 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/1.3RC1 - http://svn.apache.org/viewvc/james/project/tags/1.3RC1 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 diff --git a/project/pom.xml b/project/pom.xml index b265914cd80..230fa832d47 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.4RC1 + 1.4RC2-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.3RC1 + 1.3RC2-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index db1f0e32113..1cb194080f8 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.3RC1 + 1.3RC2-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.3RC1 + 1.3RC2-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 81b823a47e0..11830da0cbe 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.3RC1 + 1.3RC2-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.4RC1 + 1.4RC2-SNAPSHOT 2.2.0 From d2ebfbcce14467f58f59ee839aae96df901acbf8 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Wed, 16 Sep 2009 11:09:33 +0000 Subject: [PATCH 169/541] [maven-release-plugin] prepare release james-parent-1.3RC2 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@815722 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index f7396c28b80..90e88836714 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.3RC2-SNAPSHOT + 1.3RC2 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.3RC2-SNAPSHOT + 1.3RC2 diff --git a/pom.xml b/pom.xml index b80cde9803b..4bfefd9604e 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.3RC2-SNAPSHOT + 1.3RC2 The Apache JAMES Parent POM @@ -245,9 +245,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.3RC2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.3RC2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.3RC2 diff --git a/project/pom.xml b/project/pom.xml index 230fa832d47..1ffcc996b8d 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.4RC2-SNAPSHOT + 1.4RC2 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.3RC2-SNAPSHOT + 1.3RC2 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 1cb194080f8..fb5f7f5dc10 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.3RC2-SNAPSHOT + 1.3RC2 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.3RC2-SNAPSHOT + 1.3RC2 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 11830da0cbe..a115ef2743d 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.3RC2-SNAPSHOT + 1.3RC2 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.4RC2-SNAPSHOT + 1.4RC2 2.2.0 From 53f5f4fa5903fe67ec79c1a89d40d5d87b6603f2 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Wed, 16 Sep 2009 11:10:53 +0000 Subject: [PATCH 170/541] [maven-release-plugin] prepare for next development iteration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@815724 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 90e88836714..d0b8373f5ea 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.3RC2 + 1.3RC3-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.3RC2 + 1.3RC3-SNAPSHOT diff --git a/pom.xml b/pom.xml index 4bfefd9604e..41b403f48d6 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.3RC2 + 1.3RC3-SNAPSHOT The Apache JAMES Parent POM @@ -245,9 +245,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.3RC2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.3RC2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.3RC2 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 diff --git a/project/pom.xml b/project/pom.xml index 1ffcc996b8d..91e6155ec6b 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.4RC2 + 1.4RC3-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.3RC2 + 1.3RC3-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index fb5f7f5dc10..ed6484c5ccd 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.3RC2 + 1.3RC3-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.3RC2 + 1.3RC3-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index a115ef2743d..d6d2b891df3 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.3RC2 + 1.3RC3-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.4RC2 + 1.4RC3-SNAPSHOT 2.2.0 From 10184ca911529947ecfdd49dd8e1eb133c3eb08a Mon Sep 17 00:00:00 2001 From: norman Date: Fri, 25 Sep 2009 12:03:13 +0000 Subject: [PATCH 171/541] Add news and links for hupa git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@818826 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 1 + project/src/site/xdoc/index.xml | 4 ++++ project/src/site/xdoc/newsarchive.xml | 7 +++++++ 3 files changed, 12 insertions(+) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index b94dbd6e951..70c9341d398 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -40,6 +40,7 @@ + diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 5aad33eb7b0..4a369b24250 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -9,6 +9,10 @@
    +

    Sept/2009 - Hupa joins Apache James as sub-project

     +

    + The Apache JAMES project is pleased to announce the inclusion of a new sub-project called + Hupa. + Hupa is a GWT based webmail which use IMAP to connect to the backend mailserver. +

    +

    Aug/2009 - Apache James 2.3.2 Released

    The Apache JAMES project is pleased to announce that Apache James 2.3.2 From 9dc6b5c0acdab5eb40a21b887b21005049f3ac2a Mon Sep 17 00:00:00 2001 From: bago Date: Thu, 19 Nov 2009 15:59:44 +0000 Subject: [PATCH 172/541] Added jDKIM to menu, news and home. Removed older news from now too long home box. (JDKIM-5) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@882183 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 1 + project/src/site/xdoc/index.xml | 27 +++++++++++---------------- project/src/site/xdoc/newsarchive.xml | 9 ++++++++- 3 files changed, 20 insertions(+), 17 deletions(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 70c9341d398..1763fa25442 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -49,6 +49,7 @@ +

    diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 4a369b24250..2009233a99c 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -8,9 +8,13 @@
    -
    -

    Sept/2009 - Hupa joins Apache James as sub-project

     +

    Oct/2009 - jDKIM joins Apache James as sub-project

     +

    + The Apache JAMES project is pleased to announce the inclusion of a new sub-project called + jDKIM. + jDKIM is a DomainKeys Identified Mail (DKIM) implementation library written in Java. It provides both verification and signing and also provides Mailets for the Apache JAMES project. +

    + +

    Sep/2009 - Hupa joins Apache James as sub-project

    The Apache JAMES project is pleased to announce the inclusion of a new sub-project called Hupa. From 828af3875c0c75bebeb902bfcd96ca654ad83ae4 Mon Sep 17 00:00:00 2001 From: norman Date: Sat, 21 Nov 2009 19:50:10 +0000 Subject: [PATCH 173/541] Add Manuel to the weare page git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@882978 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/weare.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/project/src/site/xdoc/weare.xml b/project/src/site/xdoc/weare.xml index 9c6c46b27c0..39de4c50eb3 100644 --- a/project/src/site/xdoc/weare.xml +++ b/project/src/site/xdoc/weare.xml @@ -70,7 +70,9 @@

    Oleg Kalnichevski (olegk at apache.org)

    - +

    + Manuel Carrasco Monino (manono at apache.org) +

    • Many people have had a hand in James' success over the years, here we'd like to give credit to those who have made a difference and to those who have left.

    From acd30eede0afeaf8d1416a93cbd5d68896bad04a Mon Sep 17 00:00:00 2001 From: norman Date: Sat, 21 Nov 2009 19:52:14 +0000 Subject: [PATCH 174/541] Add Manuel to developers git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@882979 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/pom.xml b/pom.xml index 41b403f48d6..b5bbdae72b7 100644 --- a/pom.xml +++ b/pom.xml @@ -103,7 +103,7 @@ norman at apache.org 2 - Developer + PMC Chair @@ -223,6 +223,15 @@ PMC Member + + manolo + Manuel Carrasco Monino + manono at apache.org + + + Developer + + From d3811893e605b3123af4f0185cc0eaa5cf503663 Mon Sep 17 00:00:00 2001 From: norman Date: Sat, 21 Nov 2009 20:14:16 +0000 Subject: [PATCH 175/541] fix typo.. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@882983 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 2 +- project/src/site/xdoc/weare.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index b5bbdae72b7..2a9c5501be1 100644 --- a/pom.xml +++ b/pom.xml @@ -226,7 +226,7 @@ manolo Manuel Carrasco Monino - manono at apache.org + manolo at apache.org Developer diff --git a/project/src/site/xdoc/weare.xml b/project/src/site/xdoc/weare.xml index 39de4c50eb3..60ea955d321 100644 --- a/project/src/site/xdoc/weare.xml +++ b/project/src/site/xdoc/weare.xml @@ -71,7 +71,7 @@ Oleg Kalnichevski (olegk at apache.org)

    - Manuel Carrasco Monino (manono at apache.org) + Manuel Carrasco Monino (manolo at apache.org)

    From 2dd200d83297ae184041a3e489120c8841886ada Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 11 Jan 2010 21:52:23 +0000 Subject: [PATCH 176/541] Upgrade to new parent version git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898085 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pom.xml b/pom.xml index 2a9c5501be1..32a0a395859 100644 --- a/pom.xml +++ b/pom.xml @@ -29,7 +29,7 @@ org.apache apache - 6 + 7 From 583e431ba55828cfa9b713b0e550fb41985b786c Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 11 Jan 2010 23:12:43 +0000 Subject: [PATCH 177/541] [maven-release-plugin] prepare release james-parent-1.5 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898103 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index d0b8373f5ea..ffaf5570c4e 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.3RC3-SNAPSHOT + 1.5 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.3RC3-SNAPSHOT + 1.5 diff --git a/pom.xml b/pom.xml index 32a0a395859..ad39b1dde44 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.3RC3-SNAPSHOT + 1.5 The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.5 diff --git a/project/pom.xml b/project/pom.xml index 91e6155ec6b..99dd6c3fa29 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.4RC3-SNAPSHOT + 1.5 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.3RC3-SNAPSHOT + 1.5 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index ed6484c5ccd..35a5baa237d 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.3RC3-SNAPSHOT + 1.5 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.3RC3-SNAPSHOT + 1.5 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index d6d2b891df3..ff5ed2148e6 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.3RC3-SNAPSHOT + 1.5 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.4RC3-SNAPSHOT + 1.5 2.2.0 From 1863904284c6c8edf145da0edbc450947c0a4936 Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 11 Jan 2010 23:13:57 +0000 Subject: [PATCH 178/541] [maven-release-plugin] prepare for next development iteration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898106 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index ffaf5570c4e..17bc3104d15 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.5 + 1.6-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/pom.xml b/pom.xml index ad39b1dde44..34931e15993 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.5 + 1.6-SNAPSHOT The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.5 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 diff --git a/project/pom.xml b/project/pom.xml index 99dd6c3fa29..efa2b9e9f66 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.5 + 1.6-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 35a5baa237d..958a4260468 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.5 + 1.6-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.5 + 1.6-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index ff5ed2148e6..6a40dd8500b 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.5 + 1.6-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.5 + 1.6-SNAPSHOT 2.2.0 From 577365ecc4c8f2c5b422805b0ed6568708995975 Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 11 Jan 2010 23:28:57 +0000 Subject: [PATCH 179/541] [maven-release-plugin] prepare release james-parent-1.5-new git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898109 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 17bc3104d15..ffaf5570c4e 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.6-SNAPSHOT + 1.5 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.6-SNAPSHOT + 1.5 diff --git a/pom.xml b/pom.xml index 34931e15993..9be257a76cc 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.6-SNAPSHOT + 1.5 The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5-new + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5-new + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.5-new diff --git a/project/pom.xml b/project/pom.xml index efa2b9e9f66..99dd6c3fa29 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.6-SNAPSHOT + 1.5 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.6-SNAPSHOT + 1.5 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 958a4260468..35a5baa237d 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.6-SNAPSHOT + 1.5 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.6-SNAPSHOT + 1.5 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 6a40dd8500b..ff5ed2148e6 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.6-SNAPSHOT + 1.5 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.6-SNAPSHOT + 1.5 2.2.0 From 9ae497d0964c58c5a53fc27283588cea77ea97de Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 11 Jan 2010 23:29:47 +0000 Subject: [PATCH 180/541] [maven-release-plugin] rollback the release of james-parent-1.5-new git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898110 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index ffaf5570c4e..17bc3104d15 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.5 + 1.6-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/pom.xml b/pom.xml index 9be257a76cc..34931e15993 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.5 + 1.6-SNAPSHOT The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5-new - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5-new - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.5-new + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 diff --git a/project/pom.xml b/project/pom.xml index 99dd6c3fa29..efa2b9e9f66 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.5 + 1.6-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 35a5baa237d..958a4260468 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.5 + 1.6-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.5 + 1.6-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index ff5ed2148e6..6a40dd8500b 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.5 + 1.6-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.5 + 1.6-SNAPSHOT 2.2.0 From 95c8a6bbfa6e5d0050ff02980e4efbf5ee5193b2 Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 11 Jan 2010 23:31:44 +0000 Subject: [PATCH 181/541] [maven-release-plugin] prepare release 1.5 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898111 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 17bc3104d15..ffaf5570c4e 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.6-SNAPSHOT + 1.5 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.6-SNAPSHOT + 1.5 diff --git a/pom.xml b/pom.xml index 34931e15993..3da6bdcb37b 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.6-SNAPSHOT + 1.5 The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/1.5 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/1.5 + http://svn.apache.org/viewvc/james/project/tags/1.5 diff --git a/project/pom.xml b/project/pom.xml index efa2b9e9f66..99dd6c3fa29 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.6-SNAPSHOT + 1.5 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.6-SNAPSHOT + 1.5 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 958a4260468..35a5baa237d 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.6-SNAPSHOT + 1.5 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.6-SNAPSHOT + 1.5 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 6a40dd8500b..ff5ed2148e6 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.6-SNAPSHOT + 1.5 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.6-SNAPSHOT + 1.5 2.2.0 From 0d274b6e7e735618c34797bbe9b26328d91df430 Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 11 Jan 2010 23:33:29 +0000 Subject: [PATCH 182/541] [maven-release-plugin] prepare for next development iteration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898114 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index ffaf5570c4e..17bc3104d15 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.5 + 1.6-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/pom.xml b/pom.xml index 3da6bdcb37b..34931e15993 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.5 + 1.6-SNAPSHOT The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/1.5 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/1.5 - http://svn.apache.org/viewvc/james/project/tags/1.5 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 diff --git a/project/pom.xml b/project/pom.xml index 99dd6c3fa29..efa2b9e9f66 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.5 + 1.6-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 35a5baa237d..958a4260468 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.5 + 1.6-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.5 + 1.6-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index ff5ed2148e6..6a40dd8500b 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.5 + 1.6-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.5 + 1.6-SNAPSHOT 2.2.0 From cf345610d5de53fc7cfec0959b24af87f752454b Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 11 Jan 2010 23:50:35 +0000 Subject: [PATCH 183/541] [maven-release-plugin] prepare release james-parent-1.5 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898120 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 17bc3104d15..ffaf5570c4e 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.6-SNAPSHOT + 1.5 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.6-SNAPSHOT + 1.5 diff --git a/pom.xml b/pom.xml index 34931e15993..ad39b1dde44 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.6-SNAPSHOT + 1.5 The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.5 diff --git a/project/pom.xml b/project/pom.xml index efa2b9e9f66..99dd6c3fa29 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.6-SNAPSHOT + 1.5 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.6-SNAPSHOT + 1.5 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 958a4260468..35a5baa237d 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.6-SNAPSHOT + 1.5 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.6-SNAPSHOT + 1.5 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 6a40dd8500b..ff5ed2148e6 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.6-SNAPSHOT + 1.5 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.6-SNAPSHOT + 1.5 2.2.0 From 61a97313cd2f7e60c8c10c3ad8c5ae9fe8b5a06f Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 11 Jan 2010 23:51:22 +0000 Subject: [PATCH 184/541] [maven-release-plugin] prepare for next development iteration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898122 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index ffaf5570c4e..17bc3104d15 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.5 + 1.6-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/pom.xml b/pom.xml index ad39b1dde44..34931e15993 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.5 + 1.6-SNAPSHOT The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.5 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 diff --git a/project/pom.xml b/project/pom.xml index 99dd6c3fa29..efa2b9e9f66 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.5 + 1.6-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 35a5baa237d..958a4260468 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.5 + 1.6-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.5 + 1.6-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index ff5ed2148e6..6a40dd8500b 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.5 + 1.6-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.5 + 1.6-SNAPSHOT 2.2.0 From 85c5e717a28abc1022db92fba87d307e6d35a672 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 12 Jan 2010 08:26:29 +0000 Subject: [PATCH 185/541] fix scm connection, remove repositories git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898241 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/pom.xml b/pom.xml index 34931e15993..7dda79e24a6 100644 --- a/pom.xml +++ b/pom.xml @@ -254,22 +254,12 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk - - apache.releases - Apache Release Distribution Repository - scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository - - - apache.snapshots - Apache Development Snapshot Repository - scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository - james-parent-website From 820fc32cf67f840d52ee5bf4d04de16d5a310a6a Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 12 Jan 2010 08:28:43 +0000 Subject: [PATCH 186/541] [maven-release-plugin] rollback the release of james-parent-1.5 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898243 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/pom.xml b/pom.xml index 7dda79e24a6..34931e15993 100644 --- a/pom.xml +++ b/pom.xml @@ -254,12 +254,22 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk - http://svn.apache.org/viewvc/james/project/trunk + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + + apache.releases + Apache Release Distribution Repository + scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository + + + apache.snapshots + Apache Development Snapshot Repository + scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository + james-parent-website From ea3d1961ab741bff6b3fe86c5079178e78e7a180 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 12 Jan 2010 08:30:38 +0000 Subject: [PATCH 187/541] [maven-release-plugin] prepare release 1.5 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898245 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 17bc3104d15..ffaf5570c4e 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.6-SNAPSHOT + 1.5 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.6-SNAPSHOT + 1.5 diff --git a/pom.xml b/pom.xml index 34931e15993..3da6bdcb37b 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.6-SNAPSHOT + 1.5 The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/1.5 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/1.5 + http://svn.apache.org/viewvc/james/project/tags/1.5 diff --git a/project/pom.xml b/project/pom.xml index efa2b9e9f66..99dd6c3fa29 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.6-SNAPSHOT + 1.5 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.6-SNAPSHOT + 1.5 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 958a4260468..35a5baa237d 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.6-SNAPSHOT + 1.5 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.6-SNAPSHOT + 1.5 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 6a40dd8500b..ff5ed2148e6 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.6-SNAPSHOT + 1.5 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.6-SNAPSHOT + 1.5 2.2.0 From 05bf94ad5ca5c004bb8e689cea4de52a63fb817a Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 12 Jan 2010 08:32:08 +0000 Subject: [PATCH 188/541] [maven-release-plugin] rollback the release of 1.5 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898246 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index ffaf5570c4e..17bc3104d15 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.5 + 1.6-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/pom.xml b/pom.xml index 3da6bdcb37b..34931e15993 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.5 + 1.6-SNAPSHOT The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/1.5 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/1.5 - http://svn.apache.org/viewvc/james/project/tags/1.5 + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 diff --git a/project/pom.xml b/project/pom.xml index 99dd6c3fa29..efa2b9e9f66 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.5 + 1.6-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 35a5baa237d..958a4260468 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.5 + 1.6-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.5 + 1.6-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index ff5ed2148e6..6a40dd8500b 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.5 + 1.6-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.5 + 1.6-SNAPSHOT 2.2.0 From d129d9717e6466b349aba061209057eccc4438e0 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 12 Jan 2010 08:33:39 +0000 Subject: [PATCH 189/541] doh.. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898248 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/pom.xml b/pom.xml index 34931e15993..7dda79e24a6 100644 --- a/pom.xml +++ b/pom.xml @@ -254,22 +254,12 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.2 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.2 + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk - - apache.releases - Apache Release Distribution Repository - scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository - - - apache.snapshots - Apache Development Snapshot Repository - scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository - james-parent-website From a0dff2ed6250689501e22c107d2f20b724c60709 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 12 Jan 2010 08:35:35 +0000 Subject: [PATCH 190/541] [maven-release-plugin] prepare release james-parent-1.5 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898249 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 17bc3104d15..ffaf5570c4e 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.6-SNAPSHOT + 1.5 JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.6-SNAPSHOT + 1.5 diff --git a/pom.xml b/pom.xml index 7dda79e24a6..b8b2f79c034 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.6-SNAPSHOT + 1.5 The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk - http://svn.apache.org/viewvc/james/project/trunk + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.5 diff --git a/project/pom.xml b/project/pom.xml index efa2b9e9f66..99dd6c3fa29 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.6-SNAPSHOT + 1.5 The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.6-SNAPSHOT + 1.5 diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 958a4260468..35a5baa237d 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.6-SNAPSHOT + 1.5 Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.6-SNAPSHOT + 1.5 http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 6a40dd8500b..ff5ed2148e6 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.6-SNAPSHOT + 1.5 Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.6-SNAPSHOT + 1.5 2.2.0 From e5cb4e99ec90f0ae04daac92c6b514b92c07c00e Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 12 Jan 2010 08:37:24 +0000 Subject: [PATCH 191/541] [maven-release-plugin] prepare for next development iteration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@898252 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- pom.xml | 8 ++++---- project/pom.xml | 4 ++-- project/server/2.2.0/pom.xml | 4 ++-- project/server/pom.xml | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index ffaf5570c4e..17bc3104d15 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -20,14 +20,14 @@ 4.0.0 org.apache.james maven-skin - 1.5 + 1.6-SNAPSHOT JAMES Skin Apache JAMES Official Maven2 Site Skin org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/pom.xml b/pom.xml index b8b2f79c034..7dda79e24a6 100644 --- a/pom.xml +++ b/pom.xml @@ -21,7 +21,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.5 + 1.6-SNAPSHOT The Apache JAMES Parent POM @@ -254,9 +254,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.5 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.5 + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk diff --git a/project/pom.xml b/project/pom.xml index 99dd6c3fa29..efa2b9e9f66 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project Apache JAMES Project - 1.5 + 1.6-SNAPSHOT The Apache JAMES Project @@ -30,7 +30,7 @@ org.apache.james james-parent - 1.5 + 1.6-SNAPSHOT diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 35a5baa237d..958a4260468 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-site-2-2-0 JAMES Server 2.2.0 Documentation - 1.5 + 1.6-SNAPSHOT Apache JAMES Server 2.2.0 Documentation @@ -30,7 +30,7 @@ org.apache.james james-server-root - 1.5 + 1.6-SNAPSHOT http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index ff5ed2148e6..6a40dd8500b 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root JAMES Server - 1.5 + 1.6-SNAPSHOT Apache JAMES Server @@ -30,7 +30,7 @@ org.apache.james james-project - 1.5 + 1.6-SNAPSHOT 2.2.0 From ce622bdcf3385679469bf4b06e878eb1300ae886 Mon Sep 17 00:00:00 2001 From: norman Date: Tue, 19 Jan 2010 14:06:18 +0000 Subject: [PATCH 192/541] no need for custom release notes git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@900785 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO_RELEASE.txt | 104 +--------------------------------------------- 1 file changed, 1 insertion(+), 103 deletions(-) diff --git a/HOWTO_RELEASE.txt b/HOWTO_RELEASE.txt index 9b85efe5688..7a1c4b5fed8 100644 --- a/HOWTO_RELEASE.txt +++ b/HOWTO_RELEASE.txt @@ -1,106 +1,4 @@ Howto release via maven release plugin: - - 1 One time setup steps: - Windows: - 1 Create and install a SSH key - 1 Install PuTTY - 2 Use PuttyGen to create a SSH key and export the key as openssh key - 3 Use PuTTY to ssh to people.apache.org - 4 Create a ~/.ssh folder - 5 Use pscp your SSH public key to ~/authorized_keys - 6 Configure putty to use your private key and save the session - 7 Check you can login people.apache.org with your key - 2 Install cygwin - 1 Install CygWin - 2 Use ssh to login to people.apache.org . This is needed to get the correct entry in your known_hosts file - 3 Copy the known_hosts file to your $(homedir)/.ssh/ - - Linux / Unix: - 1 Create and install a SSH key - 1 Install ssh ( this should be installed by default on must linux / unix systems) - 2 Use "ssh-keygen -t dsa" to generate a new private/public key - 3 Use ssh to login people.apache.org and add the content of "~/.ssh/id_dsa.pub" (local) to "~/.ssh/authorized_keys" (people.apache.org) - 4 Check you can login people.apache.org via your private key - - 2 Some linux version (e.g: kubuntu 7) uses an hashed version of the known_hosts file. - This file is not understood by maven. So the easiest thing is to run an interactive maven command - using the ssh access to people.apache.org. - mvn deploy:deploy-file - \ -Durl=scp://people.apache.org/home/$(YOURHOME)/public_html/a-random-repository - \ -DrepositoryId=a_random.id - \ -Dfile=path_to_a_local_file.jar - \ -DgroupId=org.some.group - \ -DartifactId=your-artifact - \ -Dversion=1.0 - \ -Dpackaging=jar - This will try connecting via ssh to people.apache.org and interactively will ask you to accept the new - host key. - Run this a second time and it HAVE TO work without asking anything. If it keep asking to accept - the key for an unknown host you will not be able to make the release. - - - - General: - 1 Install Apache Maven 2.0.6+ and make its binary 'mvn' available on your PATH. - - 2 Create a settings.xml in your .m2 directory with the following content: - - - - - people.apache.org - $(USERNAME) - $(PRIVATE_KEY) - $(PASSPHRASE) - 775 - 644 - - - - - release - - people.apache.org::default::scp://people.apache.org/home/$(USERNAME)/public_html/staging-repository - - - - - - Replace $(USERNAME) with the username you use to login people.apache.org, $(PRIVATE_KEY) with the path to your private openssh key and $(PASSPHRASE) with your passphrase. - Just remove the passphrase config option if your private key is not encrypted with one. - - - 2 Do the release with maven: - - This steps will build, sign and upload the releases - - Prepare: - 1 Login to minotaur (people.apache.org) via ssh. - 2 Clean up your staging-repository via: 'rm -r ~/staging-repository/org/apache/james/*' - If this fails, you have probally not the needed directory structure in place. Create it via: 'mkdir -p ~/staging-repository/org/apache/james/' - 3 Copy the "old" published builds to staging-repository (this is needed to get the right meta data) via: - 'cp -r /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/james/* ~/staging-repository/org/apache/james/' - - - - General: - 1 Move to the root folder of the project: - 2 Use ' mvn -Plocal,release release:prepare -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) -Darguments="-Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE)" ' to prepare the release - 3 Use ' mvn -Plocal,release release:perform -Dgoals=deploy -Darguments="-Dgoals=deploy" ' to finally perfom all needed steps to finish the release stuff - 4 If the step 3 does not work try this more verbose - ' mvn -Plocal,release release:perform -Dgoals=deploy -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE) -Darguments="-Dgoals=deploy -Dgpg.keyname=$(YOURKEYNAME) -Dgpg.passphrase=$(YOURPASSPHRASE)" ' - - Now all should be done the next time with only this two maven commands - - - 3 Publish the release as maven artifact - - This steps will make the artifact's aviable in maven repositories. Get sure the VOTE has passed and the release should get official - - Publish: - 1 Copy the artifact's the maven repo via: 'cp -r ~/staging-repository/org/apache/james/* /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/james/' - 2 Get some coffee and wait till the artifact's get synced across the mirrors (this can take some time). +See http://maven.apache.org/developers/release/apache-release.html \ No newline at end of file From b682fc76097511d9353d642328000c7170f33143 Mon Sep 17 00:00:00 2001 From: norman Date: Fri, 14 May 2010 13:04:20 +0000 Subject: [PATCH 193/541] add jsieve and mailet standard releases git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@944241 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 5 +++++ project/src/site/xdoc/newsarchive.xml | 13 +++++++++++++ 2 files changed, 18 insertions(+) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 2009233a99c..317645b2187 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -9,6 +9,11 @@
    + +

    May/2010 - Apache JSieve 0.4 released

     +

    The Apache JAMES Project is pleased to announce that the forth release of + Apache JSieve - an implementation of the + Sieve mail filtering language - + is now available for download. +

    +

    May/2010 - Apache Mailet Standard 1.0 released

     +

    The Apache JAMES Project is pleased to announce that the first independent release of + Apache Mailet Standard - was bundled with JAMES Server 2.3 before - + is now available for download. +

    +

    Oct/2009 - jDKIM joins Apache James as sub-project

    From bc8bc2f8e5d22f1e85471a649f5e646410698a85 Mon Sep 17 00:00:00 2001 From: norman Date: Fri, 14 May 2010 15:21:48 +0000 Subject: [PATCH 194/541] Add links for new jsieve release and mailets standard git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@944312 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 82 ++++++++++++++++++++++-------- 1 file changed, 60 insertions(+), 22 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index bec380789ab..6cc064557a2 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -215,43 +215,43 @@ href="http://www.apache.org/dist/james/jspf/source/apache-jspf-0.9.7-src.zip.asc

    -

    Apache JSieve 0.3 is the latest stable version:

    +

    Apache JSieve 0.4 is the latest stable version:

    @@ -328,6 +328,44 @@ href="http://www.apache.org/dist/james/apache-mailet-base/1.0/apache-mailet-base
    +
    +

    Apache Mailet Standard 1.0 is the latest stable version:

    + + +
    +

    Apache Crypto Mailets 1.0 is the latest stable version:

      From 792dc56761d1c0f9d96f0bfabfcb21be83ad882e Mon Sep 17 00:00:00 2001 From: norman Date: Fri, 14 May 2010 15:22:36 +0000 Subject: [PATCH 195/541] . git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@944313 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 1763fa25442..dd0262d25a5 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -55,7 +55,7 @@ - + From 21c40d608042f0bbf6c5fec6f9deff96edb05e7d Mon Sep 17 00:00:00 2001 From: norman Date: Thu, 10 Jun 2010 17:17:22 +0000 Subject: [PATCH 196/541] mailet-base 1.1 was released git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@953400 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 38 +++++++++++++++--------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 6cc064557a2..98fc70def58 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -291,38 +291,38 @@ href="http://www.apache.org/dist/james/apache-mailet/2.4/apache-mailet-2.4.jar.m
    -

    Apache Mailet Base 1.0 is the latest stable version:

    +

    Apache Mailet Base 1.1 is the latest stable version:

    From 5bc8786dc76888cd3751a037502d5fc08b1166be Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 21 Jun 2010 13:37:47 +0000 Subject: [PATCH 197/541] Update to reflect jspf and mailet-base releases git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@956581 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 28 +++++++++++++-------------- project/src/site/xdoc/index.xml | 5 +++++ project/src/site/xdoc/newsarchive.xml | 8 ++++++++ 3 files changed, 27 insertions(+), 14 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 98fc70def58..e8e6cda4ea3 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -181,33 +181,33 @@ href="[preferred]/james/mime4j/">Other Files (javadoc.jar, sha1 checksums...
    -
    -

    Apache James jSPF 0.9.7 is the latest jSPF stable version:

    +
    +

    Apache James jSPF 0.9.8 is the latest jSPF stable version:

    • Binary Resolver (JAR): apache-jspf-resolver-0.9.7.jar [PGP]
      • +href="[preferred]/james/jspf/binaries/apache-jspf-resolver-0.9.8.jar">apache-jspf-resolver-0.9.8.jar [PGP]
    • Binary Tester (JAR): apache-jspf-tester-0.9.7.jar [PGP]
      • +href="[preferred]/james/jspf/binaries/apache-jspf-tester-0.9.8.jar">apache-jspf-tester-0.9.8.jar [PGP]
    • Binary (ZIP Format): apache-jspf-0.9.7-bin.zip [PGP]
      • +href="[preferred]/james/jspf/binaries/apache-jspf-0.9.8-bin.zip">apache-jspf-0.9.8-bin.zip [PGP]
    • Binary (Unix TAR.GZ): apache-jspf-0.9.7-bin.tar.gz [PGP]
      • +href="[preferred]/james/jspf/binaries/apache-jspf-0.9.8-bin.tar.gz">apache-jspf-0.9.8-bin.tar.gz [PGP]
    • Source (Unix TAR.GZ): apache-jspf-0.9.7-src.tar.gz [PGP]
      • +href="[preferred]/james/jspf/source/apache-jspf-0.9.8-src.tar.gz">apache-jspf-0.9.8-src.tar.gz [PGP]
    • Source (ZIP Format): apache-jspf-0.9.7-src.zip [PGP]
      • +href="[preferred]/james/jspf/source/apache-jspf-0.9.8-src.zip">apache-jspf-0.9.8-src.zip [PGP]
    • Other Binaries
      • diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 317645b2187..3ff6ef661ed 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -9,6 +9,11 @@
      +

      Jun/2010 - Apache jSPF 0.9.8 released

       +

      The Apache JAMES Project is pleased to announce a new + Apache jSPF release which includes fixed to TXT record escaping and pass the rfc4408-tests-2009.10 testsuite. +

      +

      Jun/2010 - Apache Mailet Base 1.1 released

       +

      The Apache JAMES Project is pleased to announce a new + Apache Mailet Base release which fixes a NullPointerException when using MatcherInverter. +

      May/2010 - Apache JSieve 0.4 released

      The Apache JAMES Project is pleased to announce that the forth release of Apache JSieve - an implementation of the From 4cdda76b84a5f0d30c32e61c0a355525267ed954 Mon Sep 17 00:00:00 2001 From: eric Date: Sat, 16 Oct 2010 14:19:50 +0000 Subject: [PATCH 198/541] Added my-self to committers' list git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1023290 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/weare.xml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/project/src/site/xdoc/weare.xml b/project/src/site/xdoc/weare.xml index 60ea955d321..74066429114 100644 --- a/project/src/site/xdoc/weare.xml +++ b/project/src/site/xdoc/weare.xml @@ -24,9 +24,9 @@

      -

      Special thanks go to the following people for their contributions to this project. We also appreciate documentation, feedback, and bug reports. This is a living document that describes the key contributors to James. Last Updated January 2007.

      +

      Special thanks go to the following people for their contributions to this project. We also appreciate documentation, feedback, and bug reports. This is a living document that describes the key contributors to James. Last Updated October 2010.

      -
      +

      Serge Knystautas (sergek at lokitech.com) (SK)
      Serge was the original donator of the James code, which has since been massively improved by people smarter than him. He tries to answer questions on the listserv and make code contributions when he does get a rare bit of free time.

      @@ -73,6 +73,9 @@

      Manuel Carrasco Monino (manolo at apache.org)

      +

      + Eric Charles (eric at apache.org) +

      Many people have had a hand in James' success over the years, here we'd like to give credit to those who have made a difference and to those who have left.

      From 4474a7a2902288c935c4c0f279d8c88d6e9a8d36 Mon Sep 17 00:00:00 2001 From: eric Date: Sat, 16 Oct 2010 15:36:45 +0000 Subject: [PATCH 199/541] Added my-self to developer's list. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1023309 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/pom.xml b/pom.xml index 7dda79e24a6..7b1b123db24 100644 --- a/pom.xml +++ b/pom.xml @@ -232,6 +232,15 @@ Developer + + eric + Eric Charles + eric at apache.org + + + PMC Member + + From aca9c421c3bf8e57fafe3c001c8b373bf0de4d79 Mon Sep 17 00:00:00 2001 From: eric Date: Fri, 22 Oct 2010 09:14:36 +0000 Subject: [PATCH 200/541] Announce imap 0.2-M1 a nd protocols 1.2-M1 releases. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1026261 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 7 ++++++- project/src/site/xdoc/newsarchive.xml | 9 +++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 3ff6ef661ed..c86ee7da328 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -9,9 +9,14 @@
      +

      Sep/2010 - Apache IMAP 0.2-M1 released

       +

      The Apache JAMES Project is pleased to announce a new + Apache IMAP release in preparation of + the upcoming 3.0-M1 Apache Mail server. +

      +

      Sep/2010 - Apache protocols 1.2-M1 released

       +

      The Apache JAMES Project is pleased to announce a new + Apache protocols release in preparation of the upcoming 3.0-M1 Apache Mail server. +

      Jun/2010 - Apache jSPF 0.9.8 released

      The Apache JAMES Project is pleased to announce a new Apache jSPF release which includes fixed to TXT record escaping and pass the rfc4408-tests-2009.10 testsuite. From 12bf6fdfb56129a159d4a01764f8a6443d1c3992 Mon Sep 17 00:00:00 2001 From: eric Date: Sat, 23 Oct 2010 06:08:32 +0000 Subject: [PATCH 201/541] Align version number - Update top-level menu - Review left menu and its inheritance git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1026562 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 53 +++++++++++++++++++++++++-------------- 1 file changed, 34 insertions(+), 19 deletions(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index dd0262d25a5..d36919f109d 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -17,7 +17,7 @@ specific language governing permissions and limitations under the License. --> - + James Project @@ -34,32 +34,43 @@ org.apache.james maven-skin - 1.2 + 1.6-SNAPSHOT - + + + - + + + - - - + + + + + - -

      - - - + + + - - + + @@ -70,13 +81,17 @@ + + + + + + + + From 92f436a60d513bda6fdaeda733f21970a06c79fd Mon Sep 17 00:00:00 2001 From: eric Date: Sat, 23 Oct 2010 06:09:05 +0000 Subject: [PATCH 202/541] Inherit less menu to have a lighter left menu git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1026563 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/site.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/project/server/src/site/site.xml b/project/server/src/site/site.xml index 971f5a2a1a5..6c17f546909 100644 --- a/project/server/src/site/site.xml +++ b/project/server/src/site/site.xml @@ -33,7 +33,10 @@ + + @@ -44,7 +47,10 @@ + + @@ -54,4 +60,5 @@ + From c7c2b50bcb855c35cc5513e3d1dfce8c61d0ab3c Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 25 Oct 2010 11:13:06 +0000 Subject: [PATCH 203/541] Add svn:ignore property. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027058 13f79535-47bb-0310-9956-ffa450edef68 From 98f0860acfe1343bfee3d73a000cb6bf63638732 Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 25 Oct 2010 11:14:03 +0000 Subject: [PATCH 204/541] Add svn:ignore property. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027059 13f79535-47bb-0310-9956-ffa450edef68 From e026643eba1a39ee2821d7a7d990c924fead929b Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 25 Oct 2010 12:16:49 +0000 Subject: [PATCH 205/541] Simple Format on server home page and feature matrix update. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027082 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/site.xml | 6 +- .../src/site/xdoc/design_objectives.xml | 5 +- project/server/src/site/xdoc/index.xml | 411 +++++++++++++----- project/server/src/site/xdoc/todo.xml | 6 + 4 files changed, 310 insertions(+), 118 deletions(-) diff --git a/project/server/src/site/site.xml b/project/server/src/site/site.xml index 6c17f546909..b74a791104a 100644 --- a/project/server/src/site/site.xml +++ b/project/server/src/site/site.xml @@ -47,12 +47,12 @@ - - - + + diff --git a/project/server/src/site/xdoc/design_objectives.xml b/project/server/src/site/xdoc/design_objectives.xml index d8f7863321a..71bcd3a0524 100644 --- a/project/server/src/site/xdoc/design_objectives.xml +++ b/project/server/src/site/xdoc/design_objectives.xml @@ -23,9 +23,10 @@ James Project Web Team +
      - +

      These are some of the currently implemented features:

      @@ -74,7 +75,7 @@ scalability and mission-critical use.

      Anything else you may want if you help us write it :-)

       - +

      It is the existence of published "open" standards which allows independant teams to develop interoperable software.
      James attempts to support a number of these standards most of which are diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index e0988389eb5..850e01107b6 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -22,67 +22,93 @@ Overview James Project Team + -

      -

      Apache James Server -

      - + +
      + +
      + +

      Is 100% pure JAVA capable Mail Server running on Java 1.5 onwards. James integrates emailing protocols such as:

        -
      • Is 100% pure java capable of running on Java 1.4 onwards
        • -
      • Integrates protocols -
          -
        • Email -
            -
          • -SMTP
            • -
          • -POP3 -
              -
            • Outgoing server
              • -
            • Incoming from POP3 accounts (FetchMail)
              • -
            -
            • -
          • -IMAP (James 3) -
              -
            • Server
              • -
            • Sieve - filtering into IMAP mailboxes for incoming mail
              • -
            -
            • -
          -
          • -
        -
          -
        • -NNTP (better known as news)
          • -
        -
        • -
      • Is based on open standards
        • -
      • Is a mailet container. Processing is delegated to independent, extensible, pluggable agents +
      • + SMTP
        • +
      • LMTP
        • +
      • + POP3 +
          +
        • Outgoing server
          • +
        • Incoming from POP3 accounts (FetchMail)
          • +
        +
        • +
      • + IMAP (James 3) +
          +
        • Server
          • +
        • Sieve + filtering into IMAP mailboxes for incoming mail
          • +
        +
        • +
      +
        +
      • + NNTP (better known as news) - only in 2.3., support is discontinuated in 3.0.
        • +
      + +

      Is a mailet container: the email processing is delegated to independent, extensible, pluggable agents specified by the Mailet API. Any function which is not already available (from James - or from a third party) can be developed. -

    • Is a modular, component based IoC - mail platform + or from a third party) can be developed.

      + +

      Is a modular, component based Inversion of Control + mail platform.

      + +

      Is based on open technical standards.

      +
        -
      • Based on mature, production proved Apache Excalibur - components
        • +
      • James 3 (development) supports Spring and is moving + towards OSGI.
      • James 2 (production) uses the Avalon framework. Avalon development has now stopped but the framework is mature, stable and of proved production quality.
        • -
      • James 3 (development) supports Spring and is moving - towards OSGI
        • -
      -
    +
    + + + +
    +
    + + + +
      +
    • Is a proposed milestone release allowing a preview of the James 3.0 features
      • +
    • Feedback welcomed either through the mailing lists + or JIRA.
      • +
    + +     + + + +

    The James 3 code base has many + new features + and major revisions to the architecture are ongoing

    + +

    It is recommended only for advanced users who are willing to accept that + development is ongoing and that they may need to participate actively. + Users are strongly recommended to subscribe to the server-dev + mailing list.

    + +     + -

    - James 2 is a mature, production ready code stream with minimal development. - Use of the latest stable release is recommended. -

    - + +

    James 2 is a mature, production ready code stream with minimal development. + Use of the latest stable release is recommended.

    + +

    Latest and Stable - James 2.3.2

    • Is the latest official stable release and is available for download here.
      • @@ -90,9 +116,11 @@ Is a bug fix point release. See release notes for details. -
    -     - + + + + -     - -

    -The James 3 code base has many -new features -and major revisions to the architecture are ongoing. -

    -It is recommended only for advanced users who are willing to accept that -development is ongoing and that they may need to participate actively. -Users are strongly recommended to subscribe to the server-dev -mailing list. -

    - -
      -
    • Is a proposed milestone release allowing a preview of the James 3.0 features -
    • - Feedback welcomed either through the mailing lists - or JIRA. -
      • -
    -     -     +
    + +
    + +
    +
    + + + - + + + - - - - - - - - - - - - - - - - - - - + + + - - - - + + + + + + + + + + + + + + - + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - + + + + + + - + - - + + + + - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Item Status3.02.3.x Since First released
    SMTP serverSMTP Stableyesyes 1.0 0.95
    Mailet EngineStable2.30.95
    FileSystem mailboxes/spoolStable1.21.0
    RDBMS mailboxes/spoolStable1.21.2
    POP3 serverPOP3 Stableyesyes 1.1 1.0
    RDBMS - UsersStable1.2.11.2.1IMAPOkayyesno3.03.0
    LMTPnoyes
    LDAP Support - UsersNNTP Experimentalnoyes 1.2 1.2
    TLS Support - POP3TLS POP3/SMTP Experimental 1.2 1.2
    Mailing Listyesyes
    FetchMailStable2.22.2
    Mailet ContainerStableyesyes2.30.95
    Remote Manager Stable 1.0 1.0
    Management via JMXyesyes
    TLS Support - Remote ManagerTLS Support Remote Manager Stable 1.2 1.2
    File Mail StoreStableyesyes1.21.0
    JDBC Database Mail Storeyesyes1.21.2
    JPA Database Mail Storenoyes
    JCR (Jackrabbit) Database Mail Storenoyes
    NNTP serverExperimental1.21.2JDBC UsersStable1.2.11.2.1
    FetchMailJPA Users Stable2.22.21.2.11.2.1
    IMAPOkay3.03.0JCR UsersStable1.2.11.2.1
    LDAP UsersExperimental1.21.2
    Alternate User and Mail storesyesyes
    Alternate Queuenoyes
    Integration with SpamAssassinpartialyes
    Run-as-service scriptsnoyes
    Deployment in WEB containernoyes
    Deployment in OSGI containernoplanned
    Configuration Hot Reloadnoplanned
    Monitoring via JMXyesyes
    IP V6nopartial
    Java 1.4yesno
    +
    +

    See here

    + + diff --git a/project/server/src/site/xdoc/todo.xml b/project/server/src/site/xdoc/todo.xml index 8c249fd8c5b..0b389e93a3c 100644 --- a/project/server/src/site/xdoc/todo.xml +++ b/project/server/src/site/xdoc/todo.xml @@ -20,20 +20,24 @@ + TODO Serge Knystautas Charles Benett Peter M. Goldstein +
    +

    This is a living document that will give new and existing volunteers some areas where we need help. As always, any help is appreciated, be it documentation, code, suggestions, or feedback. Last Updated July 2006.

    +

    Determine a way to support multiple domains.

    Revisit UserRepository. The interface must support multiple authentication types per user, aliasing (both local and non-local), as well as per-user quotas. It may be desirable to be able @@ -89,6 +93,7 @@ and a full suite of mail-driven commands.

    Improve the debugging output, including a) catching that DNS servers are not correct (at least have DNS log channel record DNS server usage)

    +

    Add support for better mailet router/processing (maybe like RequestDispatcher) - Use Stage/Pipeline pattern

    Add support for deployable message processing apps using Camelot pattern

    @@ -106,4 +111,5 @@ and a full suite of mail-driven commands.

    + From 8a10327106a58029a9a16bc734a773a40712510a Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 25 Oct 2010 12:18:37 +0000 Subject: [PATCH 206/541] Update svn:ignore property. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027085 13f79535-47bb-0310-9956-ffa450edef68 From c16617cb2000df55a113a65eba4d2095ff5f2319 Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 26 Oct 2010 06:55:27 +0000 Subject: [PATCH 207/541] Format main and server Index - Remove sendmail from left menu - Update hudson url. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027384 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/site.xml | 4 +- project/server/src/site/xdoc/FAQ.xml | 9 +- .../site/xdoc/archive/document_archive.xml | 7 +- project/server/src/site/xdoc/index.xml | 151 ++++---- project/src/site/site.xml | 4 +- project/src/site/xdoc/index.xml | 321 ++++++++++-------- 6 files changed, 265 insertions(+), 231 deletions(-) diff --git a/project/server/src/site/site.xml b/project/server/src/site/site.xml index b74a791104a..3857769ac5a 100644 --- a/project/server/src/site/site.xml +++ b/project/server/src/site/site.xml @@ -39,9 +39,7 @@ - - - + diff --git a/project/server/src/site/xdoc/FAQ.xml b/project/server/src/site/xdoc/FAQ.xml index 5a02e141b73..440cd2c2526 100644 --- a/project/server/src/site/xdoc/FAQ.xml +++ b/project/server/src/site/xdoc/FAQ.xml @@ -80,9 +80,12 @@
  • How do I use Subversion to get James source code?
    • -
  • - How can I control Sun's JVM DNS Lookup Configuration. -
    • +
  • + How can I control Sun's JVM DNS Lookup Configuration. +
    • +
  • + James and Sendmail. +

    • diff --git a/project/server/src/site/xdoc/archive/document_archive.xml b/project/server/src/site/xdoc/archive/document_archive.xml index 7fa00ab636a..f48bebaac99 100644 --- a/project/server/src/site/xdoc/archive/document_archive.xml +++ b/project/server/src/site/xdoc/archive/document_archive.xml @@ -36,6 +36,7 @@ for users who still have need of it. The James project urges all users to upgrade to the current Release Build of James.

    +

    +

    +     +
    + + diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index 850e01107b6..0a29b8a5d3e 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -18,6 +18,7 @@ under the License. --> + Overview James Project Team @@ -25,34 +26,28 @@ -
    - -
    + + + + +
    + +

    Is 100% pure JAVA capable Mail Server running on Java 1.5 onwards. James integrates emailing protocols such as:

    +
    • - SMTP
      • + SMTP
    • LMTP
    • - POP3 -
        -
      • Outgoing server
        • -
      • Incoming from POP3 accounts (FetchMail)
        • -
      -
      • + POP3
    • - IMAP (James 3) -
        -
      • Server
        • -
      • Sieve - filtering into IMAP mailboxes for incoming mail
        • -
      -
      • -
    -
      -
    • - NNTP (better known as news) - only in 2.3., support is discontinuated in 3.0.
      • + IMAP (James 3) +
    • Sieve + filtering into mailboxes for incoming mail
      • +
    • FetchMail from POP3 and IMAP accounts.
      • +
    • + NNTP (better known as news) + - only in 2.3., support is discontinuated in 3.0.

    Is a mailet container: the email processing is delegated to independent, extensible, pluggable agents @@ -64,21 +59,12 @@ mail platform.

    Is based on open technical standards.

    - -
      -
    • James 3 (development) supports Spring and is moving - towards OSGI.
      • -
    • James 2 (production) uses the Avalon framework. Avalon development - has now stopped but the framework is mature, stable and of proved production quality.
      • -
    - +     		-
    - -
    +
    @@ -96,6 +82,9 @@ new features and major revisions to the architecture are ongoing

    +

    James 3 (development) supports Spring and is moving + towards OSGI.

    +

    It is recommended only for advanced users who are willing to accept that development is ongoing and that they may need to participate actively. Users are strongly recommended to subscribe to the server-dev @@ -109,12 +98,18 @@ Use of the latest stable release is recommended.

    Latest and Stable - James 2.3.2

    + +

    James 2 uses the Avalon framework. Avalon development + has now stopped but the framework is mature, stable and of proved production quality.

    +
      -
    • Is the latest official stable release and is available for download - here.
    • - Is a bug fix point release. - See release notes for details. + Is the latest official stable release and is available for download + here. +
      • +
    • + Is a bug fix point release. + See release notes for details.
    @@ -141,18 +136,18 @@
    -
    - -
    - +
    +
    - + @@ -174,7 +169,7 @@ - + @@ -182,7 +177,7 @@ - + @@ -191,22 +186,22 @@ - + - - + + - + @@ -215,8 +210,8 @@ - - + + @@ -231,24 +226,24 @@ - - + + - + - + - - + + @@ -262,7 +257,7 @@ - + @@ -270,7 +265,7 @@ - + @@ -278,7 +273,7 @@ - + @@ -287,38 +282,46 @@ - - + + - - + + - - + + - - + + - + + + + + + + + + @@ -326,7 +329,7 @@ - + @@ -334,7 +337,7 @@ - + @@ -342,7 +345,7 @@ - + @@ -350,7 +353,7 @@ - + @@ -374,7 +377,7 @@ - + @@ -382,7 +385,7 @@ - + @@ -401,7 +404,7 @@ -
    +

    See here

    diff --git a/project/src/site/site.xml b/project/src/site/site.xml index d36919f109d..aff67f28bc6 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -66,8 +66,8 @@ Don't display this as the build directory is no more updated. --> - - + + diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index c86ee7da328..c7e9b8d230c 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -1,160 +1,185 @@ + + Overview JAMES Project Web Team + -
    -
    - + +
    Item Status3.0 2.3.x3.0 Since First released
    IMAPOkayExperimental yes no 3.0
    LMTPExperimental no yes
    NNTP Experimentalno yesno 1.2 1.2
    TLS POP3/SMTP Experimentalyesyes 1.2 1.2
    Mailing ListExperimental yes yes
    FetchMail Stableyesyes 2.2 2.2
    Remote Manager Stableyesyes 1.0 1.0
    Management via JMXExperimental yes yes
    TLS Support Remote ManagerTLS Remote Manager Stableyesyes 1.2 1.2
    JDBC Database Mail StoreExperimental yes yes 1.2
    JPA Database Mail StoreExperimental no yes
    JCR (Jackrabbit) Database Mail StoreExperimental no yes
    JDBC Users Stableyesyes 1.2.1 1.2.1
    JPA Users Stablenoyes 1.2.1 1.2.1
    JCR Users Stablenoyes 1.2.1 1.2.1
    LDAP Users Experimentalyesyes 1.2 1.2
    Alternate User and Mail storesAlternate Mail storesExperimentalyesyes
    Alternate Mail storesExperimental yes yes
    Alternate QueueExperimental no yes
    Integration with SpamAssassinStable partial yes
    Run-as-service scriptsStable no yes
    Deployment in WEB containerExperimental no yes
    Monitoring via JMXExperimental yes yes
    IP V6Experimental no partial
    + +
    + +

    The Apache JAMES Project delivers a rich set of open source modules and libraries, written in Java, + related to internet mail and news which build into an advanced enterprise mail server.

    + +

    Apache projects are developed in an + open + collaborative manner. All + are welcome. We recommend that:

    - Read all the news in full in the News Archive
    - -
    - - - -
    -

    -The Apache JAMES Project delivers a rich set of open source modules and libraries, written in Java, -related to internet mail and news which build into an advanced enterprise mail server. -

    - -

    -Apache projects are developed in an -open -collaborative manner. All -are welcome. -

    -We recommend that -

    - -     -
    -
    - -

    - James Server is a stable, mature and production ready email server. -

    + +
    + +
    + +
    + + + +

    James Server is a stable, mature and + production ready email server.

    + +
      +
    • Is an advanced fully functioned integrated mail server
      • +
    • Is a mailet container, delegating to independent processing agents known as mailets
      • +
    • Is modular
      • +
    • Supports Spring and is moving towards OSGi
      • +
    • Supports the following protocols: + +
      • +
    + +

    Read more about the features.

    +     - -

    - Developers looking for a modular mail platform on which to build should start by - looking at the modules and libraries used to compose James Server 3.x. -

    -
      -
    • JAMES Server 3 -
        -
      • Is an advanced fully functioned integrated mail server
        • -
      • Is a mailet container, delegating to independent processing agents known as mailets
        • -
      • Is modular
        • -
      • Supports Spring and is moving towards OSGi
        • -
      • Retains the mature, production ready Apache Excalibur -components used by Avalon
        • -
      • Supports the following protocols: - -
        • -
      -
      • -
    • The Mailet subproject collects products -related to mailets (mail processing components analogous to servlets). These are independent of the -JAMES server and can be reused in any mailet container. -
        -
      • The Mailet API specifies mailets
        • -
      • The Mailet Basic Toolkit -collects utilities and lightweight frameworks useful for developing and testing mailets
        • -
      • Standard Mailets collects -general processing mailets with limited dependencies
        • -
      • Crypto Mailets collects -mailets which perform cryptographic processing such as signing, encrypting, -decrypting and signature verification.
        • -
      -
      • -
    • jSPF implements -SPF
      • -
    • jDKIM implements -DKIM
      • -
    • Mime4J parses MIME typed documents (including -- but not limited to - mail). APIs similar to DOM, SAX and pull parsers are exposed.
      • -
    • jSieve implements the -Sieve mail filtering language
      • -
    • Postage generates mail traffic suitable -for stress testing mail servers
      • -
    • MPT is a scripted functional test tool -suitable for testing mail protocols.
      • -
    + +     		+ + + +

    Developers looking for a modular mail platform on which to build should start by + looking at the modules and libraries used to compose James Server 3.0.

    + +

    The Mailet subproject collects products + related to mailets (mail processing components analogous to servlets). These are independent of the + JAMES server and can be reused in any mailet container.

    + +
      +
    • The Mailet API specifies mailets
      • +
    • The Mailet Basic Toolkit + collects utilities and lightweight frameworks useful for developing and testing mailets
      • +
    • Standard Mailets collects + general processing mailets with limited dependencies
      • +
    • Crypto Mailets collects + mailets which perform cryptographic processing such as signing, encrypting, + decrypting and signature verification.
      • +
    + +

    jSPF implements + SPF

    + +

    jDKIM implements + DKIM

    + +

    Mime4J parses MIME typed documents (including + - but not limited to - mail). APIs similar to DOM, SAX and pull parsers are exposed.

    + +

    jSieve implements the + Sieve mail filtering language

    + +

    Postage generates mail traffic suitable + for stress testing mail servers

    + +

    MPT is a scripted functional test tool + suitable for testing mail protocols.

    +     - - + +
    + +
    + +
    		+ + + +
    + + + From 78dba270cfcfb10229722f3a7036c707a5e5eea7 Mon Sep 17 00:00:00 2001 From: eric Date: Wed, 27 Oct 2010 09:25:26 +0000 Subject: [PATCH 208/541] Update menu for nighlty download,... git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027867 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index aff67f28bc6..96e63f7b1c5 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -38,7 +38,8 @@ - - - - - @@ -81,6 +72,19 @@ + + + + + + + From 89d16f0180755f4ff63e428e3ac8661fb597813c Mon Sep 17 00:00:00 2001 From: eric Date: Wed, 27 Oct 2010 09:25:49 +0000 Subject: [PATCH 209/541] JAMES is James git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027868 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/guidelines.xml | 26 ++++----- project/src/site/xdoc/newsarchive.xml | 80 +++++++++++++-------------- 2 files changed, 53 insertions(+), 53 deletions(-) diff --git a/project/src/site/xdoc/guidelines.xml b/project/src/site/xdoc/guidelines.xml index 099ab468256..5ba8a57cdc7 100644 --- a/project/src/site/xdoc/guidelines.xml +++ b/project/src/site/xdoc/guidelines.xml @@ -19,14 +19,14 @@ --> - Apache JAMES Project Guidelines + Apache James Project Guidelines James Project Web Team -
    +

    - This document defines the guidelines for the Apache JAMES Project. It includes definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the Apache JAMES products. + This document defines the guidelines for the Apache James Project. It includes definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the Apache James products.

    @@ -36,22 +36,22 @@

    - +

    - The group of volunteers who are responsible for managing the Apache JAMES Project. This includes deciding what is distributed as products of the Apache JAMES Project, maintaining the Project's shared resources, speaking on behalf of the Project, resolving license disputes regarding Apache JAMES products, nominating new PMC members or committers, and establishing these guidelines. + The group of volunteers who are responsible for managing the Apache James Project. This includes deciding what is distributed as products of the Apache James Project, maintaining the Project's shared resources, speaking on behalf of the Project, resolving license disputes regarding Apache James products, nominating new PMC members or committers, and establishing these guidelines.

    - Membership in the Apache JAMES PMC is by invitation only and must be approved by consensus of the active Apache JAMES PMC members. A PMC member is considered inactive by their own declaration or by not contributing in any form to the project for over six months. An inactive member can become active again by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the project's work). Membership can be revoked by a unanimous vote of all the active PMC members other than the member in question. + Membership in the Apache James PMC is by invitation only and must be approved by consensus of the active Apache James PMC members. A PMC member is considered inactive by their own declaration or by not contributing in any form to the project for over six months. An inactive member can become active again by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the project's work). Membership can be revoked by a unanimous vote of all the active PMC members other than the member in question.

    - +

    - The group of volunteers who are responsible for the technical aspects of the Apache JAMES Project. This group has write access to the appropriate source repositories and these volunteers may cast non-binding votes on any technical discussion. + The group of volunteers who are responsible for the technical aspects of the Apache James Project. This group has write access to the appropriate source repositories and these volunteers may cast non-binding votes on any technical discussion.

    - Membership as a Committer is by invitation only and must be approved by consensus of the active Apache JAMES PMC members. A Committer is considered inactive by their own declaration or by not contributing in any form to the project for over six months. An inactive member can become active again by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the project's work). Membership can be revoked by a unanimous vote of all the active PMC members (except the member in question if they are a PMC member). + Membership as a Committer is by invitation only and must be approved by consensus of the active Apache James PMC members. A Committer is considered inactive by their own declaration or by not contributing in any form to the project for over six months. An inactive member can become active again by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the project's work). Membership can be revoked by a unanimous vote of all the active PMC members (except the member in question if they are a PMC member).

    @@ -63,13 +63,13 @@

    - The Apache JAMES Project's private mailing list for discussion of issues that are inappropriate for public discussion, such as legal, personal, or security issues prior to a published fix. Subscription to the list is only open to Apache JAMES PMC members and Apache Software Foundation Members. + The Apache James Project's private mailing list for discussion of issues that are inappropriate for public discussion, such as legal, personal, or security issues prior to a published fix. Subscription to the list is only open to Apache James PMC members and Apache Software Foundation Members.

    - All of the Apache JAMES products are maintained in shared information repositories using SVN on svn.apache.org. The Apache committers have write access to these repositories; everyone has read access via anonymous SVN. + All of the Apache James products are maintained in shared information repositories using SVN on svn.apache.org. The Apache committers have write access to these repositories; everyone has read access via anonymous SVN.

    @@ -88,7 +88,7 @@

    - Any of the Apache JAMES Committers may vote on any issue or action item. However, the only binding votes are those cast by active members of the Apache James PMC; if the vote is about a change to source code or documentation, the primary author of what is being changed may also cast a binding vote on that issue. All other votes are non-binding. All committers are encouraged to participate in decisions, but the decision itself is made by those who have been long-time contributors to the project. In other words, the Apache Project is a minimum-threshold meritocracy. + Any of the Apache James Committers may vote on any issue or action item. However, the only binding votes are those cast by active members of the Apache James PMC; if the vote is about a change to source code or documentation, the primary author of what is being changed may also cast a binding vote on that issue. All other votes are non-binding. All committers are encouraged to participate in decisions, but the decision itself is made by those who have been long-time contributors to the project. In other words, the Apache Project is a minimum-threshold meritocracy.

    @@ -153,7 +153,7 @@

    - Changes to the Apache JAMES products, including code and documentation, will appear as action items under several categories corresponding to the change status: + Changes to the Apache James products, including code and documentation, will appear as action items under several categories corresponding to the change status:

    diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 0eda2dc4dde..de0800c9e45 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -2,7 +2,7 @@ News Archive - JAMES Project Web Team + James Project Web Team
    @@ -13,52 +13,52 @@

    Sep/2010 - Apache IMAP 0.2-M1 released

     -

    The Apache JAMES Project is pleased to announce a new +

    The Apache James Project is pleased to announce a new Apache IMAP release in preparation of the upcoming 3.0-M1 Apache Mail server.

    Sep/2010 - Apache protocols 1.2-M1 released

     -

    The Apache JAMES Project is pleased to announce a new +

    The Apache James Project is pleased to announce a new Apache protocols release in preparation of the upcoming 3.0-M1 Apache Mail server.

    Jun/2010 - Apache jSPF 0.9.8 released

     -

    The Apache JAMES Project is pleased to announce a new +

    The Apache James Project is pleased to announce a new Apache jSPF release which includes fixed to TXT record escaping and pass the rfc4408-tests-2009.10 testsuite.

    Jun/2010 - Apache Mailet Base 1.1 released

     -

    The Apache JAMES Project is pleased to announce a new +

    The Apache James Project is pleased to announce a new Apache Mailet Base release which fixes a NullPointerException when using MatcherInverter.

    May/2010 - Apache JSieve 0.4 released

     -

    The Apache JAMES Project is pleased to announce that the forth release of +

    The Apache James Project is pleased to announce that the forth release of Apache JSieve - an implementation of the Sieve mail filtering language - is now available for download.

    May/2010 - Apache Mailet Standard 1.0 released

     -

    The Apache JAMES Project is pleased to announce that the first independent release of - Apache Mailet Standard - was bundled with JAMES Server 2.3 before - +

    The Apache James Project is pleased to announce that the first independent release of + Apache Mailet Standard - was bundled with James Server 2.3 before - is now available for download.

    Oct/2009 - jDKIM joins Apache James as sub-project

    - The Apache JAMES project is pleased to announce the inclusion of a new sub-project called + The Apache James project is pleased to announce the inclusion of a new sub-project called jDKIM. - jDKIM is a DomainKeys Identified Mail (DKIM) implementation library written in Java. It provides both verification and signing and also provides Mailets for the Apache JAMES project. + jDKIM is a DomainKeys Identified Mail (DKIM) implementation library written in Java. It provides both verification and signing and also provides Mailets for the Apache James project.

    Sep/2009 - Hupa joins Apache James as sub-project

    - The Apache JAMES project is pleased to announce the inclusion of a new sub-project called + The Apache James project is pleased to announce the inclusion of a new sub-project called Hupa. Hupa is a GWT based webmail which use IMAP to connect to the backend mailserver.

    Aug/2009 - Apache James 2.3.2 Released

    - The Apache JAMES project is pleased to announce that Apache James 2.3.2 + The Apache James project is pleased to announce that Apache James 2.3.2 is now available. This is a minor bug fix release. @@ -67,7 +67,7 @@ for more details. Upgrading is recommended for users of previous 2.x releases.

    Jul/2009 - Apache MPT 0.1 released

     -

    The Apache JAMES project is pleased to announced that the first release of +

    The Apache James project is pleased to announced that the first release of Apache MPT - a functional testing library particularly suitable for line protocols based on ASCII - is now available. These @@ -76,11 +76,11 @@ for more details.

    Jun/2009 - Apache jSPF 0.9.7 released

     -

    The Apache JAMES Project is pleased to announce a new +

    The Apache James Project is pleased to announce a new Apache jSPF release which included some critical bug fixes.

    Jun/2009 - Apache JSieve 0.3 released

     -

    The Apache JAMES Project is pleased to announce that the third release of +

    The Apache James Project is pleased to announce that the third release of Apache JSieve - an implementation of the Sieve mail filtering language - is now available for download. This is the first @@ -89,14 +89,14 @@ for more details.

    May/2009 - Apache Crypto Mailets 1.0 released

     -

    The Apache JAMES Project is pleased to announce the first independent release of +

    The Apache James Project is pleased to announce the first independent release of Apache Cryptographic Mailets (previous versions were released as part of the Apache James Server). This package contains mailets which encode, decode, sign and verify mail plus cryptology utilities.

    Apr/2009 - Apache Mailet Base 1.0 released

     -

    The Apache JAMES Project is pleased to announce the first independent release of +

    The Apache James Project is pleased to announce the first independent release of Apache Mailet Base (previous versions were released as part of the Apache James Server). The Basic Mailet Toolkit @@ -110,7 +110,7 @@ stream parser is expected to be 50% faster when line counting is disabled. Please also note that as of this release Mime4j requires a Java 1.5 compatible runtime

    Feb/2009 - MailetDocs Maven Plugin 0.1 released

     -

    The Apache JAMES Project is pleased to announce the first release of the +

    The Apache James Project is pleased to announce the first release of the plugin for . The plugin catalogs mailet (for example). @@ -118,7 +118,7 @@ release notes.

    Jan/2009 - Apache Mailet 2.4 released

     -

    The Apache JAMES Project is pleased to announce the first independent release of +

    The Apache James Project is pleased to announce the first independent release of Apache Mailet (previous versions were released as part of the Apache James Server). The Mailet API @@ -130,7 +130,7 @@

    We are proud to announce the availability of APACHE Mime4j-0.5. This release addresses a number of important issues discovered since 0.4. In particular, it improves Mime4j ability to deal with malformed data streams including those intentionally crafted to cause excessive CPU and memory utilization that can lead to DoS condition

    This release also fixes a serious bug that can prevent Mime4j from correctly processing binary content

    Aug/2008 - Apache JSieve 0.2 released

     -

    The Apache JAMES Project is pleased to announce the first public release of +

    The Apache James Project is pleased to announce the first public release of Apache JSieve an implementation of RFC3028 - Sieve: A Mail Filtering Language for Java. @@ -161,15 +161,15 @@

    Sept/2007 - jSPF-0.9.5 released

    We are proud to announce the availability of APACHE jSPF-0.9.5. This release brings initial support for asynchronous processing and is fully RFC4408 compliant.

    May/2007 - Apache Mime4J 0.3 Final Released

     -

    After almost 2 years the Apache JAMES team is proud to announce the availability of Apache Mime4J 0.3. This is the first release under the ASF umbrella.

    +

    After almost 2 years the Apache James team is proud to announce the availability of Apache Mime4J 0.3. This is the first release under the ASF umbrella.

    May/2007 - Mailet API sub-project lives

     -

    Following a decision taken by the James PMC a few months ago, the Apache Mailet API project is now independent of JAMES Server and has its own webpage and its own source repository.

    -

    Apr/2007 - JAMES Server 2.3.1 Final Released

    -

    James PMC is proud to announce the availability of the final release of JAMES Server 2.3.1. More informations on what has been fixed since the 2.3.0 release can be found in the changelog.

    -

    Apr/2007 - JAMES Server 2.3.1 RC1 released

     -

    James PMC is proud to announce the availability of the first release candidate of JAMES Server 2.3.1. This release is maintenance release. See the changelog for more detail.

    -

    Apr/2007 - Apache JAMES Project Guidelines published

     -

    The James PMC has approved - for the first time - a set of guidelines for the project. These guidelines are intended to reflect and summarize well-known practices in our community. They include "... definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the Apache JAMES products."

    +

    Following a decision taken by the James PMC a few months ago, the Apache Mailet API project is now independent of James Server and has its own webpage and its own source repository.

    +

    Apr/2007 - James Server 2.3.1 Final Released

    +

    James PMC is proud to announce the availability of the final release of James Server 2.3.1. More informations on what has been fixed since the 2.3.0 release can be found in the changelog.

    +

    Apr/2007 - James Server 2.3.1 RC1 released

     +

    James PMC is proud to announce the availability of the first release candidate of James Server 2.3.1. This release is maintenance release. See the changelog for more detail.

    +

    Apr/2007 - Apache James Project Guidelines published

     +

    The James PMC has approved - for the first time - a set of guidelines for the project. These guidelines are intended to reflect and summarize well-known practices in our community. They include "... definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the Apache James products."

    Feb/2007 - jSPF-0.9b4 released

    James PMC is proud to announce the availability of the fourth beta of jspf 0.9. This version pass all tests in the last official release of the spf testsuite.

    Feb/2007 - Feathercast features James

     @@ -182,25 +182,25 @@

    -

    Oct/2006 - JAMES Server 2.3.0 Final Released

    -

    James PMC is proud to announce the availability of the long awaited final release of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

    +

    Oct/2006 - James Server 2.3.0 Final Released

    +

    James PMC is proud to announce the availability of the long awaited final release of James Server 2.3.0. More informations on what's new can be found in the changelog.

    Sep/2006 - jSPF 0.9 b3 Released

    James PMC is proud to announce the availability of the third beta of jspf 0.9. This version has start to use the official spf testsuite to fix all rfc issues.

    -

    Aug/2006 - JAMES Server 2.3.0 RC3 Released

    -

    James PMC is proud to announce the availability of the third, and hopefully last, release candidate of JAMES Server 2.3.0. More informations on what's new can be found in the changelog.

    +

    Aug/2006 - James Server 2.3.0 RC3 Released

    +

    James PMC is proud to announce the availability of the third, and hopefully last, release candidate of James Server 2.3.0. More informations on what's new can be found in the changelog.

    New development roadmaps are being discussed right now, so stay tuned for 2.3.0 final and for the following news. - Sep/2006

    -

    Aug/2006 - JAMES Products website revamped

    +

    Aug/2006 - James Products website revamped

    We just finished a major update of james products to be able to publish each product specific site under this new website structure

    -

    Jul/2006 - JAMES Server 2.3.0 on the way

    -

    After a long time of development we have released the first release candidate of JAMES Server 2.3.0. After a period of user testing version 2.3.0 will be released.

    -

    Jul/2006 - New project JAMES jSPF

    -

    JAMES PMC is happy to announce that we are working on a Java implementation of the SPF specification. The first betas are already available for download.

    +

    Jul/2006 - James Server 2.3.0 on the way

    +

    After a long time of development we have released the first release candidate of James Server 2.3.0. After a period of user testing version 2.3.0 will be released.

    +

    Jul/2006 - New project James jSPF

    +

    James PMC is happy to announce that we are working on a Java implementation of the SPF specification. The first betas are already available for download.

     -

    JAMES PMC react to the closure of Apache Avalon.

    -

    JAMES PMC would like to reassure all of our users that JAMES Server is alive and well. All of the James team have kept abreast of the Avalon developments culminating in the closure of the Avalon project and dispersal of its codebase. We are are keen to stress that this has little impact on our ability to support and develop Server in both the short and long terms.
    Over the coming months we will be finalising and publishing a road map for JAMES Server which will address all of the specific concerns raised by Avalon's closure, but rest assured JAMES Server' future is safe, and we have enthusiasm and plans aplenty.
    In the meantime we would like to extend our best wishes to all our friends from Avalon, here's luck with your future projects guys!
    If you are at all concerned please subscribe to the server-user mailing list and raise your points there. - 05/Jan/2005

    +

    James PMC react to the closure of Apache Avalon.

    +

    James PMC would like to reassure all of our users that James Server is alive and well. All of the James team have kept abreast of the Avalon developments culminating in the closure of the Avalon project and dispersal of its codebase. We are are keen to stress that this has little impact on our ability to support and develop Server in both the short and long terms.
    Over the coming months we will be finalising and publishing a road map for James Server which will address all of the specific concerns raised by Avalon's closure, but rest assured James Server' future is safe, and we have enthusiasm and plans aplenty.
    In the meantime we would like to extend our best wishes to all our friends from Avalon, here's luck with your future projects guys!
    If you are at all concerned please subscribe to the server-user mailing list and raise your points there. - 05/Jan/2005

    -

    JAMES product sources have moved to "Subversion"

    +

    James product sources have moved to "Subversion"

    Subversion is a version control system like CVS, but it has advantages over CVS for Apache Software Foundation (ASF) projects.
    In common with all other ASF projects we have reviewed our use of CVS and migrated our code to Subversion.
    Have a look at this FAQ for further details. - 05/Jan/2005

    From ed7efab2bda1c7dc8366ecb970e75425d2814a19 Mon Sep 17 00:00:00 2001 From: eric Date: Wed, 27 Oct 2010 09:26:06 +0000 Subject: [PATCH 210/541] Add reference to snapshot download. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027869 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 872 +++++++++++++++-------------- 1 file changed, 448 insertions(+), 424 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index e8e6cda4ea3..bdc4311c616 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -18,436 +18,460 @@ under the License. --> + Apache James Mail Server Project Download + -

    - -

    Use the links below to download the product from one of -our mirrors. You must verify the -integrity of the downloaded files using signatures downloaded from -our main distribution directory.

    - -

    Only current recommended releases are available on the main -distribution site and its mirrors. Older releases are available from -the archive download -site.

    - - - - - -

    [if-any logo] -[end] -The currently selected mirror is [preferred]. If you encounter a -problem with this mirror, please select another mirror. If all -mirrors are failing, there are backup mirrors (at the end of -the mirrors list) that should be available.

    - -
    -Other mirrors: - -
    - -

    You may also consult the complete -list of mirrors.

    - -     - - -

    It is essential that you verify the integrity of the downloaded -files using the PGP or MD5 signatures.

    - -

    The PGP signatures can be verified using PGP or GPG. First -download the KEYS -as well as the asc signature file for the particular -distribution. Make sure you get these files from the main distribution -directory, rather than from a mirror. Then verify the signatures -using

    - -

    -% pgpk -a KEYS
    -% pgpv james-version.tar.gz.asc
    -     -or
    - -% pgp -ka KEYS
    -% pgp james-version.tar.gz.asc
    -     -or
    - -% gpg --import KEYS
    -% gpg --verify james-version.tar.gz.asc -

    - -     -
    - -
    - - -

    This release has many enhancements and bug fixes over the previous -release. See the Release Notes -for a detailed list of changes. Some of the earlier defects could -turn a JAMES mail server into an Open Relay. All users of JAMES Server are urged to upgrade to version v2.3.1 as soon as -possible.

    - - - - -

    -Are now archived. -

    -     -     -
    - -
    -

    Apache Mime4J 0.6 is the latest stable version:

    - - -
    - -
    -

    Apache James jSPF 0.9.8 is the latest jSPF stable version:

    - - -
    -
    -

    Apache JSieve 0.4 is the latest stable version:

    - - -
    - -
    -

    Apache Mailet 2.4 is the latest stable version:

    - - -
    - -
    -

    Apache Mailet Base 1.1 is the latest stable version:

    - - -
    - -
    -

    Apache Mailet Standard 1.0 is the latest stable version:

    - - -
    - -
    -

    Apache Crypto Mailets 1.0 is the latest stable version:

    - -
    - -
    -

    Apache MPT 0.1 is the latest stable version:

    - -
    - -
    - -

    The software listed above represents the latest Release Build -available from the Apache JAMES Project.

    - -

    The JAMES project also provides -Nighly Builds: -periodic snapshots during development. Generally, these are considered -stable snapshots, but they have not undergone as much testing as a -Release Build, nor have they been voted upon for release by the -developer community. These are simply convenient test builds. -Sometimes the purpose for a Nightly Build could be soliciting feedback on -a specific change.

    - - -
    +
    + +

    Use the links below to download the product from one of + our mirrors. You must verify the + integrity of the downloaded files using signatures downloaded from + our main distribution directory.

    + +

    Only current recommended releases are available on the main + distribution site and its mirrors. Older releases are available from + the archive download + site.

    + + + +

    (*) James maven repositories can be found on + https://repository.apache.org/content/repositories/releases/org/apache/james/.

    + + + +

    [if-any logo] + [end] + The currently selected mirror is [preferred]. If you encounter a + problem with this mirror, please select another mirror. If all + mirrors are failing, there are backup mirrors (at the end of + the mirrors list) that should be available.

    + +
    + Other mirrors: + +
    + +

    You may also consult the complete + list of mirrors.

    + +     + + +

    It is essential that you verify the integrity of the downloaded + files using the PGP or MD5 signatures.

    + +

    The PGP signatures can be verified using PGP or GPG. First + download the KEYS + as well as the asc signature file for the particular + distribution. Make sure you get these files from the main distribution + directory, rather than from a mirror. Then verify the signatures + using

    + +

    + % pgpk -a KEYS
    + % pgpv james-version.tar.gz.asc
    +     + or
    + + % pgp -ka KEYS
    + % pgp james-version.tar.gz.asc
    +     + or
    + + % gpg --import KEYS
    + % gpg --verify james-version.tar.gz.asc +

    + +     + +
    + +
    + + + +

    This release has many enhancements and bug fixes over the previous + release. See the Release Notes + for a detailed list of changes. Some of the earlier defects could + turn a James mail server into an Open Relay. All users of James Server are urged to upgrade to version v2.3.1 as soon as + possible.

    + + + + +

    Are now archived

    +     + +     + +
    + +
    + +

    Apache Mime4J 0.6 is the latest stable version:

    + + +
    + +
    + +

    Apache James jSPF 0.9.8 is the latest jSPF stable version:

    + + +
    + +
    + +

    Apache JSieve 0.4 is the latest stable version:

    + + +
    + +
    + +

    Apache Mailet 2.4 is the latest stable version:

    + + +
    + +
    + +

    Apache Mailet Base 1.1 is the latest stable version:

    + + +
    + +
    + +

    Apache Mailet Standard 1.0 is the latest stable version:

    + + +
    + +
    + +

    Apache Crypto Mailets 1.0 is the latest stable version:

    + + +
    + +
    + +

    Apache MPT 0.1 is the latest stable version:

    + + +
    + +
    + +

    The software listed above represents the latest Release Build + available from the Apache James Project.

    + +

    The James project also provides + Nighly Builds: + periodic snapshots during development. Generally, these are considered + stable snapshots, but they have not undergone as much testing as a + Release Build, nor have they been voted upon for release by the + developer community. These are simply convenient test builds. + Sometimes the purpose for a Nightly Build could be soliciting feedback on + a specific change.

    + +

    James continous integration can be found on + Hudson.

    + +
    +     From 8d9b258042688a6548f61a6e324601b556801f0f Mon Sep 17 00:00:00 2001 From: eric Date: Wed, 27 Oct 2010 09:26:30 +0000 Subject: [PATCH 211/541] Format and content review (column, 3.0,...) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027870 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 98 ++++++++++++++++----------------- 1 file changed, 46 insertions(+), 52 deletions(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index c7e9b8d230c..2a5481716f3 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -4,7 +4,7 @@ Overview - JAMES Project Web Team + James Project Web Team @@ -13,17 +13,13 @@
    -

    The Apache JAMES Project delivers a rich set of open source modules and libraries, written in Java, +

    The Apache James Project delivers a rich set of open source modules and libraries, written in Java, related to internet mail and news which build into an advanced enterprise mail server.

    Apache projects are developed in an - open - collaborative manner. All - are welcome. We recommend that:

    - + open and + collaborative manner. + All are welcome! We recommend that Users, Developers, Curious and Fans subscribe to the James mailing lists.

    @@ -31,43 +27,51 @@
    - - -

    James Server is a stable, mature and - production ready email server.

    + -
      -
    • Is an advanced fully functioned integrated mail server
      • -
    • Is a mailet container, delegating to independent processing agents known as mailets
      • -
    • Is modular
      • -
    • Supports Spring and is moving towards OSGi
      • -
    • Supports the following protocols: +

      James Server 3.0 and 2.3.2 are integrated email server with advanced fully functional features.

      + +

      James 3.0 provides a mailet container, delegating to independent processing agents known as mailets. + It benefits from modular architecture, is built on Spring and is moving towards OSGi. + It supports the following protocols:

      + -
      • -
    + (see the IMAP sub-project, only with James 3.0) +
  • Sieve filtering into mailboxes for incoming mail.
    • +
  • Fetchmail from POP3 and IMAP accounts.
    • +
  • + NNTP (better known as news, only with James 2.3.2)
    • + -

    Read more about the features.

    +

    Read more about the complete features of James 3.0 and + on the stable, mature and production ready James 2.3.2.

    + +

    You can also try the Hupa WEB-mail solution to give access + from any browser to IMAP mailboxes (hosted by James Server or any other IMAP Server).

         		- +

    Developers looking for a modular mail platform on which to build should start by looking at the modules and libraries used to compose James Server 3.0.

    +

    IMAP iproviding a flexible codec for IMAP, + command processors and a sample data access layer. In combination with a socket layer, + this library can be used to create an IMAP server.

    +

    The Mailet subproject collects products related to mailets (mail processing components analogous to servlets). These are independent of the - JAMES server and can be reused in any mailet container.

    + James server and can be reused in any mailet container.

    • The Mailet API specifies mailets
      • @@ -80,24 +84,30 @@ decrypting and signature verification.
    -

    jSPF implements - SPF

    - -

    jDKIM implements - DKIM

    - +

    Protocols project delivers a lightweight, + and highly extensible framework for mail protocols implementations.

    + +

    Mailbox is a flexible Mailbox storage + accessible by mail (imap, pop3, smtp,...) and other protocols..

    +

    Mime4J parses MIME typed documents (including - but not limited to - mail). APIs similar to DOM, SAX and pull parsers are exposed.

    +

    jSPF implements + SPF

    +

    jSieve implements the Sieve mail filtering language

    -

    Postage generates mail traffic suitable - for stress testing mail servers

    +

    jDKIM implements + DKIM

    MPT is a scripted functional test tool suitable for testing mail protocols.

    +

    Postage generates mail traffic suitable + for stress testing mail servers

    +
    @@ -128,11 +138,11 @@
  • Oct/2009 -
  • Sep/2009 -
  • Aug/2009 -
    • -
  • Apr/2009 - -
    • -
  • Mar/2009 - -
    • -
  • Feb/2009 - -
    • -
  • Jan/2009 - -
    • Read all the news in full in the News Archive
    From 196494e8d6eb696c2aa3a132c020610ff362f644 Mon Sep 17 00:00:00 2001 From: eric Date: Wed, 27 Oct 2010 09:27:02 +0000 Subject: [PATCH 212/541] Move some 2.3.x from menu to archive page. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027871 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/site.xml | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/project/server/src/site/site.xml b/project/server/src/site/site.xml index 3857769ac5a..48a9098cd27 100644 --- a/project/server/src/site/site.xml +++ b/project/server/src/site/site.xml @@ -49,11 +49,8 @@ --> - - - - - + + From be6e69412f6c1363537772a91a9c0b6f6258622d Mon Sep 17 00:00:00 2001 From: eric Date: Wed, 27 Oct 2010 09:27:16 +0000 Subject: [PATCH 213/541] Format and content review (column, 3.0,...) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1027872 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 94 +++++++++++--------------- 1 file changed, 41 insertions(+), 53 deletions(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index 0a29b8a5d3e..85ff6fc62d2 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -32,7 +32,8 @@
    -

    Is 100% pure JAVA capable Mail Server running on Java 1.5 onwards. James integrates emailing protocols such as:

    +

    Apache James Server is a 100% pure JAVA capable Mail Server running on Java 1.5 onwards. + James integrates emailing protocols such as:

    • @@ -43,22 +44,20 @@
    • IMAP (James 3)
    • Sieve - filtering into mailboxes for incoming mail
      • + filtering into mailboxes for incoming mail.
    • FetchMail from POP3 and IMAP accounts.
    • NNTP (better known as news) - only in 2.3., support is discontinuated in 3.0.
    -

    Is a mailet container: the email processing is delegated to independent, extensible, pluggable agents +

    James Server provides a mailet container: the email processing is delegated to independent, extensible, pluggable agents specified by the Mailet API. Any function which is not already available (from James or from a third party) can be developed.

    -

    Is a modular, component based Inversion of Control - mail platform.

    - -

    Is based on open technical standards.

    +

    James Server's architecture is modular, component based and offers a Inversion of Control + mail platform. All developments and implementations are based on open technical standards.

    @@ -68,11 +67,11 @@ -
      -
    • Is a proposed milestone release allowing a preview of the James 3.0 features
      • -
    • Feedback welcomed either through the mailing lists - or JIRA.
      • -
    +

    James 3.0 Milestone 1 is a proposed milestone release allowing a preview of the James 3.0 features. + We strongly encourage to download and test it.

    + +

    Feedback welcomed either through the mailing lists + or JIRA.

     @@ -80,10 +79,9 @@

    The James 3 code base has many new features - and major revisions to the architecture are ongoing

    - -

    James 3 (development) supports Spring and is moving - towards OSGI.

    + and major revisions compared to the 2.3.x architecture have been implemented. + James 3 (development) + supports Spring and is moving towards OSGI.

    It is recommended only for advanced users who are willing to accept that development is ongoing and that they may need to participate actively. @@ -92,26 +90,16 @@ - + -

    James 2 is a mature, production ready code stream with minimal development. - Use of the latest stable release is recommended.

    - -

    Latest and Stable - James 2.3.2

    - -

    James 2 uses the Avalon framework. Avalon development - has now stopped but the framework is mature, stable and of proved production quality.

    - -
      -
    • - Is the latest official stable release and is available for download - here. -
      • -
    • - Is a bug fix point release. - See release notes for details. -
      • -
    +

    James 2.3.2 is a mature, production ready code stream with minimal development. + Use of the previous stable James 2.3.2 release is recommended. James 2.3.2 uses the Avalon framework. Avalon development + has now stopped but the framework is mature, stable and of proved production quality.

    + +

    James 2.3.2 is still the official stable release and is available for download + here. + James 3.0 will soon replace 2.3.2 as recommended release. + See also the release notes for details on 2.3.2 bug fixes.

    | | ######### + | Queue |<># Mail # + TCP port 25 | Manager | # Queue # + <----------------------| | ######### + +-----------------+ + Local * ^ Local * Local + IPC * | IPC * IPC + * | * + * | * + * | * + V | V + Non-SMTP +----------+ +----------+ + Protocol | Gateway | | Local | ######### + <==============>| Delivery | | Delivery |>># Mail # + | Agent | | Agent | # Spool # + +----------+ +----------+ ######### + + + The host's mail system has three independent, communicating + subsystems. The first is a queue manager, which acts as a + + + +Myers Informational [Page 2] + +RFC 2033 LMTP October 1996 + + + traditional SMTP agent, transferring messages to and from other hosts + over TCP and managing a mail queue in persistent storage. The other + two are agents which handle delivery for addresses in domains for + which the host takes responsibility. One agent performs gatewaying + to and from some other mail system. The other agent delivers the + message into a persistent mail spool. + + It would be desirable to use SMTP over a local inter-process + communication channel to transfer messages from the queue manager to + the delivery agents. It would, however, significantly increase the + complexity of the delivery agents to require them to manage their own + mail queues. + + The common practice of invoking a delivery agent with the envelope + address(es) as command-line arguments, then having the delivery agent + communicate status with an exit code has three serious problems: the + agent can only return one exit code to be applied to all recipients, + it is difficult to extend the interface to deal with ESMTP extensions + such as DSN [DSN] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES], and + exits performed by system libraries due to temporary conditions + frequently get interpreted as permanent errors. + + The LMTP protocol causes the server to return, after the final "." of + the DATA command, one reply for each recipient. Therefore, if the + queue manager is configured to use LMTP instead of SMTP when + transferring messages to the delivery agents, then the delivery + agents may attempt delivery to each recipient after the final "." and + individually report the status for each recipient. Connections which + should use the LMTP protocol are drawn in the diagram above using + asterisks. + + Note that it is not beneficial to use the LMTP protocol when + transferring messages to the queue manager, either from the network + or from a delivery agent. The queue manager does implement a mail + queue, so it may store the message and take responsibility for later + delivering it. + +4. The LMTP protocol + + The LMTP protocol is identical to the SMTP protocol SMTP [SMTP] + [HOST-REQ] with its service extensions [ESMTP], except as modified by + this document. + + A "successful" RCPT command is defined as an RCPT command which + returns a Positive Completion reply code. + + A "Positive Completion reply code" is defined in Appendix E of STD + 10, RFC 821 [SMTP] as a reply code which "2" as the first digit. + + + +Myers Informational [Page 3] + +RFC 2033 LMTP October 1996 + + +4.1. The LHLO, HELO and EHLO commands + + The HELO and EHLO commands of ESMTP are replaced by the LHLO command. + This permits a misconfiguration where both parties are not using the + same protocol to be detected. + + The LHLO command has identical semantics to the EHLO command of ESMTP + [ESMTP]. + + The HELO and EHLO commands of ESMTP are not present in LMTP. A LMTP + server MUST NOT return a Postive Completion reply code to these + commands. The 500 reply code is recommended. + +4.2. The DATA command + + In the LMTP protocol, there is one additional restriction placed on + the DATA command, and one change to how replies to the final "." are + sent. + + The additional restriction is that when there have been no successful + RCPT commands in the mail transaction, the DATA command MUST fail + with a 503 reply code. + + The change is that after the final ".", the server returns one reply + for each previously successful RCPT command in the mail transaction, + in the order that the RCPT commands were issued. Even if there were + multiple successful RCPT commands giving the same forward-path, there + must be one reply for each successful RCPT command. + + When one of these replies to the final "." is a Positive Completion + reply, the server is accepting responsibility for delivering or + relying the message to the corresponding recipient. It must take + this responsibility seriously, i.e., it MUST NOT lose the message for + frivolous reasons, e.g., because the host later crashes or because of + a predictable resource shortage. + + A multiline reply is still considered a single reply and corresponds + to a single RCPT command. + + EXAMPLE: + + S: 220 foo.edu LMTP server ready + C: LHLO foo.edu + S: 250-foo.edu + S: 250-PIPELINING + S: 250 SIZE + C: MAIL FROM: + S: 250 OK + + + +Myers Informational [Page 4] + +RFC 2033 LMTP October 1996 + + + C: RCPT TO: + S: 250 OK + C: RCPT TO: + S: 550 No such user here + C: RCPT TO: + S: 250 OK + C: DATA + S: 354 Start mail input; end with . + C: Blah blah blah... + C: ...etc. etc. etc. + C: . + S: 250 OK + S: 452 is temporarily over quota + C: QUIT + S: 221 foo.edu closing connection + + +NOTE: in the above example, the domain names of both the client and + server are identical. This is because in the example the client and + server are different subsystems of the same mail domain. + +4.3. The BDAT command + + If the server supports the ESMTP CHUNKING extension [BINARYMIME], a + BDAT command containing the LAST parameter returns one reply for each + previously successful RCPT command in the mail transaction, in the + order that the RCPT commands were issued. Even if there were + multiple successful RCPT commands giving the same forward-path, there + must be one reply for each successful RCPT command. If there were no + previously successful RCPT commands in the mail transaction, then the + BDAT LAST command returns zero replies. + + When one of these replies to the BDAT LAST command is a Positive + Completion reply, the server is accepting responsibility for + delivering or relaying the message to the corresponding recipient. + It must take this responsibility seriously, i.e., it MUST NOT lose + the message for frivolous reasons, e.g., because the host later + crashes or because of a predictable resource shortage. + + A multiline reply is still considered a single reply and corresponds + to a single RCPT command. + + The behavior of BDAT commands without the LAST parameter is not + changed; they still return exactly one reply. + + + + + + + +Myers Informational [Page 5] + +RFC 2033 LMTP October 1996 + + +5. Implementation requirements + + As LMTP is a different protocol than SMTP, it MUST NOT be used on the + TCP service port 25. + + A server implementation MUST implement the PIPELINING [PIPELINING] + and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions. A + server implementation SHOULD implement the 8BITMIME [8BITMIME] + extension. + + Use of LMTP can aggravate the situation described in [DUP-MSGS]. To + avoid this synchronization problem, the following requirements are + made of implementations: + + A server implementation which is capable of quickly accepting + responsibility for delivering or relaying a message to multiple + recipients and which is capable of sending any necessary notification + messages SHOULD NOT implement the LMTP protocol. + + The LMTP protocol SHOULD NOT be used over wide area networks. + + The server SHOULD send each reply as soon as possible. If it is + going to spend a nontrivial amount of time handling delivery for the + next recipient, it SHOULD flush any outgoing LMTP buffer, so the + reply may be quickly received by the client. + + The client SHOULD process the replies as they come in, instead of + waiting for all of the replies to arrive before processing any of + them. If the connection closes after replies for some, but not all, + recipients have arrived, the client MUST process the replies that + arrived and treat the rest as temporary failures. + +6. Acknowledgments + + This work is a refinement of the MULT extension, which was invented + by Jeff Michaud and was used in implementing gateways to the Mail-11 + mail system. + + Many thanks to Matt Thomas for assisting me in understanding the + semantics of the Mail-11 MULT extension. + + + + + + + + + + + +Myers Informational [Page 6] + +RFC 2033 LMTP October 1996 + + +7. References + + [8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-MIME + transport", RFC 1652, July 1994. + + [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission + of Large and Binary MIME Messages", RFC 1830, August 1995. + + [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, January 1996. + + [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047, + February 1988. + + [ENHANCEDSTATUSCODES] Freed, N., "SMTP Service Extension for + Returning Enhanced Error Codes", RFC 2034, October 1996. + + [ESMTP] Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, N., + "SMTP Service Extensions", RFC 1869, November 1995. + + [HOST-REQ] Braden, R., "Requirements for Internet hosts - application + and support", STD 3, RFC 1123 section 5, October 1989. + + [PIPELINING] Freed, N., Cargille, A, "SMTP Service Extension for + Command Pipelining", RFC 1854, October 1995. + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + August 1982. + + + There are no known security issues with the issues in this memo. + +9. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + EMail: jgm+@cmu.edu + + + + + + + + + + + +Myers Informational [Page 7] + diff --git a/project/server/src/site/xdoc/archive/document_archive.xml b/project/server/src/site/xdoc/archive/document_archive.xml index d7e429d09af..7eeceea9b84 100644 --- a/project/server/src/site/xdoc/archive/document_archive.xml +++ b/project/server/src/site/xdoc/archive/document_archive.xml @@ -39,9 +39,9 @@ users to upgrade to the current Release Build of James.

      -
    • Server 2.3.1 Documentation
      • -
    • Server 2.3.0 Documentation
      • -
    • Server 2.2.0 Documentation
      • +
    • Server 2.3.1 Documentation
      • +
    • Server 2.3.0 Documentation
      • +
    • Server 2.2.0 Documentation
    • Announcement (version 2.1)
    • Install (version 2.0)
    • Configuration (version 2.0)
      • diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index 85ff6fc62d2..85b028a33af 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -37,18 +37,19 @@
      • - SMTP
        • -
      • LMTP
        • + SMTP. +
      • + LMTP (only with Server V3).
      • POP3
      • - IMAP (James 3)
        • + IMAP (only with Server V3).
      • Sieve filtering into mailboxes for incoming mail.
      • FetchMail from POP3 and IMAP accounts.
      • NNTP (better known as news) - - only in 2.3., support is discontinuated in 3.0.
        • + (only with Server V2, support is discontinuated in Server V3).

      James Server provides a mailet container: the email processing is delegated to independent, extensible, pluggable agents @@ -75,31 +76,32 @@ - + -

      The James 3 code base has many - new features +

      The James 3 code base has many + new features and major revisions compared to the 2.3.x architecture have been implemented. - James 3 (development) + James 3 (development) supports Spring and is moving towards OSGI.

      It is recommended only for advanced users who are willing to accept that development is ongoing and that they may need to participate actively. Users are strongly recommended to subscribe to the server-dev - mailing list.

      + mailing list.

      James 2.3.2 is a mature, production ready code stream with minimal development. - Use of the previous stable James 2.3.2 release is recommended. James 2.3.2 uses the Avalon framework. Avalon development - has now stopped but the framework is mature, stable and of proved production quality.

      - -

      James 2.3.2 is still the official stable release and is available for download + James 2.3.2 is still the official stable release and is available for download here. - James 3.0 will soon replace 2.3.2 as recommended release. - See also the release notes for details on 2.3.2 bug fixes.

      + James 3.0 will soon replace 2.3.2 as recommended release.

      + +

      James 2.3.2 uses the Avalon framework. Avalon + development has now stopped but the framework is mature, stable and of proved production quality. + See also the release notes for details on + 2.3.2 bug fixes.

      +

      Tabs

      +
      + +
      Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
      +
      Phasellus mattis tincidunt nibh. Cras orci urna, blandit id, pretium vel, aliquet ornare, felis. Maecenas scelerisque sem non nisl. Fusce sed lorem in enim dictum bibendum.
      +
      Nam dui erat, auctor a, dignissim quis, sollicitudin eu, felis. Pellentesque nisi urna, interdum eget, sagittis et, consequat vestibulum, lacus. Mauris porttitor ullamcorper augue.
      +
      + + + +

      Framework Icons (content color preview)

      +
        + +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • +
        • + +
        • +
        • +
        • +
        • +
        • +
      + + + +

      Highlight / Error

      +
      +
      +

      + Hey! Sample ui-state-highlight style.

      +
      +
      +
      +
      +
      +

      + Alert: Sample ui-state-error style.

      +
      +
      + + + + + diff --git a/maven-skin/src/main/resources/js/jquery/js/jquery-1.4.2.min.js b/maven-skin/src/main/resources/js/jquery/js/jquery-1.4.2.min.js new file mode 100644 index 00000000000..7c243080233 --- /dev/null +++ b/maven-skin/src/main/resources/js/jquery/js/jquery-1.4.2.min.js @@ -0,0 +1,154 @@ +/*! + * jQuery JavaScript Library v1.4.2 + * http://jquery.com/ + * + * Copyright 2010, John Resig + * Dual licensed under the MIT or GPL Version 2 licenses. + * http://jquery.org/license + * + * Includes Sizzle.js + * http://sizzlejs.com/ + * Copyright 2010, The Dojo Foundation + * Released under the MIT, BSD, and GPL Licenses. + * + * Date: Sat Feb 13 22:33:48 2010 -0500 + */ +(function(A,w){function ma(){if(!c.isReady){try{s.documentElement.doScroll("left")}catch(a){setTimeout(ma,1);return}c.ready()}}function Qa(a,b){b.src?c.ajax({url:b.src,async:false,dataType:"script"}):c.globalEval(b.text||b.textContent||b.innerHTML||"");b.parentNode&&b.parentNode.removeChild(b)}function X(a,b,d,f,e,j){var i=a.length;if(typeof b==="object"){for(var o in b)X(a,o,b[o],f,e,d);return a}if(d!==w){f=!j&&f&&c.isFunction(d);for(o=0;o)[^>]*$|^#([\w-]+)$/,Ua=/^.[^:#\[\.,]*$/,Va=/\S/, +Wa=/^(\s|\u00A0)+|(\s|\u00A0)+$/g,Xa=/^<(\w+)\s*\/?>(?:<\/\1>)?$/,P=navigator.userAgent,xa=false,Q=[],L,$=Object.prototype.toString,aa=Object.prototype.hasOwnProperty,ba=Array.prototype.push,R=Array.prototype.slice,ya=Array.prototype.indexOf;c.fn=c.prototype={init:function(a,b){var d,f;if(!a)return this;if(a.nodeType){this.context=this[0]=a;this.length=1;return this}if(a==="body"&&!b){this.context=s;this[0]=s.body;this.selector="body";this.length=1;return this}if(typeof a==="string")if((d=Ta.exec(a))&& +(d[1]||!b))if(d[1]){f=b?b.ownerDocument||b:s;if(a=Xa.exec(a))if(c.isPlainObject(b)){a=[s.createElement(a[1])];c.fn.attr.call(a,b,true)}else a=[f.createElement(a[1])];else{a=sa([d[1]],[f]);a=(a.cacheable?a.fragment.cloneNode(true):a.fragment).childNodes}return c.merge(this,a)}else{if(b=s.getElementById(d[2])){if(b.id!==d[2])return T.find(a);this.length=1;this[0]=b}this.context=s;this.selector=a;return this}else if(!b&&/^\w+$/.test(a)){this.selector=a;this.context=s;a=s.getElementsByTagName(a);return c.merge(this, +a)}else return!b||b.jquery?(b||T).find(a):c(b).find(a);else if(c.isFunction(a))return T.ready(a);if(a.selector!==w){this.selector=a.selector;this.context=a.context}return c.makeArray(a,this)},selector:"",jquery:"1.4.2",length:0,size:function(){return this.length},toArray:function(){return R.call(this,0)},get:function(a){return a==null?this.toArray():a<0?this.slice(a)[0]:this[a]},pushStack:function(a,b,d){var f=c();c.isArray(a)?ba.apply(f,a):c.merge(f,a);f.prevObject=this;f.context=this.context;if(b=== +"find")f.selector=this.selector+(this.selector?" ":"")+d;else if(b)f.selector=this.selector+"."+b+"("+d+")";return f},each:function(a,b){return c.each(this,a,b)},ready:function(a){c.bindReady();if(c.isReady)a.call(s,c);else Q&&Q.push(a);return this},eq:function(a){return a===-1?this.slice(a):this.slice(a,+a+1)},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},slice:function(){return this.pushStack(R.apply(this,arguments),"slice",R.call(arguments).join(","))},map:function(a){return this.pushStack(c.map(this, +function(b,d){return a.call(b,d,b)}))},end:function(){return this.prevObject||c(null)},push:ba,sort:[].sort,splice:[].splice};c.fn.init.prototype=c.fn;c.extend=c.fn.extend=function(){var a=arguments[0]||{},b=1,d=arguments.length,f=false,e,j,i,o;if(typeof a==="boolean"){f=a;a=arguments[1]||{};b=2}if(typeof a!=="object"&&!c.isFunction(a))a={};if(d===b){a=this;--b}for(;b
      a"; +var e=d.getElementsByTagName("*"),j=d.getElementsByTagName("a")[0];if(!(!e||!e.length||!j)){c.support={leadingWhitespace:d.firstChild.nodeType===3,tbody:!d.getElementsByTagName("tbody").length,htmlSerialize:!!d.getElementsByTagName("link").length,style:/red/.test(j.getAttribute("style")),hrefNormalized:j.getAttribute("href")==="/a",opacity:/^0.55$/.test(j.style.opacity),cssFloat:!!j.style.cssFloat,checkOn:d.getElementsByTagName("input")[0].value==="on",optSelected:s.createElement("select").appendChild(s.createElement("option")).selected, +parentNode:d.removeChild(d.appendChild(s.createElement("div"))).parentNode===null,deleteExpando:true,checkClone:false,scriptEval:false,noCloneEvent:true,boxModel:null};b.type="text/javascript";try{b.appendChild(s.createTextNode("window."+f+"=1;"))}catch(i){}a.insertBefore(b,a.firstChild);if(A[f]){c.support.scriptEval=true;delete A[f]}try{delete b.test}catch(o){c.support.deleteExpando=false}a.removeChild(b);if(d.attachEvent&&d.fireEvent){d.attachEvent("onclick",function k(){c.support.noCloneEvent= +false;d.detachEvent("onclick",k)});d.cloneNode(true).fireEvent("onclick")}d=s.createElement("div");d.innerHTML="";a=s.createDocumentFragment();a.appendChild(d.firstChild);c.support.checkClone=a.cloneNode(true).cloneNode(true).lastChild.checked;c(function(){var k=s.createElement("div");k.style.width=k.style.paddingLeft="1px";s.body.appendChild(k);c.boxModel=c.support.boxModel=k.offsetWidth===2;s.body.removeChild(k).style.display="none"});a=function(k){var n= +s.createElement("div");k="on"+k;var r=k in n;if(!r){n.setAttribute(k,"return;");r=typeof n[k]==="function"}return r};c.support.submitBubbles=a("submit");c.support.changeBubbles=a("change");a=b=d=e=j=null}})();c.props={"for":"htmlFor","class":"className",readonly:"readOnly",maxlength:"maxLength",cellspacing:"cellSpacing",rowspan:"rowSpan",colspan:"colSpan",tabindex:"tabIndex",usemap:"useMap",frameborder:"frameBorder"};var G="jQuery"+J(),Ya=0,za={};c.extend({cache:{},expando:G,noData:{embed:true,object:true, +applet:true},data:function(a,b,d){if(!(a.nodeName&&c.noData[a.nodeName.toLowerCase()])){a=a==A?za:a;var f=a[G],e=c.cache;if(!f&&typeof b==="string"&&d===w)return null;f||(f=++Ya);if(typeof b==="object"){a[G]=f;e[f]=c.extend(true,{},b)}else if(!e[f]){a[G]=f;e[f]={}}a=e[f];if(d!==w)a[b]=d;return typeof b==="string"?a[b]:a}},removeData:function(a,b){if(!(a.nodeName&&c.noData[a.nodeName.toLowerCase()])){a=a==A?za:a;var d=a[G],f=c.cache,e=f[d];if(b){if(e){delete e[b];c.isEmptyObject(e)&&c.removeData(a)}}else{if(c.support.deleteExpando)delete a[c.expando]; +else a.removeAttribute&&a.removeAttribute(c.expando);delete f[d]}}}});c.fn.extend({data:function(a,b){if(typeof a==="undefined"&&this.length)return c.data(this[0]);else if(typeof a==="object")return this.each(function(){c.data(this,a)});var d=a.split(".");d[1]=d[1]?"."+d[1]:"";if(b===w){var f=this.triggerHandler("getData"+d[1]+"!",[d[0]]);if(f===w&&this.length)f=c.data(this[0],a);return f===w&&d[1]?this.data(d[0]):f}else return this.trigger("setData"+d[1]+"!",[d[0],b]).each(function(){c.data(this, +a,b)})},removeData:function(a){return this.each(function(){c.removeData(this,a)})}});c.extend({queue:function(a,b,d){if(a){b=(b||"fx")+"queue";var f=c.data(a,b);if(!d)return f||[];if(!f||c.isArray(d))f=c.data(a,b,c.makeArray(d));else f.push(d);return f}},dequeue:function(a,b){b=b||"fx";var d=c.queue(a,b),f=d.shift();if(f==="inprogress")f=d.shift();if(f){b==="fx"&&d.unshift("inprogress");f.call(a,function(){c.dequeue(a,b)})}}});c.fn.extend({queue:function(a,b){if(typeof a!=="string"){b=a;a="fx"}if(b=== +w)return c.queue(this[0],a);return this.each(function(){var d=c.queue(this,a,b);a==="fx"&&d[0]!=="inprogress"&&c.dequeue(this,a)})},dequeue:function(a){return this.each(function(){c.dequeue(this,a)})},delay:function(a,b){a=c.fx?c.fx.speeds[a]||a:a;b=b||"fx";return this.queue(b,function(){var d=this;setTimeout(function(){c.dequeue(d,b)},a)})},clearQueue:function(a){return this.queue(a||"fx",[])}});var Aa=/[\n\t]/g,ca=/\s+/,Za=/\r/g,$a=/href|src|style/,ab=/(button|input)/i,bb=/(button|input|object|select|textarea)/i, +cb=/^(a|area)$/i,Ba=/radio|checkbox/;c.fn.extend({attr:function(a,b){return X(this,a,b,true,c.attr)},removeAttr:function(a){return this.each(function(){c.attr(this,a,"");this.nodeType===1&&this.removeAttribute(a)})},addClass:function(a){if(c.isFunction(a))return this.each(function(n){var r=c(this);r.addClass(a.call(this,n,r.attr("class")))});if(a&&typeof a==="string")for(var b=(a||"").split(ca),d=0,f=this.length;d-1)return true;return false},val:function(a){if(a===w){var b=this[0];if(b){if(c.nodeName(b,"option"))return(b.attributes.value||{}).specified?b.value:b.text;if(c.nodeName(b,"select")){var d=b.selectedIndex,f=[],e=b.options;b=b.type==="select-one";if(d<0)return null;var j=b?d:0;for(d=b?d+1:e.length;j=0;else if(c.nodeName(this,"select")){var u=c.makeArray(r);c("option",this).each(function(){this.selected= +c.inArray(c(this).val(),u)>=0});if(!u.length)this.selectedIndex=-1}else this.value=r}})}});c.extend({attrFn:{val:true,css:true,html:true,text:true,data:true,width:true,height:true,offset:true},attr:function(a,b,d,f){if(!a||a.nodeType===3||a.nodeType===8)return w;if(f&&b in c.attrFn)return c(a)[b](d);f=a.nodeType!==1||!c.isXMLDoc(a);var e=d!==w;b=f&&c.props[b]||b;if(a.nodeType===1){var j=$a.test(b);if(b in a&&f&&!j){if(e){b==="type"&&ab.test(a.nodeName)&&a.parentNode&&c.error("type property can't be changed"); +a[b]=d}if(c.nodeName(a,"form")&&a.getAttributeNode(b))return a.getAttributeNode(b).nodeValue;if(b==="tabIndex")return(b=a.getAttributeNode("tabIndex"))&&b.specified?b.value:bb.test(a.nodeName)||cb.test(a.nodeName)&&a.href?0:w;return a[b]}if(!c.support.style&&f&&b==="style"){if(e)a.style.cssText=""+d;return a.style.cssText}e&&a.setAttribute(b,""+d);a=!c.support.hrefNormalized&&f&&j?a.getAttribute(b,2):a.getAttribute(b);return a===null?w:a}return c.style(a,b,d)}});var O=/\.(.*)$/,db=function(a){return a.replace(/[^\w\s\.\|`]/g, +function(b){return"\\"+b})};c.event={add:function(a,b,d,f){if(!(a.nodeType===3||a.nodeType===8)){if(a.setInterval&&a!==A&&!a.frameElement)a=A;var e,j;if(d.handler){e=d;d=e.handler}if(!d.guid)d.guid=c.guid++;if(j=c.data(a)){var i=j.events=j.events||{},o=j.handle;if(!o)j.handle=o=function(){return typeof c!=="undefined"&&!c.event.triggered?c.event.handle.apply(o.elem,arguments):w};o.elem=a;b=b.split(" ");for(var k,n=0,r;k=b[n++];){j=e?c.extend({},e):{handler:d,data:f};if(k.indexOf(".")>-1){r=k.split("."); +k=r.shift();j.namespace=r.slice(0).sort().join(".")}else{r=[];j.namespace=""}j.type=k;j.guid=d.guid;var u=i[k],z=c.event.special[k]||{};if(!u){u=i[k]=[];if(!z.setup||z.setup.call(a,f,r,o)===false)if(a.addEventListener)a.addEventListener(k,o,false);else a.attachEvent&&a.attachEvent("on"+k,o)}if(z.add){z.add.call(a,j);if(!j.handler.guid)j.handler.guid=d.guid}u.push(j);c.event.global[k]=true}a=null}}},global:{},remove:function(a,b,d,f){if(!(a.nodeType===3||a.nodeType===8)){var e,j=0,i,o,k,n,r,u,z=c.data(a), +C=z&&z.events;if(z&&C){if(b&&b.type){d=b.handler;b=b.type}if(!b||typeof b==="string"&&b.charAt(0)==="."){b=b||"";for(e in C)c.event.remove(a,e+b)}else{for(b=b.split(" ");e=b[j++];){n=e;i=e.indexOf(".")<0;o=[];if(!i){o=e.split(".");e=o.shift();k=new RegExp("(^|\\.)"+c.map(o.slice(0).sort(),db).join("\\.(?:.*\\.)?")+"(\\.|$)")}if(r=C[e])if(d){n=c.event.special[e]||{};for(B=f||0;B=0){a.type= +e=e.slice(0,-1);a.exclusive=true}if(!d){a.stopPropagation();c.event.global[e]&&c.each(c.cache,function(){this.events&&this.events[e]&&c.event.trigger(a,b,this.handle.elem)})}if(!d||d.nodeType===3||d.nodeType===8)return w;a.result=w;a.target=d;b=c.makeArray(b);b.unshift(a)}a.currentTarget=d;(f=c.data(d,"handle"))&&f.apply(d,b);f=d.parentNode||d.ownerDocument;try{if(!(d&&d.nodeName&&c.noData[d.nodeName.toLowerCase()]))if(d["on"+e]&&d["on"+e].apply(d,b)===false)a.result=false}catch(j){}if(!a.isPropagationStopped()&& +f)c.event.trigger(a,b,f,true);else if(!a.isDefaultPrevented()){f=a.target;var i,o=c.nodeName(f,"a")&&e==="click",k=c.event.special[e]||{};if((!k._default||k._default.call(d,a)===false)&&!o&&!(f&&f.nodeName&&c.noData[f.nodeName.toLowerCase()])){try{if(f[e]){if(i=f["on"+e])f["on"+e]=null;c.event.triggered=true;f[e]()}}catch(n){}if(i)f["on"+e]=i;c.event.triggered=false}}},handle:function(a){var b,d,f,e;a=arguments[0]=c.event.fix(a||A.event);a.currentTarget=this;b=a.type.indexOf(".")<0&&!a.exclusive; +if(!b){d=a.type.split(".");a.type=d.shift();f=new RegExp("(^|\\.)"+d.slice(0).sort().join("\\.(?:.*\\.)?")+"(\\.|$)")}e=c.data(this,"events");d=e[a.type];if(e&&d){d=d.slice(0);e=0;for(var j=d.length;e-1?c.map(a.options,function(f){return f.selected}).join("-"):"";else if(a.nodeName.toLowerCase()==="select")d=a.selectedIndex;return d},fa=function(a,b){var d=a.target,f,e;if(!(!da.test(d.nodeName)||d.readOnly)){f=c.data(d,"_change_data");e=Fa(d);if(a.type!=="focusout"||d.type!=="radio")c.data(d,"_change_data", +e);if(!(f===w||e===f))if(f!=null||e){a.type="change";return c.event.trigger(a,b,d)}}};c.event.special.change={filters:{focusout:fa,click:function(a){var b=a.target,d=b.type;if(d==="radio"||d==="checkbox"||b.nodeName.toLowerCase()==="select")return fa.call(this,a)},keydown:function(a){var b=a.target,d=b.type;if(a.keyCode===13&&b.nodeName.toLowerCase()!=="textarea"||a.keyCode===32&&(d==="checkbox"||d==="radio")||d==="select-multiple")return fa.call(this,a)},beforeactivate:function(a){a=a.target;c.data(a, +"_change_data",Fa(a))}},setup:function(){if(this.type==="file")return false;for(var a in ea)c.event.add(this,a+".specialChange",ea[a]);return da.test(this.nodeName)},teardown:function(){c.event.remove(this,".specialChange");return da.test(this.nodeName)}};ea=c.event.special.change.filters}s.addEventListener&&c.each({focus:"focusin",blur:"focusout"},function(a,b){function d(f){f=c.event.fix(f);f.type=b;return c.event.handle.call(this,f)}c.event.special[b]={setup:function(){this.addEventListener(a, +d,true)},teardown:function(){this.removeEventListener(a,d,true)}}});c.each(["bind","one"],function(a,b){c.fn[b]=function(d,f,e){if(typeof d==="object"){for(var j in d)this[b](j,f,d[j],e);return this}if(c.isFunction(f)){e=f;f=w}var i=b==="one"?c.proxy(e,function(k){c(this).unbind(k,i);return e.apply(this,arguments)}):e;if(d==="unload"&&b!=="one")this.one(d,f,e);else{j=0;for(var o=this.length;j0){y=t;break}}t=t[g]}m[q]=y}}}var f=/((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|['"][^'"]*['"]|[^[\]'"]+)+\]|\\.|[^ >+~,(\[\\]+)+|[>+~])(\s*,\s*)?((?:.|\r|\n)*)/g, +e=0,j=Object.prototype.toString,i=false,o=true;[0,0].sort(function(){o=false;return 0});var k=function(g,h,l,m){l=l||[];var q=h=h||s;if(h.nodeType!==1&&h.nodeType!==9)return[];if(!g||typeof g!=="string")return l;for(var p=[],v,t,y,S,H=true,M=x(h),I=g;(f.exec(""),v=f.exec(I))!==null;){I=v[3];p.push(v[1]);if(v[2]){S=v[3];break}}if(p.length>1&&r.exec(g))if(p.length===2&&n.relative[p[0]])t=ga(p[0]+p[1],h);else for(t=n.relative[p[0]]?[h]:k(p.shift(),h);p.length;){g=p.shift();if(n.relative[g])g+=p.shift(); +t=ga(g,t)}else{if(!m&&p.length>1&&h.nodeType===9&&!M&&n.match.ID.test(p[0])&&!n.match.ID.test(p[p.length-1])){v=k.find(p.shift(),h,M);h=v.expr?k.filter(v.expr,v.set)[0]:v.set[0]}if(h){v=m?{expr:p.pop(),set:z(m)}:k.find(p.pop(),p.length===1&&(p[0]==="~"||p[0]==="+")&&h.parentNode?h.parentNode:h,M);t=v.expr?k.filter(v.expr,v.set):v.set;if(p.length>0)y=z(t);else H=false;for(;p.length;){var D=p.pop();v=D;if(n.relative[D])v=p.pop();else D="";if(v==null)v=h;n.relative[D](y,v,M)}}else y=[]}y||(y=t);y||k.error(D|| +g);if(j.call(y)==="[object Array]")if(H)if(h&&h.nodeType===1)for(g=0;y[g]!=null;g++){if(y[g]&&(y[g]===true||y[g].nodeType===1&&E(h,y[g])))l.push(t[g])}else for(g=0;y[g]!=null;g++)y[g]&&y[g].nodeType===1&&l.push(t[g]);else l.push.apply(l,y);else z(y,l);if(S){k(S,q,l,m);k.uniqueSort(l)}return l};k.uniqueSort=function(g){if(B){i=o;g.sort(B);if(i)for(var h=1;h":function(g,h){var l=typeof h==="string";if(l&&!/\W/.test(h)){h=h.toLowerCase();for(var m=0,q=g.length;m=0))l||m.push(v);else if(l)h[p]=false;return false},ID:function(g){return g[1].replace(/\\/g,"")},TAG:function(g){return g[1].toLowerCase()}, +CHILD:function(g){if(g[1]==="nth"){var h=/(-?)(\d*)n((?:\+|-)?\d*)/.exec(g[2]==="even"&&"2n"||g[2]==="odd"&&"2n+1"||!/\D/.test(g[2])&&"0n+"+g[2]||g[2]);g[2]=h[1]+(h[2]||1)-0;g[3]=h[3]-0}g[0]=e++;return g},ATTR:function(g,h,l,m,q,p){h=g[1].replace(/\\/g,"");if(!p&&n.attrMap[h])g[1]=n.attrMap[h];if(g[2]==="~=")g[4]=" "+g[4]+" ";return g},PSEUDO:function(g,h,l,m,q){if(g[1]==="not")if((f.exec(g[3])||"").length>1||/^\w/.test(g[3]))g[3]=k(g[3],null,null,h);else{g=k.filter(g[3],h,l,true^q);l||m.push.apply(m, +g);return false}else if(n.match.POS.test(g[0])||n.match.CHILD.test(g[0]))return true;return g},POS:function(g){g.unshift(true);return g}},filters:{enabled:function(g){return g.disabled===false&&g.type!=="hidden"},disabled:function(g){return g.disabled===true},checked:function(g){return g.checked===true},selected:function(g){return g.selected===true},parent:function(g){return!!g.firstChild},empty:function(g){return!g.firstChild},has:function(g,h,l){return!!k(l[3],g).length},header:function(g){return/h\d/i.test(g.nodeName)}, +text:function(g){return"text"===g.type},radio:function(g){return"radio"===g.type},checkbox:function(g){return"checkbox"===g.type},file:function(g){return"file"===g.type},password:function(g){return"password"===g.type},submit:function(g){return"submit"===g.type},image:function(g){return"image"===g.type},reset:function(g){return"reset"===g.type},button:function(g){return"button"===g.type||g.nodeName.toLowerCase()==="button"},input:function(g){return/input|select|textarea|button/i.test(g.nodeName)}}, +setFilters:{first:function(g,h){return h===0},last:function(g,h,l,m){return h===m.length-1},even:function(g,h){return h%2===0},odd:function(g,h){return h%2===1},lt:function(g,h,l){return hl[3]-0},nth:function(g,h,l){return l[3]-0===h},eq:function(g,h,l){return l[3]-0===h}},filter:{PSEUDO:function(g,h,l,m){var q=h[1],p=n.filters[q];if(p)return p(g,l,h,m);else if(q==="contains")return(g.textContent||g.innerText||a([g])||"").indexOf(h[3])>=0;else if(q==="not"){h= +h[3];l=0;for(m=h.length;l=0}},ID:function(g,h){return g.nodeType===1&&g.getAttribute("id")===h},TAG:function(g,h){return h==="*"&&g.nodeType===1||g.nodeName.toLowerCase()===h},CLASS:function(g,h){return(" "+(g.className||g.getAttribute("class"))+" ").indexOf(h)>-1},ATTR:function(g,h){var l=h[1];g=n.attrHandle[l]?n.attrHandle[l](g):g[l]!=null?g[l]:g.getAttribute(l);l=g+"";var m=h[2];h=h[4];return g==null?m==="!=":m=== +"="?l===h:m==="*="?l.indexOf(h)>=0:m==="~="?(" "+l+" ").indexOf(h)>=0:!h?l&&g!==false:m==="!="?l!==h:m==="^="?l.indexOf(h)===0:m==="$="?l.substr(l.length-h.length)===h:m==="|="?l===h||l.substr(0,h.length+1)===h+"-":false},POS:function(g,h,l,m){var q=n.setFilters[h[2]];if(q)return q(g,l,h,m)}}},r=n.match.POS;for(var u in n.match){n.match[u]=new RegExp(n.match[u].source+/(?![^\[]*\])(?![^\(]*\))/.source);n.leftMatch[u]=new RegExp(/(^(?:.|\r|\n)*?)/.source+n.match[u].source.replace(/\\(\d+)/g,function(g, +h){return"\\"+(h-0+1)}))}var z=function(g,h){g=Array.prototype.slice.call(g,0);if(h){h.push.apply(h,g);return h}return g};try{Array.prototype.slice.call(s.documentElement.childNodes,0)}catch(C){z=function(g,h){h=h||[];if(j.call(g)==="[object Array]")Array.prototype.push.apply(h,g);else if(typeof g.length==="number")for(var l=0,m=g.length;l";var l=s.documentElement;l.insertBefore(g,l.firstChild);if(s.getElementById(h)){n.find.ID=function(m,q,p){if(typeof q.getElementById!=="undefined"&&!p)return(q=q.getElementById(m[1]))?q.id===m[1]||typeof q.getAttributeNode!=="undefined"&& +q.getAttributeNode("id").nodeValue===m[1]?[q]:w:[]};n.filter.ID=function(m,q){var p=typeof m.getAttributeNode!=="undefined"&&m.getAttributeNode("id");return m.nodeType===1&&p&&p.nodeValue===q}}l.removeChild(g);l=g=null})();(function(){var g=s.createElement("div");g.appendChild(s.createComment(""));if(g.getElementsByTagName("*").length>0)n.find.TAG=function(h,l){l=l.getElementsByTagName(h[1]);if(h[1]==="*"){h=[];for(var m=0;l[m];m++)l[m].nodeType===1&&h.push(l[m]);l=h}return l};g.innerHTML=""; +if(g.firstChild&&typeof g.firstChild.getAttribute!=="undefined"&&g.firstChild.getAttribute("href")!=="#")n.attrHandle.href=function(h){return h.getAttribute("href",2)};g=null})();s.querySelectorAll&&function(){var g=k,h=s.createElement("div");h.innerHTML="

      ";if(!(h.querySelectorAll&&h.querySelectorAll(".TEST").length===0)){k=function(m,q,p,v){q=q||s;if(!v&&q.nodeType===9&&!x(q))try{return z(q.querySelectorAll(m),p)}catch(t){}return g(m,q,p,v)};for(var l in g)k[l]=g[l];h=null}}(); +(function(){var g=s.createElement("div");g.innerHTML="
      ";if(!(!g.getElementsByClassName||g.getElementsByClassName("e").length===0)){g.lastChild.className="e";if(g.getElementsByClassName("e").length!==1){n.order.splice(1,0,"CLASS");n.find.CLASS=function(h,l,m){if(typeof l.getElementsByClassName!=="undefined"&&!m)return l.getElementsByClassName(h[1])};g=null}}})();var E=s.compareDocumentPosition?function(g,h){return!!(g.compareDocumentPosition(h)&16)}: +function(g,h){return g!==h&&(g.contains?g.contains(h):true)},x=function(g){return(g=(g?g.ownerDocument||g:0).documentElement)?g.nodeName!=="HTML":false},ga=function(g,h){var l=[],m="",q;for(h=h.nodeType?[h]:h;q=n.match.PSEUDO.exec(g);){m+=q[0];g=g.replace(n.match.PSEUDO,"")}g=n.relative[g]?g+"*":g;q=0;for(var p=h.length;q=0===d})};c.fn.extend({find:function(a){for(var b=this.pushStack("","find",a),d=0,f=0,e=this.length;f0)for(var j=d;j0},closest:function(a,b){if(c.isArray(a)){var d=[],f=this[0],e,j= +{},i;if(f&&a.length){e=0;for(var o=a.length;e-1:c(f).is(e)){d.push({selector:i,elem:f});delete j[i]}}f=f.parentNode}}return d}var k=c.expr.match.POS.test(a)?c(a,b||this.context):null;return this.map(function(n,r){for(;r&&r.ownerDocument&&r!==b;){if(k?k.index(r)>-1:c(r).is(a))return r;r=r.parentNode}return null})},index:function(a){if(!a||typeof a=== +"string")return c.inArray(this[0],a?c(a):this.parent().children());return c.inArray(a.jquery?a[0]:a,this)},add:function(a,b){a=typeof a==="string"?c(a,b||this.context):c.makeArray(a);b=c.merge(this.get(),a);return this.pushStack(qa(a[0])||qa(b[0])?b:c.unique(b))},andSelf:function(){return this.add(this.prevObject)}});c.each({parent:function(a){return(a=a.parentNode)&&a.nodeType!==11?a:null},parents:function(a){return c.dir(a,"parentNode")},parentsUntil:function(a,b,d){return c.dir(a,"parentNode", +d)},next:function(a){return c.nth(a,2,"nextSibling")},prev:function(a){return c.nth(a,2,"previousSibling")},nextAll:function(a){return c.dir(a,"nextSibling")},prevAll:function(a){return c.dir(a,"previousSibling")},nextUntil:function(a,b,d){return c.dir(a,"nextSibling",d)},prevUntil:function(a,b,d){return c.dir(a,"previousSibling",d)},siblings:function(a){return c.sibling(a.parentNode.firstChild,a)},children:function(a){return c.sibling(a.firstChild)},contents:function(a){return c.nodeName(a,"iframe")? +a.contentDocument||a.contentWindow.document:c.makeArray(a.childNodes)}},function(a,b){c.fn[a]=function(d,f){var e=c.map(this,b,d);eb.test(a)||(f=d);if(f&&typeof f==="string")e=c.filter(f,e);e=this.length>1?c.unique(e):e;if((this.length>1||gb.test(f))&&fb.test(a))e=e.reverse();return this.pushStack(e,a,R.call(arguments).join(","))}});c.extend({filter:function(a,b,d){if(d)a=":not("+a+")";return c.find.matches(a,b)},dir:function(a,b,d){var f=[];for(a=a[b];a&&a.nodeType!==9&&(d===w||a.nodeType!==1||!c(a).is(d));){a.nodeType=== +1&&f.push(a);a=a[b]}return f},nth:function(a,b,d){b=b||1;for(var f=0;a;a=a[d])if(a.nodeType===1&&++f===b)break;return a},sibling:function(a,b){for(var d=[];a;a=a.nextSibling)a.nodeType===1&&a!==b&&d.push(a);return d}});var Ja=/ jQuery\d+="(?:\d+|null)"/g,V=/^\s+/,Ka=/(<([\w:]+)[^>]*?)\/>/g,hb=/^(?:area|br|col|embed|hr|img|input|link|meta|param)$/i,La=/<([\w:]+)/,ib=/"},F={option:[1,""],legend:[1,"
      ","
      "],thead:[1,"","
      "],tr:[2,"","
      "],td:[3,"","
      "],col:[2,"","
      "],area:[1,"",""],_default:[0,"",""]};F.optgroup=F.option;F.tbody=F.tfoot=F.colgroup=F.caption=F.thead;F.th=F.td;if(!c.support.htmlSerialize)F._default=[1,"div
      ","
      "];c.fn.extend({text:function(a){if(c.isFunction(a))return this.each(function(b){var d= +c(this);d.text(a.call(this,b,d.text()))});if(typeof a!=="object"&&a!==w)return this.empty().append((this[0]&&this[0].ownerDocument||s).createTextNode(a));return c.text(this)},wrapAll:function(a){if(c.isFunction(a))return this.each(function(d){c(this).wrapAll(a.call(this,d))});if(this[0]){var b=c(a,this[0].ownerDocument).eq(0).clone(true);this[0].parentNode&&b.insertBefore(this[0]);b.map(function(){for(var d=this;d.firstChild&&d.firstChild.nodeType===1;)d=d.firstChild;return d}).append(this)}return this}, +wrapInner:function(a){if(c.isFunction(a))return this.each(function(b){c(this).wrapInner(a.call(this,b))});return this.each(function(){var b=c(this),d=b.contents();d.length?d.wrapAll(a):b.append(a)})},wrap:function(a){return this.each(function(){c(this).wrapAll(a)})},unwrap:function(){return this.parent().each(function(){c.nodeName(this,"body")||c(this).replaceWith(this.childNodes)}).end()},append:function(){return this.domManip(arguments,true,function(a){this.nodeType===1&&this.appendChild(a)})}, +prepend:function(){return this.domManip(arguments,true,function(a){this.nodeType===1&&this.insertBefore(a,this.firstChild)})},before:function(){if(this[0]&&this[0].parentNode)return this.domManip(arguments,false,function(b){this.parentNode.insertBefore(b,this)});else if(arguments.length){var a=c(arguments[0]);a.push.apply(a,this.toArray());return this.pushStack(a,"before",arguments)}},after:function(){if(this[0]&&this[0].parentNode)return this.domManip(arguments,false,function(b){this.parentNode.insertBefore(b, +this.nextSibling)});else if(arguments.length){var a=this.pushStack(this,"after",arguments);a.push.apply(a,c(arguments[0]).toArray());return a}},remove:function(a,b){for(var d=0,f;(f=this[d])!=null;d++)if(!a||c.filter(a,[f]).length){if(!b&&f.nodeType===1){c.cleanData(f.getElementsByTagName("*"));c.cleanData([f])}f.parentNode&&f.parentNode.removeChild(f)}return this},empty:function(){for(var a=0,b;(b=this[a])!=null;a++)for(b.nodeType===1&&c.cleanData(b.getElementsByTagName("*"));b.firstChild;)b.removeChild(b.firstChild); +return this},clone:function(a){var b=this.map(function(){if(!c.support.noCloneEvent&&!c.isXMLDoc(this)){var d=this.outerHTML,f=this.ownerDocument;if(!d){d=f.createElement("div");d.appendChild(this.cloneNode(true));d=d.innerHTML}return c.clean([d.replace(Ja,"").replace(/=([^="'>\s]+\/)>/g,'="$1">').replace(V,"")],f)[0]}else return this.cloneNode(true)});if(a===true){ra(this,b);ra(this.find("*"),b.find("*"))}return b},html:function(a){if(a===w)return this[0]&&this[0].nodeType===1?this[0].innerHTML.replace(Ja, +""):null;else if(typeof a==="string"&&!ta.test(a)&&(c.support.leadingWhitespace||!V.test(a))&&!F[(La.exec(a)||["",""])[1].toLowerCase()]){a=a.replace(Ka,Ma);try{for(var b=0,d=this.length;b0||e.cacheable||this.length>1?k.cloneNode(true):k)}o.length&&c.each(o,Qa)}return this}});c.fragments={};c.each({appendTo:"append",prependTo:"prepend",insertBefore:"before",insertAfter:"after",replaceAll:"replaceWith"},function(a,b){c.fn[a]=function(d){var f=[];d=c(d);var e=this.length===1&&this[0].parentNode;if(e&&e.nodeType===11&&e.childNodes.length===1&&d.length===1){d[b](this[0]); +return this}else{e=0;for(var j=d.length;e0?this.clone(true):this).get();c.fn[b].apply(c(d[e]),i);f=f.concat(i)}return this.pushStack(f,a,d.selector)}}});c.extend({clean:function(a,b,d,f){b=b||s;if(typeof b.createElement==="undefined")b=b.ownerDocument||b[0]&&b[0].ownerDocument||s;for(var e=[],j=0,i;(i=a[j])!=null;j++){if(typeof i==="number")i+="";if(i){if(typeof i==="string"&&!jb.test(i))i=b.createTextNode(i);else if(typeof i==="string"){i=i.replace(Ka,Ma);var o=(La.exec(i)||["", +""])[1].toLowerCase(),k=F[o]||F._default,n=k[0],r=b.createElement("div");for(r.innerHTML=k[1]+i+k[2];n--;)r=r.lastChild;if(!c.support.tbody){n=ib.test(i);o=o==="table"&&!n?r.firstChild&&r.firstChild.childNodes:k[1]===""&&!n?r.childNodes:[];for(k=o.length-1;k>=0;--k)c.nodeName(o[k],"tbody")&&!o[k].childNodes.length&&o[k].parentNode.removeChild(o[k])}!c.support.leadingWhitespace&&V.test(i)&&r.insertBefore(b.createTextNode(V.exec(i)[0]),r.firstChild);i=r.childNodes}if(i.nodeType)e.push(i);else e= +c.merge(e,i)}}if(d)for(j=0;e[j];j++)if(f&&c.nodeName(e[j],"script")&&(!e[j].type||e[j].type.toLowerCase()==="text/javascript"))f.push(e[j].parentNode?e[j].parentNode.removeChild(e[j]):e[j]);else{e[j].nodeType===1&&e.splice.apply(e,[j+1,0].concat(c.makeArray(e[j].getElementsByTagName("script"))));d.appendChild(e[j])}return e},cleanData:function(a){for(var b,d,f=c.cache,e=c.event.special,j=c.support.deleteExpando,i=0,o;(o=a[i])!=null;i++)if(d=o[c.expando]){b=f[d];if(b.events)for(var k in b.events)e[k]? +c.event.remove(o,k):Ca(o,k,b.handle);if(j)delete o[c.expando];else o.removeAttribute&&o.removeAttribute(c.expando);delete f[d]}}});var kb=/z-?index|font-?weight|opacity|zoom|line-?height/i,Na=/alpha\([^)]*\)/,Oa=/opacity=([^)]*)/,ha=/float/i,ia=/-([a-z])/ig,lb=/([A-Z])/g,mb=/^-?\d+(?:px)?$/i,nb=/^-?\d/,ob={position:"absolute",visibility:"hidden",display:"block"},pb=["Left","Right"],qb=["Top","Bottom"],rb=s.defaultView&&s.defaultView.getComputedStyle,Pa=c.support.cssFloat?"cssFloat":"styleFloat",ja= +function(a,b){return b.toUpperCase()};c.fn.css=function(a,b){return X(this,a,b,true,function(d,f,e){if(e===w)return c.curCSS(d,f);if(typeof e==="number"&&!kb.test(f))e+="px";c.style(d,f,e)})};c.extend({style:function(a,b,d){if(!a||a.nodeType===3||a.nodeType===8)return w;if((b==="width"||b==="height")&&parseFloat(d)<0)d=w;var f=a.style||a,e=d!==w;if(!c.support.opacity&&b==="opacity"){if(e){f.zoom=1;b=parseInt(d,10)+""==="NaN"?"":"alpha(opacity="+d*100+")";a=f.filter||c.curCSS(a,"filter")||"";f.filter= +Na.test(a)?a.replace(Na,b):b}return f.filter&&f.filter.indexOf("opacity=")>=0?parseFloat(Oa.exec(f.filter)[1])/100+"":""}if(ha.test(b))b=Pa;b=b.replace(ia,ja);if(e)f[b]=d;return f[b]},css:function(a,b,d,f){if(b==="width"||b==="height"){var e,j=b==="width"?pb:qb;function i(){e=b==="width"?a.offsetWidth:a.offsetHeight;f!=="border"&&c.each(j,function(){f||(e-=parseFloat(c.curCSS(a,"padding"+this,true))||0);if(f==="margin")e+=parseFloat(c.curCSS(a,"margin"+this,true))||0;else e-=parseFloat(c.curCSS(a, +"border"+this+"Width",true))||0})}a.offsetWidth!==0?i():c.swap(a,ob,i);return Math.max(0,Math.round(e))}return c.curCSS(a,b,d)},curCSS:function(a,b,d){var f,e=a.style;if(!c.support.opacity&&b==="opacity"&&a.currentStyle){f=Oa.test(a.currentStyle.filter||"")?parseFloat(RegExp.$1)/100+"":"";return f===""?"1":f}if(ha.test(b))b=Pa;if(!d&&e&&e[b])f=e[b];else if(rb){if(ha.test(b))b="float";b=b.replace(lb,"-$1").toLowerCase();e=a.ownerDocument.defaultView;if(!e)return null;if(a=e.getComputedStyle(a,null))f= +a.getPropertyValue(b);if(b==="opacity"&&f==="")f="1"}else if(a.currentStyle){d=b.replace(ia,ja);f=a.currentStyle[b]||a.currentStyle[d];if(!mb.test(f)&&nb.test(f)){b=e.left;var j=a.runtimeStyle.left;a.runtimeStyle.left=a.currentStyle.left;e.left=d==="fontSize"?"1em":f||0;f=e.pixelLeft+"px";e.left=b;a.runtimeStyle.left=j}}return f},swap:function(a,b,d){var f={};for(var e in b){f[e]=a.style[e];a.style[e]=b[e]}d.call(a);for(e in b)a.style[e]=f[e]}});if(c.expr&&c.expr.filters){c.expr.filters.hidden=function(a){var b= +a.offsetWidth,d=a.offsetHeight,f=a.nodeName.toLowerCase()==="tr";return b===0&&d===0&&!f?true:b>0&&d>0&&!f?false:c.curCSS(a,"display")==="none"};c.expr.filters.visible=function(a){return!c.expr.filters.hidden(a)}}var sb=J(),tb=//gi,ub=/select|textarea/i,vb=/color|date|datetime|email|hidden|month|number|password|range|search|tel|text|time|url|week/i,N=/=\?(&|$)/,ka=/\?/,wb=/(\?|&)_=.*?(&|$)/,xb=/^(\w+:)?\/\/([^\/?#]+)/,yb=/%20/g,zb=c.fn.load;c.fn.extend({load:function(a,b,d){if(typeof a!== +"string")return zb.call(this,a);else if(!this.length)return this;var f=a.indexOf(" ");if(f>=0){var e=a.slice(f,a.length);a=a.slice(0,f)}f="GET";if(b)if(c.isFunction(b)){d=b;b=null}else if(typeof b==="object"){b=c.param(b,c.ajaxSettings.traditional);f="POST"}var j=this;c.ajax({url:a,type:f,dataType:"html",data:b,complete:function(i,o){if(o==="success"||o==="notmodified")j.html(e?c("
      ").append(i.responseText.replace(tb,"")).find(e):i.responseText);d&&j.each(d,[i.responseText,o,i])}});return this}, +serialize:function(){return c.param(this.serializeArray())},serializeArray:function(){return this.map(function(){return this.elements?c.makeArray(this.elements):this}).filter(function(){return this.name&&!this.disabled&&(this.checked||ub.test(this.nodeName)||vb.test(this.type))}).map(function(a,b){a=c(this).val();return a==null?null:c.isArray(a)?c.map(a,function(d){return{name:b.name,value:d}}):{name:b.name,value:a}}).get()}});c.each("ajaxStart ajaxStop ajaxComplete ajaxError ajaxSuccess ajaxSend".split(" "), +function(a,b){c.fn[b]=function(d){return this.bind(b,d)}});c.extend({get:function(a,b,d,f){if(c.isFunction(b)){f=f||d;d=b;b=null}return c.ajax({type:"GET",url:a,data:b,success:d,dataType:f})},getScript:function(a,b){return c.get(a,null,b,"script")},getJSON:function(a,b,d){return c.get(a,b,d,"json")},post:function(a,b,d,f){if(c.isFunction(b)){f=f||d;d=b;b={}}return c.ajax({type:"POST",url:a,data:b,success:d,dataType:f})},ajaxSetup:function(a){c.extend(c.ajaxSettings,a)},ajaxSettings:{url:location.href, +global:true,type:"GET",contentType:"application/x-www-form-urlencoded",processData:true,async:true,xhr:A.XMLHttpRequest&&(A.location.protocol!=="file:"||!A.ActiveXObject)?function(){return new A.XMLHttpRequest}:function(){try{return new A.ActiveXObject("Microsoft.XMLHTTP")}catch(a){}},accepts:{xml:"application/xml, text/xml",html:"text/html",script:"text/javascript, application/javascript",json:"application/json, text/javascript",text:"text/plain",_default:"*/*"}},lastModified:{},etag:{},ajax:function(a){function b(){e.success&& +e.success.call(k,o,i,x);e.global&&f("ajaxSuccess",[x,e])}function d(){e.complete&&e.complete.call(k,x,i);e.global&&f("ajaxComplete",[x,e]);e.global&&!--c.active&&c.event.trigger("ajaxStop")}function f(q,p){(e.context?c(e.context):c.event).trigger(q,p)}var e=c.extend(true,{},c.ajaxSettings,a),j,i,o,k=a&&a.context||e,n=e.type.toUpperCase();if(e.data&&e.processData&&typeof e.data!=="string")e.data=c.param(e.data,e.traditional);if(e.dataType==="jsonp"){if(n==="GET")N.test(e.url)||(e.url+=(ka.test(e.url)? +"&":"?")+(e.jsonp||"callback")+"=?");else if(!e.data||!N.test(e.data))e.data=(e.data?e.data+"&":"")+(e.jsonp||"callback")+"=?";e.dataType="json"}if(e.dataType==="json"&&(e.data&&N.test(e.data)||N.test(e.url))){j=e.jsonpCallback||"jsonp"+sb++;if(e.data)e.data=(e.data+"").replace(N,"="+j+"$1");e.url=e.url.replace(N,"="+j+"$1");e.dataType="script";A[j]=A[j]||function(q){o=q;b();d();A[j]=w;try{delete A[j]}catch(p){}z&&z.removeChild(C)}}if(e.dataType==="script"&&e.cache===null)e.cache=false;if(e.cache=== +false&&n==="GET"){var r=J(),u=e.url.replace(wb,"$1_="+r+"$2");e.url=u+(u===e.url?(ka.test(e.url)?"&":"?")+"_="+r:"")}if(e.data&&n==="GET")e.url+=(ka.test(e.url)?"&":"?")+e.data;e.global&&!c.active++&&c.event.trigger("ajaxStart");r=(r=xb.exec(e.url))&&(r[1]&&r[1]!==location.protocol||r[2]!==location.host);if(e.dataType==="script"&&n==="GET"&&r){var z=s.getElementsByTagName("head")[0]||s.documentElement,C=s.createElement("script");C.src=e.url;if(e.scriptCharset)C.charset=e.scriptCharset;if(!j){var B= +false;C.onload=C.onreadystatechange=function(){if(!B&&(!this.readyState||this.readyState==="loaded"||this.readyState==="complete")){B=true;b();d();C.onload=C.onreadystatechange=null;z&&C.parentNode&&z.removeChild(C)}}}z.insertBefore(C,z.firstChild);return w}var E=false,x=e.xhr();if(x){e.username?x.open(n,e.url,e.async,e.username,e.password):x.open(n,e.url,e.async);try{if(e.data||a&&a.contentType)x.setRequestHeader("Content-Type",e.contentType);if(e.ifModified){c.lastModified[e.url]&&x.setRequestHeader("If-Modified-Since", +c.lastModified[e.url]);c.etag[e.url]&&x.setRequestHeader("If-None-Match",c.etag[e.url])}r||x.setRequestHeader("X-Requested-With","XMLHttpRequest");x.setRequestHeader("Accept",e.dataType&&e.accepts[e.dataType]?e.accepts[e.dataType]+", */*":e.accepts._default)}catch(ga){}if(e.beforeSend&&e.beforeSend.call(k,x,e)===false){e.global&&!--c.active&&c.event.trigger("ajaxStop");x.abort();return false}e.global&&f("ajaxSend",[x,e]);var g=x.onreadystatechange=function(q){if(!x||x.readyState===0||q==="abort"){E|| +d();E=true;if(x)x.onreadystatechange=c.noop}else if(!E&&x&&(x.readyState===4||q==="timeout")){E=true;x.onreadystatechange=c.noop;i=q==="timeout"?"timeout":!c.httpSuccess(x)?"error":e.ifModified&&c.httpNotModified(x,e.url)?"notmodified":"success";var p;if(i==="success")try{o=c.httpData(x,e.dataType,e)}catch(v){i="parsererror";p=v}if(i==="success"||i==="notmodified")j||b();else c.handleError(e,x,i,p);d();q==="timeout"&&x.abort();if(e.async)x=null}};try{var h=x.abort;x.abort=function(){x&&h.call(x); +g("abort")}}catch(l){}e.async&&e.timeout>0&&setTimeout(function(){x&&!E&&g("timeout")},e.timeout);try{x.send(n==="POST"||n==="PUT"||n==="DELETE"?e.data:null)}catch(m){c.handleError(e,x,null,m);d()}e.async||g();return x}},handleError:function(a,b,d,f){if(a.error)a.error.call(a.context||a,b,d,f);if(a.global)(a.context?c(a.context):c.event).trigger("ajaxError",[b,a,f])},active:0,httpSuccess:function(a){try{return!a.status&&location.protocol==="file:"||a.status>=200&&a.status<300||a.status===304||a.status=== +1223||a.status===0}catch(b){}return false},httpNotModified:function(a,b){var d=a.getResponseHeader("Last-Modified"),f=a.getResponseHeader("Etag");if(d)c.lastModified[b]=d;if(f)c.etag[b]=f;return a.status===304||a.status===0},httpData:function(a,b,d){var f=a.getResponseHeader("content-type")||"",e=b==="xml"||!b&&f.indexOf("xml")>=0;a=e?a.responseXML:a.responseText;e&&a.documentElement.nodeName==="parsererror"&&c.error("parsererror");if(d&&d.dataFilter)a=d.dataFilter(a,b);if(typeof a==="string")if(b=== +"json"||!b&&f.indexOf("json")>=0)a=c.parseJSON(a);else if(b==="script"||!b&&f.indexOf("javascript")>=0)c.globalEval(a);return a},param:function(a,b){function d(i,o){if(c.isArray(o))c.each(o,function(k,n){b||/\[\]$/.test(i)?f(i,n):d(i+"["+(typeof n==="object"||c.isArray(n)?k:"")+"]",n)});else!b&&o!=null&&typeof o==="object"?c.each(o,function(k,n){d(i+"["+k+"]",n)}):f(i,o)}function f(i,o){o=c.isFunction(o)?o():o;e[e.length]=encodeURIComponent(i)+"="+encodeURIComponent(o)}var e=[];if(b===w)b=c.ajaxSettings.traditional; +if(c.isArray(a)||a.jquery)c.each(a,function(){f(this.name,this.value)});else for(var j in a)d(j,a[j]);return e.join("&").replace(yb,"+")}});var la={},Ab=/toggle|show|hide/,Bb=/^([+-]=)?([\d+-.]+)(.*)$/,W,va=[["height","marginTop","marginBottom","paddingTop","paddingBottom"],["width","marginLeft","marginRight","paddingLeft","paddingRight"],["opacity"]];c.fn.extend({show:function(a,b){if(a||a===0)return this.animate(K("show",3),a,b);else{a=0;for(b=this.length;a").appendTo("body");f=e.css("display");if(f==="none")f="block";e.remove();la[d]=f}c.data(this[a],"olddisplay",f)}}a=0;for(b=this.length;a=0;f--)if(d[f].elem===this){b&&d[f](true);d.splice(f,1)}});b||this.dequeue();return this}});c.each({slideDown:K("show",1),slideUp:K("hide",1),slideToggle:K("toggle",1),fadeIn:{opacity:"show"},fadeOut:{opacity:"hide"}},function(a,b){c.fn[a]=function(d,f){return this.animate(b,d,f)}});c.extend({speed:function(a,b,d){var f=a&&typeof a==="object"?a:{complete:d||!d&&b||c.isFunction(a)&&a,duration:a,easing:d&&b||b&&!c.isFunction(b)&&b};f.duration=c.fx.off?0:typeof f.duration=== +"number"?f.duration:c.fx.speeds[f.duration]||c.fx.speeds._default;f.old=f.complete;f.complete=function(){f.queue!==false&&c(this).dequeue();c.isFunction(f.old)&&f.old.call(this)};return f},easing:{linear:function(a,b,d,f){return d+f*a},swing:function(a,b,d,f){return(-Math.cos(a*Math.PI)/2+0.5)*f+d}},timers:[],fx:function(a,b,d){this.options=b;this.elem=a;this.prop=d;if(!b.orig)b.orig={}}});c.fx.prototype={update:function(){this.options.step&&this.options.step.call(this.elem,this.now,this);(c.fx.step[this.prop]|| +c.fx.step._default)(this);if((this.prop==="height"||this.prop==="width")&&this.elem.style)this.elem.style.display="block"},cur:function(a){if(this.elem[this.prop]!=null&&(!this.elem.style||this.elem.style[this.prop]==null))return this.elem[this.prop];return(a=parseFloat(c.css(this.elem,this.prop,a)))&&a>-10000?a:parseFloat(c.curCSS(this.elem,this.prop))||0},custom:function(a,b,d){function f(j){return e.step(j)}this.startTime=J();this.start=a;this.end=b;this.unit=d||this.unit||"px";this.now=this.start; +this.pos=this.state=0;var e=this;f.elem=this.elem;if(f()&&c.timers.push(f)&&!W)W=setInterval(c.fx.tick,13)},show:function(){this.options.orig[this.prop]=c.style(this.elem,this.prop);this.options.show=true;this.custom(this.prop==="width"||this.prop==="height"?1:0,this.cur());c(this.elem).show()},hide:function(){this.options.orig[this.prop]=c.style(this.elem,this.prop);this.options.hide=true;this.custom(this.cur(),0)},step:function(a){var b=J(),d=true;if(a||b>=this.options.duration+this.startTime){this.now= +this.end;this.pos=this.state=1;this.update();this.options.curAnim[this.prop]=true;for(var f in this.options.curAnim)if(this.options.curAnim[f]!==true)d=false;if(d){if(this.options.display!=null){this.elem.style.overflow=this.options.overflow;a=c.data(this.elem,"olddisplay");this.elem.style.display=a?a:this.options.display;if(c.css(this.elem,"display")==="none")this.elem.style.display="block"}this.options.hide&&c(this.elem).hide();if(this.options.hide||this.options.show)for(var e in this.options.curAnim)c.style(this.elem, +e,this.options.orig[e]);this.options.complete.call(this.elem)}return false}else{e=b-this.startTime;this.state=e/this.options.duration;a=this.options.easing||(c.easing.swing?"swing":"linear");this.pos=c.easing[this.options.specialEasing&&this.options.specialEasing[this.prop]||a](this.state,e,0,1,this.options.duration);this.now=this.start+(this.end-this.start)*this.pos;this.update()}return true}};c.extend(c.fx,{tick:function(){for(var a=c.timers,b=0;b
      "; +a.insertBefore(b,a.firstChild);d=b.firstChild;f=d.firstChild;e=d.nextSibling.firstChild.firstChild;this.doesNotAddBorder=f.offsetTop!==5;this.doesAddBorderForTableAndCells=e.offsetTop===5;f.style.position="fixed";f.style.top="20px";this.supportsFixedPosition=f.offsetTop===20||f.offsetTop===15;f.style.position=f.style.top="";d.style.overflow="hidden";d.style.position="relative";this.subtractsBorderForOverflowNotVisible=f.offsetTop===-5;this.doesNotIncludeMarginInBodyOffset=a.offsetTop!==j;a.removeChild(b); +c.offset.initialize=c.noop},bodyOffset:function(a){var b=a.offsetTop,d=a.offsetLeft;c.offset.initialize();if(c.offset.doesNotIncludeMarginInBodyOffset){b+=parseFloat(c.curCSS(a,"marginTop",true))||0;d+=parseFloat(c.curCSS(a,"marginLeft",true))||0}return{top:b,left:d}},setOffset:function(a,b,d){if(/static/.test(c.curCSS(a,"position")))a.style.position="relative";var f=c(a),e=f.offset(),j=parseInt(c.curCSS(a,"top",true),10)||0,i=parseInt(c.curCSS(a,"left",true),10)||0;if(c.isFunction(b))b=b.call(a, +d,e);d={top:b.top-e.top+j,left:b.left-e.left+i};"using"in b?b.using.call(a,d):f.css(d)}};c.fn.extend({position:function(){if(!this[0])return null;var a=this[0],b=this.offsetParent(),d=this.offset(),f=/^body|html$/i.test(b[0].nodeName)?{top:0,left:0}:b.offset();d.top-=parseFloat(c.curCSS(a,"marginTop",true))||0;d.left-=parseFloat(c.curCSS(a,"marginLeft",true))||0;f.top+=parseFloat(c.curCSS(b[0],"borderTopWidth",true))||0;f.left+=parseFloat(c.curCSS(b[0],"borderLeftWidth",true))||0;return{top:d.top- +f.top,left:d.left-f.left}},offsetParent:function(){return this.map(function(){for(var a=this.offsetParent||s.body;a&&!/^body|html$/i.test(a.nodeName)&&c.css(a,"position")==="static";)a=a.offsetParent;return a})}});c.each(["Left","Top"],function(a,b){var d="scroll"+b;c.fn[d]=function(f){var e=this[0],j;if(!e)return null;if(f!==w)return this.each(function(){if(j=wa(this))j.scrollTo(!a?f:c(j).scrollLeft(),a?f:c(j).scrollTop());else this[d]=f});else return(j=wa(e))?"pageXOffset"in j?j[a?"pageYOffset": +"pageXOffset"]:c.support.boxModel&&j.document.documentElement[d]||j.document.body[d]:e[d]}});c.each(["Height","Width"],function(a,b){var d=b.toLowerCase();c.fn["inner"+b]=function(){return this[0]?c.css(this[0],d,false,"padding"):null};c.fn["outer"+b]=function(f){return this[0]?c.css(this[0],d,false,f?"margin":"border"):null};c.fn[d]=function(f){var e=this[0];if(!e)return f==null?null:this;if(c.isFunction(f))return this.each(function(j){var i=c(this);i[d](f.call(this,j,i[d]()))});return"scrollTo"in +e&&e.document?e.document.compatMode==="CSS1Compat"&&e.document.documentElement["client"+b]||e.document.body["client"+b]:e.nodeType===9?Math.max(e.documentElement["client"+b],e.body["scroll"+b],e.documentElement["scroll"+b],e.body["offset"+b],e.documentElement["offset"+b]):f===w?c.css(e,d):this.css(d,typeof f==="string"?f:f+"px")}});A.jQuery=A.$=c})(window); diff --git a/maven-skin/src/main/resources/js/jquery/js/jquery-ui-1.8.5.custom.min.js b/maven-skin/src/main/resources/js/jquery/js/jquery-ui-1.8.5.custom.min.js new file mode 100644 index 00000000000..040ed18107a --- /dev/null +++ b/maven-skin/src/main/resources/js/jquery/js/jquery-ui-1.8.5.custom.min.js @@ -0,0 +1,68 @@ +/*! + * jQuery UI 1.8.5 + * + * Copyright 2010, AUTHORS.txt (http://jqueryui.com/about) + * Dual licensed under the MIT or GPL Version 2 licenses. + * http://jquery.org/license + * + * http://docs.jquery.com/UI + */ +(function(c,j){function k(a){return!c(a).parents().andSelf().filter(function(){return c.curCSS(this,"visibility")==="hidden"||c.expr.filters.hidden(this)}).length}c.ui=c.ui||{};if(!c.ui.version){c.extend(c.ui,{version:"1.8.5",keyCode:{ALT:18,BACKSPACE:8,CAPS_LOCK:20,COMMA:188,COMMAND:91,COMMAND_LEFT:91,COMMAND_RIGHT:93,CONTROL:17,DELETE:46,DOWN:40,END:35,ENTER:13,ESCAPE:27,HOME:36,INSERT:45,LEFT:37,MENU:93,NUMPAD_ADD:107,NUMPAD_DECIMAL:110,NUMPAD_DIVIDE:111,NUMPAD_ENTER:108,NUMPAD_MULTIPLY:106, +NUMPAD_SUBTRACT:109,PAGE_DOWN:34,PAGE_UP:33,PERIOD:190,RIGHT:39,SHIFT:16,SPACE:32,TAB:9,UP:38,WINDOWS:91}});c.fn.extend({_focus:c.fn.focus,focus:function(a,b){return typeof a==="number"?this.each(function(){var d=this;setTimeout(function(){c(d).focus();b&&b.call(d)},a)}):this._focus.apply(this,arguments)},scrollParent:function(){var a;a=c.browser.msie&&/(static|relative)/.test(this.css("position"))||/absolute/.test(this.css("position"))?this.parents().filter(function(){return/(relative|absolute|fixed)/.test(c.curCSS(this, +"position",1))&&/(auto|scroll)/.test(c.curCSS(this,"overflow",1)+c.curCSS(this,"overflow-y",1)+c.curCSS(this,"overflow-x",1))}).eq(0):this.parents().filter(function(){return/(auto|scroll)/.test(c.curCSS(this,"overflow",1)+c.curCSS(this,"overflow-y",1)+c.curCSS(this,"overflow-x",1))}).eq(0);return/fixed/.test(this.css("position"))||!a.length?c(document):a},zIndex:function(a){if(a!==j)return this.css("zIndex",a);if(this.length){a=c(this[0]);for(var b;a.length&&a[0]!==document;){b=a.css("position"); +if(b==="absolute"||b==="relative"||b==="fixed"){b=parseInt(a.css("zIndex"));if(!isNaN(b)&&b!=0)return b}a=a.parent()}}return 0},disableSelection:function(){return this.bind("mousedown.ui-disableSelection selectstart.ui-disableSelection",function(a){a.preventDefault()})},enableSelection:function(){return this.unbind(".ui-disableSelection")}});c.each(["Width","Height"],function(a,b){function d(f,g,l,m){c.each(e,function(){g-=parseFloat(c.curCSS(f,"padding"+this,true))||0;if(l)g-=parseFloat(c.curCSS(f, +"border"+this+"Width",true))||0;if(m)g-=parseFloat(c.curCSS(f,"margin"+this,true))||0});return g}var e=b==="Width"?["Left","Right"]:["Top","Bottom"],h=b.toLowerCase(),i={innerWidth:c.fn.innerWidth,innerHeight:c.fn.innerHeight,outerWidth:c.fn.outerWidth,outerHeight:c.fn.outerHeight};c.fn["inner"+b]=function(f){if(f===j)return i["inner"+b].call(this);return this.each(function(){c.style(this,h,d(this,f)+"px")})};c.fn["outer"+b]=function(f,g){if(typeof f!=="number")return i["outer"+b].call(this,f);return this.each(function(){c.style(this, +h,d(this,f,true,g)+"px")})}});c.extend(c.expr[":"],{data:function(a,b,d){return!!c.data(a,d[3])},focusable:function(a){var b=a.nodeName.toLowerCase(),d=c.attr(a,"tabindex");if("area"===b){b=a.parentNode;d=b.name;if(!a.href||!d||b.nodeName.toLowerCase()!=="map")return false;a=c("img[usemap=#"+d+"]")[0];return!!a&&k(a)}return(/input|select|textarea|button|object/.test(b)?!a.disabled:"a"==b?a.href||!isNaN(d):!isNaN(d))&&k(a)},tabbable:function(a){var b=c.attr(a,"tabindex");return(isNaN(b)||b>=0)&&c(a).is(":focusable")}}); +c(function(){var a=document.createElement("div"),b=document.body;c.extend(a.style,{minHeight:"100px",height:"auto",padding:0,borderWidth:0});c.support.minHeight=b.appendChild(a).offsetHeight===100;b.removeChild(a).style.display="none"});c.extend(c.ui,{plugin:{add:function(a,b,d){a=c.ui[a].prototype;for(var e in d){a.plugins[e]=a.plugins[e]||[];a.plugins[e].push([b,d[e]])}},call:function(a,b,d){if((b=a.plugins[b])&&a.element[0].parentNode)for(var e=0;e0)return true;a[b]=1;d=a[b]>0;a[b]=0;return d},isOverAxis:function(a,b,d){return a>b&&a",remove:null,select:null,show:null,spinner:"Loading…",tabTemplate:"
    • #{label}
      • "},_create:function(){this._tabify(true)},_setOption:function(a,e){if(a=="selected")this.options.collapsible&& +e==this.options.selected||this.select(e);else{this.options[a]=e;this._tabify()}},_tabId:function(a){return a.title&&a.title.replace(/\s/g,"_").replace(/[^\w\u00c0-\uFFFF-]/g,"")||this.options.idPrefix+u()},_sanitizeSelector:function(a){return a.replace(/:/g,"\\:")},_cookie:function(){var a=this.cookie||(this.cookie=this.options.cookie.name||"ui-tabs-"+w());return d.cookie.apply(null,[a].concat(d.makeArray(arguments)))},_ui:function(a,e){return{tab:a,panel:e,index:this.anchors.index(a)}},_cleanup:function(){this.lis.filter(".ui-state-processing").removeClass("ui-state-processing").find("span:data(label.tabs)").each(function(){var a= +d(this);a.html(a.data("label.tabs")).removeData("label.tabs")})},_tabify:function(a){function e(g,f){g.css("display","");!d.support.opacity&&f.opacity&&g[0].style.removeAttribute("filter")}var b=this,c=this.options,h=/^#.+/;this.list=this.element.find("ol,ul").eq(0);this.lis=d(" > li:has(a[href])",this.list);this.anchors=this.lis.map(function(){return d("a",this)[0]});this.panels=d([]);this.anchors.each(function(g,f){var i=d(f).attr("href"),l=i.split("#")[0],q;if(l&&(l===location.toString().split("#")[0]|| +(q=d("base")[0])&&l===q.href)){i=f.hash;f.href=i}if(h.test(i))b.panels=b.panels.add(b._sanitizeSelector(i));else if(i&&i!=="#"){d.data(f,"href.tabs",i);d.data(f,"load.tabs",i.replace(/#.*$/,""));i=b._tabId(f);f.href="#"+i;f=d("#"+i);if(!f.length){f=d(c.panelTemplate).attr("id",i).addClass("ui-tabs-panel ui-widget-content ui-corner-bottom").insertAfter(b.panels[g-1]||b.list);f.data("destroy.tabs",true)}b.panels=b.panels.add(f)}else c.disabled.push(g)});if(a){this.element.addClass("ui-tabs ui-widget ui-widget-content ui-corner-all"); +this.list.addClass("ui-tabs-nav ui-helper-reset ui-helper-clearfix ui-widget-header ui-corner-all");this.lis.addClass("ui-state-default ui-corner-top");this.panels.addClass("ui-tabs-panel ui-widget-content ui-corner-bottom");if(c.selected===p){location.hash&&this.anchors.each(function(g,f){if(f.hash==location.hash){c.selected=g;return false}});if(typeof c.selected!=="number"&&c.cookie)c.selected=parseInt(b._cookie(),10);if(typeof c.selected!=="number"&&this.lis.filter(".ui-tabs-selected").length)c.selected= +this.lis.index(this.lis.filter(".ui-tabs-selected"));c.selected=c.selected||(this.lis.length?0:-1)}else if(c.selected===null)c.selected=-1;c.selected=c.selected>=0&&this.anchors[c.selected]||c.selected<0?c.selected:0;c.disabled=d.unique(c.disabled.concat(d.map(this.lis.filter(".ui-state-disabled"),function(g){return b.lis.index(g)}))).sort();d.inArray(c.selected,c.disabled)!=-1&&c.disabled.splice(d.inArray(c.selected,c.disabled),1);this.panels.addClass("ui-tabs-hide");this.lis.removeClass("ui-tabs-selected ui-state-active"); +if(c.selected>=0&&this.anchors.length){this.panels.eq(c.selected).removeClass("ui-tabs-hide");this.lis.eq(c.selected).addClass("ui-tabs-selected ui-state-active");b.element.queue("tabs",function(){b._trigger("show",null,b._ui(b.anchors[c.selected],b.panels[c.selected]))});this.load(c.selected)}d(window).bind("unload",function(){b.lis.add(b.anchors).unbind(".tabs");b.lis=b.anchors=b.panels=null})}else c.selected=this.lis.index(this.lis.filter(".ui-tabs-selected"));this.element[c.collapsible?"addClass": +"removeClass"]("ui-tabs-collapsible");c.cookie&&this._cookie(c.selected,c.cookie);a=0;for(var j;j=this.lis[a];a++)d(j)[d.inArray(a,c.disabled)!=-1&&!d(j).hasClass("ui-tabs-selected")?"addClass":"removeClass"]("ui-state-disabled");c.cache===false&&this.anchors.removeData("cache.tabs");this.lis.add(this.anchors).unbind(".tabs");if(c.event!=="mouseover"){var k=function(g,f){f.is(":not(.ui-state-disabled)")&&f.addClass("ui-state-"+g)},n=function(g,f){f.removeClass("ui-state-"+g)};this.lis.bind("mouseover.tabs", +function(){k("hover",d(this))});this.lis.bind("mouseout.tabs",function(){n("hover",d(this))});this.anchors.bind("focus.tabs",function(){k("focus",d(this).closest("li"))});this.anchors.bind("blur.tabs",function(){n("focus",d(this).closest("li"))})}var m,o;if(c.fx)if(d.isArray(c.fx)){m=c.fx[0];o=c.fx[1]}else m=o=c.fx;var r=o?function(g,f){d(g).closest("li").addClass("ui-tabs-selected ui-state-active");f.hide().removeClass("ui-tabs-hide").animate(o,o.duration||"normal",function(){e(f,o);b._trigger("show", +null,b._ui(g,f[0]))})}:function(g,f){d(g).closest("li").addClass("ui-tabs-selected ui-state-active");f.removeClass("ui-tabs-hide");b._trigger("show",null,b._ui(g,f[0]))},s=m?function(g,f){f.animate(m,m.duration||"normal",function(){b.lis.removeClass("ui-tabs-selected ui-state-active");f.addClass("ui-tabs-hide");e(f,m);b.element.dequeue("tabs")})}:function(g,f){b.lis.removeClass("ui-tabs-selected ui-state-active");f.addClass("ui-tabs-hide");b.element.dequeue("tabs")};this.anchors.bind(c.event+".tabs", +function(){var g=this,f=d(g).closest("li"),i=b.panels.filter(":not(.ui-tabs-hide)"),l=d(b._sanitizeSelector(g.hash));if(f.hasClass("ui-tabs-selected")&&!c.collapsible||f.hasClass("ui-state-disabled")||f.hasClass("ui-state-processing")||b.panels.filter(":animated").length||b._trigger("select",null,b._ui(this,l[0]))===false){this.blur();return false}c.selected=b.anchors.index(this);b.abort();if(c.collapsible)if(f.hasClass("ui-tabs-selected")){c.selected=-1;c.cookie&&b._cookie(c.selected,c.cookie);b.element.queue("tabs", +function(){s(g,i)}).dequeue("tabs");this.blur();return false}else if(!i.length){c.cookie&&b._cookie(c.selected,c.cookie);b.element.queue("tabs",function(){r(g,l)});b.load(b.anchors.index(this));this.blur();return false}c.cookie&&b._cookie(c.selected,c.cookie);if(l.length){i.length&&b.element.queue("tabs",function(){s(g,i)});b.element.queue("tabs",function(){r(g,l)});b.load(b.anchors.index(this))}else throw"jQuery UI Tabs: Mismatching fragment identifier.";d.browser.msie&&this.blur()});this.anchors.bind("click.tabs", +function(){return false})},_getIndex:function(a){if(typeof a=="string")a=this.anchors.index(this.anchors.filter("[href$="+a+"]"));return a},destroy:function(){var a=this.options;this.abort();this.element.unbind(".tabs").removeClass("ui-tabs ui-widget ui-widget-content ui-corner-all ui-tabs-collapsible").removeData("tabs");this.list.removeClass("ui-tabs-nav ui-helper-reset ui-helper-clearfix ui-widget-header ui-corner-all");this.anchors.each(function(){var e=d.data(this,"href.tabs");if(e)this.href= +e;var b=d(this).unbind(".tabs");d.each(["href","load","cache"],function(c,h){b.removeData(h+".tabs")})});this.lis.unbind(".tabs").add(this.panels).each(function(){d.data(this,"destroy.tabs")?d(this).remove():d(this).removeClass("ui-state-default ui-corner-top ui-tabs-selected ui-state-active ui-state-hover ui-state-focus ui-state-disabled ui-tabs-panel ui-widget-content ui-corner-bottom ui-tabs-hide")});a.cookie&&this._cookie(null,a.cookie);return this},add:function(a,e,b){if(b===p)b=this.anchors.length; +var c=this,h=this.options;e=d(h.tabTemplate.replace(/#\{href\}/g,a).replace(/#\{label\}/g,e));a=!a.indexOf("#")?a.replace("#",""):this._tabId(d("a",e)[0]);e.addClass("ui-state-default ui-corner-top").data("destroy.tabs",true);var j=d("#"+a);j.length||(j=d(h.panelTemplate).attr("id",a).data("destroy.tabs",true));j.addClass("ui-tabs-panel ui-widget-content ui-corner-bottom ui-tabs-hide");if(b>=this.lis.length){e.appendTo(this.list);j.appendTo(this.list[0].parentNode)}else{e.insertBefore(this.lis[b]); +j.insertBefore(this.panels[b])}h.disabled=d.map(h.disabled,function(k){return k>=b?++k:k});this._tabify();if(this.anchors.length==1){h.selected=0;e.addClass("ui-tabs-selected ui-state-active");j.removeClass("ui-tabs-hide");this.element.queue("tabs",function(){c._trigger("show",null,c._ui(c.anchors[0],c.panels[0]))});this.load(0)}this._trigger("add",null,this._ui(this.anchors[b],this.panels[b]));return this},remove:function(a){a=this._getIndex(a);var e=this.options,b=this.lis.eq(a).remove(),c=this.panels.eq(a).remove(); +if(b.hasClass("ui-tabs-selected")&&this.anchors.length>1)this.select(a+(a+1=a?--h:h});this._tabify();this._trigger("remove",null,this._ui(b.find("a")[0],c[0]));return this},enable:function(a){a=this._getIndex(a);var e=this.options;if(d.inArray(a,e.disabled)!=-1){this.lis.eq(a).removeClass("ui-state-disabled");e.disabled=d.grep(e.disabled,function(b){return b!=a});this._trigger("enable",null, +this._ui(this.anchors[a],this.panels[a]));return this}},disable:function(a){a=this._getIndex(a);var e=this.options;if(a!=e.selected){this.lis.eq(a).addClass("ui-state-disabled");e.disabled.push(a);e.disabled.sort();this._trigger("disable",null,this._ui(this.anchors[a],this.panels[a]))}return this},select:function(a){a=this._getIndex(a);if(a==-1)if(this.options.collapsible&&this.options.selected!=-1)a=this.options.selected;else return this;this.anchors.eq(a).trigger(this.options.event+".tabs");return this}, +load:function(a){a=this._getIndex(a);var e=this,b=this.options,c=this.anchors.eq(a)[0],h=d.data(c,"load.tabs");this.abort();if(!h||this.element.queue("tabs").length!==0&&d.data(c,"cache.tabs"))this.element.dequeue("tabs");else{this.lis.eq(a).addClass("ui-state-processing");if(b.spinner){var j=d("span",c);j.data("label.tabs",j.html()).html(b.spinner)}this.xhr=d.ajax(d.extend({},b.ajaxOptions,{url:h,success:function(k,n){d(e._sanitizeSelector(c.hash)).html(k);e._cleanup();b.cache&&d.data(c,"cache.tabs", +true);e._trigger("load",null,e._ui(e.anchors[a],e.panels[a]));try{b.ajaxOptions.success(k,n)}catch(m){}},error:function(k,n){e._cleanup();e._trigger("load",null,e._ui(e.anchors[a],e.panels[a]));try{b.ajaxOptions.error(k,n,a,c)}catch(m){}}}));e.element.dequeue("tabs");return this}},abort:function(){this.element.queue([]);this.panels.stop(false,true);this.element.queue("tabs",this.element.queue("tabs").splice(-2,2));if(this.xhr){this.xhr.abort();delete this.xhr}this._cleanup();return this},url:function(a, +e){this.anchors.eq(a).removeData("cache.tabs").data("load.tabs",e);return this},length:function(){return this.anchors.length}});d.extend(d.ui.tabs,{version:"1.8.5"});d.extend(d.ui.tabs.prototype,{rotation:null,rotate:function(a,e){var b=this,c=this.options,h=b._rotate||(b._rotate=function(j){clearTimeout(b.rotation);b.rotation=setTimeout(function(){var k=c.selected;b.select(++k Date: Sun, 31 Oct 2010 05:06:39 +0000 Subject: [PATCH 217/541] maven skin has james-branded tabs (color,...) and fancy css buttons. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029242 13f79535-47bb-0310-9956-ffa450edef68 --- .../src/main/resources/META-INF/maven/site.vm | 9 +-- maven-skin/src/main/resources/css/james.css | 68 ++++++++++++++++++ .../resources/images/minibutton_icons.png | Bin 0 -> 5191 bytes .../resources/images/minibutton_matrix.png | Bin 0 -> 3469 bytes .../ui-bg_diagonals-thick_18_b81900_40x40.png | Bin .../ui-bg_diagonals-thick_20_666666_40x40.png | Bin .../images/ui-bg_flat_10_000000_40x100.png | Bin .../images/ui-bg_glass_100_525d76_1x400.png | Bin 0 -> 142 bytes .../images/ui-bg_glass_100_b2bacd_1x400.png | Bin 0 -> 131 bytes .../images/ui-bg_glass_100_f6f6f6_1x400.png | Bin .../images/ui-bg_glass_65_ffffff_1x400.png | Bin .../ui-bg_gloss-wave_35_525d76_500x100.png | Bin 0 -> 4062 bytes .../ui-bg_highlight-soft_100_ffffff_1x100.png | Bin 0 -> 86 bytes .../ui-bg_highlight-soft_75_525d76_1x100.png | Bin 0 -> 130 bytes .../images/ui-icons_222222_256x240.png | Bin .../images/ui-icons_228ef1_256x240.png | Bin .../images/ui-icons_525d76_256x240.png} | Bin 4369 -> 4369 bytes .../images/ui-icons_76526c_256x240.png | Bin 0 -> 4369 bytes .../images/ui-icons_ffd27a_256x240.png | Bin 0 -> 4369 bytes .../images/ui-icons_ffffff_256x240.png | Bin .../jquery-ui-1.8.5.custom.css | 23 +++--- .../images/ui-bg_glass_100_fdf5ce_1x400.png | Bin 125 -> 0 bytes .../ui-bg_gloss-wave_35_f6a828_500x100.png | Bin 3762 -> 0 bytes .../ui-bg_highlight-soft_100_eeeeee_1x100.png | Bin 90 -> 0 bytes .../ui-bg_highlight-soft_75_ffe45c_1x100.png | Bin 129 -> 0 bytes .../images/ui-icons_ffd27a_256x240.png | Bin 5355 -> 0 bytes .../src/main/resources/js/jquery/index.html | 4 +- 27 files changed, 86 insertions(+), 18 deletions(-) create mode 100644 maven-skin/src/main/resources/css/james.css create mode 100644 maven-skin/src/main/resources/images/minibutton_icons.png create mode 100644 maven-skin/src/main/resources/images/minibutton_matrix.png rename maven-skin/src/main/resources/js/jquery/css/{ui-lightness => custom-theme}/images/ui-bg_diagonals-thick_18_b81900_40x40.png (100%) rename maven-skin/src/main/resources/js/jquery/css/{ui-lightness => custom-theme}/images/ui-bg_diagonals-thick_20_666666_40x40.png (100%) rename maven-skin/src/main/resources/js/jquery/css/{ui-lightness => custom-theme}/images/ui-bg_flat_10_000000_40x100.png (100%) create mode 100644 maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_glass_100_525d76_1x400.png create mode 100644 maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_glass_100_b2bacd_1x400.png rename maven-skin/src/main/resources/js/jquery/css/{ui-lightness => custom-theme}/images/ui-bg_glass_100_f6f6f6_1x400.png (100%) rename maven-skin/src/main/resources/js/jquery/css/{ui-lightness => custom-theme}/images/ui-bg_glass_65_ffffff_1x400.png (100%) create mode 100644 maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_gloss-wave_35_525d76_500x100.png create mode 100644 maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_highlight-soft_100_ffffff_1x100.png create mode 100644 maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_highlight-soft_75_525d76_1x100.png rename maven-skin/src/main/resources/js/jquery/css/{ui-lightness => custom-theme}/images/ui-icons_222222_256x240.png (100%) rename maven-skin/src/main/resources/js/jquery/css/{ui-lightness => custom-theme}/images/ui-icons_228ef1_256x240.png (100%) rename maven-skin/src/main/resources/js/jquery/css/{ui-lightness/images/ui-icons_ef8c08_256x240.png => custom-theme/images/ui-icons_525d76_256x240.png} (92%) create mode 100644 maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_76526c_256x240.png create mode 100644 maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_ffd27a_256x240.png rename maven-skin/src/main/resources/js/jquery/css/{ui-lightness => custom-theme}/images/ui-icons_ffffff_256x240.png (100%) rename maven-skin/src/main/resources/js/jquery/css/{ui-lightness => custom-theme}/jquery-ui-1.8.5.custom.css (93%) delete mode 100644 maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-bg_glass_100_fdf5ce_1x400.png delete mode 100644 maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-bg_gloss-wave_35_f6a828_500x100.png delete mode 100644 maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-bg_highlight-soft_100_eeeeee_1x100.png delete mode 100644 maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-bg_highlight-soft_75_ffe45c_1x100.png delete mode 100644 maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-icons_ffd27a_256x240.png diff --git a/maven-skin/src/main/resources/META-INF/maven/site.vm b/maven-skin/src/main/resources/META-INF/maven/site.vm index e58d4d5d94f..2183998b198 100644 --- a/maven-skin/src/main/resources/META-INF/maven/site.vm +++ b/maven-skin/src/main/resources/META-INF/maven/site.vm @@ -274,14 +274,15 @@ $title - - + + #foreach( $author in $authors ) #end diff --git a/maven-skin/src/main/resources/css/james.css b/maven-skin/src/main/resources/css/james.css new file mode 100644 index 00000000000..27c7cb7e58d --- /dev/null +++ b/maven-skin/src/main/resources/css/james.css @@ -0,0 +1,68 @@ +/* + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +*/ + +/* + Button + From http://davidwalsh.name/github-css and adapted to maven site. +*/ + +.minibutton { + display:inline-block; + height:23px; + padding:0 0 0 3px; + font-size:11px; + font-weight:bold; + color:#333; + text-shadow:1px 1px 0 #fff; + background:url(../images/minibutton_matrix.png) 0 0 no-repeat; + white-space:nowrap; + border:none; + overflow:visible; + cursor:pointer; + text-decoration:none; +} + +.minibutton>a>span { + display:block; + height:23px; + padding:0 10px 0 8px; + line-height:23px; + background:url(../images/minibutton_matrix.png) 100% 0 no-repeat; +} + +.minibutton:hover, .minibutton:focus { + color:#fff; + text-decoration:none; + text-shadow:-1px -1px 0 rgba(0,0,0,0.3); + background-position:0 -30px; +} + +.minibutton:hover>a>span, .minibutton:focus>a>span {background-position:100% -30px;} +.minibutton.mousedown {background-position:0 -60px; } +.minibutton.mousedown>a>span {background-position:100% -60px; } + +.btn-download .icon { + float:left; + margin-left:-4px; + width:18px; + height:22px; + background:url(../images/minibutton_icons.png) 0 0 no-repeat; +} +.btn-download .icon {background-position:-40px 0;} +.btn-download:hover .icon, .btn-download:focus .icon {background-position:-40px -25px;} diff --git a/maven-skin/src/main/resources/images/minibutton_icons.png b/maven-skin/src/main/resources/images/minibutton_icons.png new file mode 100644 index 0000000000000000000000000000000000000000..657a950c2530391d50c2b30a498b683361161bb6 GIT binary patch literal 5191 zcmb7Ic{tQ>*S9ZY%~}d$ELnzG7|Z+`VV3M=X$-<(24k6-%*awy_7F)bl8R7_P{|%+ zja2p)O4&kESyHy%(QkR4_r0F$xvuyAW9GiUb3UJQ?sLw4?(>~}-*~v=BY-9T~ld5IP6V#dY9d1l`*=h|C1~ko_rC6zEGsGYCi_p+GJO zJE$EUO%9+~Mun1{qU@c0qk?=*NT7qJzylFT4nYW+=?#ns38pfT5h&1aULcf#x zDDbZV;%Eyc`5_%KxW9C9Rwz&alSxNHAmQQRdg1zdv`~Kt%*4cGhXW4Rv`o`demae}ALw?EX6fm-7@BWb2${;X!k|E5VH6V55N!g*85zQ$ z7_0>b3xk;$VsKa!s38VzWP(P+js7P1cOXZX9*Kj6TNs;Tjf^df4Gmy07zSsIG151I z8^R3`hG-lX4gVW!MP)F(slMbLr8`*4zp&>26^lfNlD(O1mUVwW;-vD<^q(`tS^RSf$y83zLOEwF z24+^z#U-g{g)w)Ic(dRk;w(F?kl*Gc!>#2wWOK2i{)cw9V}pjNi_2Y1>Jb@k?BJ!K z2x)}fvn98e!%OU=XxjWUc^m!e)ZD2;gX$qZuN)!J&D&?rwCs|3z7_Mj3!(VpLvJ2K z=-aJv12=knr1cB zw_ww?_H)vwxcA`M>@n^_-1(@of&w4MYlb2C-Wvx`>s(x7H)IT8g+xU5PR!5G%gD=L ziMJ~+pEvUBy{b`ERP^%g+qdCeU0sLK17Vd9FUM=tD5yk^^(=g5ryR84b6p`++JX!W zR<18CEp^1i#5DLn&$BvzUp8XHK?*$dEo=y8UN&s~X{7v`#5cF3DO>lUe$J2<@u$&f z_0+hQ3U=AZlnHaTFUx0je6)s^;Y9gxD%j^`gTnb4wrMs#T%W#YNj&kZ^GJBv1^%jh zz{p-&qqjs_$?Au;q|sZ;b-vYVaQIR+B5354I`ZLbdok{SRBEznu=g#1JZ_>-9~=x7BN zcz-Rm%G1-+aj zPfRTFvJzZ4$%0h2dT=o-tK@k;YIHG9!t}>A*^w^z{Ys*1z|nkbp6dMeg!X&kU*6pi zHh;^L|LEa?XSs-zrM0y`-23h&@(00wO88fB={m zT(CVS%jYc~-^xwR8)}SP?zyb%e!1;U9iYDtkUINFxGGAd_2HFvYl6UZEI&u8!!W565|+Z@|9e)`weElqc27ER_ddj270Q13&HrP)cHrmHffE2+cR zXphguTsu6{=?PT?*Q`9gV3s*t9l1QS+Lf+2nsocJT0p^Lwsv``=#fKe-?YHs;PB6H zsvp$4K(u-bDi38SHF1X17x|Ir_jpE@&vlGe%`lKgOpA#R0;6&^H2302&kn$=y^Xu8XX-iX^rT% z7+A-2tVqgrAwK4%mtXaC4xm{`L=&Q>Ml$J{ z6<=d3D}EFhcryP72A_M8kY+rCIBx$fK}3F~VY7Wn0o*EhS?tGksVa*m>FLYEQ{7ox z4r?XARv7ouCl-Y5Sq_D` z6BG&seO#=#&CNajAxXt8<-UxZcE*Zc``^OZz)!nGrw zp4*2b3phnz9H0H@@C{Qfkg0{982|a~UX^;WE1?M7$f>l)(pgzq?mkobX`Pi4Be>T& z`u?7Y>I1hKAD`!N-0KE`RCv*!Q@`$aq89J!8|*HF>r^mOfb7} z6wA#xY927=ub@_J)@Zqa;soilzHet*(UT0;v<_ey_`#j`!|olQEzQo(zN>uyX7$VX z>HK$+vBbCcmkgWarKK4PpUcHUcCKtb0cV%mIQhwmiO20Ue`~zGiT5UVEdTPBM{@U~ zd7J=(Qw8UF&Qf^f?F6f=rSFZ1XMdBw4;*+?Lu-y1VY&Kedi8NGPcKV5yU*$4+HJI= z7V`SD7cVl9u8H&-`?E%+(u%b#8Q*!|vJ|HnVPWBi2ab5;O0{^1gTdfNWs+xeOtcGO zkNorNf4tm&lBv4pk;b`<(kmb1Fc{1cRO%%+SNPL;{U~eA{C$oG4gmlF1;H{ZOA=gk z7+#GVt6IaH`gno#cIxo`&@1d!u|0;tua*hF9FubfmhVP~SVXQvT<_nO9PNIO*!yU8 z<-&yv!%_W-M~!P;Dm)KjHC!qlGRzBYzl-bc<0mA0%6{Vs;g}Rgrv55gc zrjkRYYYf?r>G<-lI_?_w9-e#5Cp@~Bv*k1-P3Nw5AI-jUVX6QND)LIHJv#I#WOQQn zxcS}|xx?d@E2d-BLGpI{U;EsB^}bOpxs%+#7z~(-wrRH#E>yu^@8-WfPSU!geDjyo zfbBG1U0wan++fM!$HymeBs!fgfU^p0x518e{xky!5T_!S5PPc=dqi-{_>K zq%3gC^M>NF^x#_1LEvXE$6?-7xca@Ddp@PI%7v}Jh#`yQrbF+rSf?~`VM|k1@^KNz z!hT+@?~;{N@CuDQZd+9q7x**^h8VowlNvo2b}LPEI(9m_$d^Q#DkGE03{G_mhaEVu zDL#;Xq?zkMU|pJ0D>A5HsgY+FS__)#uQRvC4y%sb9m{88CIqgF5yS?c8+&!n@hEi7 zy}Nzzs4Ai8{nc-Qlg7h@Vi8Vu%+H>f+0JeAX{k&g&b{pRC@fKXoA4Bur3kUTE z?q#D=y4Y&1bHSBvhgs0}D(z?n!FFd{B$@zp*mkvn8YOz1-WM10yAQ4;!gh-a{GXQi zcXtdXi2m6fLwEn4@~5(i&_HEt&r!I2X_RhgpXw>aM4>kdD<1>bReydAyO~~BY*{hY zKWOoa;o>vI&(7r;2(q0$U-*Yof6&)@=hcE%51+RqvD0AJwJ0TYo=o2DH+drgvm!4f zGFibWU9P750R3?FPGxRE{lenyRrM8W$kxfS#IvK$o46n--_Yq-vG0QGtV*M#F(GlD zhBf#{P54WnE{QD_*BG8sDSM#cyrFVbCHCh;K8w}yDf}0@^r9?H8^OJOLA%X(s<3RA z=fF|#y|4Bj6Y?}*r007Q8;uXj=7FyY47g)l&SvO5Ib=gK%MS6MQ^H*iK3&BAR{V;m zk)l>{&F2P*--G=H8u zc4`sTS%!6W$czhNcdkD=)3A~3^dev=qvwRne=c{p3Bp&;7j2xE(>%Cw3Zu@U7Y0UIC3L zB|)~fmz`$J#y8#dd@vUYFUok|RVN9JHEZ%rtZaX8a~vLZ_u6$>WVpRj=H#lOb~D~_ z?HnZKme{3I&uQDw37))-{{t+=1p@pYf|r9){1Gi|V-5 zQkxYBriEbV*5+6v4CgAtn;pM3LqvaNfi;%zTVJ^_EA&W?=}g%(d?^9pwoh5rW&?8@ z>-IrvzL#*+`YFNnyiLRrg6-w>Q@*564Q#LYFpAXzEva{DPP?!oyKp%%kY#j2>{F(V z@yHV~umHNex3P$odE~&SFYg=f-~1^Lh#L(|C^Y0tJvNXt@#8});U6-}z}Q*- zuP+SY6UZ~F?0lb%WcuFc!i+BtAc8TrO2b# zZ5I79K!IWQkm*8c;xrSGXb~i0n%M?ZwKHTZ*9UN{mPdf*~>Ni%1bvTCLUs zAzmu@5ET&{AQ6-YK_~*L7+FGyY$hyW4MY&+&Sa9-r?-EY%zSgcIp=%N`@V-0MI((dFUGeP!WN@UnAAPzkL-GkHL#B>2M&)FZMKv5)qFB+#+L7;&vX1iNNE& z!9_$;z*#2lQ;2M&p_*Cf}H5vwt;y zq%-QicQ=9QS^r%)60Lmmd7%51?cDL;TJ3uqZ9IQm2iWKx__5-?Yjq~leB0eP&EE&A z@iau&SxRAc&+3P{&U&HG+G0=GwXh3A+0R%9(tg zO+L}HD7bp{>XLg+k>S%1!+B}FgM&6(P2Vso8_psDdQXOCGdhPKpUU{ijA0p)nM|ga zDp>B@`wu7gh)1JrH}P*ptsItCwqfp!ZU-a|1=1gA>o|vXunB+KOQ{^JA>A zcDe|l9yMAL6Tp!z-icS$zicuBePgOgtnL85I{G{l1)U{wTury84bvC71KN?wG=oDl zTuy7*r01)oha%>?m}U?L1xf*&2$fblK$Ng^oxp~}AJJ6+0HZcAjM|QAQNmQJEaQ1! zz^RWYUmH2p4VQ@FJ~azq>y@dURQd#`OQKvM}yx)g0uT>Of1 zD&PORn1QHEBfs&^VdLNbQ+9w1u1_kdc1wS+k6+6vg14$VmpQKmBc#dy{j(#ZORvf^Y#4Pop+Q%M$Z9xyVLO~I(ygMv_|}_71;~Vao&Z}v4>C%ePFOzsOfOSSAl^psTWYhjcc-k2Hd_^0XG#n^Z1$5 zTPdc+GHBz&IJX|sn@(R0k;T>FdAcNc|HLk`M2FJ5L6M443YtY3q7&eIC#abJ9uU!6 zmB2oe?D<4e<7c8S?|{k>^r0+|RTKS6jwQr=iM`jWst-M7Hu|i0yw;U`#G5SePup4Q znBJiDL;cc66#6G67Io5Hk>a+K&v`rREjvQ+L844q0L+m? z7e=Hd`GrHH;T z`zgM;P|D&bS6<~aQNVg^fNNqTGJ1Bl$?OsUWX~4ZfqTJ#9oer8&~jW|KIIwRZ}u<- z(%oxivLgc$7O>mMu+{0Bkq6qumlZ7P*g}r6amKt;qOhXN?_xanE3ipwIkW^^DkYW7 zG~Aul*hog!FfY-zA?_yPqEE_Yw}NHu>dd=hdCcfo9Ny^+OOR-cx~x^749VZ)AIbAg z-5{lLj^6E5GZFSaGe%3M1Lv6_WWO{Ax5~L?$zuc!uq}w!Gak3eRWfHR{`lQ(*nM(6 z7HglHw9z#!f)Ds6c|lTOrx1iLf<<@cv{9U#Q-v{jPQ(F)+B#+_^p*N?Tr)A+O|Bv{ zgq*R*35A+EJ_-VVLFz>+NZU!z`Vs*u7N?r4OY)7&ng1g#NrY%HJ4>GC0->^#{?c?* z{^i?ZqOG*R4%PvyR`R_HyGfhHs2Bt6eRQc2BtG#Si@sra&_dU!2~0;_>oVo+c^^l} z7X)LgcFx<0eJ;p6CcpCJz^Az5AqVtKyQfB9XagYIsXzBrv1-1Hvj|?F7>|?YZ5LY5 zy?m;mO;a-{>vNIfwC)r!h<|~SOtT|*qLpq~FlkHbkRle#d5A%IgRU`La8E1JwWFra62B%wKkJXx$UKQ zWaU`tFeYBlJ?1}9^XI;>na)RCsS$wG4exlpk4Bzu)U@*gd%6^y<4i#_I|EJ?F9ee_YgtUG21H4n^0 zk2WfZYrxpAr^WdFOr#!mzbqz_CPs(2<#_Lu8TZp{+@!h#L0PdxQcKy7G_Y36hP7g_ zlXBiSPTm#*0)&_a3Vjg^^Yl79l4&1xcbiv6*6k79@G28ye#NAt=RwnivD87<3@3vRSM;-;rb2uJW zT0nzUUhA<8uhnpMB|3kM7y?4hwBUGt+}R!2hmz+Tp~8+A-VGXS(^ls$Slu4DYB~5cb#0~9lkSOPxYZ>OY!)TF zv#&ib>|}j-r7YKSI#A}b zhEXQIY^p<+%R$I#Mcg+Y!{Aju7t7rQt*Pdps5JJ2%v?Y9p_+ys>0L=)wU_gjdX!D| zRPq%7xE$Hc((oGcT7qXUG~|p%C#a@a-A3BO9pd~oyUt88|4a!Fh}`8)`m8TB<<$vf zqcuGomSJ9(VfFiJoja?KpaHD4XJV_gEb5}XcMR_GpISoy+O&oru~i1IaHc|ymAx%z zHiP$^tcBv_w{H?s)+LfRhrkDPM3l)4c>xho6*vV_vP-xS-J*N{v0?l{3;_QAqetu;K*U0Ll51Wa_r&{5KKsG&}{VPTyrW? qvoUm*uxrDl=EHB8(`PNKe9G88kNsSGgz0vm1q`09elF{r5}E*gyf3Bz literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_glass_100_b2bacd_1x400.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_glass_100_b2bacd_1x400.png new file mode 100644 index 0000000000000000000000000000000000000000..dee5542fe7bb34f708bc5cef5849316ae1565981 GIT binary patch literal 131 zcmeAS@N?(olHy`uVBq!ia0vp^j6gJjgAK^akKnouq`W*`978O6-=5#d+u$I;?0Emz zulKzTOm+&3+tnRCJmMLg{M=?+Y}i)oqoUdJA^KQh*D9f9Exj9bZ*}B#zgzxC>+oKU fSKR4N9NK!%9&nxt3b}9;XexuJtDnm{r-UW|6V@&v literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-bg_glass_100_f6f6f6_1x400.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_glass_100_f6f6f6_1x400.png similarity index 100% rename from maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-bg_glass_100_f6f6f6_1x400.png rename to maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_glass_100_f6f6f6_1x400.png diff --git a/maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-bg_glass_65_ffffff_1x400.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_glass_65_ffffff_1x400.png similarity index 100% rename from maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-bg_glass_65_ffffff_1x400.png rename to maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_glass_65_ffffff_1x400.png diff --git a/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_gloss-wave_35_525d76_500x100.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_gloss-wave_35_525d76_500x100.png new file mode 100644 index 0000000000000000000000000000000000000000..e537f8e6f5998c5f5af4398a995bd5c4ff2ccd4d GIT binary patch literal 4062 zcmcImYgiKKwx(&OW@^&i#mxJhuBOf~N@-qs8WX21mAv0mQ5=yN?+PL_&2HRYIc93) zZ6{+Xhzt^%2~xWV@8qN?;@uDxkrY7@kwfRqk2BAC&d>elTi^TR`@Xf-_pY_xd|z+R zLkElx004kPSHHh<69Cw=q1(eg-=|xDi(pS3;?*b=idmb_hK{6J$dSkzQ-hlt1M1^VskZlSjLIvG>>h} zkzONuNR9*Rqr#09v>ntncn#(RU2WZBPK2~V!=Z!B4rt=zJ2&?dZckSXU{8yC;**Q` zO>m-}o(vZ^neD`?JtONW>aRLiCW?M~W3t_f25|#vOJz3v1TA^x5Ogw#yU2OO$MIK% z&n3T<6g3sH>%&6c5~STh>3c}~FE2Q}qrAUBH&gk=K~gG~szWY}(1MfC%WaQ@eb%t= z*km*7rux*yOQBDoQE~dd`hWn>p}v@n#s&Gxo|bV7qrx*FFF4E_)KS2ux(pNDST$a& zy6hf&@v|NP@H@bC@&5yxSQJv2>q;}1O`e;t)A-bCd<5MU4Wp9yR_+P(G|SaGvai;| zqD+&fywktjaPMlh#62CpiBdIpvWuslnkEt#WzW=VO@|p{}qh7?ItLa-40aPLYzD; zYHuKHdY|0~eI-1~yo6uNQa#Oy7yD(DgwWvPWtRRh#*|?uv~F{mTzMf?6UDu=l-KtK ze!}u#dN{-~1zKCKB9{aZFdWbOl|!_mZNK!dAt^41Y62^9lH5jC5ErO1^grB;iJ?^^ zSysyOooXXbPF*Ox0GVD4K?~+VYK?&5a?^*US2^*2csbLB-z_!Lr808g)T6xsfDK^3 zla9ild=R_nIc*Lq>HQm+Bnop3=3Zxe8uf?{5 z*X;|h4mpA{NyzjYMJ0~!s-VJ=>MLjxib_2+)}O?ia&H-z*oB~K+GAW;7I8_ZatGf> zxZ>k$JSfG|N1((-`KaCO$AIyWdF9Umj zxOmn>+&|IO=DGfO+jk>=IOF2Ek?iJiGtRp@R$e$`G_DoI?`U{3R^>VhN`rHpVtq{3 zM2sKo_4lK-tKWU`-4Jbx26H=BRbgiR_*$_P+LgBEEP7YMb!ZMhb_8$tc&gT*vXW}EYKbq! z_t(V;d&}eA6`t=SSDN??njm1WjPu0j=x|Or#o6cFI*LX6RM+za6;`vHL9pM>3U4^~nwL2DHk$({zMe8}abw3R=nZ@)JC;>9F)!7BLcX zpw)>*71P(J<)S5cVOX+@h&o6$P2e?raPp7K~zF^!OzQB=5f$_b7h?HlU_76D!D z+S5XBg?^9NE*R>j!j4cU| zboNjwm&>u!!uhpl-5ChH##m^v-2SuJ}?D!}5oMAnSti=X(RJD+%C4_~^YxDzdGYfBG0 zUJ?YpEtI;0fkyzlITPAlwsv#U7VzR{Y@PPbY=(O4&Of#ES5m38Y^RKZtkf=jI>Q?z zV&p>h)m$bUmoqi#vAQ-ECBNqk=oe{RL&VxG_cjJH41-Z)KZ~9Y!#JC73HcGxV*_Al z(t!5eXD`S@7SAXQz7oG*f)aR2fZ)v(nM{AFqT680*A#GHM|sT}mz#NTvMSFnsS4{c zlhH}2!?|=l+xklO6!%v28OMv>UXk0Kg?qnA+}vfVCI6`zqscmWL3ee^BC-HGJz#xc zs_s7y7#jWxrJl|Le&a@Ski=d)lPwY&tKDQK*4hFhwnP+dN)jrUZY-b6U4E$|O?1rY z0sbcc#@vNu`oiEx))yZ&%4!bkO8{U-{K`2^$K%gt5QvYx;>S&JV)jn3XpLAr#RZk) zkxmw+Hp2Wg8x36e4$<0Q6@qzCmu{8qj2nz)R6GWZ= z5>I>@6(;;Ux0V?rFS`C)>=Nqov?YsTx$g`vr0&{V_fj}DLss%z zOT~-TXToHlL^UaxoI$PNZ3JN8%U@NsgKYf=e{FtDyyPiwS;d}G_t;Dm?QyPMKD!ks zb#dnG&9T%;id%cO#*IIYz7Kl;t=sPSbm->c3!k55|1%f=tb8g(H$!azvi~jdR>PBZ z?P^Q)=gGg`^Cz0fo!nLwOwSglL2~^xz(wPRZdhRt- zPw)^kl2&1bPzCs=5(gs|yfkL3(CteUu>rfZWgW8|IAw(n67|S~7_RG8>rodU9}vif z5%#O;ae4|wPI4oU=GCI4Og@+5I-<^Y9KDzL`bVQ-IJ0RiGJPFx^Kk zZ~FMrFY@Me=J-#4iEU=8txmZ|ml42X2ZJAq6JVz|ag4ai_vK#7T5Mn5XvTf~`}?*V zZ7xQ@cut!k+YlAtZRB$wh?+X)Xbl0D^j8`a@4@v0&XVeOlkEe^5UY;0xyAJ6=NmD+ zH{l*@hnIr27SiGsSLi^n5){>IE*iNJPkpZ6gqi8CJyC33cwP>=2@jc~oCpwfdrr%i zJQ=d3^AfPUlA}_hw7Zq;j(a-qKAhUxa@aUZ<>v`9r)6}ij5p`MeTonpb=E|c)8>IC zc%Q9w-CW6il-Fo?q#flFn_MhM-Iuc%zMW+kJW7--T zJ9H|3-83w{sJz2OL`D{ERfU*LBM~AeZND^qznYX>oH9c3)vho@y{+0GWA6&Dw{$Ne z?|Y)GUEXn%Oz5|PF1?w;(2hZHDvH8jNs-Q9?x=QDUP(MIx2^U`E+2QFmZP*UL2@sl zoda<`z}O{B3Tq&8v|waiqN18`@CdRx-P1WqDFVd;iQDrcOaJV`)$sCw4_ zHgGr5A?zss1SYDMouFrhfyVVmGJDO()Pr-4tB%X61=W~vS1tBazbN6k8u>&@@i~EW zi^B3tpia^auX6>q^pJel^-4jFCR`y=1f)KB?b`&5Gb`F2$Qj%q_V+D15oW<*ody<( zhakB`Zb+S>S31?XGsr*1Atoq7O;q3Bcs9o#cbM~>#6i}{wJ2z3nq(9y94E-gC1d36 zYO~mK&@TI=a*C_unH;EDGvU+}_Y{be^dQJaTDXojDyG%K@=n*0pcOF4mtST)N?@o) z{O6j6CyO+<;#)`=c+69$)lTc=Tgvy=N(k!8hluJmtpN@0@cV;kdW@DlPdMCHE>A1x zkz-m0W!A}@UC>^|uNUY^tOMm)R_PA0;0FXUX|iC4uHB7EJ*X>yy&vXnbmriX2CGz~*U`y|~zj7}xa5!Tl(<0)S715-ERKX9@Yf?{C!=Va zetPK~e$jXz%*v#pcR3H;Fd$b1mm72f1M=%akB!oQlZy<@U1#KG4W`oW1KL(hU azH1@moChIz;8!{bxa#43rRBR@cm4|sl1KCa literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_highlight-soft_100_ffffff_1x100.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_highlight-soft_100_ffffff_1x100.png new file mode 100644 index 0000000000000000000000000000000000000000..8169ec3e0e8cd5ef3efcbb2a28eb46544cac674f GIT binary patch literal 86 zcmeAS@N?(olHy`uVBq!ia0vp^j6j^i!3HGVb)pi0l&q(VV~E7m+9=V`FPm j^fNFr;$utaVP#^dU&V5Geb0tfK!psRu6{1-oD!M<@4FPw literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_highlight-soft_75_525d76_1x100.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-bg_highlight-soft_75_525d76_1x100.png new file mode 100644 index 0000000000000000000000000000000000000000..a60c34eee1c27dcc7fa6eec137ea6f097f166522 GIT binary patch literal 130 zcmeAS@N?(olHy`uVBq!ia0vp^j6j^i!3HGVb)pi0l&7bQV~E7mtNq?w4Gs)WM}Oa6 z7^?oF;^!PQ<136!8On750k`XTyf5`LOt`Ih`BckEp(hP-svg^phjdPzFy|KbLh*2~7YMc`wfZ literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-icons_222222_256x240.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_222222_256x240.png similarity index 100% rename from maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-icons_222222_256x240.png rename to maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_222222_256x240.png diff --git a/maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-icons_228ef1_256x240.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_228ef1_256x240.png similarity index 100% rename from maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-icons_228ef1_256x240.png rename to maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_228ef1_256x240.png diff --git a/maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-icons_ef8c08_256x240.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_525d76_256x240.png similarity index 92% rename from maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-icons_ef8c08_256x240.png rename to maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_525d76_256x240.png index 85e63e9f604ce042d59eb06a8428eeb7cb7896c9..4a4167b1e32bd05e9b65bf6555fe8e68db87c29b 100644 GIT binary patch delta 267 tcmbQJG*M}SW_?Ip$v~od`dZ&;w`&>$1A|{lkY6x^gn$vtW_89_`~YE2W6l5o delta 267 tcmbQJG*M}SX8oH!o`FR5^tC=(>C8+91_r;9AirP+2>~OP&FYM=_yG>qfk6NO diff --git a/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_76526c_256x240.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_76526c_256x240.png new file mode 100644 index 0000000000000000000000000000000000000000..b7b84746cb0e4b54b0dbb78aa61b2e947b3729e1 GIT binary patch literal 4369 zcmd^?`8O2)_s3^phOrG}UnfiUEn8(9QW1?MNkxXVDEpFin2{xWrLx5kBC;k~GmPmYTG^FX}c% zlGE{DS1Q;~I7-6ze&TN@+F-xsI6sd%SwK#*O5K|pDRZqEy< zJg0Nd8F@!OxqElm`~U#piM22@u@8B<moyKE%ct`B(jysxK+1m?G)UyIFs1t0}L zemGR&?jGaM1YQblj?v&@0iXS#fi-VbR9zLEnHLP?xQ|=%Ihrc7^yPWR!tW$yH!zrw z#I2}_!JnT^(qk)VgJr`NGdPtT^dmQIZc%=6nTAyJDXk+^3}wUOilJuwq>s=T_!9V) zr1)DT6VQ2~rgd@!Jlrte3}}m~j}juCS`J4(d-5+e-3@EzzTJNCE2z)w(kJ90z*QE) zBtnV@4mM>jTrZZ*$01SnGov0&=A-JrX5Ge%Pce1Vj}=5YQqBD^W@n4KmFxxpFK`uH zP;(xKV+6VJ2|g+?_Lct7`uElL<&jzGS8Gfva2+=8A@#V+xsAj9|Dkg)vL5yhX@~B= zN2KZSAUD%QH`x>H+@Ou(D1~Pyv#0nc&$!1kI?IO01yw3jD0@80qvc?T*Nr8?-%rC8 z@5$|WY?Hqp`ixmEkzeJTz_`_wsSRi1%Zivd`#+T{Aib6-rf$}M8sz6v zb6ERbr-SniO2wbOv!M4)nb}6UVzoVZEh5kQWh_5x4rYy3c!871NeaM(_p=4(kbS6U#x<*k8Wg^KHs2ttCz<+pBxQ$Z zQMv;kVm5_fF_vH`Mzrq$Y&6u?j6~ftIV0Yg)Nw7JysIN_ z-_n*K_v1c&D}-1{NbBwS2h#m1y0a5RiEcYil+58$8IDh49bPnzE7R8In6P%V{2IZU z7#clr=V4yyrRe@oXNqbqo^^LvlLE?%8XaI&N(Np90-psU}7kqmbWk zZ;YBwJNnNs$~d!mx9oMGyT( znaBoj0d}gpQ^aRr?6nW)$4god*`@Uh2e+YpS@0(Mw{|z|6ko3NbTvDiCu3YO+)egL z>uW(^ahKFj>iJ-JF!^KhKQyPTznJa;xyHYwxJgr16&Wid_9)-%*mEwo{B_|M9t@S1 zf@T@q?b2Qgl!~_(Roe;fdK)y|XG0;ls;ZbT)w-aOVttk#daQcY7$cpY496H*`m@+L zeP#$&yRbBjFWv}B)|5-1v=(66M_;V1SWv6MHnO}}1=vby&9l+gaP?|pXwp0AFDe#L z&MRJ^*qX6wgxhA_`*o=LGZ>G_NTX%AKHPz4bO^R72ZYK}ale3lffDgM8H!Wrw{B7A z{?c_|dh2J*y8b04c37OmqUw;#;G<* z@nz@dV`;7&^$)e!B}cd5tl0{g(Q>5_7H^@bEJi7;fQ4B$NGZerH#Ae1#8WDTH`iB&) zC6Et3BYY#mcJxh&)b2C^{aLq~psFN)Q1SucCaBaBUr%5PYX{~-q{KGEh)*;n;?75k z=hq%i^I}rd;z-#YyI`8-OfMpWz5kgJE3I!3ean6=UZi!BxG7i(YBk? z02HM7wS0)Wni{dWbQMRtd-A)_Az!t>F;IwWf~!*)-Az4}yryNkz&9)w>ElA80Oc`6 zHo#9H!Y3*Qx9n@Jn)!w6G^hb;e_n8zpIyXCN`JFkPc)^Q?2MsLNFhMgrcZI-<#1ne zjH;KFf?4eAT9mQZ}ZfHLGA#d%s;SZK4p0FwZT2S^{ zQ2BG1xJsbK6?yrHTjJi|5C0u=!|r!?*4FL%y%3q#(d+e>b_2I9!*iI!30}42Ia0bq zUf`Z?LGSEvtz8s``Tg5o_CP(FbR0X$FlE0yCnB7suDPmI2=yOg^*2#cY9o`X z;NY-3VBHZjnVcGS){GZ98{e+lq~O$u6pEcgd0CrnIsWffN1MbCZDH<7c^hv+Z0Ucf0{w zSzi^qKuUHD9Dgp0EAGg@@$zr32dQx>N=ws`MESEsmzgT2&L;?MSTo&ky&!-JR3g~1 zPGTt515X)wr+Bx(G9lWd;@Y3^Vl}50Wb&6-Tiy;HPS0drF`rC}qYq22K4)G#AoD0X zYw$E+Bz@Zr^50MAwu@$?%f9$r4WHH?*2|67&FXFhXBrVFGmg)6?h3^-1?t;UzH0*I zNVf9wQLNLnG2@q>6CGm>&y|lC`iCFfYd}9i%+xkl^5oBJ?<;aneCfcHqJh7Yl5uLS z9Fx-(kMdcNyZejXh22N{mCw_rX1O!cOE&3>e(ZH81PR95wQC37En4O{w;{3q9n1t&;p)D%&Z%Nw$gSPa!nz8Slh7=ko2am)XARwOWw zpsz0~K!s{(dM$NB=(A=kkp>T(*yU6<_dwIx>cH4+LWl282hXa6-EUq>R3t?G2623< z*RwTN%-fgBmD{fu*ejNn)1@KG?Sg*8z3hYtkQJQjB6 zQ|x>wA=o$=O)+nLmgTXW3_6diA;b4EY{*i*R%6dO2EMg z@6g?M3rpbnfB@hOdUeb96=~I?OIA3@BWAGmTwiQ{x5Cqq<8c10L!P zd@Qk^BseTX%$Q7^s}5n%HB|)gKx}H$d8Sb$bBnq9-AglT2dGR2(+I;_fL|R4p$odJ zllfb0NqI)7=^z~qAm1V{(PkpxXsQ#4*NH9yYZ`Vf@)?#ueGgtCmGGY|9U#v|hRdg- zQ%0#cGIfXCd{Y)JB~qykO;KPvHu|5Ck&(Hn%DF~cct@}j+87xhs2ew;fLm5#2+mb| z8{9e*YI(u|gt|{x1G+U=DA3y)9s2w7@cvQ($ZJIA)x$e~5_3LKFV~ASci8W}jF&VeJoPDUy(BB>ExJpck;%;!`0AAo zAcHgcnT8%OX&UW_n|%{2B|<6Wp2MMGvd5`T2KKv;ltt_~H+w00x6+SlAD`{K4!9zx z*1?EpQ%Lwiik){3n{-+YNrT;fH_niD_Ng9|58@m8RsKFVF!6pk@qxa{BH-&8tsim0 zdAQ(GyC^9ane7_KW*#^vMIoeQdpJqmPp%%px3GIftbwESu#+vPyI*YTuJ6+4`z{s? zpkv~0x4c_PFH`-tqafw5)>4AuQ78SkZ!$8}INLK;Egr;2tS18hEO5=t;QDmZ-qu?I zG+=DN`nR72Xto{{bJp||`k}-2G;5#xg8E~xgz22)^_Z;=K|4@(E&5J)SY2of=olcw z5)@L)_Ntcm!*5nEy0M9v0`S33;pO4TN;>4(Z+19p_0>u#e-vE zXCU(6gAvu~I7Cw(xd%0e59MNLw^U37ZDbsBrj%eDCexw8a3G`nTcXVNL6{B7Hj@i& zbVB{;ApEtHk76q08DJ48dSxd$C(;$K6=FpU<~l9pVoT9arW^Vu{%Bcn4`eIpkOVC| z$)AKYG_`ypM{0@BUb3^9lqi_c?ONH|4UJMJWDowMVjacycX7}9g={O7swOB+{;+?; zjBo!9?+nd)ie#x5IbFW-zBOo0c4q@9wGVt5;pNt`=-~Zgcw#*`m($6ibxtZ`H=e=} zF#GZ~5$%AUn};8U#tRem0J(JTR}d4vR(dgK2ML~lZsPhayJ2h1%sD4FVst| zKF)+@`iNzLRjg4=K8@**0=5cE>%?FDc({I^+g9USk<8$&^qD~@%W0i4b|yMG*p4`N zh}I!ltTRI8Ex$+@V{02Br%xq#O?UlhO{r8WsaZnZCZq0MK9%AXU%MDLT;3=0A9(BV z9VxxxJd7jo$hw3q;3o?yBLmA=azBUrd9>-<_ANs0n3?-Ic*6&ytb@H~?0E(*d>T5n z-HiH2jsDf6uWhID%#n>SzOqrFCPDfUcu5QPd?<(=w6pv1BE#nsxS{n!UnC9qAha1< z;3cpZ9A-e$+Y)%b;w@!!YRA9p%Kf9IHGGg^{+p`mh;q8i7}&e@V3EQaMsItEMS&=X plT@$;k0WcB_jb;cn%_Idz4HO$QU*abf4}+wi?e96N>fbq{{fe7Keqq? literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_ffd27a_256x240.png b/maven-skin/src/main/resources/js/jquery/css/custom-theme/images/ui-icons_ffd27a_256x240.png new file mode 100644 index 0000000000000000000000000000000000000000..e117effa3dca24e7978cfc5f8b967f661e81044f GIT binary patch literal 4369 zcmd^?`8O2)_s3@pGmLE*`#M>&Z`mr_kcwz5Nh&g=McJ3E!;CE1E0ryV5Ro;>nvtvt zk&I==Xd;cVGZ@>q_xtnx{1u%7-D)N|5YqOB>i;(bZ#o62{J2Y9&^D3~R^$o+X? zwbxAEIb)xwCwK3TSR4QVym6N1rVgPmmt0caryBUceHP_&u}{?^Jn7f0PT$#h>UDqI zr!q(F&1jJ2_!jxdAB<)7H$foI*2zuncvu;;$SoU7br=AiJ@4=BC4vNO>DS`&UIB=K z;2)0F*t^FBvVfPuT4FVMSwUw%Xksjyl+;#*DDy%=ocFOyzDLvLR(`zCSOuJ=?FWYn z5ZD!UaoF>-$@=Vt?a&;UQYM$Oqe0ZB?Je?8ZnMxDe&uzzs*zlHd)V58nfJPc8S^({_4bj5HQ_B&EXHWj6wx@B;!mr04b_Mx)UFL)W7`V!c zpMp#C!a!!sh3h491y}^qfimXVY%!+sYu0_DWoJMqpN(FR9LM#jdZ{vJzEck`P^9(1N=4J za9%u4$2J8TAkUaJk_FX%iHuv#svL_mMmp{SR}ifc#ZcXv%CFsT?*>N^6r(%D?1YnU zAaT?UZGlOna6UXXs0m)3YDp}d%hb@)@Y!lK_A&D6{OPlNnj zYY*$b>vnRzL8=CDbQSi!DL3D!P^xhNtwrYByo?h-&OvQZYJ6ka{Re# zSc0ry_d(K$_Q2M{Y^O~DOK(szDOnMi_*h_Rx%eSRxA%n|FuC&=F=)B z_Qsgmj8g!GA+LZOX)gOW}vbo9|l8QW3iYw9qCD{o~xt^HIU>;dV5MJgc0#uHTA z80%Ee_r;G`GUjssm z*AhtwpW%Ly;X4Lq1Zq#ZpuwzrZE$sR087dN{w7PA6|Mo#6wwJP085K+h7+D>NyeX# zk|?MJ^Es)JtP-2eNr0EQe*ZM`&}OU zCD*uSSviE&p}uX|@1g_%|3*ra*MbBV#~cshdcFQ(dGLnTqaO-3{u==x1;Pp2im!#` zuZ2`ThfAmiSzb|4h`c4?^ZoGOF*oXYcV}(ge!v@^bse?daA`Ma+bSZLIg;pIN17vM zIOYfK=@s_Pj?~#lqnY2o?d1$MpoqsYQw%eX%X6Y4*^27{hMWGqILEMnVYUEMW#x7f zu^I*nzXQ@6HJ8n;26 zo^1+Ewi$fN$Unum1(FTb8I#cYgcGklwIExt#Mb(D=x~OTeZ^ubJ)S-ywfdZS?SRCq zDm=eU+CCWO@8S_m!W{alT)zj zZJbjxm5&No5xe_~Jw-i7`&G}=r)POGGfFq+c@kQbB#)ay`coj&C3- z(#&xV@Q3@VJd{qdH4g@4ZJi&mx9e@Io7@~(o5vTrkW>QEO1T-gmlTRHH+3)gcUC0P zk07rvDnf*7Y5J}8!>F_7D^Z3IoH^uGH}_a(ax{Q(IrvV$olf3WN&DY?uYZfvXI(;Vv&EAoQtfH;+4VI_a>yh*J+Cj!?h!QX?O`QXk@@G7AjloJe51Cw*rPXQ>#y?B^^ExRQFui zolmv*C5K|-p){rZiCNai^0H`1(Qr(Hz3v%7NnmriXu2tD>xsbN#*R3*wsZhRj6Lvb zn0Cu=qkC?*e4{NF_3=^bTb1f!g?@ryFH6Zw2tz%A zzz&o{w`dDv66!6Wk9w1-dglS#Sm{doxw&h5Z8&ONmlBBte{J)puaDzc!LC==rPRQK zQNH23?-rIo^MQdt3Tk!B@8l#}fxVtrlc8Y<>ORaVE($DKc{77qV^`+`%_DotrUD=8 z4}L7QnZi3RgUy*tteY-=$SqA2@IZWe(}mI`nzhAT{qC)my#rJsfoS*)xCXj!Tk6=3)cr@Jw#OcNqgS3pg7x|4!A$|w15X!huR*vB3q9Ya4 zF{xuzEQz{9YPl(gk`}Gffut%jotgqp$jZvzRO4EsExf~93vY~04AxH=lR>R3v3Qs2 zy$v4SN%ee@Kz#kDtARaQD`d!R%}#@T1=v8DAow*r>+0d1KS{ZtA~KMtgm)+$JHumW zw=;@qWk&MuG@LKx#K3@&WMw?r=jD2_)(*$LmkCm4_@};QZI|SPe8hIC6xqBy!LQyK z01_xmfNA9UlBU@Kzu7;zQYxHE>OCADA$gwaVqm`eN?XQF@NkrocB}lU4hcCf>wqir z>Ya=PcE!Xm#JG8v@G0lj&~)hScM}X57vGw3g<$^SUls53f|Bk>5FQwqE&{%u(f$!1 zl8+53vyYZ`mEEp&YT<=(krhKrw?~pS{N)?q{0qBR#2Y!w4!hWMdj`a(@A@r$zVB+u z06Hb@_9(cQ_AxbXI|-2w>#QUhp7k<+`z9+(jkh~v-Renr#C9U+&jL4vg6-E$f7@UU z(1fxB8{U2vq}h3rE!Z+n7=(>D&}@9~3mJ^R5}|WVG@!RSh3r{!>QHwg!t29YS&jiR ztyn_q*k9H0efZ7hO*b(WR|G!TDY`rol~Ob4&1OwdM8kbGj`^$~L5gdWYceWwL=PB{~NX=cu3p-{S;hqaE?bSHv$g+SA6bxy+VU3YVTPDj6CN zKLb_(9gM2Y#KW8ONxjH9To^Y)r?ql2cq8+WE438uIF$hjfdLs6-;!jv55jGcc3Ipg z;}aT32NAEGeU;J}&j5=+u`4?%xlwL7?NDn%2={4WS39yn3f;&r=|}5=M-Y2yrxeSw zv%*PmV{_{#Qk1sD>?M2KDapb~z3!E*-LPmCe9q86D%MGSe;4~~K-jKQxq6b^902_{ z%>4G>@Xqk8muR*|vGe5{@7sds2i|i;g}oMkd!o^0=HG+vcPrcN54A zLGv$PlTePRxp~-OSb_*aACO1qc{MpfS-fv(@UmRv%UO)cSt;ee@9(S)f>|~bwU@eZ z=kTS*sdjLclwMZG#?%U3)bq-uj?@@vj~6tq)ZS||Jxz`+di-M5SXM=h3EL`?pB>W9A;`V2vM)vk&%KFy|TAh#AQA zb_?J==3f@%LL{`vU$3Z@A2a9C3aC-YY43dR> pI7J0n@;b3~`)ubvsr|iU(l;L{A#E6J`}eC4usn-0uQEf&{2ws1m(l zFlmZ}YMcJY=eo?o%*@I?2`NblNeMudl#t?di0+w!yaC|_1uvA>yaxz|iX3eBv#HR0ASmSVIKMS&kf`CSAV4g0DJLgPkRO79xj%J<(hH6`bTGj zrr^$JeiHJI?;s&<5pRw-^kj}=E;X0OX+pgz+f5GVt0NQv_gbu0>-8J+F$O>HpW?Lx z+YFO`CV&6VV9fsEwG#js0_-|v*!ujZ*M=jfo457?0Do-z<^}+8bI+qk+W~+$zz%Z& z;L7&@&ns`l8Ofh*WdU0pO%RP^?Xa_h7I}7K#}4Xt`s%-(m-enaPWX$O&- zX~a1aOzn?!r?5wJVBNPJ_o8-(9Fz<_c1LYGxUl(E+Wdx?wkNHH2T%eWq9Kz00h#RB zYKI~=a<9_QqC^n<>hyWlS66waWgyAP#t&TfTWP=Sxa)ukRY%j7WH}(@r=B^W_;b&M zRzPYsb*j^Kou%%`K6VP+dKtR@x~qEHq4rXMxoX-gcSf&->lMY%TMXF!Gw_A)(tp6} z2A%kN3twbr%KyUrrmw24V3d%wzK<-q(M;MTr41}un`P!!xejADEv_CJ{CTif907B& zEP`pDJIZHVgnmxh$EZnBOUxz~Ap+ZzKbFmg39_n-)$wY!Q@i~5aGmHbN7&*gkq9zWgV|2(Zhxl zoDqJp&MxW(qX#C@oF8L)*r$RdSjVFSc$%z?*9%YoZ6sOZ!vtxXtBM<*r82vyC}_Eiz1PJ2L$bttko`=+fH{Ne@G#lMDxkKt_y)O(J5&Ak)w-I znm!vzYX3$kLDG$hOp-KJg~7}M;73BFWA{!a61fe?NJkjR_}Xw+*`O0=AGg7&dUA`A?9`whW zM{fkFf`G`P^9j*|-q9KLvS<191z9a^mK3Lss}W8O=sZ}N$V4Fh*SWF5NbZQ>p{0>$ z0pe}d$*s!y*R&NSXbjmld6{4Y;O89MuDTK0Hn0C?QdL9z1qGegXs! z7$MIGkPkwdHF2os-Z-e85B?5An>yc|m<}>!Iirg%H-%F11XY{{>@kgL>a#6fM9JzBE&an&F>eWh|b0^kJ zNBM5*nCa~(xwn~rG~>GSG9mz3h z9F~64y}giIrz^lfl|_5HpUsG}?Wpr*&f?bS=|9biqivN)-a~u>uK<{Lfcng{663QL zLXzO@*N5)q4C=j6E8nC+P%lEwI#~0wkt;M4Y8!+DYzN2rBuYao1*HRIa^NC9nFeep z+ns5$X9Bh48S-`ss!k&!J#Ddd=j1O-9}?`v(B|>R7wD97BV;nK~quUHx^mj^G6K2GZ1*uSN?iLm!7vHB7_1^TGbKhmnK+K`GYA zocp2=on8LxJH^`7^1ch0ft(MTU$vJB!R@gQ^R`qoX>(=iY#u++3K>oqSpG={?#YVw zp3m99FXk^~<6#X9X1oKYXEH%8t2btG65(u0zF-J)^>8dj0Evc+9_Bd^Y)k9AfW~FV z%iDV(ClS6)TC7eVzh{ml;p4cx8)$TV&qhRWp+dqiw>i32?1;5d>HLrNj=^OdJ<}L) zWxqw8aFI<~_TkMDQHS?`z+KQ?+{ASoy%}RBu6i9?BXbh%OEx1OuZ}?n(VjrT(!B1; zQ!#WA0NBx=^6rJrFVsDCuT4)OTGzZ3$Z4Yqz z&c9+7%g!%zxtv#p2fhHbo98KBwfE&Y(&2#=}qEEU`ECEjlCp=X^_tIoMx>%kBT5k)^c=zyV5w3 zc>DLKY6%=y0igWi9B@4hB}bR6K|+jYBt+}i6Ld|b`*s62c6Ge?zGYvdW)=p90~$Ad zxGB>c<3Dy~hPJ#vNXierOl41xBn_0L<5NhK6JO-LvtS&Z{xjGKfIC6*9%*?tv*?+! zv;Q{?mHN2b|3DEJO}R9w11ZT5QVC(H0u|0n9cVK_@2r%C<)OnZ(3aS0Ux^6G$ja*< z9R~o~9XjhPL)w@vYi6r;H$tR>wW`0-Z&Qed`X0LZY9-~mfso!@dt?5Q;@|K6$mAB& z$J41&y)<{N;QATPeU}BC{lM_@-LlQ2hjX;}6~qdglT zGm%qJm*F^in=w*?j;@C_PCMnXK5Fd^wXV**pZOdS1KbSJsC~s#R;tmXIMb` zHB>sxQg&E5Yf@}d#~Z9D4R{}ZpLm7S=bY0x#k<=H?=R+=W$=Bm2aU*n z)qgD*0#4>GGlHhQ`bx#k=Njc;+9D@{F5`xI^tMkBf{XIzwB=b9KbuuLF7jMTR~Mwt zN#!)9J4&^V@JRe9Y!b2!;$rCLPWZfG`C;Qz`u~TJdCzv->e`=R8uHX_2{Fp&pWJ*h z#A60&bY(j(^P@t_`_pktBV7{tFVoeNWlNA|zgNr&DMjJ_!k2%2s2~F@la$M6k%hWi z7}}hoDuoaN7?lchVk@4DunpEIS$72&uuF&F;&4uhC$L)6IzHHUryR9emzpxwsRXmj zfc}pI#oRCB7Y1;t=*58Gsv7x3PGuW^spn6V&dWf#?*TQ0(|*rr=EeE1o~y1wyQi%)e*oX6iX@$m0F1RtKUT0vgg!8^fWhYLqS zF@EOpFld7>f^kprb~YwMq=^<e|gw?QFyf8ck|ZC^>)3c`b$^C>jCB4Fne_1e$Cqt=4Ud#K~~8Nfa91W zwk17&D?X?4FRzR+5qCiIqPf0};K4$tW$}l~A?u_E=JSe;*f_DO>r{z=U4_<)dY)M! z7O#mizC+GN&#;)k)vkBUS@fZesb{v?YuFlCPRjsT5bxB4@+sqdq}xvvBhTngZ(N1LUCS-ei=5sgE-Tbc z7HK+A_O23MP@sUoc?I?*ZB|F)&%us|2O$#G7V$6z zq>G%6!cu7OEf+_#^A=23Hd6Db9-yK*NQ#S+kjJI7 zhLiLz{>zKKtHH>H;B-cALzj`>@+-~?X2aP7ypf9WMf8q0m)wS!Nkf+&R&&zEjFOUx zlq^>v#VAq}=)?dKRMe+010g9O;qAiaTA4dV+==mw%i3Re)DwZ$Wd5CK1m4Ivy&&Ef zO8W!SpcgA>zfTGAE!{IPJMhdZ`T4{K#7ndDT8K2&*jf=J8O>H*iDJ}ZK}z|$C3U62 z$nZhk4v$QIYzMaV+0`B8S!=9RSYzi*QG#tp>ZY|lY_`}A-zI7)(tV$B9G-tC#zt8m zre~pD7oIFkmIAM=s zw+Iili%nSC?yks)t~q4lTlZW(#5^yUV@+^KvIuQzZDO^*TBz!j#nX%*uiW|{x9q0w diff --git a/maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-bg_highlight-soft_100_eeeeee_1x100.png b/maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-bg_highlight-soft_100_eeeeee_1x100.png deleted file mode 100644 index f1273672d253263b7564e9e21d69d7d9d0b337d9..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 90 zcmeAS@N?(olHy`uVBq!ia0vp^j6j^i!3HGVb)pi0l%l7LV~E7mxPQ=F85a&M@g_{ d|GeK{$Y5lo%PMu^>wln`44$rjF6*2UngE4^EGqy2 diff --git a/maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-icons_ffd27a_256x240.png b/maven-skin/src/main/resources/js/jquery/css/ui-lightness/images/ui-icons_ffd27a_256x240.png deleted file mode 100644 index d9dc50933653200e041d37aa53a93d62c47bb989..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 5355 zcmd^@=Q|sY*Ty4}Sg|)zYE|u`wI#ONCH9`xQd?|dtD4`|Xi-Y3(V{JCM%0KEvu0{j zl!{rKU!T9@IoEmdx!;}pesy2xxv`-(H6;fn005wVsH0&50FeAcz#cj1AJrO$`TP@q zjP;S4m*Wxte|8O5wD8ZkVW5ejDS(Ymij>^ABkr|0FVYv`?#RJ_hw><~sOjk5vKEvy z5lxUuis^dVKZ29ffVDSAR5z5RRet&^bXCMpq=W!7N}aRc)p{)!YN>cfWqEjv>s$c< zj1CVqRFNSCf9$AS2#xfReqHN|ypqd2&c~<;(b+G8;cx{p8|l`q@tWu?v0vl;yk=hk&VJihX@&PDB{&_5G{6r5TgEE90QXSXzJ$k7t*j~wA5oM ze-x+x)m}Fr#3amKua`}N?FOd}d=5kAeNpYKuWQ_jx(Rg^LvraqaXVx+tu__XL;vnc zhH<=7;@RGIj=3ZhObxAS3K+Hw&-a@~O^Z7;9k|T!ciMP#bNRkr{|+}@|{ePlb67nbk6Vb|plUN_e`FIx6F%pP9F z_4(x@TEyd~PM_Qi4^d*PW__x=R#4?8QKoq*V4boD!HW*4PHGn}v%%Q=Iib0TDE1SR z=_>9tJl_~ZSAJ)QH~O0P_V0AeneHH1Vc0dBKS`XrTN>eQ?iO6QCh$6VRfUf+mt+)$ zU8mm|rZw%|KpjFM%kLXLKnJ*6qxnSL7>*n5kW_wG68%d#5gjgzgte1A^kk*;TTXXh z-|fX0&N}yiT7X=vDbGLv_eU<;S5WzZC-qG~B!6x78>*K^G_ zo!-9R2)GJTx06+(bCVTqYm=e)FgM=6I8ZyqZpKWLG1(2XU@iC{_WB&J-obLzhmtMn z3POep2zS)WpN;d5taq5l?@WYUFB^4h6(pH8lQV(kmd8@>0<5CiMA(-ERxCfs5KWOz z78>)WG!_$mZcl?C+4S}kV=o`F5%C7Jk0l&9XbjqY+<0dNtD@MS@x08So$L%T(~A8@8W5|YA1dy=Vz75=E`T% zzVDcM1?Z@qJ*nF8bTYH|ERX-ocPU{E7Y?f7?~TeJ|1z?AqGJV%U2pvT;=WW|+EmfE zUrXd@u0{KZUvr$W*fY@Ro--jl!l_df?ukKbN}zhMaS5Iv{l+2qECf*MqpavU9pc3~ z!v&&c#%d0SGj^P+D!`pG4Wv5wwfz#+M6x{?Ns`pTDuJ194n`z$ouBuxuBT}glEKDa zjhdN`Sn6X{)&5vqm(7-V5%x`17`4!^x(Lf^=+HH#xK_qNN&1W!$W)TDMFA&2)t4 z5%1Il85`{McIiyEUksKpME5j8Rat3~N2aUz2kMby5!Hl& z3}F4`&BD3k{r;e;Jh?t&D$?kIT*Ma=7)e;H#nN{XcEP7~YJ0JmzpLT}ztw%5)EYIbeDBKOM{I!K}muBfF8wCzm0 z(#7wAteiqB2k-7Lbj6V+Pug6rwJb|2Y^#!w2~VCna=R@pa)JDHg!;>tad4R z`R^NM?6(t>OGfOmF^0~#C7plmlZ50vOX-;~%JkxApoLa>o4RHf0r0C;0wSd_#-8mF zxTpUrZ4}NiDaWCx;-&ORR%>MwwSZS;M|k0}|8C_@gANvRnt^uH*|5zEN8dTUv>-x1 zt^&~y(5-Ml+jfBIR-!EpfY?cOc42PR)zneOShI(+KsS?+9dz=(H2N`GO5G$4o)3E8 z_UF2Dw43>r;Fe|Bd+_P*hv^U$M4Ak08w|$=!<8XYzZb3Sl-QjjWH9VjK-MEklM>N#e3$!1N9OXFH?ebg&K+F7*ZhqMc}eDGVg+#Q_s;e zb>Zw)R#xmc8eTPJ^gK!X>svx-;&-cWm&M^_KY0yXBN`_`mRKESW1i+RQYopw>7Bj( z$AH6IoJE8!o=D$dEM=yXeKz{lmIPoD%jhBU&Ypr`Xk*rmF(o$KO(k&hK3uUYb+#ncTdoE6e72h#uI#F1UY~S{aSXI z*B$~5-D;qmX&0-2Ph6up>A-#)#lcl6xQt0F(s6CDOxhe$#E`=#Q-zf3$lb~n5WjE< zS$fc4Im7rfGTi#f$xdpJXYm+#L8B=DKzE{u<8o}j)YR5K45|+n4bp14WC&~<)C={9 zr8{Pfe7ZX8>hI3Kj+g$aq30D*jWn%MFDcVk+R#0~>ej}dSYu1@P+a5lzT2|}x z)Wk48hN5hvE|W7J26{DC^oW83vcqDU+JOcaeg;U;*c&@ z(9E6v#10u)ijEdTRlYqZq=p(aofwmIbkS>6Yv|ry*WQKn4RbmN?{QG|qRkOT5)vIO z2cxEcM(j+Z=SR}2gF`xy-h{ar+A3@9RX%dVYu;H1wgc~E7ZB5sGFhzIO zlosi@omAz&O7iDjn&p{$r4gtIGC%CI{vMH`%ITwGaY4no8tn~{D$|P=o@aH(l^dM= zO6&JfsFuwH6yNVLI2Res;A#quH~hQ9uGE!cOrh`NJ=3oOf@XRsaN}O17C0V8CCG1W zWVh(?+;?xGcFo)1?EVID8UDMd{8p~COkPf!wz^qQ=II^^QnyQgQw|HoGCnDbU`L=N zT@0BM;)ecS5NAQO`3;r5D3PJcd(4RzZ^qYK{dEa=CFMtjh0p3&ZIqYC*dV(?pd3|c zeYQ+&`MmDrlK!pb1a?ab@{FNA9T4YWd4J~vg~?AG@3_OB=w7*$)82V?<1QHUJY!3r zFdz8308a)OLPg%|+Pyyk9g0Zk>J`W*G^PnGNsaCkebliz&v;fB_8mg1Y|(!fTS+|U47=MTve`AbG|A$8&6G%PZ9jmnDoqW)?lq{1nX* z(h3X639tAt2L+vuKC|$S*;N%lLt$-~8k|BYU4EJSfJd;4>!VL++w<@3DyI8b?APLS zHFh0K)>S1Bgm^-l{!0j>Z@RVI-vx~AQ+*yDFPc)+KPQ6DLx+j5Q5OFz@>Gtbe+l3a zMx_wezJIfcTgYCzs!~#+@wLgP&mvc9@wszF$?SxRbZ;=$D@b}tfe2jdDhY9a+AUX1 z7X^ezc+B`3lcZwrEP$n?q;4rR+M^bw;v7*w!|yo85lF8n_NZg+*(2ocMsSP{}|} z{<*&J6k1C1*se>q=u1j12FdhrFrC)$DmpbagCqP;XUuD7>${@12n{w3rAzc@5U5k^#gfx4r_r^)jL&k@#8d++CFfJ$^1^ ziGE%W5JcA{?EI`b1HE=Ed^^v^Zi(ZzK49kvKBCS47iBula_f|eu*PE+%*x$33eKXN z{SC<^=K0S*=@VvzzxV{{3MqeGn>E!;cU6$436*GHB(Vytz9T z@K;ilRXvK;mP)~F%KXiPqz$tsO52_-#{*f}JxNzB)CnP%CL6P70n{~aV3$R-~mm3H$ zPX@~Ec>S1mhv~C32H<)O4_-DtXGn+*?Xy^B9*q46=DyRd^@l-5-|nB zgq@$`CrzcSt6JVM%10upc+8wm#V%_uhIGJXziQbH@P@L&Z!-6$9*@r4Q}o^+ykK}Z zPU-GDuI4E~`UTu{4hD__Pe}J(gr3}<{J>|2ps;Kqy+5ONPP>=8duZ_uvEtyQX^|?p z{QGwhqHC<8q`*zR)$sR5!?y=@w*jtyxvg5qwYBd2p{a|x4(LK}1N~K>*GgCluJyRj z9#6y;S#kwd{%7vcc736i+_UJw`6b(;!{^-oB%VubN}js@*h zT+Wd&%u1>y90a1Js|%?e`qkPgFB%?OPk~66!&Ej%TTG4y#>==JS_ASg?O0_%yx8YJ zdbE$`8a7QMb3--Qtc4B&bNB^%HMMnmGRA;s+5K0n>(5$ARC(5>2?s92i;OW*y@$|B)=wvU{gmVEKy+Ntqf|LJl(N;Gh$5sLx?W*{DDud za^#t7PTIgECPYz@$dTC zES%%GL=%knK2EEx)71-u}Mx!<_?Zc@w<-?-K(P zl1=l^2UG8!129uqv)Q1nQg!OR-#sF8za}M%pY$nz=(93qXJ;=WKaE7+K4;k?;5UN? z2|2fb9khESqM7CrYOVK=3R7yo6Gf>DSo-&9#V^&rM3A&E`=7l^xTqigK0mz)%4}_< zu(nsc7?<<~3$DKO;9Y_2cV@u*GO#|eIkHhcUf-Qad?BJ<&HfH%ZkF1{~5VJ+=OeUQzoz}z&>%EOZuMM8-@S^}-suIl4(xeFsuB5 jQuery UI Example Page - + -

      Developers looking for a modular mail platform on which to build should start by - looking at the modules and libraries used to compose James Server 3.0.

      + -

      IMAP iproviding a flexible codec for IMAP, - command processors and a sample data access layer. In combination with a socket layer, - this library can be used to create an IMAP server.

      + + + -

      The Mailet subproject collects products - related to mailets (mail processing components analogous to servlets). These are independent of the - James server and can be reused in any mailet container.

      - +
      + +
      + -

      Protocols project delivers a lightweight, - and highly extensible framework for mail protocols implementations.

      +
      + + -

      Mailbox is a flexible Mailbox storage - accessible by mail (imap, pop3, smtp,...) and other protocols..

      +

      The Apache James Project delivers a rich set of open source modules and libraries, written in Java, + related to internet mail communication which build into an advanced enterprise mail server.

      + +

      Download your mail server.

      + +

      + + + Early James Server 3.0-M1 + + +

      +

      + + + Stable James Server 2.3.2 + + +

      + +       + + -

      Mime4J parses MIME typed documents (including - - but not limited to - mail). APIs similar to DOM, SAX and pull parsers are exposed.

      +

      Apache projects are developed in an + open and + collaborative manner.

      + +

      All are welcome to the Community! We recommend that Users, Developers, Curious and Fans subscribe to the James + mailing lists and follow @ApacheJames on Twitter.

      + +       + +
      + +
      + + + +

      James Server 3.0 and 2.3.2 are integrated email server with advanced fully functional features.

      + +

      James 3.0 provides a mailet container, delegating to independent processing agents known as mailets. + It benefits from modular architecture, is built on Spring and is moving towards OSGi. + It supports the following protocols:

      + +
        +
      • + SMTP
        • +
      • + LMTP.
        • +
      • + POP3
        • +
      • + IMAP + (see IMAP sub-project).
        • +
      • Sieve filtering into mailboxes for incoming mail.
        • +
      • Fetchmail from POP3 and IMAP accounts.
        • +
      • + NNTP (better known as news, only with Server V2).
        • +
      + +

      You can also try the Hupa WEB-mail solution to give access + from any browser to IMAP mailboxes (hosted by James Server or any other IMAP Server).

      + +       -

      jSPF implements - SPF

      +
      -

      jSieve implements the - Sieve mail filtering language

      +
      + + -

      jDKIM implements - DKIM

      +

      Developers looking for a modular mail platform on which to build can look + at the modules and libraries used to compose James Server 3.0.

      + +

      IMAP provides a flexible codec for IMAP, + command processors and a sample data access layer. In combination with a socket layer, + and a mailbox persistence, this library can be used to create an IMAP server.

      + +

      The Mailet subproject collects products + related to mailets (mail processing components analogous to servlets). These are independent of the + James server and can be reused in any mailet container.

      + +
        +
      • The Mailet API specifies mailets.
        • +
      • The Mailet Basic Toolkit. + collects utilities and lightweight frameworks useful to develop and test mailets.
        • +
      • Standard Mailets collects + general processing mailets with limited dependencies.
        • +
      • Crypto Mailets collects + mailets which perform cryptographic processing such as signing, encrypting, + decrypting and signature verification.
        • +
      + +

      Protocols project delivers a lightweight, + and highly extensible framework for mail protocols implementations.

      + +

      Mailbox is a flexible Mailbox storage + accessible by mail (imap, pop3, smtp,...) and other protocols..

      + +

      Mime4J parses MIME typed documents (including + - but not limited to - mail). APIs similar to DOM, SAX and pull parsers are exposed.

      + +

      jSPF implements + SPF

      + +

      jSieve implements the + Sieve mail filtering language

      + +

      jDKIM implements + DKIM

      + +

      MPT is a scripted functional test tool + suitable for testing mail protocols.

      + +

      Postage generates mail traffic suitable + for stress testing mail servers

      + +       + +
      -

      MPT is a scripted functional test tool - suitable for testing mail protocols.

      +
      -

      Postage generates mail traffic suitable - for stress testing mail servers

      - - - -
      - -
    - - + + + + + + -
    +
    + + + + + + +
    + + + Read all the news in full in the News Archive
     From 7d9e424d1e03e978b8f015084a39c1c2bf6e9c8a Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 05:09:11 +0000 Subject: [PATCH 219/541] List of mailing-lists is now at top of page. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029244 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/mail.xml | 190 ++++++++++++++++----------------- 1 file changed, 94 insertions(+), 96 deletions(-) diff --git a/project/src/site/xdoc/mail.xml b/project/src/site/xdoc/mail.xml index 2b01cdd6889..3c7b410b576 100644 --- a/project/src/site/xdoc/mail.xml +++ b/project/src/site/xdoc/mail.xml @@ -18,18 +18,102 @@ under the License. --> + Mailing lists James Project Web Team + -
    -

    This is a living -document that provides details of mailing lists and guidelines for their -use for the Apache James project.
    Please read the whole document -and find a list of available mailinglists at the bottom of the -page.
    Last Updated June 2006.

    + +
    +

    + Please the guidelines below before subscribing to our lists and join our +community.

    + +

    + Low Traffic  + Subscribe + Unsubscribe + Guidelines + +Archive +

    +

    This is the list where users of the Apache James +(Server) meet and discuss issues. Developers are also expected to be +subscribed to this list to offer support to users of Apache James +(Server).

    +     + +

    + High Traffic  + Subscribe + Unsubscribe + Guidelines + +Archive +

    +

    This is the list where participating developers of +the the Apache James Project meet and discuss issues, code +changes/additions, etc. Subscribers to this list get notices of each and +every code change, build results, testing notices, etc. Do not send +mail to this list with usage questions or configuration problems -- +that's what server-user@james is for.

    +     + +

    + Medium Traffic  + Subscribe + Unsubscribe + Guidelines + +Archive +

    +

    Discussions on the Mime4j + parser library.

    +     + +

    + Very Low Traffic  + Subscribe + Unsubscribe + Guidelines + +Archive +

    +

    This is the list where participating developers of +the the Apache James project discuss changes/additions to the James +websites etc. Subscribers to this list get notifications of every commit +of the website reaourcesDo not send mail to this list with James +software problems -- that's what server-user@james is for.

    +     + +

    + Low Traffic  + Subscribe + Unsubscribe + Guidelines + +

    +

    This is the list for general discussions +relating to the running of the project, it is the public list of the +James project management committee (PMC) and is a public list open to +all. Do not send mail to this list with James software problems +-- that's what server-user@james is for.

    +     + +

    + Very Low Traffic  + Subscribe + Unsubscribe + Guidelines +

    +

    This is the public list for the Mailet API subproject, discussing all Mailet API design and implementation related topics. Questions about using Mailets and their configuration should be addressed to the server-user list.

    +
    +

    A mailing list is an electronic discussion forum that anyone can subscribe to. When someone sends an email message to the @@ -157,11 +241,12 @@ only see part of the conversation.

    The Return-Path header contains the email address which is subscribed.

    -

    To stop subscription for the address john@host.domain , send an email to 

    server-dev-unsubscribe-john=host.domain@james.apache.org
    +

    To stop subscription for the address john@host.domain , send an email to 

    server-dev-unsubscribe-john=host.domain@james.apache.org
    or to 
    server-user-unsubscribe-john=host.domain@james.apache.org
    .

    +

    There are several sites on the net that archive and provide searching for our mailing lists in HTML readable format. @@ -194,94 +279,7 @@ servlet and JSP list archives

    -
    -

    - Now that you have -read the guidelines above please subscribe to our lists and join our -community.

    - -

    - Low Traffic - Subscribe - Unsubscribe - Guidelines - -Archive -

    -

    This is the list where users of the Apache James -(Server) meet and discuss issues. Developers are also expected to be -subscribed to this list to offer support to users of Apache James -(Server).

    -     - -

    - High Traffic - Subscribe - Unsubscribe - Guidelines - -Archive -

    -

    This is the list where participating developers of -the the Apache James Project meet and discuss issues, code -changes/additions, etc. Subscribers to this list get notices of each and -every code change, build results, testing notices, etc. Do not send -mail to this list with usage questions or configuration problems -- -that's what server-user@james is for.

    -     - -

    - Medium Traffic - Subscribe - Unsubscribe - Guidelines - -Archive -

    -

    Discussions on the Mime4j - parser library.

    -     - -

    - Very Low Traffic - Subscribe - Unsubscribe - Guidelines - -Archive -

    -

    This is the list where participating developers of -the the Apache James project discuss changes/additions to the James -websites etc. Subscribers to this list get notifications of every commit -of the website reaourcesDo not send mail to this list with James -software problems -- that's what server-user@james is for.

    -     - -

    - Low Traffic - Subscribe - Unsubscribe - Guidelines - -

    -

    This is the list for general discussions -relating to the running of the project, it is the public list of the -James project management committee (PMC) and is a public list open to -all. Do not send mail to this list with James software problems --- that's what server-user@james is for.

    -     - -

    - Very Low Traffic - Subscribe - Unsubscribe - Guidelines -

    -

    This is the public list for the Mailet API subproject, discussing all Mailet API design and implementation related topics. Questions about using Mailets and their configuration should be addressed to the server-user list.

    -     -
    - + + From 104957e33b2e176d305af5583a1a25455d96a60a Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 05:09:41 +0000 Subject: [PATCH 220/541] Announce Server 3.0-M1. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029245 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/newsarchive.xml | 97 ++++++++++++++++++++++++--- 1 file changed, 86 insertions(+), 11 deletions(-) diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index de0800c9e45..05d1985295b 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -1,47 +1,85 @@ + News Archive James Project Web Team + -
    -
    -
    - -
    + +
    + +
    +
    +
    +
    + + +

    Nov/2010 - Apache Server 3.0-M1 released

     +

    The Java Apache Mail Enterprise Server (a.k.a. Apache James) Project is happy to announce + the release of version 3.0-M1 (Milestone 1) of the Apache James server.

    + +

    The Apache James Server is a 100% pure Java enterprise mail server based on open protocols. + Currently supported are SMTP/LMTP, POP3, IMAP4 protocols together with several different + storage solutions (relational database via JPA and JDBC, File system with MailDir, JCR Content Repsitory).

    + +

    The James server also serves as a mail application platform. It hosts the Apache Mailet API, + and acts has a Mailet container. This feature makes it easy to design, write, and deploy custom applications for mail processing. This modularity and ease of customization is one of James' strengths, and can allow administrators to produce powerful applications surprisingly easily.

    + +

    Features for that version include enhancements to nearly every area of functionality, + including full IMAP support, improved mailing list capabilities, fastfail support, SMTP API + for developing own fastfail filters and the next revision of the Mailet API.

    + +

    This was an exciting time in James development and we thank all contributors.

    + +

    We are still actively looking for eager, capable developers to contribute to James. + If you're interesting in contributing to the James project, please subscribe to the James + mailing lists.

    + +

    Information about James can be found at the James web site + at http://james.apache.org/.

    +

    Sep/2010 - Apache IMAP 0.2-M1 released

    The Apache James Project is pleased to announce a new Apache IMAP release in preparation of the upcoming 3.0-M1 Apache Mail server.

    +

    Sep/2010 - Apache protocols 1.2-M1 released

    The Apache James Project is pleased to announce a new Apache protocols release in preparation of the upcoming 3.0-M1 Apache Mail server.

    +

    Jun/2010 - Apache jSPF 0.9.8 released

    The Apache James Project is pleased to announce a new Apache jSPF release which includes fixed to TXT record escaping and pass the rfc4408-tests-2009.10 testsuite. -

    +

    +

    Jun/2010 - Apache Mailet Base 1.1 released

    The Apache James Project is pleased to announce a new Apache Mailet Base release which fixes a NullPointerException when using MatcherInverter. -

    +

    +

    May/2010 - Apache JSieve 0.4 released

    The Apache James Project is pleased to announce that the forth release of Apache JSieve - an implementation of the Sieve mail filtering language - is now available for download. -

    +

    +

    May/2010 - Apache Mailet Standard 1.0 released

    The Apache James Project is pleased to announce that the first independent release of Apache Mailet Standard - was bundled with James Server 2.3 before - is now available for download.

    +     + +

    Oct/2009 - jDKIM joins Apache James as sub-project

    The Apache James project is pleased to announce the inclusion of a new sub-project called @@ -75,10 +113,12 @@ See the release notes for more details.

    +

    Jun/2009 - Apache jSPF 0.9.7 released

    The Apache James Project is pleased to announce a new Apache jSPF release which included some critical bug fixes.

    +

    Jun/2009 - Apache JSieve 0.3 released

    The Apache James Project is pleased to announce that the third release of Apache JSieve - an implementation of the @@ -88,6 +128,7 @@ See the release notes for more details.

    +

    May/2009 - Apache Crypto Mailets 1.0 released

    The Apache James Project is pleased to announce the first independent release of Apache Cryptographic Mailets (previous versions @@ -95,6 +136,7 @@ Apache James Server). This package contains mailets which encode, decode, sign and verify mail plus cryptology utilities.

    +

    Apr/2009 - Apache Mailet Base 1.0 released

    The Apache James Project is pleased to announce the first independent release of Apache Mailet Base (previous versions @@ -103,12 +145,14 @@ contains lightweight frameworks and utilities likely to be of interest to Mailet developers.

    +

    Mar/2009 - Mime4j 0.6 released

    We are proud to announce the availability of Apache Mime4j-0.6. This release brings another round of API enhancements and performance optimizations. There has been a number of notable improvements in the DOM support. MIME stream parser is expected to be 50% faster when line counting is disabled. Please also note that as of this release Mime4j requires a Java 1.5 compatible runtime

    +

    Feb/2009 - MailetDocs Maven Plugin 0.1 released

    The Apache James Project is pleased to announce the first release of the @@ -117,6 +161,7 @@ For more information, see the release notes.

    +

    Jan/2009 - Apache Mailet 2.4 released

    The Apache James Project is pleased to announce the first independent release of Apache Mailet (previous versions @@ -124,8 +169,11 @@ Apache James Server). The Mailet API defines a standard approach to enterprise mail processing.

    +     + +

    October/2008 - Mime4j 0.5 released

    We are proud to announce the availability of APACHE Mime4j-0.5. This release addresses a number of important issues discovered since 0.4. In particular, it improves Mime4j ability to deal with malformed data streams including those intentionally crafted to cause excessive CPU and memory utilization that can lead to DoS condition

    This release also fixes a serious bug that can prevent Mime4j from correctly processing binary content

    @@ -135,6 +183,7 @@ of RFC3028 - Sieve: A Mail Filtering Language for Java.

    +

    Aug/2008 - Mime4j 0.4 released

    We are proud to announce the availability of APACHE Mime4j-0.4. This release brings a number of significant improvements in terms of supported capabilities, flexibility and performance:

      @@ -145,6 +194,7 @@
    • More comprehensive header parsing including support for RFC1864, RFC2045, RFC2183, RFC2557 and RFC3066
    • Revised packaging and exception hierarchy. MimeException now extends IOException
    +

    Apr/2008 - jSPF-0.9.6 released

    We are proud to announce the availability release of APACHE jSPF-0.9.6. This release fix two possible NullPointerExceptions and handle the "exp=" modifier correctly.

    @@ -155,56 +205,81 @@
    And
    2) James' provided mailing list manager is fine for small closed groups, but lacks the functionality of a more robust MLM, the project is to add some all or more of the following features subscriber and message moderation, double opt-in and bounce handling.

    +     +

    Sept/2007 - jSPF-0.9.5 released

    We are proud to announce the availability of APACHE jSPF-0.9.5. This release brings initial support for asynchronous processing and is fully RFC4408 compliant.

    +

    May/2007 - Apache Mime4J 0.3 Final Released

    After almost 2 years the Apache James team is proud to announce the availability of Apache Mime4J 0.3. This is the first release under the ASF umbrella.

    +

    May/2007 - Mailet API sub-project lives

    Following a decision taken by the James PMC a few months ago, the Apache Mailet API project is now independent of James Server and has its own webpage and its own source repository.

    +

    Apr/2007 - James Server 2.3.1 Final Released

    James PMC is proud to announce the availability of the final release of James Server 2.3.1. More informations on what has been fixed since the 2.3.0 release can be found in the changelog.

    +

    Apr/2007 - James Server 2.3.1 RC1 released

    James PMC is proud to announce the availability of the first release candidate of James Server 2.3.1. This release is maintenance release. See the changelog for more detail.

    +

    Apr/2007 - Apache James Project Guidelines published

    The James PMC has approved - for the first time - a set of guidelines for the project. These guidelines are intended to reflect and summarize well-known practices in our community. They include "... definitions of how conflict is resolved by voting, who is able to vote, and the procedures to follow for proposing and making changes to the Apache James products."

    +

    Feb/2007 - jSPF-0.9b4 released

    James PMC is proud to announce the availability of the fourth beta of jspf 0.9. This version pass all tests in the last official release of the spf testsuite.

    +

    Feb/2007 - Feathercast features James

    James PMC member and commiter Danny Angus was interviewed about James by David Reid for Feathercast episode 24. You can download the podcast from here.

    +

    Jan/2007 - Mailet API to become a sub-project

    The James commiters have voted to promote the Mailet API to its own James sub-project.
    This move will provide a clearer division between development of the API and development of James server, and we hope this will encourage more participation from external projects.

    The effort will start small, by releasing the current version, and move on to look at the enhancements we've been discussing over on the mailet api list where we will extend a warm welcome to anyone who has something to contribute.

    Eventually we hope to extend the scope of the sub-project to include things like a Reference Implementation independent of James Server and suitable for embedding, an SDK, and possibly a TCK.

    +     + +

    Oct/2006 - James Server 2.3.0 Final Released

    James PMC is proud to announce the availability of the long awaited final release of James Server 2.3.0. More informations on what's new can be found in the changelog.

    +

    Sep/2006 - jSPF 0.9 b3 Released

    James PMC is proud to announce the availability of the third beta of jspf 0.9. This version has start to use the official spf testsuite to fix all rfc issues.

    +

    Aug/2006 - James Server 2.3.0 RC3 Released

    James PMC is proud to announce the availability of the third, and hopefully last, release candidate of James Server 2.3.0. More informations on what's new can be found in the changelog.

    New development roadmaps are being discussed right now, so stay tuned for 2.3.0 final and for the following news. - Sep/2006

    +

    Aug/2006 - James Products website revamped

    We just finished a major update of james products to be able to publish each product specific site under this new website structure

    +

    Jul/2006 - James Server 2.3.0 on the way

    After a long time of development we have released the first release candidate of James Server 2.3.0. After a period of user testing version 2.3.0 will be released.

    +

    Jul/2006 - New project James jSPF

    James PMC is happy to announce that we are working on a Java implementation of the SPF specification. The first betas are already available for download.

    +     + -

    James PMC react to the closure of Apache Avalon.

    + +

    James PMC react to the closure of Apache Avalon.

    James PMC would like to reassure all of our users that James Server is alive and well. All of the James team have kept abreast of the Avalon developments culminating in the closure of the Avalon project and dispersal of its codebase. We are are keen to stress that this has little impact on our ability to support and develop Server in both the short and long terms.
    Over the coming months we will be finalising and publishing a road map for James Server which will address all of the specific concerns raised by Avalon's closure, but rest assured James Server' future is safe, and we have enthusiasm and plans aplenty.
    In the meantime we would like to extend our best wishes to all our friends from Avalon, here's luck with your future projects guys!
    If you are at all concerned please subscribe to the server-user mailing list and raise your points there. - 05/Jan/2005

    James product sources have moved to "Subversion"

    Subversion is a version control system like CVS, but it has advantages over CVS for Apache Software Foundation (ASF) projects.
    In common with all other ASF projects we have reviewed our use of CVS and migrated our code to Subversion.
    -Have a look at this FAQ for further details. - 05/Jan/2005

    + Have a look at this FAQ for further details. - 05/Jan/2005

    - + + +

    + + From 4ca1bd3fcf895ba3caec300aeaf9960f183d6ad7 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 05:10:27 +0000 Subject: [PATCH 221/541] Remove "Project" from "Project Guidelines" to lighten menu. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029246 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 96e63f7b1c5..380b34d984e 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -66,7 +66,7 @@ - + From 2bbfc185748a42bf78d7796a05059361951e28b4 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 05:40:06 +0000 Subject: [PATCH 222/541] Tabbed layout to have less large page - content update further to ml comments - download buttons git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029250 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 149 +++++++++++++++++-------- 1 file changed, 104 insertions(+), 45 deletions(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index 85b028a33af..527ee2b7828 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -23,14 +23,34 @@ Overview James Project Team + + + + + + - - -
    + - -
    + +
    -
    + + +
    + +

    Apache James Server is a 100% pure JAVA capable Mail Server running on Java 1.5 onwards. James integrates emailing protocols such as:

    @@ -52,31 +72,59 @@ (only with Server V2, support is discontinuated in Server V3). +

    Download your mail server.

    +

    + + + Early James Server 3.0-M1 + + +

    +

    + + + Stable James Server 2.3.2 + + +

    +

    James Server provides a mailet container: the email processing is delegated to independent, extensible, pluggable agents specified by the Mailet API. Any function which is not already available (from James or from a third party) can be developed.

    James Server's architecture is modular, component based and offers a Inversion of Control - mail platform. All developments and implementations are based on open technical standards.

    + mail platform. All developments and implementations are based on open technical standards.

    -
    +

    You can have also have a look on our to do list and + join the community via the mailing list + and @ApacheJames on Twitter.

    + + -
    		- -
    + - +
    + +

    James 3.0 Milestone 1 is a proposed milestone release allowing a preview of the James 3.0 features. We strongly encourage to download and test it.

    +

    + + + Early James Server 3.0-M1 + + +

    +

    Feedback welcomed either through the mailing lists or JIRA.

     - +

    The James 3 code base has many new features @@ -84,6 +132,14 @@ James 3 (development) supports Spring and is moving towards OSGI.

    +

    + + + Snapshot James Server 3.0 + + +

    +

    It is recommended only for advanced users who are willing to accept that development is ongoing and that they may need to participate actively. Users are strongly recommended to subscribe to the server-dev @@ -91,18 +147,25 @@ - + -

    James 2.3.2 is a mature, production ready code stream with minimal development. - James 2.3.2 is still the official stable release and is available for download - here. - James 3.0 will soon replace 2.3.2 as recommended release.

    +

    James 2.3.2 is a mature, production ready code stream with minimal development + and is still the official stable release. James 3.0 will soon replace 2.3.2 + as recommended release.

    +

    + + + Stable James Server 2.3.2 + + +

    James 2.3.2 uses the Avalon framework. Avalon development has now stopped but the framework is mature, stable and of proved production quality. - See also the release notes for details on + See also the release notes for details on 2.3.2 bug fixes.

    +     - -
    - -
    -
    - + + +
    + @@ -269,6 +328,14 @@ + + + + + + + + @@ -302,15 +369,7 @@ - - - - - - - - - + @@ -351,7 +410,7 @@ - + @@ -359,7 +418,7 @@ - + @@ -382,21 +441,21 @@ - - - + + + -
    Item
    Alternate Mail storesExperimentalyesyes
    JDBC Users Stable1.2
    Alternate Mail storesExperimentalyesyes
    Alternate Mail storesAlternate User Stores Experimental yes yes
    Deployment in OSGI containerPlanned planned no
    Configuration Hot ReloadPlanned planned no
    Java 1.4noJava 1.5Requirement yesno
    - -
    +
    + +
    + +
    -
    -

    See here.

    -
    + From c8406be9e3ad8bf3ab3e14f077ad0783f2bba7f4 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 05:40:31 +0000 Subject: [PATCH 223/541] Download link fix. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029251 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 06b00036c56..edd832fabfc 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -54,7 +54,7 @@

    - + Stable James Server 2.3.2 From 4368c87fb5fb34cadd5da609d6a243560d0fd383 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 06:27:56 +0000 Subject: [PATCH 224/541] Fix Download sentence. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029258 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 2 +- project/src/site/xdoc/index.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index 527ee2b7828..a3d6e9a301c 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -72,7 +72,7 @@ (only with Server V2, support is discontinuated in Server V3). -

    Download your mail server.

    +

    Download James Mail Server.

    diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index edd832fabfc..062ba299d9a 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -43,7 +43,7 @@

    The Apache James Project delivers a rich set of open source modules and libraries, written in Java, related to internet mail communication which build into an advanced enterprise mail server.

    -

    Download your mail server.

    +

    Download James Mail server.

    From 22f7960deb68c962b2d7287f59979f68f7f558a5 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 06:36:52 +0000 Subject: [PATCH 225/541] Add info box with 3.0-M1 release and tks. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029260 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 062ba299d9a..265a1d557a5 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -40,6 +40,14 @@ +

    +
    +

    + Hey! James 3.0-M1 is out! Thank you to everyone who contributed code, + documentation, bug reports, and feedback.

    +
    +
    +

    The Apache James Project delivers a rich set of open source modules and libraries, written in Java, related to internet mail communication which build into an advanced enterprise mail server.

    From 1571f114452cdc817b9f318ef50d4d754c795c92 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 06:39:40 +0000 Subject: [PATCH 226/541] Update on info boxes. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029261 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 265a1d557a5..b289ae821d8 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -43,7 +43,7 @@

    - Hey! James 3.0-M1 is out! Thank you to everyone who contributed code, + Hey! James Server 3.0-M1 is out! Thank you to everyone who contributed code, documentation, bug reports, and feedback.

    From 41f52c7f5d23ad98cdd2b73e48f68450ff228aa8 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 08:54:18 +0000 Subject: [PATCH 227/541] Announce 3.0-M1 in red. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029277 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index b289ae821d8..426321c189f 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -40,14 +40,25 @@ +
    +
    +

    + Hey! + James Server 3.0-M1 is out! Thank you to everyone who contributed code, + documentation, bug report, feedback... +

    +
    +
    +

    The Apache James Project delivers a rich set of open source modules and libraries, written in Java, related to internet mail communication which build into an advanced enterprise mail server.

    From 04652bbe38fa64369bc16a39d5e28b82175ae854 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 10:28:30 +0000 Subject: [PATCH 228/541] Display an alert box when clicking on 3.0-M1 download button. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029299 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 4 ++-- project/src/site/xdoc/index.xml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index a3d6e9a301c..b144772ad9c 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -75,7 +75,7 @@

    Download James Mail Server.

    - + Early James Server 3.0-M1 @@ -113,7 +113,7 @@

    - + Early James Server 3.0-M1 diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 426321c189f..3f0966e1a4e 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -66,7 +66,7 @@

    - + Early James Server 3.0-M1 From 9e50b5426781a472534d8e6d49898dc76384f876 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 31 Oct 2010 15:59:32 +0000 Subject: [PATCH 229/541] Updates further to 3.0-M1 artifacts uploaded and mirrored. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1029388 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 21 ++++++---- project/src/site/xdoc/download.xml | 55 +++++++++++++++++++------- project/src/site/xdoc/index.xml | 8 ++-- project/src/site/xdoc/newsarchive.xml | 2 +- 4 files changed, 60 insertions(+), 26 deletions(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index b144772ad9c..a6034e02f2e 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -52,10 +52,17 @@ -

    Apache James Server is a 100% pure JAVA capable Mail Server running on Java 1.5 onwards. - James integrates emailing protocols such as:

    +
    +
    +

    + Hey! James Server 3.0-M1 is out.

    +
    +
    + +

    Apache James Server is a 100% pure JAVA capable Mail Server running on Java 1.5 onwards. + James integrates emailing protocols such as:

    -
    + +

    @@ -458,6 +460,8 @@
    +

    +
    diff --git a/project/server/src/site/xdoc/todo.xml b/project/server/src/site/xdoc/todo.xml index 0b389e93a3c..6a8381dbad1 100644 --- a/project/server/src/site/xdoc/todo.xml +++ b/project/server/src/site/xdoc/todo.xml @@ -21,7 +21,7 @@ - TODO + James Server - To Do Serge Knystautas Charles Benett Peter M. Goldstein @@ -30,10 +30,11 @@ -
    +

    This is a living document that will give new and existing volunteers some areas where we need help. As always, any help is appreciated, be it documentation, code, suggestions, or feedback. Last Updated July 2006.

    +
    diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index ec787fb5718..46fb45ef73b 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -29,7 +29,7 @@

    Use the links below to download the product from one of - our mirrors. You must verify the + our mirrors. You must verify the integrity of the downloaded files using signatures downloaded from our main distribution directory.

    @@ -114,6 +114,25 @@ + + +

    The software listed above represents the latest Release Build + available from the Apache James Project.

    + +

    The James project also provides + Nighly Builds: + periodic snapshots during development. Generally, these are considered + stable snapshots, but they have not undergone as much testing as a + Release Build, nor have they been voted upon for release by the + developer community. These are simply convenient test builds. + Sometimes the purpose for a Nightly Build could be soliciting feedback on + a specific change.

    + +

    James continous integration can be found on + Hudson.

    + +     +
    @@ -480,25 +499,6 @@
    -
    - -

    The software listed above represents the latest Release Build - available from the Apache James Project.

    - -

    The James project also provides - Nighly Builds: - periodic snapshots during development. Generally, these are considered - stable snapshots, but they have not undergone as much testing as a - Release Build, nor have they been voted upon for release by the - developer community. These are simply convenient test builds. - Sometimes the purpose for a Nightly Build could be soliciting feedback on - a specific change.

    - -

    James continous integration can be found on - Hudson.

    - -
    - diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index ce0422f4d3d..4d6412f777d 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -66,7 +66,7 @@

    - + Early James Server 3.0-M1 From dcc0714dc180e761f3df20ba52d69b1d959fb204 Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 2 Nov 2010 15:45:25 +0000 Subject: [PATCH 231/541] Correct broken link to release notes v3. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1030089 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 46fb45ef73b..ce87b54071c 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -141,7 +141,7 @@

    This release is the first milestone based on release. See the Release Notes + href="http://james.apache.org/server/3/release_notes.html">Release Notes for a detailed list of changes.

      From 1536a996a0a3df5a3a8df6c80b193a76ef98ede8 Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 2 Nov 2010 21:39:36 +0000 Subject: [PATCH 232/541] Remove uneeded link to guideline - Move archive to top. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1030241 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/mail.xml | 143 +++++++++++++++------------------ 1 file changed, 67 insertions(+), 76 deletions(-) diff --git a/project/src/site/xdoc/mail.xml b/project/src/site/xdoc/mail.xml index 3c7b410b576..8f407dffe77 100644 --- a/project/src/site/xdoc/mail.xml +++ b/project/src/site/xdoc/mail.xml @@ -35,9 +35,7 @@ community.

      Low Traffic  Subscribe Unsubscribe - Guidelines - -Archive + Archive

      This is the list where users of the Apache James (Server) meet and discuss issues. Developers are also expected to be @@ -49,9 +47,7 @@ subscribed to this list to offer support to users of Apache James High Traffic  Subscribe Unsubscribe - Guidelines - -Archive + Archive

      This is the list where participating developers of the the Apache James Project meet and discuss issues, code @@ -65,11 +61,9 @@ that's what server-user@james is for.

      Medium Traffic  Subscribe Unsubscribe - Guidelines - -Archive + Archive

      -

      Discussions on the Mime4j +

      Discussions on the Mime4j parser library.

      @@ -77,9 +71,7 @@ Archive Very Low Traffic  Subscribe Unsubscribe - Guidelines - -Archive + Archive

      This is the list where participating developers of the the Apache James project discuss changes/additions to the James @@ -92,7 +84,6 @@ software problems -- that's what server-user@james is for.

      Low Traffic  Subscribe Unsubscribe - Guidelines @@ -108,13 +99,72 @@ all. Do not send mail to this list with James software problems Very Low Traffic  Subscribe Unsubscribe - Guidelines

      This is the public list for the Mailet API subproject, discussing all Mailet API design and implementation related topics. Questions about using Mailets and their configuration should be addressed to the server-user list.
    -
    +
    +

    + First, find out the particular email adress to which ezmlm is sending. + The email headers are visible in Microsoft Outlook via the messages menu + "View | Options". +

    + 
    +        Microsoft Mail Internet Headers Version 2.0
+        ...
+        List-Unsubscribe: <mailto:server-user-unsubscribe@james.apache.org>
+        List-Help: <mailto:server-user-help@james.apache.org>
+        List-Post: <mailto:server-user@james.apache.org>
+        List-Id: "James Server Users List" <server-user.james.apache.org>
+        Reply-To: "James Server Users List" <server-user@james.apache.org>
+        Delivered-To: mailing list server-user@james.apache.org
+        ...
+        Return-Path: server-user-return-12345-john=host.domain@james.apache.org
+        ...
+
    +

    + The Return-Path header contains the email address which is subscribed. +

    +

    To stop subscription for the address john@host.domain , send an email to 

    server-dev-unsubscribe-john=host.domain@james.apache.org
    + or to 
    server-user-unsubscribe-john=host.domain@james.apache.org
    . +

    +
    + +
    +

    There are several sites on the net that archive and +provide searching for our mailing lists in HTML readable format. +

    +

    +

    +

    +
    + +

    A mailing list is an electronic discussion forum that anyone can subscribe to. When someone sends an email message to the mailing list, a copy of that message is broadcast to everyone who is @@ -219,67 +269,8 @@ list and send your messages to that mailing list only. Do not send your messages to multiple mailing lists. The reason is that people may be subscribed to one list and not to the other. Therefore, some people will only see part of the conversation.

    - -

    - First, find out the particular email adress to which ezmlm is sending. - The email headers are visible in Microsoft Outlook via the messages menu - "View | Options". -

    - 
    -        Microsoft Mail Internet Headers Version 2.0
-        ...
-        List-Unsubscribe: <mailto:server-user-unsubscribe@james.apache.org>
-        List-Help: <mailto:server-user-help@james.apache.org>
-        List-Post: <mailto:server-user@james.apache.org>
-        List-Id: "James Server Users List" <server-user.james.apache.org>
-        Reply-To: "James Server Users List" <server-user@james.apache.org>
-        Delivered-To: mailing list server-user@james.apache.org
-        ...
-        Return-Path: server-user-return-12345-john=host.domain@james.apache.org
-        ...
-
    -

    - The Return-Path header contains the email address which is subscribed. -

    -

    To stop subscription for the address john@host.domain , send an email to 

    server-dev-unsubscribe-john=host.domain@james.apache.org
    - or to 
    server-user-unsubscribe-john=host.domain@james.apache.org
    . -

    -     -
    +
    -
    -

    There are several sites on the net that archive and -provide searching for our mailing lists in HTML readable format. -

    -

    -

    -

    -
    - From 5cdf08293eaf9515237c7cb96e5d6fc4c859b410 Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 2 Nov 2010 21:39:54 +0000 Subject: [PATCH 233/541] Add twitter account name in widget. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1030242 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 4d6412f777d..4a4140c5e18 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -210,7 +210,7 @@ search: 'from:ApacheJames OR #ApacheJames', interval: 6000, title: 'Apache James Conversations', - subject: '', + subject: '@ApacheJames', width: 250, height: 300, theme: { From ce7f4051ddf188f5f2ce702e6c4915b12e48cd51 Mon Sep 17 00:00:00 2001 From: eric Date: Sat, 6 Nov 2010 15:06:10 +0000 Subject: [PATCH 234/541] Announce 3.0-M2 release. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1032089 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 6 ++-- project/src/site/xdoc/download.xml | 41 +++++++++++++------------- project/src/site/xdoc/index.xml | 10 +++++-- project/src/site/xdoc/newsarchive.xml | 19 ++++++++---- 4 files changed, 44 insertions(+), 32 deletions(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index f68d462c0bb..8128773b08c 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -55,7 +55,7 @@

    - Hey! James Server 3.0-M1 is out - Read more.

    + Hey! James Server 3.0-M2 is out - Read more.

    @@ -83,7 +83,7 @@

    - Early James Server 3.0-M1 + Early James Server 3.0-M2

    @@ -121,7 +121,7 @@

    - Early James Server 3.0-M1 + Early James Server 3.0-M2

    diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index ce87b54071c..3285a4c1971 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -29,18 +29,19 @@

    Use the links below to download the product from one of - our mirrors. You must verify the - integrity of the downloaded files using signatures downloaded from - our main distribution directory.

    + our mirrors. You must verify the + integrity of the downloaded files using signatures downloaded from + our main distribution directory.

    Only current recommended releases are available on the main - distribution site and its mirrors. Older releases are available from - the archive download - site.

    + distribution site and its mirrors. Older releases are available from + the archive download + site.

    • Apache James Server
    • Apache James Hupa is available from the James maven repositories (*)
      • +
    • Apache James Protocols is available from the James maven repositories (*)
    • Apache James IMAP is available from the James maven repositories (*)
    • Apache James Mailbox is available from the James maven repositories (*)
    • Apache Mime4j
      • @@ -120,13 +121,13 @@ available from the Apache James Project.

      The James project also provides - Nighly Builds: - periodic snapshots during development. Generally, these are considered - stable snapshots, but they have not undergone as much testing as a - Release Build, nor have they been voted upon for release by the - developer community. These are simply convenient test builds. - Sometimes the purpose for a Nightly Build could be soliciting feedback on - a specific change.

      + Nighly Builds: + periodic snapshots during development. Generally, these are considered + stable snapshots, but they have not undergone as much testing as a + Release Build, nor have they been voted upon for release by the + developer community. These are simply convenient test builds. + Sometimes the purpose for a Nightly Build could be soliciting feedback on + a specific change.

      James continous integration can be found on Hudson.

      @@ -137,7 +138,7 @@
      - +

      This release is the first milestone based on release. See the

    • Binary (Unix TAR): james-server-container-spring-3.0-M1-bin.tar.gz [PGP]
      • + href="[preferred]/james/server/james-server-container-spring-3.0-M2-bin.tar.gz">james-server-container-spring-3.0-M2-bin.tar.gz [PGP]
    • Binary (ZIP Format): james-server-container-spring-3.0-M1-bin.zip [PGP]
      • + href="[preferred]/james/server/james-server-container-spring-3.0-M2-bin.zip">james-server-container-spring-3.0-M2-bin.zip [PGP]
    • Source (ZIP Format): james-server-3.0-M1-source-release.zip [PGP]
      • + href="[preferred]/james/server/james-server-3.0-M2-source-release.zip">james-server-3.0-M2-source-release.zip [PGP]
    diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 4a4140c5e18..353ad7e10e3 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -44,7 +44,7 @@

    Hey! - James Server 3.0-M1 is out! Thank you to everyone who contributed code, + James Server 3.0-M2 is out! Thank you to everyone who contributed code, documentation, bug report, feedback...

    @@ -67,7 +67,7 @@

    - Early James Server 3.0-M1 + Early James Server 3.0-M2

    @@ -207,7 +207,7 @@ new TWTR.Widget({ version: 2, type: 'search', - search: 'from:ApacheJames OR #ApacheJames', + search: 'from:ApacheJames OR #ApacheJames OR @ApacheJames', interval: 6000, title: 'Apache James Conversations', subject: '@ApacheJames', @@ -239,6 +239,10 @@
      +
    • Nov/2010 - +
    • Nov/2010 - diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 4faf6dbdb19..06c4d37729b 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -18,27 +18,34 @@ +

      Nov/2010 - Apache Server 3.0-M2 released

       +

      The Java Apache Mail Enterprise Server (a.k.a. Apache James) Project is happy to announce + the release of version 3.0-M2 (Milestone 1) of the Apache James server.

      +

      M2 is not only a fast corrective release on M1 (issues related to JMX + security configuration on Windows platforms,...), but also contains an important number + of enhancement and JIRA fixes.

      +

      For example, memory usage has been reduced thanks to optimizations on + the ActiveMQ component usage (responsible for the mail spooling).

      +

      We thank all Users for their feedback and tests and we encourage + anyone to discover this Milestone 2 release.

      +

      If you're interested in contributing to the James project, please subscribe to the James + mailing lists.

      +

      Nov/2010 - Apache Server 3.0-M1 released

      The Java Apache Mail Enterprise Server (a.k.a. Apache James) Project is happy to announce the release of version 3.0-M1 (Milestone 1) of the Apache James server.

      -

      The Apache James Server is a 100% pure Java enterprise mail server based on open protocols. Currently supported are SMTP/LMTP, POP3, IMAP4 protocols together with several different storage solutions (relational database via JPA and JDBC, File system with MailDir, JCR Content Repsitory).

      -

      The James server also serves as a mail application platform. It hosts the Apache Mailet API, and acts has a Mailet container. This feature makes it easy to design, write, and deploy custom applications for mail processing. This modularity and ease of customization is one of James' strengths, and can allow administrators to produce powerful applications surprisingly easily.

      -

      Features for that version include enhancements to nearly every area of functionality, including full IMAP support, improved mailing list capabilities, fastfail support, SMTP API for developing own fastfail filters and the next revision of the Mailet API.

      -

      This was an exciting time in James development and we thank all contributors.

      -

      We are still actively looking for eager, capable developers to contribute to James. If you're interesting in contributing to the James project, please subscribe to the James mailing lists.

      -

      Information about James can be found at the James web site at http://james.apache.org/.

      From f7aa488829f2d8bf9ac9072352bd050ca6b41c05 Mon Sep 17 00:00:00 2001 From: eric Date: Sat, 6 Nov 2010 15:44:45 +0000 Subject: [PATCH 235/541] Miscellaneous format and naming typos/enhancements. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1032097 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/mail.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/mail.xml b/project/src/site/xdoc/mail.xml index 8f407dffe77..0b35f93cd04 100644 --- a/project/src/site/xdoc/mail.xml +++ b/project/src/site/xdoc/mail.xml @@ -28,7 +28,7 @@

      - Please the guidelines below before subscribing to our lists and join our + Please the guidelines below before subscribing to our lists and join our community.

      From 93a53d04e08b1947eae2238872c7bd36cbd5b8d3 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 7 Nov 2010 05:52:41 +0000 Subject: [PATCH 236/541] Change source artifact names to map the M2 release. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1032214 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 3285a4c1971..11d6e22c170 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -40,10 +40,6 @@

      • Apache James Server
        • -
      • Apache James Hupa is available from the James maven repositories (*)
        • -
      • Apache James Protocols is available from the James maven repositories (*)
        • -
      • Apache James IMAP is available from the James maven repositories (*)
        • -
      • Apache James Mailbox is available from the James maven repositories (*)
      • Apache Mime4j
      • Apache jSPF
      • Apache JSieve
        • @@ -51,6 +47,10 @@
      • Apache Mailet Base
      • Apache Crypto Mailets
      • Apache MailetDoc Plugin for Maven is available from the standard maven repositories (*)
        • +
      • Apache James Hupa is available from the James maven repositories (*)
        • +
      • Apache James Protocols is available from the James maven repositories (*)
        • +
      • Apache James IMAP is available from the James maven repositories (*)
        • +
      • Apache James Mailbox is available from the James maven repositories (*)
      • Apache MPT
      @@ -156,8 +156,8 @@ href="http://www.apache.org/dist/james/server/james-server-container-spring-3.0-M2-bin.zip.asc">PGP]
    • Source (ZIP Format): james-server-3.0-M2-source-release.zip [PGP]
      • + href="[preferred]/james/server/james-server-3.0-M2-sources.jar">james-server-3.0-M2-sources.jar [PGP]
    From f8376fcf33bb88e8ccd58dfae2a4bbf0e1c0a70e Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 7 Nov 2010 07:22:23 +0000 Subject: [PATCH 237/541] Rechange source artifact names to map the M2 release. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1032222 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 11d6e22c170..9d1632aaa1e 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -156,8 +156,8 @@ href="http://www.apache.org/dist/james/server/james-server-container-spring-3.0-M2-bin.zip.asc">PGP]
  • Source (ZIP Format): james-server-3.0-M2-sources.jar [PGP]
    • + href="[preferred]/james/server/james-server-3.0-M2-source-release.zip">james-server-3.0-M2-source-release.zip [PGP] From 648a1364389f4cdb554b30d06e5140c0001c62b7 Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 8 Nov 2010 11:27:06 +0000 Subject: [PATCH 238/541] Link to release-notes (not release_notes) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1032544 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 9d1632aaa1e..9a7ee95e6d5 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -142,7 +142,7 @@

    This release is the first milestone based on release. See the Release Notes + href="http://james.apache.org/server/3/release-notes.html">Release Notes for a detailed list of changes.

    Eventually we hope to support mailet reloading and a special lib and classes directory within the james directory that custom mailets can load from, but for now these are hopefully some useful tips.

     +

    @@ -246,14 +217,17 @@ match as follows (in precedence order):

    +

    The version of Avalon Phoenix distributed with James v2.1 and later includes a wrapper that lets you run James as a service. An alternative strategy is to install the JavaService from Alexandia Software.

    +

    Check the JavaMail docs. Per the API, when you call MimeMessage.setContent(blah), you have to call saveChanges() to apply your changes. James tries to automatically call this method so you don't have to, but in certain cases you'll still have to call saveChanges().

     +

    The following information is based on James 2.0a3, but the @@ -276,16 +250,19 @@ match as follows (in precedence order): you will get error messages, saying that there is no corresponding block.

     +

    Read the "Contributors How To" here

    +

    Read the "sendmail How To" here

    +

    I am using Microsoft's SQL Type 4 JDBC Driver, why do I get the following exception?
    java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Can't start manual transaction mode because there are cloned connections.

    @@ -293,6 +270,7 @@ match as follows (in precedence order):

    To solve this you need to add ;SelectMethod=cursor to the end of your dburl string. Your dburl string would then look something like this
    <dburl>jdbc:microsoft:sqlserver://dbserver.host.name:1433;SelectMethod=cursor</dburl>

    NOTE: some people have complained about performance when using this option, the alternative is a 3rd party JDBC driver but these are often not free.

     +

    When a user tries to send a large message that is close to but not quite at the max message limit the send fails and an exception similar to the following appears in the log:

    @@ -312,6 +290,7 @@ match as follows (in precedence order): max_packet_size allows only a 3.2MB max message.

    +

    First of all read this: ASF Source Code. @@ -319,6 +298,7 @@ match as follows (in precedence order):
    James subversion repository is at http://svn.apache.org/repos/asf/james/server. Commiters use "https".
    You may want to search the web, our dev and user mail archives or our wiki for more information.

    +

    Sun's JVM Internet address lookup uses a cache which is unbounded and doesn't time out.
    @@ -328,6 +308,10 @@ This is obviously not great for a long running process like a mail server so we

    We are not currently aware of the behaviour of this cache in other JVM implementations, nor of the effect, if any, which this change might have on them

    For more on this read defect report JAMES-592 and related defects.

    +
    + + + From 8965504fa3f115298003afb116df208b3243a05b Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 6 Dec 2010 13:17:30 +0000 Subject: [PATCH 249/541] 'James FAQ' is 'Server FAQ' git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1042624 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/site.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/server/src/site/site.xml b/project/server/src/site/site.xml index 48a9098cd27..24fcc3a4109 100644 --- a/project/server/src/site/site.xml +++ b/project/server/src/site/site.xml @@ -39,7 +39,7 @@ - + From ac2731b72a9aa13a62a49f8310c275c36b00e2e5 Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 3 Jan 2011 13:31:04 +0000 Subject: [PATCH 250/541] Update web site download page for mime4j and protocols release. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1054611 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 81 +++++++++++++++++++++--------- 1 file changed, 56 insertions(+), 25 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 58b36a344c9..abeebf161ca 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -40,18 +40,18 @@

    (*) James maven repositories can be found on @@ -213,33 +213,33 @@

    -

    Apache Mime4J 0.6 is the latest stable version:

    +

    Apache Mime4J 0.6.1 is the latest stable version:

    +
    + +

    Apache James Protocols 1.3 is the latest stable version:

    + + +
    +

    Apache MPT 0.1 is the latest stable version:

    From 4d196693958aed6be09f64d34a2f5021e23480d7 Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 4 Jan 2011 08:33:58 +0000 Subject: [PATCH 251/541] Adjust maven repo link git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1054931 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index abeebf161ca..9db4f9741c5 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -48,14 +48,14 @@
  • Apache James Crypto Mailets
  • Apache James Protocols
  • Apache James MPT
    • -
  • Apache James IMAP is available from the James maven repositories (*)
    • -
  • Apache James Mailbox is available from the James maven repositories (*)
    • -
  • Apache MailetDoc Plugin for Maven is available from the standard maven repositories (*)
    • -
  • Apache James Hupa is available from the James maven repositories (*)
    • +
  • Apache James IMAP is available from the James Maven repositories (*)
    • +
  • Apache James Mailbox is available from the James Maven repositories (*)
    • +
  • Apache MailetDoc Plugin for Maven is available from the standard Maven repositories (*)
    • +
  • Apache James Hupa is available from the James Maven repositories (*)

    • (*) James maven repositories can be found on - https://repository.apache.org/content/repositories/releases/org/apache/james/.

    + http://repo1.maven.org/maven2/org/apache/james/.

    @@ -504,7 +504,7 @@ href="http://www.apache.org/dist/james/protocols/protocols-1.3-source-release.zip.md5">MD5]
  • Jars (including source and javadocs) for the modules are distributed through the standard - Maven repositories.
    • + Maven repositories on http://repo1.maven.org/maven2/org/apache/james/.
    @@ -535,7 +535,7 @@ href="http://www.apache.org/dist/james/apache-james-mpt/apache-james-mpt/0.1/apache-james-mpt-0.1-src.zip.md5">MD5]
  • Jars (including source and javadocs) for the modules are distributed through the standard - Maven repositories.
    • + Maven repositories on http://repo1.maven.org/maven2/org/apache/james/.
    From 97483d79dd499116177492bb60356b25cf54a11a Mon Sep 17 00:00:00 2001 From: eric Date: Sat, 29 Jan 2011 06:28:49 +0000 Subject: [PATCH 252/541] Add proposal 8 for james logo on index page of web site (JAMES-1091) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1064966 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/resources/js/james/index.js | 6 +++++- .../resources/logo-call/james-logo-8-avatar.png | Bin 0 -> 3558 bytes .../site/resources/logo-call/james-logo-8.png | Bin 0 -> 18159 bytes project/src/site/xdoc/index.xml | 12 +++++++++++- 4 files changed, 16 insertions(+), 2 deletions(-) create mode 100644 project/src/site/resources/logo-call/james-logo-8-avatar.png create mode 100644 project/src/site/resources/logo-call/james-logo-8.png diff --git a/project/src/site/resources/js/james/index.js b/project/src/site/resources/js/james/index.js index 4eb3287c8a1..1d420bc6f9e 100644 --- a/project/src/site/resources/js/james/index.js +++ b/project/src/site/resources/js/james/index.js @@ -31,7 +31,7 @@ function initIndexPage() { switchLogo('images/james-project-logo.gif'); }); /* - for (var i=0; i < 8; i++) { + for (var i=0; i < 9; i++) { $('#james-logo-' + i + '-preview').click(function() { switchLogo('logo-call/james-logo-'+ i + '.png'); }); @@ -65,6 +65,10 @@ function initIndexPage() { switchLogo('logo-call/james-logo-7.png'); }); + $('#james-logo-8-preview').click(function() { + switchLogo('logo-call/james-logo-8.png'); + }); + if (window.location.hash == '#logo') { selectLogoTab(); } diff --git a/project/src/site/resources/logo-call/james-logo-8-avatar.png b/project/src/site/resources/logo-call/james-logo-8-avatar.png new file mode 100644 index 0000000000000000000000000000000000000000..7b46706b185c9a0de408d24af696a2b3e4174701 GIT binary patch literal 3558 zcmWlcc{o&G7{^D*D9aeKXUkZ!j3WCIQD!jqeP3p3B*NH+Y>{lq%#eL&H1v}sku_z= zPDrwbAtd`!^1I#VIrlv0-1Emd?|I+v_j41?P`6mm@t*^MK&%KueG8yh_}9Q^fw%3M zqXeL12-HJZfq^Fi?DZHJGv7C~4+Pdv{A+Z2Qn{hPBp=Se4rl3y!G*X7pg|!aA@W$? zyMdnW_tElx0k?C1YVrfCJrVl4R(E2?vL5(+Udp8Ev>o-|rIqhqKxU7qNX0|9nqFI( z+c`>aONhZ^3~^%_>tA`#Ojv5XW#ByUS2LY zVsWfJI)KBdw`Ct`4gT#|;z2fspy2_N#6IDjJenFUVz75dgJvGQ{zbHr4iVP5r12;! zD9s-1PvzZFFF| z>D|2XNhJ!t-&CFCd19_dyD2;-LCK?ulRjtN?%V-`tgZduO@r>_JnHd!?@{{=LQ=my zkY`&?GL*J&41j4DrZooAMrLMEO8f@Mo~EF+Uq=zD`6x{xc128|+y46G?!kegre?~R zH~MIMiG_`Ad+s6o_V+X$vGPSq;Lq0IzMpz~na@7l-P=pg&o?nJV6;Fk4;GrL3RX}k zNli`aIOp5%Z`fH)s0iI};{fV>$Qs_WJVFh=ba{Q#Pg= z6tN@XU1`E;gR~n+1R4!9F)^{SwY?PA?xVaj9WuK$?&xRk?3_xWR6EosF`nnXKmVQ) z=S*G2jf{_XF$qVsH;3)Kba>%2)0|yVA%PDM$KJbFUSFSKC;JEij`?qmL?W3vIvNE9 zU1MSw64%iY7G;>2v8ZX@KG&Nm_r0p7)gv@C%aV*r&&V+F_rLP{V3XX`l+zM^a5Zq* zI1b|Fo8xA)6QpVATCi6ES_aK>fZI{LZn+XeHr zR3Xp#_wlk$Z=c4-#>yD@)Y{!w75qFlwl#c9*nfKwfyz_WwXxyO&(D7Z5@i5l;f29i zI5`KJ>+xBKxJiRbN5wQ3hcohud$f<;45PY(Vi7jT0Mz=qMYtq=P0HJr>j- z{PU~RR?N)8;{BU@Q(tO5nSe|%Nao(!?u8Rcq&NztD+b-0>0a+3Eho2>sxs5=Q9BpV zs2cf4wWjT_dSqK+hK%hiOh13YgMIswVX0a>79b5Zg@gkGo%h7rFQsYfxw{wFMlN=9 z3>0W-oVyMrFdB{S5~`U<4*T}j->Eq?{pU~L;Ek_n-fGHaCN{yMw{O2d?jQbgU)WOJ z*w|1~Q3>2%xBnBVlT`BS&(5GgY(hf9^Qx*#l9CC3{zT;D=1R-USCGk6g|C=8b9;Mi zUL&m_{18}~Nd4}0`?jT>UH8Xip2UwHT?KrK7&BMb!S;4gQb`fz^0Iv$W~)cC@TKpx z`uKm&cYS<)d=@tvW-&lKyBx&Q=Q`PSl&;&@*t~M@JnIrV&j?gv>VpKfiyoUZEk2X4 z;;-Eue~IqpZarK$fAi+emCa2_8JXmf5euNW=kN1Y*_WtX^jK+NIpC;1v7|Fpy0 zJl#F7MCxWSD?9t>*x1LBa-+%myU#cpSp}4N4?^ADMXjx^tL zTeDlXMmvvBc^3*bV?Vn_4U9g32GaCj?{MdQ(*}y!R0L8~QSqqv89Z>|19PUVy`DH! z6q@)nGxO2$;rFz*96)Y-edPf)(>3SfGU)JaurxQ18S{pzsPN?W-^602XCr^h0czBj z{cy~?yt+EYP+ZT^F_%tWMdcX~>Zj@Hx}KhwmX?-C<%Y6Bw|Z3f_!M&;D)|wxh)>2} zVTye7SQgm1L~NK6v469SvrWeM)+ua%bJi4(S7+DSg^ZF-g~vF=VX$JK*;ePS@BTm% zXcrE;sSC0N1O%9I#iyjO;PH4f>x@9!0G&eEwikgwfancPPO4G%41?_r8`7Q%wi%*a zb>``GI5mv39%dV^>a7GD<1fcrSyW?CYv*`scV<1ZT+msl;U_Tc<1Hd#3*S;!Q9;Pf z)u_lY<6>NjVG??(6C%>c@tip|d{3zQ4aBm9W5GH28|;dYi9}zqc&r3th(apZSMO?m z7D11PAdfA%F}&3aHebNy;1!HgSyDG-?X+?*U<3$;+b8uC)j>+Fgpn7 z#c)tQpvq6Qiq@<`q={KZJ=kgYdpp@4d!1U*e&E4NCKS1D zDf;k>N`Ag`SLa)RqNj!aS?3LbKV#F-+i`ZeX?j0Sc(Tz~Si8ps=a(Dh(b4(F9 zql({^3VwI7m>Px&qVEyXEph$0_fE{g)c8_0_(wT2BWDmYOW}%@(%D6k9O#WtU}Zk4 z=c}isWeNsg5j=c$iwqWA0+bDd9aivz_Lb*@(AH~C8vwY;!g$vddwa&r9j$D?VF&Up7py`gPK0TM-;m-f}#4*-UyF*@f5pjO4 zHJqtWBJ!Aa$=J>Ti5zASqiJA61DL))`*vg86)wSHs_>_yZDFd8sh`8m5IJDHKR11R z@P*7(iqM#zo~~>=VlAoPONzlLu1(aCi;ANA`izxKO3CDeoE(02b@i@+5810dpW?2R2FJJ=`R}s6x&SGk6*(r&9eJ8o-G6$|Emr#1e%TK;pSy`ix$Egs?841oO zZBj*xzifOsyEsRKtcZ!EsEC3C^(WBvp=^O<^+`oghc zK11HlbAOP#VO=6 z^DNWb9t#tDKGb?rhX|u;6QBFmN3O;}1hw#7Y1Gc69h$V1ltMEt_}$j;lMfzOX2NI} zFHQXZ{oCC7f;5bpCM>C?mH+N%Q!=3O!((Fxckjx~MxCBy(5>P@fWw(d>1ztzLLvZ` zFv^q#@Bjd@&K{!V^UBJi*RO%kUQ&C%PqO+k@~*8ZBtmhqD4;!w`mq4~l}H^%XcLG; zK0!f!BqAh41w|&#%((pc@gpVJ5v(iAeFLluU_xqYD%XVz|BwxXkswN#i0SAQ0y33) zR-{~9kc|_}z(U8J%-A-Y28pF-Vk=rx2TbAcLR*+ZfhOv+r~$Pr4rRXaW_A+* zsjEs#aU{a=F&>~$U?XqdC?6jmD`Xpowz&8x3s@i}Obhzv=0sRoS@X0X)U-$G^|l$Dp81NJ`Q8l`o)1>n7F#nVWr-cv(yGwYxfHfdO*{`<$>^-7ep zn8AWnNbLT8@Iang=iVy%YIfwl(QZEhpnv*_Jv<%#=d346Iy$p$o!ZzJP&REy z^3Aw((?CQhjoz(c$}f@Ndf8!OBx|$1e`G^pJ8iW^8q_fLrLfeGC0Zxp)+txMr?yv{ z_z862h<9+f(9NipBWtV;Up7et2h+0GS<5MS&W-KVgfpWsW Ys#aeG$7MYS{>eZH1C;)MdTz1*1B2GRg#Z8m literal 0 HcmV?d00001 diff --git a/project/src/site/resources/logo-call/james-logo-8.png b/project/src/site/resources/logo-call/james-logo-8.png new file mode 100644 index 0000000000000000000000000000000000000000..442c654a01a1d46803d9e568f6bf99aee52b7a98 GIT binary patch literal 18159 zcmXt=1yoht)5ZaTmy+(3PHB)vke2T5ZUHF?>F(|Z=?3Wr>2B!;>F#gyU+Z%%4A#Au zbI#s-=9y=HV~D)0_0&3`HvVIP`!&| z9)yU4z!Qf00_Ec$v@OHh@elgXh44>kxZY?84TvqzIGn)-XDdCeHoL}E!QM8f#%8UR zSnKqA&#WSndRw(wZk0ya3?-E!SxI5IvG05rf5_cF!^k7;7b^BQDUUmb;M}#WQ^O)b z@asKHCH*za%KJ;2ff(^nZs$3StPM3{ru}m$?nSfqnX2~tQM*JaHApo!M&&~7i&v%t3Nz?EbS8V%d-!*D5aaKd zRy}W5_|3xXS;tEB`Jc{u5OHzxQQjRvy4CQ#3Z78JZEA1AjB$JUqZ)oXgF1WSzy0g@ zWQ{IJ?|VJ*1w{wmzL*Dd3G=+txNygWVZSXeJ#H_np3jYt-VQ67} z@|Y%t_uNn(*YtY#L#Ga=4hUR%zSj|U9$W7^Klvcem`xW@OQM_B;^j^Lf{&3c`jWU) z=1$|`Avz1=g<#>i1lw-mA{CDeq z--Uz!^NAV}ajRi4;!NZ4NgWE4RU5y}oBr$!<=NnxW=X=O^d!?SM}tX*3Wo{@9o%QA zM0p8yrgyvg;}nkt%}lwf{pGqc3F;Q=6Xe4|JmoMeb{I_UVtAMSAD%VoS+hc((WYE9 zN=bJ;H_6#dwk|mebW&8f_1niHGGmtYz0S7V6&JnRx|EQfaQM0T_M7^np92t&b-1w< zWvcY5rPrR*RNkj|Kc+vk3F*Q4jPLavUGG}cA&@?Gj^3_$zg8BGd`2()s1E+#0sZvp zEa8CFs9L>Bv;5D+kFbE#qKqsAGsBrI+aMmCoVf$*OKShlqwCGvN2RGu|13MG*X#O9 zPaDlRuH-`f=UeaBMxr~It>HbTz(M0~!|Lp5nZaT*Gvn!)@mb^_734|Iym5Xe?D&00 z*XT&Fj-wB(XHj~u5Ay?sU%ZEWzpr`T&O$Ij4Lc0t$jQZ05F(4qI{spdaFqFyX?6F5 zjg348&bE8S&!h2xvr!UEQFR;&>x zac&%T$&& zcs21wZd+O~Db!;J>^F!roYm{2G%50AX{r&^%O6Pj2fygmDtb5U&0pz5yH8eHLPW?c zhGhq$WQ&aMFLvN}3Vd^E{Cf*FS&Y#G{C1TG(~f)WqG~-1>RU{L~rx!DYb*^}x5@KYKy> zboyW6JvcxwT%7fwbfh3Ym))keKkYD$LwSiuj@6u3sWadr1xoU&N=m{bVlzmXL-=)d z9?q7!?Pa()VDIPVk{uo%Dsr0h8Ec4D&gab^fg6^H?Ok90@E+yMQtC){5`9HsjLLQq8VbUx`X7bBc882Nh-IiNAlt z2jZ6C+uGZSv&NIyGK|5xSXxA+^SOeTWj*b)Bx`TM+|Kmn7|NJH@Tew=NNoIu-kBLF^? zmzXC5xpuMaJ)uT6uIqUu?+Mqb*4jhjr!*uD_(asrz0OqYCW$~0duWsg!|*97DWA@x zyk|zRNTJ)>+Q1H_qo?PHqgcL=%%y=Nt(kMGRu6x9@p`-DMmrL)$G2NA$KL&sS_V%z zU6xu#Mh2WYhG95Ta~qqT*sqMFf`VB&IXUre)R!hsT!hvu%?al0L#JN1ybli#=w3_= z3=~XEC?NXjR#KzFnVae}VCUuK`9($|BOo9w)R-U=a9Zm>-WJG9 zMIVwrIU5Y4Vq*bMk{j#FonI`Er7JfXdibZF$9b4u>rIR}aY}rbB+SuQkmdM0#cK;P zkuqe9QoI-07ji|zaPjdCot!X#Mi6|eF&aSjMmnx2jgRKa!KYkohA~-YfJiB?r#If}c3CIX1wvzl7%eR= zDHBuF=B8nDbF;an<>vNa91;r3<(!sXwcF(`dJN~Fi{aH_V*3@sa8h<>Pql%W32WETk24$7rQ<#J6 zhjd*D9UUSNUxeX&bSuqvh7z2TZm zV9lvosVk$Tgz^0R3|^yt#1QxK1BDTI5WiP!Gd*uK${D{VG8k<2M-cM4MrXZT6(J!Z z<&RjgrX=&aFyd(2Lt4#O?2LX|o8eKucvN_mE2u8?y%SRLL|IHuuzd7f75h8@=c=|C!7a=XSrM3B&%ld01Kr ze$EGzBE{FJ*EFeNV?W~!<>6t~DooK7{gc8kPai0UYZ`W#@uaDgG;w~h-@Vv0t~5OJ zuHDOOo`%=?Qu_bSaKWK3G`z$|3QRxV;jo&s-|U6Ak@OslrEI+zqStmmD8NO670y8g z@yKjA@gq3LyxgPJn@6PnpA${~IY0V4O`6BsbB!!4;C29&cem&LVwRegR)6`qr>935 zMA_BVik+~^Ef9FQJnpJ)tlvKQYU-=D^PRnA)t|0`LC_7i&Y5{!}X2d8Lqb#-h& z@a0?Xq`6d=6mjq-IRCwficj37(g#}y{dOA0h?2327ikrOCC~It|+Xzulb~fTh2i2oex6Fxbe? zs|!{3Eto#AZ_=inMkKXwS#ff9Mn?`B93P)I|L)?l<-{{x!I_Yda6Uv|`N2QCt_~9< z!k6bqjW%}<@QeM^r|FrQ-aZ_?@Im8LCqxK+knZoEy<`yakzg6yt`xnVkM!6$IRkq( zIuD$vxR^>Ojt2CqC(S_^i~?I=f1idpDv0EHUwr9s(fAnal}{(lq}$lBOxZ$3sVO`A z^W(?mF7|ou9CvxnAb}r`-cJMGPvb5fk1O%tI28NSQHB4K``h=X$v1fzYs`riTMK}I z4UQxbGb<}AaHQ%r#_;dozXw_8=5%em#$>pz-_qPXyS-iD=wgdk?BYM#w68GQ3HO9*0L#P2U7)0-C?M{AWGKQtqHt^=N6Yr)gXOl2`ejlu$|NDK4OU) zfIYng6^ZIA8ixJt;mQJRm~Tzm+dDgy=DyO`toRY}@$u^pO+XYA^1HK}G~eBX+6g9z zT~HJ8*OzZ`=u^FHPE)7l7O!elJQ+XiUq5I+G^xOS)6*2n_z>8*rc3XCH=-OMCCZ3} zE?nh)Z3*t8GNIOZ5FPv_s!Kn+tu5o}$pd5}VK`)BJ_!?(o&4^YzbvtC8UG4!BgBwk z{TjBj{%*txhT$-op02hnNwnB+2!odfGYqqHaIk=l0-~xg9QZgn5Ysh@H%BRprU#3a zirAM*Rm(Ta8&|t`91J+qYBxXL1KmtRODp+Up$Olr%wt{RzmW{>^!uq)M%ph#2v1K>kS-UkP1o8zmx2Ykxc-2{ zhKR#BQqr}l)>K2pJsVY0KjWcViq)|uNSZNf+OuIlv9J(~>YJL19~c-2A{Ncio$ee6 z+!}S}Xu@zdk*XRRDKTCa7PPjFT9>zMxJXpaua`3!-^z-@YHam#L1+}$G zjwT9f&ohza!>s?I5O2q2JyCdr9SylqYlianikuu$o2J3>IBzvQW1f*LL6W$^e0c27 z-@dT~p^(VpZs>b-lvh_PXm#s?q}k$fI>#OgQV_U(kNqzsQ+!O|xsNx0Kcf0K+&4}R zw1-!CrB})JNySo(&1B(flpymr90VrQ9E9 z>s|0C(u-u%C3Xnfmy6?GH}3@Rx=@_^1*Ip{g@a$wg(VhKv5V_wmBm7UI#oX#@Bsf3W*$|}ALC8e8xw%jovPlhXM94v$W*EZq z+S<}~c6PFt3&kT}R*zBONP|Vl!o$POAw3=LUE6eJmSyKo22&LkFav{vs?{0bvj)wV zj-5Ge|8ng#gjD`W%xZ}%keOD`dVSiH>73h!UNrxJrGzK+RZ5CEZ8V+F4V@I)ac``k zqk{wp->MNy&a}5I4b*ZrP*w6Yy4b_j86%~>8T+(W4ILs$_6{-H`Hiqo@i!Clp!%0kg z|3eDs>mU)pnwJh_oV-x zR|gQGq?z6?Zr~`?@0pmGlxa0a0u|bVaZ#q%k;(t##@tD@LVNHlQyY6%oL-{ITjuI` zIqJCRC$NL4vYKaPY~Ckx{+)Sv_v5l*H8T$nPezqq99aTwGW_{LjRvw>y%G=p zG|`6{NSkJx_;)0x>kjLUhwo&n{86VvwPFy-Ew{eLihyzkJcq2G=dwy54aUg{q*N^x zkfDcwbUNk>gUIEu4fhs!@XE`}E%YoM#JRt1LZk3sP51-p&0s==&7j`dV6*IcF-VO^ zL`2ENB=gNxi!OsJq2Ly;iAC?*@9;gXr z(1cMV#Hh`+W|8=mBp7)?<{_|a{U$}E8%vSten>moqT?x^a;J6x0;a%a%J{annnof# zG?bY&aw^qvkR)~)I90Xi_B(aIlhe=q%|Ki<1a;Z6hfa-gi1P@UN*;Kl^U2@A036+4 z1}7cieEj$^j#I>AFTHGX)RYZm-!hF_SP)uKyzjn%ECF_&?4KX2ZhMoHlRopj zUa4=1^WSP4LEdC?EHD=g2O^2ew3}k*=2U?s2j%QeZW!Zc(_Us;^y<;Ir5{qbm2yxI zi@~`uRg5)HX-*4?*WE_?aP#$?Rz0_|$Nj;Qpc~`}*xRqq+%2V+{|OZNN~0CBURB$? z3D0Z6$Hnp7vkDNY1v=TsG)*L3q2|i9l9(ISYfaw+O)T3TGHvWHObS9$_3|+|smO#} zo&6C6lLt;1t?^sb!{^ByR@iBrHmRMZhkB;9i=e!#tFH$|nVtRq1Sz;==N28UNR?{q z#TsZOWsY}NR#wz!6}tpPL?&InFhGfs#lZczJ=wv?x)Tw`$2ttG3k8`K6zgJ2bXvwO zbia^A7TueBztlq&Hq*gLhuG@s>dv+M(rv=frR*`R8}h|JWNq+wHS*DeAD z15zv|Zq{XdV&X*?ikJOV&9yr}P@~2q4hN<7T&3Q4nq8p)e};A@$S&5Lm&^D-~|iy+)V2qo8(>KcXNfC+EB0j?=hAJ=N*>acc|0#gjkA0JE32$@9bY(km#g zL76~4eBnQMFWpw^v_rxB(M(CUS*1hUbu_`2FGKn@3sU?2U)b!9gTl0upD<=V=1|xl zHRG9!&fMFU_$bxhPSC81nu5H1=h@kr|Jrm!XYnSURBV1Z|$%9Q`mW*w^sG zT_E@J5~k3Dc-6Z*nns;&396*N4SRjgG+-=>Af2R zb{ezyP{UJg`L}U&OM&ZRxlwOWDaamTi53ei&&=Kj9e$HnR_^T%Ky+j@17~|{APOU_ z?=4Q4%*z# z&TP6+=B*Hbe*(Iv+V$LU)ClNpBCtP2c@y}ildVq*atjLsfimpguwQbPVx-4Jpk!#2 z3(C4x_(}C4GHJ0>QUgvQbBpmZUf{fC1?+u8AgJ(_K*2=}e1y0MT&f@MwcU0SG&{#Z zfMxc6@hFcS%u@c-|Al03Z2is| z1sdw#T1VEY#~v>pkxs3foRXWKSqW3odI8kuO0N`JY0l97Yxk0p5@3T zhAGg?Z;5AP!$4*kGgudUxp|+Y?reeMsH(+NTmD0>bwTFIDk$U@jauHzfHi3i&uyO#@9l-Cod3Irr>*jzYP#QT@?w+EZ*#;nx>NJ$W#?#5`8O4 zSONJS2+gHl&(&5pP~h$`C^LI0x3{-v78X+Jd-SUDbJuKqFZurFwouDu&TQH;=(Z-4 zi$`vQ7mi(qV$ts(9tsDa|KtV*zJ)LxbDQos@Wkl_fYD@SGdnxm2a@Gt^LKi%_xWC* zE@}6Y&adN5QhPAI9Yl*2Vp134VT3#t*9nywgf@!u!SM<5Ub8w;64U?lOQ7P~hO7TZU4 zU^_^vyJ`Rl+5wgkgO9bQ50r3CTamnP4-}~X8nj2|B(Z1x;bqS8XQs?UhB|nPp9>fC&5~N8q1^bwb%4Nvfq?-w%jDEl z?nhuzIRP)Tj2l4@T)@oC3Fp0@Wkmq}N zk_W56f*%21osTq;{9X{$fBpSpAe8myd+0jiezlv zr83AiK=#^SY)c;FdN6|87f3obvoS)Dp7Dr@O^uEHfobPI>Xw3R_6AJT2n z>e6FrNNSC6Or5_{slw9_1Vk!Y{+bNn%1>4=$r>H2ilPZvz$BRbi~|x0h?=rl0y5s- zfZ@oY>_Co3C&RoJ0``>AS$g zeA_Aw)_A}t$+}R<=gE*|`!6jm&F9;tJ+Q9eV}6=w^y@R9ZO6&gd_PhZcs`K31n!Lk z@PI+q=XE(T-W$tUIIC4&lN~fiykTJ~9i5oP&TD&*Js>?JdcozPXe#3s4b$C4+ac1p znX5jOCzZ_Q6RuFhOlKL5`ny0OGDbY8Y^(0fUb6usOl1G`bYSazVrr^;Fpm2C-s4YA zSwKxDhn1?BOR4n|9e%{cu-*&n9%sP0qqUl@+Ya7!v9upst!oT&ECq|%Sh_#+_?u?0 zpVu9>NaDkbh=}lb+9DY+t=+i1H@CF~=Dm`lVs5}Fx}l+djB(Ji_5RVdJ5W6sV(TWu ziRa+M9W-5@h=E~OTG@`@rdxTB>~-cx(rZ~y_3s!D3D&S0ce&B7sJuMFs-h|I+DdKu zWyEEI=$<}NJvlbGQ!uycm$JCAgyEh=%B%t}XJ0RI*$lx~4HKstYUYv9st!~lb79O_v3p^R$d@#uovin{An^f_9F=C*uJQO06%JVQ=kb#P4z#c9U4Cy?v9xQu z^RcFk6+G#$l9El(qMP+nLm}PurTm%*(sdIs6YI@D9I9(<6sj(9qCiHZx?^(gbw|F$#1^^DyA0%Y0g4&lyW83%kVj#byjPAml1~;=5cN??HgjAp!c3-Cz?-vXu z!RN@+kOH$h|MQ7ig9#EEvf;-|C5s#VLzHT%m}po`SY8-i(ScZDp-XtYup;!9?R+&> z;AH>VkcjSk@MvWr(osmJ3|*uaOQBR@l?b1{QleH_7c#Q1r3c5hGF>OTjq+K%}QNGnI)%VHjR-k z?d0A%+MQSnGrz7b9;kF6yYL7IK<3+Y;sGV1 zCTgZ@dCcf%9vwug_VTUQOqu=hIT7@J0uHxprj#3LryJ#+e0L2c4J>ID)j|hM(VT_9 zUp^j>5WiQ%4UOH4%qEGYxh9ZD#C5EbDqQJ{OPv_`GdyK1T=9@V+?(NAU8}y#s**1!<(8lub{a;W44S9+8OEGnNSDe!Z!Wn+!**Ed9{z_&lji_ zjvA+V_TP{5pfog*7?TvTVKRjL2z4VWM)+|P2|?j{<kj7y5t{S#qox>^B zBP*>&k!klcl4FAYs&>jGw$K`J$|fX%Y@d{$VP~ix%%leokJA;4REBXr!MpO`$wdrX zQMo~v+i{(YM@U5D+@6kgC~@u>AH_?%a99$n8)RG z%;oVtUBEN7yIZ)qrRCt{L@YL+R);B#eyrdnE)?egI9wT=L5DS#4A|2r1ff}B=|>UF zN(*yKW3xV_=|V(Oy}}*Fh7iAEu<*aLUQgjlEeMwyipEI&>hJr&+9q5mTaq1xYhxIF ztw{Q=Q&xCep9{q~QB2!?MBqay|G)ZQY41w@R=~uM;`;e9Yy7KB!L!D7W z+FU4$2lWjT4Fs@qV;3hiaN|Fa=p(~GIUn(AP$V!jz@~(az=VeQHAC*^iu+=- zbh{VCktZ?_5en*6Rf;B>09P6p509I?nrqB-4OA3M0qBR+_lm6yF^`*~4A?!Vw_BI@ zz;eUz-`DO+aV71S2-cWH)xk!@NeY)Q6gi9fDMXUn&Ky_|1uOTZXgM@S({!WzXG-9& zsDju8qV917c&X}1#w)@uDHcX(7F~HUn&{Ajfe~brVE5wm52P<51gt7gqDYF7|B?6A zk)E-HYB~6^OGoQ=PZA5q2tl6)VAbLtE90vw7L63DR~z*S3oU#uFf0^F4w2|7ON8d6 z4HOTlkqw<-Xx-lG%J+}{mKWFk=WY^SkS7Dhq9Ezh3MX;YTyE>pTFQ_(i<;w!HonJJ z4nneS<$z(ee!XU`gXtfsDj>TAvQVPD9gQ93S0}F(CL`itGe;1Igq7rch1VkGbX6VrHa24Dsi2ST#l~Bf;@`vl^?Xv@({&Yv6 zk;F3kcWqKy$%T&Z@zQfT@_^pX`RVJ+sfD-qNzk3iwR45gHot`lh3N;=?v6y7s>yYC299k5UdDqpyZ7IB&K6lpk0w2i(Vqa0!x~cMEHkn z#AJw1EZ^Y41jEnp=d~iRX z{mVTc6<&JnKtaD4DUACdh(pfM-&LjD$CevKhxs6y>_scp;pAV1NlpeUFXA7Jn@4&` zIfR?t`c=7?-qI)y2*q?>{-gfYkbgCw;_k@r-qqH zqM`mJ{bk7YpQd3L_*!beg{pfs1?O(Kk0mIUBQ8N4P8J+ag2IC2kLws%+(gs+Q*GnD zHa_SIP-Yv7lLSZZGT_1@qF4+Iuc^^cXg@^jOa{Z$gk2$LAt zXr{CQ(B~VmBV5q`u)ZiOj?nm7C+wp4d=0`hX0%AEHOa6~x>OZ&0owf&AlqF%rA|=SnIO54M zc5&Uqf2#FX!KwfBG3geg|KeJ}TEfgm(_e*vBQzK$6Kaqk#!c33oiN1B$kQYSm7??y z$5vI+IW-=elaA_UkQn4J1>MdCt$T_LCHRWj(%~17wiIlS0azHR`O) zG<@-4!ri$9d3?g{m^;5Gs>MpOh1l(5wuPuVh0ye?^Ub846 zC(~-jZg<*^&;q~TF!Ws3&u6R13A4#qHe+t< z5=OmII2+ZZi_mq)hGt5`{9!L_5=GNZ>E8w!rr4Q1RKSj6aE773M@cd{o(0C2vS=hE z8UfWXxG&v3l8c>CgMYHmFjNq@M^R{*R{n2$;lZLHfrj=ZsjE5sL?t=zDc zKtLPW=PFHS)`4!2f@u^*+bb{9FA+{H8gHTqZ(#HvhoT^(l|KeCfje!MOa4~68mmMe zgZX>9r;l_jWSB2GpS!lF&f}`2?UbwjpbXQG{&hy+34qsO@PALw5_imh>dBA#PTJnu z(tzMqZBzO^Tnz&Xq=a*er#&D+0?hn}kUpToO)M>?-rRy3jJ9t$8Rb3`f(lOTntj07Utmauk*I}VK{LW>#cfvZaFx(>NJlJZ4J2om({K!f7tBB|r-uj9ChHdc9Y@y1)f8Bi9O z*w}!X0{t(O+mjVOKnz>h9sDVHMnpjPeb$Yr(c=6Octe13IA(3Fu4VyJ*X^jh@r~f4 z(#gpvdwugazaP!LHTyx&6L3wSUj;}^-O42JYS6p@d^MVw&V!N05;{@DpIzSf(I$gO=Dm{;_-d00d z$YEv1(GJ*ac>tEwvTdR~dUU4S~)#8=3m_@vv|(GOl1$y&!sswgEHl zDv1sc{0y!eT`Ya3jQF@%H0v{yBzmb@KmDR5pj zksg%UXHRPw9JeAq)tHSFx9T#1RsI0{MDS!-?O4}F(>k;(3vPnw#jtj1#LoPkn3#adMhOs>0Zy^*x4@ok6D1$zge-=aHDhwQr{JS=SFZ1e zn7~s6CNuC8;R1vKpNoKq_y$J-*HMnkE>8PJMNOygw*9uP&UC=omr_#E7dw*VoDKdf zU{-{K;e`uUaR{>nxI1Kvwt&e#=vuw@e7hF4VmluRLzx6Pe?T2Efq3**#scPo(|RFW z$BH0}nh+U4$8UCB6X@S5uKsWat>lf{M~o#pfmZ-JTbP?qc&HH}|JT>oHKXe{dc8t9> ztKXnb$pdU0oJ&wHgQJlVTi9o~aWTx4Rh5mJ#W{O$u-ySd$(t7rZ0VSo7_^Gk3#m8e zAMiqog;7~Yy@o7r$Mx*#a(sGW;SbV!NyF1q zy+N;U*|sGDu+q|h9syXF>3yH%osumBm@WXGfXm9vdj4mIanYpBc#Iyh-P*Y7ZY8C8 zPV@2O4u}={pwG8-EwcyVRqi$UPJ}Eb3l_>J3gEf}(uyf#=GnV4CJ6mWX@d=sB4nTw zAji95$&3qd?^MYGF*vo%S_ImP)ul@fPg`kN|t4H?scRsQyTJx{Iu>1swv zPC;8c9o3aRVHZ`{eqP7r{9o-j)YiKRa0~an)B-G|x}JPGDq98J03DV4fGSaJVN{I^ zdKx$Yrk$`&RF=`m8Xo|gf*+encLV^1RNE0EWZL#!Fi)E}9m&}nTSi8`^V55mlM@r4 zb#;kNYc+U@D`^k_peRoxLW7xGSs7)P<(c^Qb#ZY)t0NJENOd$EOL0xY>nz;@FF&h( z3JnEWIen0>(3J{LA(ySv8`YokRxS?jfcB>GcS$Dzwu872@{_!xV(jOy&jgjDib6ZI z3Gxtc*RXzfz7?O81XeKGBn4~+5U79Hwj4KvyP<&2lH)kPI6#~@)86}aeFm3PTN?+s zM(Ak<0lVg~rU)@|0IM&@GZ8_05iE#^D##Q-&%ldvwSzcbn+ zV9n7loB?TQ&qb9#f8g}SkbMnq%R;aWhKm~bA}1F$7kP>Upi}0cD+r&@pTF^B{FgUr zey{w6GE0(a&&kJvRYp@~B!!JSr)$1Uqvx#&$+abxhvwJCY!C@<0DYv=HMN-WK{ba) zYRQB7MDhXz!(_0ml!QkOn&sgU5omDGbr8vx?RPbq9v6~e?f|1z1~B&^y8{@~QaH;J zxoG-;3P}XS(m5yy%1gT5JDXSl)xh)h^&B{X@q?UEg17@QGPJj@)BoyKyha}kCF29)6awRIT^K)Y_~Gfb(9 zX11DRuo))P2o6B~>ohI%*J1dh#Zg|n-(5oQHoI(*V>hp@t*z->+lR{ALl-PI0I4tc z#^*D|$p5huTtt@MN!BalmzxrS63IjY|nXG8MtzcX5;1@ zd2?Zjio2)JVqKwoI?tuLOG%7vljbu^j9z}6P12R~Y1J}uZeEw8pFlIbtl3<(pvP z{~j8OmX{}-Bu7E*y^>JTvZ&3uKLin^l=S*J} zFoDkV>JZGi1T+Xp7)l6^ppSBpSM)++hd|{LKFB9JqaIOw@!-)OE{qo9MxbSQ`%`9M|IzTR=)zm43M?!V4y-D=o#yUD#*M^uADMuC?clM;IJhP_kl*R z8&DBb4KfYy+$s*hKv#)m8#FI6yxrj5rCWyVUgMM3>lf8hj%!v$STV!u5i^VPxnN5KN$gn?LI!^8E{n-RP*QeK7gDtN$dkH#--3) z<5nbLtVrbyE-!%;I`6_(I=jIqWE7MlZ8YWA(|`YF4&(Sj|PC>|_{ci;f6lrQ{ zxjh^dErOOe800Vpr4A6dit6gWG{^>>HeYY=JpkwQ7LdFA{;Mz5jEni&F5~6o(0zsz*7q`Sdixr*Xq_2XirTBk!x>k~eon4iGL{%R2TmqB)y}yakWjBza+@|mEDE9~m38hCF7Om$9ZMJ}_dm9Y^{W!o(QuGD^*$RTPlDfJC&{lv%;K~^DcQ0P^>-qpP z11NvOi${zI22<%1`V}j$C9x$q#zE5@ILbNA&6;8FaH4?Bv*y&&jAPU_DiEeBM~e_+OC5=k zps*1ir_051)VlgYQEujKdo={XC`=FljE`(n&GQ3W6kP?r)sCf<`<@ zNPxZvWDw{r)_T8s=|BBj8W6athDLEsP|F$*0s$%ZNZTXRcwpZNl-8)fnO06|-#a%h zKWhsKb+wt+x@lAl?}LsVb=S}?rXAJ$Xv?M*!)o(ST!q7IcB`#*mkB@{2yDRqFrETiM-e@sKtD1@J^WJ0_sJF{Thn zf0dS!3knJrIPL=h@T;4n29r^U*XaezYJvRF<-38_i?xR>uqC6C0mQf z&My!19W^$~4bYnB)Q*id%l&rVk6KVZpP|~6uYq|4Fo-H3n?Xr-aBv{0u{K+(w&l}uZHsd&*eWf^w=kKO#VVUsXd3=i}=c+&O^S|QCYu%JIm zv$NL=R?0{Dh!a|hRM{wLLlM4-e0ISIPhZ+WO%WsY2&|EM@TJPR>xwN(>xYN`I8o&G#7N`>k zPM-i#VRrR0_S>YKW~k%t8Gy1GwqRar*qsJd7`%zv6;2xF9RKUHU{epJ3$|pexw*MM z;1(^Wad2=PLAoiup3#+H#_ioY&o6*6W*=0JNMQ7?Y53|DQ_?TRv6dp84K#`-n{v5P z$rEEz*qcy`^18}{|KVFwcyw^kwd0@wW)pRER-ofJn<7i>e|=+7te@@dgm7*lN*fIX z!+<*u7KQpxgmf=pilI(r=x)v6ufxI7(ex9qqYt=|g3G~B_0ICclO1qMN zM2%){2_ORB(A1qIJyVb)F%p|pAQjq{XP=qtpH(oFbzJ3fAZFYYOBzDO@{r!Yx4@U- z|DK)6C%-IKfQAr&OH4dBa_jm6x}pUIqL=sSNQ0i7Ub<=Uu@ui)b8~Y8)G~i4d|}p| zTf{FeFB|VY+B*Q8d7-UbK7Z7w&uqM-k_lgYqp&Gcs{BI=KmtL;?!jREnc$5UbMq8f zgNDQ^QC5Ob;wRN-3m*xMoHy`N4yVAK_?7!eUs znR+#u(PJ-4D;+qps$F&zk`GE+TFb|AR311QZcLGpk(mHb%|eET>Zns^s2Fr?4FY8n z@M0XD;Ill^*ZeUg6m*5b!#&tacwz*8z1x6PnOLM+yM}tNix=0(1i^?Ts-8dk;)%*z^(+5ad-?$7Jxj zys`HqrfdM%&HMcuw{|go?rEg%DLpHzvOo>ZPSwN#SH*LEYI3x0AlJQ}VoxPz)Zq$@ zkAQad6z3yg66^1yEMZHo6#^vMc!06M!pAqVzyHhB1pF8Pku&?q0@w^xJWEahR|RDO zfLJkPQGN**(1e=Wx`R=KEui-ml$7GCZ3jDOL%Sy?;b#eGKerqe`jjjOtZCWzskcW;sFrhI;qzoyFzjv)9`wP|L~^Tbpha zK#jM~DV$~i(*oQ+Ki$eAfaf2Zo3i5<1B~xpiyhx&zT(PpIW!c(a`pXSA_AB-nc+3m;X4bEd=HmezS~#2?(6R!gK^M zVEvZlWO@pHd6L5BRnGww_%>#{xw%wsHc(x$`$Eb0^w zN|A3#%0PcVXlOzEb-}ZU&D5HJ|F0mdPZ*TEz;V$?d#P4Os+-9snAO33_rWOyT5+tSuvuDvruJB9oA=-S5-}{ zcj*UYQ1sNUs?9&W=R-Aaz0hpkh4d4{UA7SIr5`1yyVAnJx2?CcztX6h9=X>GZ)#LNq0`C4tLm}yY zb#*YUHxf@nApNxp0vJe$#u{D#va_B!aN@pa!NS3@GDw63)K?RjH}tvn|JBmMTW)j! zrm;mWEDplmr_93coOzR=&!t@si_@pm2A!0;z+@fJjd7E35U+Eyv)5rM+1&LUXIvl* zM}SRY3;c#xafSG!D|b(Yh6q7s=C?Y&tV~*KPK7)#u*X15Oswu+{=&f)47>gEuCA=pl_+$H$}3Qi({(3SEl8fq4>=j3oxy9Pv9(#_lvb zUO6c0zjeXj-9C=TfUr;dv;odTZ^2t8|psOomm?7SZWov;go zbvz)usHHd{{f-RZzBZ~>eF*GZCidvbbltj}0$i@>g=ZJ-FON?HMyfQ9Z@ z?jFxaJoy)yhkKOb=~_B~1D=4#?uda0;GVa)(~YEipU#x!6%Dalg9w_pIsgCw07*qo IM6N<$f)ka&w*UYD literal 0 HcmV?d00001 diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 7f58fd257e5..4566ed620d1 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -16,7 +16,7 @@ - + + #end +#end +## + + $title - #foreach( $author in $authors ) + +#foreach( $author in $authors ) - #end - +#end +#if ( $dateCreation ) + +#end +#if ( $dateRevision ) + +#end +#if ( $locale ) + +#end #if ( $decoration.body.head ) #foreach( $item in $decoration.body.head.getChildren() ) + ## Workaround for DOXIA-150 due to a non-desired behaviour in p-u + ## @see org.codehaus.plexus.util.xml.Xpp3Dom#toString() + ## @see org.codehaus.plexus.util.xml.Xpp3Dom#toUnescapedString() + #set ( $documentHeader = '' ) #if ( $item.name == "script" ) - $item.toUnescapedString() + $StringUtils.replace( $item.toUnescapedString(), $documentHeader, "" ) #else - $item.toString() + $StringUtils.replace( $item.toString(), $documentHeader, "" ) #end #end #end - - - - -
    - -
    -
    -
    - $bodyContent -
    -
    -
    -
    -
    - - - + $headContent + #googleAnalytics( "UA-1384591-1" ) #if ( $currentFileName.toLowerCase().startsWith("download") ) #end + + + + +
    + +
    +
    +
    + $bodyContent +
    +
    +
    +
    +
    + From b3f58be982ea83bf8e92284b4e7282f9df431dda Mon Sep 17 00:00:00 2001 From: felixk Date: Thu, 3 Mar 2011 21:38:14 +0000 Subject: [PATCH 259/541] Add formatting template for eclipse git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1076805 13f79535-47bb-0310-9956-ffa450edef68 --- .../site/resources/downloads/formatting.xml | 279 ++++++++++++++++++ project/src/site/site.xml | 17 +- 2 files changed, 288 insertions(+), 8 deletions(-) create mode 100644 project/src/site/resources/downloads/formatting.xml diff --git a/project/src/site/resources/downloads/formatting.xml b/project/src/site/resources/downloads/formatting.xml new file mode 100644 index 00000000000..dd8286166b1 --- /dev/null +++ b/project/src/site/resources/downloads/formatting.xml @@ -0,0 +1,279 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 380b34d984e..91e7cc564b5 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -19,24 +19,25 @@ --> + + org.apache.james + maven-skin + 1.6-SNAPSHOT + + + James Project - images/james-project-logo.gif + http://james.apache.org/images/logos/james-project-logo.gif http://james.apache.org/index.html The Apache Software Foundation - images/asf-logo-reduced.gif + http://james.apache.org/images/logos/asf-logo-reduced.gif http://www.apache.org/index.html - - org.apache.james - maven-skin - 1.6-SNAPSHOT - - - - true - - + + + org.apache.maven.plugins + maven-site-plugin + + + + org.apache.maven.plugins + maven-project-info-reports-plugin + 2.3.1 + + + + distribution-management + index + issue-tracking + license + mailing-list + project-team + scm + summary + + + + + + + + diff --git a/maven-skin/src/site/site.xml b/maven-skin/src/site/site.xml index 418e0b6553c..87372b17f7c 100644 --- a/maven-skin/src/site/site.xml +++ b/maven-skin/src/site/site.xml @@ -25,9 +25,9 @@ 1.6-SNAPSHOT - + - James Project + James Maven Skin http://james.apache.org/images/logos/james-project-logo.gif http://james.apache.org/index.html From 6435fbc272f35218d49065e4b53eb5c5fcea21dd Mon Sep 17 00:00:00 2001 From: felixk Date: Sat, 5 Mar 2011 20:44:20 +0000 Subject: [PATCH 263/541] Using maven-site-plugin 2.x with Maven 2.x and maven-site-plugin 3.x with Maven 3.x git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1078348 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 35 +++++++++++++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index b81e73f7b0e..bc2303ec3d2 100644 --- a/pom.xml +++ b/pom.xml @@ -286,7 +286,38 @@ - - + + + + + maven-3 + + + + ${basedir} + + + + 2.2 + + + + + + org.apache.maven.plugins + maven-site-plugin + 3.0-beta-3 + + + + + + org.apache.maven.plugins + maven-site-plugin + + + + + From ee43218444ad6450652c328a2dbe017564789930 Mon Sep 17 00:00:00 2001 From: felixk Date: Sat, 5 Mar 2011 20:56:09 +0000 Subject: [PATCH 264/541] Make sure that technical reports (using profile -Psite-reports) do no inherit menues from src/site/site.xml as documentation does. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1078351 13f79535-47bb-0310-9956-ffa450edef68 --- project/pom.xml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/project/pom.xml b/project/pom.xml index efa2b9e9f66..e2b1a67bdfe 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -94,4 +94,21 @@ http://mail-archives.apache.org/mod_mbox/james-site-dev/ + + + + site-reports + + + + org.apache.maven.plugins + maven-site-plugin + + ${basedir}/src/reporting-site + + + + + + From a0183b7b87c6477ca71176c15991ea575c2e48d8 Mon Sep 17 00:00:00 2001 From: felixk Date: Sun, 6 Mar 2011 14:36:51 +0000 Subject: [PATCH 265/541] Fix banner inheritence. See JAMES-1203 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1078475 13f79535-47bb-0310-9956-ffa450edef68 --- .../src/main/resources/META-INF/maven/site.vm | 29 ++++++++------ .../images/logos/asf-logo-reduced.gif | Bin 0 -> 6636 bytes .../images/logos/james-imap-logo.gif | Bin 0 -> 7244 bytes .../images/logos/james-mailets-logo.gif | Bin 0 -> 8489 bytes .../resources/images/logos/james-mpt-logo.gif | Bin 0 -> 5179 bytes .../images/logos/james-project-logo.gif | Bin 0 -> 7227 bytes .../images/logos/james-server-logo.gif | Bin 0 -> 6944 bytes maven-skin/src/site/apt/index.apt | 36 +++++++++++------- maven-skin/src/site/site.xml | 5 ++- 9 files changed, 43 insertions(+), 27 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/asf-logo-reduced.gif create mode 100644 maven-skin/src/main/resources/images/logos/james-imap-logo.gif create mode 100644 maven-skin/src/main/resources/images/logos/james-mailets-logo.gif create mode 100644 maven-skin/src/main/resources/images/logos/james-mpt-logo.gif create mode 100644 maven-skin/src/main/resources/images/logos/james-project-logo.gif create mode 100644 maven-skin/src/main/resources/images/logos/james-server-logo.gif diff --git a/maven-skin/src/main/resources/META-INF/maven/site.vm b/maven-skin/src/main/resources/META-INF/maven/site.vm index 2c53e349e57..b1d5f9e441b 100644 --- a/maven-skin/src/main/resources/META-INF/maven/site.vm +++ b/maven-skin/src/main/resources/META-INF/maven/site.vm @@ -83,19 +83,26 @@ #end ## #if( $banner.src ) - #set ( $bsrc = $banner.src ) - #if ( ! ( $bsrc.toLowerCase().startsWith("http:/") || $bsrc.toLowerCase().startsWith("https:/") || - $bsrc.toLowerCase().startsWith("ftp:/") || $bsrc.toLowerCase().startsWith("mailto:/") || - $bsrc.toLowerCase().startsWith("file:/") || ($bsrc.toLowerCase().indexOf("://") != -1) ) ) - #set ( $bsrc = $PathTool.calculateLink( $bsrc, $relativePath ) ) - #set ( $bsrc = $src.replaceAll( '\\', '/' ) ) - #end - #if ( $banner.alt ) - #set ( $alt = $banner.alt ) + #set ( $src = $banner.src ) + + ## Workaround for banner inheriting problems, see also skin docs + ## Right banner is always ASF reduced logo, image included in skin + #if( $id.toLowerCase().equals('bannerright') ) + #set ( $src = 'images/logos/asf-logo-reduced.gif' ) #else - #set ( $alt = $banner.name ) + ## Left banner is constructed by a fix path and the value given in the tag + #set ( $src = 'images/logos/' + $banner.alt ) + #if ( ! ( $src.toLowerCase().startsWith("http:/") || $src.toLowerCase().startsWith("https:/") || + $src.toLowerCase().startsWith("ftp:/") || $src.toLowerCase().startsWith("mailto:/") || + $src.toLowerCase().startsWith("file:/") || ($src.toLowerCase().indexOf("://") != -1) ) ) + #set ( $src = $PathTool.calculateLink( $src, $relativePath ) ) + #set ( $src = $src.replaceAll( '\\', '/' ) ) + #end #end - $alt + #set ( $alt = $banner.name ) + ## End Workaround + + $alt #else $banner.name #end diff --git a/maven-skin/src/main/resources/images/logos/asf-logo-reduced.gif b/maven-skin/src/main/resources/images/logos/asf-logo-reduced.gif new file mode 100644 index 0000000000000000000000000000000000000000..93cc102077a940966a0bf6d77e74ac273a10ef8f GIT binary patch literal 6636 zcmW-jdpy&NB^`k5({Ud=*EWJLJM77(p_7Ubjo^?L{6ozBTG zrT8~-uT3`YA6z(iU(uWv#wdC?*LrZ+m}~LRdiKU&$f@Oy^oJ`=i6+hgRAVF_PDwp- ztgxs!1ZD4l68M_KW_UVk-#Q!$Pa@K2Br166_?3pnI2h|A-a0BAXQR5&A?Fpb?Gb8 z2*k5oCs=r^?5ey-sZ^AxYup^lC`5wE?{)1hj19^$$^{?dW+pEpj_VrXL%+<@Wf;^t zJCdiUvs(#-G^G|kfoFntz873~ctb_>t(@D#$7q=4Jv#>J`Qv=$b>~!(=u%)Bm4nQx4G0uy}~g_xl^(YUhBvak#5 zgOuvw;WT+BuH_Fe^Qfh^cx6`2s#Q)p=qizh0B=u>WgT3-Um`*}GI*J|%p$EpRN<4Y zGf~z{=<@Z%ciE4S^38-`SDls-3H17pfQxW&*i~EFS~THa;&q8l$;Vfpq4`<-XV(d$ z`-SexHAn1eerw`+&nuVTz17YrVcMN=n%6b~Pk7R#fQs2Gpwl_l;)!9Zix3)AS!c&C zQ34C)+gAHfADmZ#J!@ouF>Xj{z_YVB18pQxGV z#8&ZYQIjf}4+ukXt98XP)EbGFTjdXCr7XQ<39V`EX@7dX7sgi%K^WawfM#Gv=)Aa1 z+o?NS!01`I1iDVjJKI}zgx$&^C5Ef~EU7JH?OH!a+{=QV@_zU`-5PH*I zPuRv#n3aaLEiBR7@r{SVvX-}mUhuV3xb?k!BFIAH>qbPzbWFRFgIRYuh*K-nKBmlY zXo!mHbNn_F82LJk8Y(6HVBaJGfDmIP$=s!3^Huul_S2gBtEE}_T2@5k_$OT|Hfb(5 z)X<#6D%iKo^EXxX4F^7^85Vz6sG)}#XEvtZDoScZ&v0xHPB;j%ar+w*l2aoKKDo2- zb9>!cbUD@Cqd08ehtuEgl-E^3le=d;7%p1%H-?USDXO&=Ns#x}Gv34#dLGHj^Mbev){8$exY)@D8txn4_GgU^Q#nGSmQLy^q-T1(e6TLYS zkyodfAaB@J5Bc38m*mNB>VrC0Ux|ebUq~Fex!-O z_3SLrfr{Ra$gx{pd(y!YKvCLGkH;%6{CVnQ{;UW?4*=tq1vDz`SEy-1yIj(V2R)ZFCY__!(Zs!f z`rl=^e16E7%Pt1a*QGNC=$-{`qOzJAu$vUT+P&2n>8pCwFvLX7zj^SYb`8p=S+0`E z$XYnM2{X2F1lL-FD1N}lfYe#DT)AY*L<*-3n_K(QvY5+XtlTfjs_Xqib0@!ESbnk! zSA5ArtJN=qF`{-hEnA~6zDFo%d=8mF^^sHw%D{yEh@{rPMqBF5>hB{?M8h{}t@d0a z$TBh@8x%i2xYqf->Z_kO?ik9N@?Tnd1s`-Sm~BEsL0u8q&B1GhLXeauby8lte(=TH z=AV&6s2Bxw4Bv}#m_ApmU%KiQkf8nY=}IGzQPzj<_?tbT?S^q>@387$GCgoZ>{a?} zs*!BKHygc@UGbJ=GHbM@>qZ!K2AH8?ChBt!Rc8lW$zk7VEIyd*pHZ< zE$>3tEVKs2MMV7_y;EJ&`Ixn`WSsRp6bJd9jN0ez7 z|Ma|Lc!>!cW3KHdjTYX+6Ie1ce`!;(oJVsG#TcaQP4A00xHl)OMsj5M5|l7eC(3az zDJOcF{El8dJ#Rzx_qnmF*i5mBua?=I@#wMvrXgR?ichil(W`n;21chubB`0YX{t^$lR@)6e zzxHWowXNRH^1Qj<$tzEf&Y^`bdfs&ERfbPdDZ3B53tO443vu5as^NZ_IwXJfQLrGe z*svE7@rd$rX)~s^qXx&9l&pV0F0Lg#>vRaEt0D{^yK6JYuX|TyX#+v*D)2mcq;*Cp zfmg+{`z{X8I**n$^E#AvnZc#GzrRAukx7ov5b^QQouH>j)7lqpVBE5P^}wWc9VJMF zl|RDZCikc^4kDE8%0ixL8a>;T0`GN{#v6|OnR?@tEUXAkxLJ7eVdS$v?N0>>6O+H` z^2{Fo2$O4$vb6y!ta9)n;7$uEBjvIC)aTjix?Ev&58b zTHCwd`4prf7n;f;4aFhXHwe2DD!6nD&voHBVW_e^kk z4BA-^s7S#3%MdJ4#z`=;Gr>L_NJXrykOQM%3PUrC{5VkM211p-l*eeZE_gIfIC*wHsp5pD4ONn{s>gfc~b%Z~YZ zfnp?qAD#z;w}Pl!;NNdN^7{Ah$UuBd#BGr$q;yX1IYErS2Le0Dx zqKPdB6#2#+aF1s2nU>;y3GRIxtU@)ZW|^FpfQ~=ZZp%^@YPfu9&Thx@P=y`kq&RXQ zrP!}nk8sM64X>6!PGY$JGH6aPF_geaVX2e20;v#Fg(T&7r%qiezhli!WB6VLkCZ*B zG&`?pe<1&KTg6Y!%9gm&{(-Dz0m4ZN2hm-2e=EFq8EYj6+(TS9F#>*%LhWhDO$Eqg(i@Bw z)ysu*&R-5ba{&B^X%ph=;~Ze6V^@UXC;oaVAh3nK4e=SJ+})Q!mhX`!p&LC@;->&y z*%W2taFQ)dn8M%$JL=tRX3)qPH=>dPFsJGwCA2L|HJ%mKj z+y{JohjEIwLdk)ki%L3nlF_un1W|C)_?oXdHHJxWEt5OSuAY78a@UvZQv>#fngy#D zda$eabAW`YbKVk=e-xVk`<#M<0C`~Vq#5R;JN!<{#bsQ{XJ#H_~xNkfws>)tk=Nd2=DuVh(`? zKbj9|62X&jT2m5yRsj^6*w}MyONIWHK+*)q!^jL_U2(Mwdv&9cwJ)Nvvpa7o8k)iy zo$y3h|0JtOk~^bd8{WmujPMc%sHVchB03^Sb~uD=9ux_+r#L6jz0P(=Y$!X|c){Km z?fLK}si+@jkFBv!Q@K0>0$w#6{ub%)YMSm>%~9uFy#et(ya<}gRQ2;ElN`gOWOB)M z?>DekR{i9Jsx8$4$*0#w)Bf5RkUxJ!K+o^z4rbhv;V_6(p-7uz?>a# zDmQ!+XacocAKJy4EE*aJ5_O zOl7@}o4eoGZTmg|$@UZeg7>|qstB=;z~yyP7^X&>6Iul9wdDbqR!|(HgI(~y4bEgj z%tqp_C+GnG6Eu5vYZwFarm%kO0S`>W{wXs4Bc*Kx9v*U#|E11@P&c^;w33o+rS3mX zZ^{t6E||fFhT*& z$DjcTq$Y2;o9%Wf9FZevyFIOXQdsN9MYJA58+<3}B-N#2cE!;z5WI==7sz?xMoOhz zCcFEp2Joy;%Tm{v(b4hj?*Q^*NLZjte-Cvs+}BwF*3RDM+ZvgK2YRtLoAP1um6~CC zw@>rEM)H;)OM3k2JaP$*d$h-ya-e6dr-4L468u-H8afR_e5*9CiF(K(Cm9J@isrWu;W$PP1TA^Q5f6Fvm^0E!e%5G?i3bKu z{Y_bc)_ET~Je&J>&|Ppxty-gD7^mFzg)*;3yK$m!uh89nW?=u;;J(Ukj}X{@$o$uk z$D||T{CMs~RQp&nti<#1&O(x{p7CHf|PgnQpY-@>Nvror76~GP}JT(kgx;Nb}5NhSZnAlLKawpPv{}C;)2hij} z-VORkhG$HWlVpA6+QO`}!i1jeMpnIN(Qw3S+*Ou5@BOsu;ShlNeakxDSlH5X@`wsZ-B=B^}t8EVN2WpeWtGP7&oYjaRX;8E)O+J)+0Eg`%&btht7o@_=5B zG}L1PyFKiFGCjmEgcCDdUcVCjw?p#*6+*WFo_@ZNNb6~LvrE2P1Ru4##STL3u4F3L z*$=Vae1mATs5Qf%z+bemF7Xbf3~@o!*q#q%6(KZ*3pVUEz8tvgS;Lvcg@LO8O#eXH zq>p^m_Q3Yl@-yi5M)=KD;6NHM`7vBn)9`{|U3AEtE=_e1P?$VMP7CLdHrY4?p-KJt z?4I-SV<|g?s@V3;aUsaKmh-9j@-TT;R2b6YKEmiZGJXW%GmD56}7a!qg*ZT093>v zRz?yK$i^kR0fx>=K=sg4p)3658SV*r>97F6DgYB65WZigcl|(D>z%LO=H`Mnn`wZ$ z17R)!YJR$CP66?+0Ra!Q>N@l%0q;r2xtIPhwW?=e^`9!vZwV17-} z`v&|Lxi`;X*yrlGVH2dVIefugw~g0%h=SUIP?B$j31DUvBdWX!RR_#(g^grxEaBNF zPBtudN<)iV+FZ!d+5hg+5J&Kc{8OETWxW%AhS&-JAzgnD!y2*9@s(5EO^-9pGAbx= zg#EdZxG!MeuOgDwu1+Avr1pU-1JvD&F&{S%|h`1jKPE8AZ9k@JRFi0v2K#muJ(ewI`fD=fye1%bs?&BeGF zZ;Kf*o`hYW^tpt?tq$ty>AH5Dulshs%z~6tiW1;GG`f9=Ly2Rh*sacZBEQUkRMCso zF(ECs$v<#4B+Ci`W8DE(IH(va?>eRhd&*Ws)cPcdW>57a3zdK*%pb*f<;JNtKI0 z-OK4Xju4k0B=B+2Gi?d-6YhU0Hg-u4T3_eoi!hE{=_4w2X!!hhR9UR3Z*bVfO^dB@ z%PGwF+v0V23+}E!LbhW#s?0(LXH?3&zWt$Tk-C=x5J4Uxye3j?S>N?L*6t@Ap4dt zcM)kz>l6V3L(wORWE4ZuXZU>MMajkfSMTVD^jZMsMn!gIo{f6w>v(K0>sOvxzEw=a zrNq05F^F4qmE!-zC(QGQ`ALI5Ao<%CXooIt<-mU(5n<_HaS8j zDuLZSYT+|{!Wh1VGuH~Ji%q}YTBR-VL>(y61_$YZ82tG5K;VJrr`+k+V ifk3o@FNQYto?ua@#Ta7 literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/logos/james-imap-logo.gif b/maven-skin/src/main/resources/images/logos/james-imap-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..22321027549bd96fcea143963754bb1f38a5988c GIT binary patch literal 7244 zcmZwJcRUo1|G@D(cgAtsIMoxE{(!Hifd2r2Ko%Aj5C{YYgIQTw+1S|F z+1WWbI3N%R7Z(={216haNF)-4LZQ)UUS3{4K0ZM{aSR3{ARr(pC@3T(bmq(%0y-Fr z#Y#v>NJ>gdNlD4b$lOMvaX6f;tSlan_Y)92ckZ0Lyu5;ff})}#fj}Sd#>Upx*3QnZQdigB-rmjH zGs?o+(b4hBl`Bq8PFJs9b#`{XcI_IKN_BB@adUHXcX#)3_we-ejJ|fu$H!;dLc`bB z_xkngetv!d0Ra_mo`HdZK|w*m!NIqJL;e#Q8X6WB79JiR5fKp;6%`#Fef#$9J9qBf zy?Zw%CgzQw7mY@%h=aw(#>U0PrNk!2$HylmB+%*f)YR0pw6uHo?xm-vXJlk#W@ct( zWwp}dv$L~va&mHWa|?5F^YZfY^YaS|3W|z~9z1wZTwGjIQc_x4`tadH27^&nR#s6_ zQC(3{RaI3}Q}gg~)oM{ue??_OL&KBDjZdCDX=-YE`t<3`mZ$&x^Uu@^-Dl69wY9aq zc=4jWz5V6OmmM7)ot>RsU0ttUz54b~Yj^jn?(Xj1-rl~xzJY;(!NI}d;o&zU!>?bz z9vd4QA0L1F_U**P#N_1UyLa!VrlzK+r)Oqn=4Rgg92=XPo134X|M>Car%xY`K2?4B z@?~LRVR3PBX=!P8ZGCxp`Ol|?m6es%)z!7NwXa|Qo3HEZ>)*eB-`w2X+S+1neBIvO z-r3ptyLq^~_hWBwZ-0OP;6I1EhlhvEgFai4zVdEx7PaFp~-f6h0 ztS<>EVOnh5>^cy>yEzFmNP^?Yy&EHa;R+8gL}3W;E5Z~+HA4?AE*G0Tt$y=B$B<3FRtH@fo9Qkd@`h5qaR=KdLp73C}T33ll-({_6gO??uUo8Sw6qP zR>2KdW8s%+n)@>iv+_>Q%`W5;2Nc~okXXyC$8JePx0i7`eR$`wIajUzQ>T`k)~daH zet@&mho#CrPe;K{myIm@L?3AMA8poEKJS&mCbzz|4_lSzFO|v(w7Yp{%UI?Fup>U3 zIcSFrMR-3mMSjooUeb{&;juQ`Jt$AXk2822O?T;TR_djn7USVs{((tyv-GLdxKe7+ zJ;jz`@v-b}YFsi#bH2?~YnmRItT0P0cgrxuOC%{QIwj;?IP5rf*49s$N)>x|g9cGn z7^q0s*c;}aGV|qRsp3BRmzFHE=$=5)2Jo0pa6c2K-~hnQETs0e=hQdloHH%!XSgW7 z6GR^#vNvjstp6^JC7~jYU6eyNL+co;`dOJN@3PN;i_>>vIWAF`UZZOxUEQ>U=nFk) zY-0F3lUuIhk2tzGFMHivR1>v; zZ4#xUGPL6E6;L|3SNR0c;~v<{l}K!_ zr|*|)u@rt7SDx-*aB3EWH(J~{1YhP23Z9psa|Gq?r-%PRTh~gUJwy!4?%{IH0SSCW z@~e|@sqr=J9qT+|>!^;U(?Y>IM$+poF z@;VWS3!6GJ!37nK$GZ$(g3Yh@5 z`AU)whnvsrWNPSdmI6`oYsol#xuBG|xNM@g{BTdAB6tOIX>*VSHATj3(1jd3K=jVx z-Vl`v65u&mxI;d|4FE@VdI)@vo)5mfIIxXXun?Gqf zNV9n4e)V2tdJk!i(VC^Et0gy|8$QWz8@ZWKA>2~?#U%4TYy)Qkb%BG}M_mfFW1W~pt z!S(Xd@BZ{-as(baBneLwPz>s7zH#<&cVHR6*o52COnW$406XmVcTYsgITtXs<< zP?GwF%0|=UU?ajTfm9?rq)rFfT&pbiNYXEA&h!hPNuaK+K1srOSdmcSmqLYj5FtGF ziG<$L{;C4&;`V$b9J#6|Y~e6Fye@er_aD$rxeZ92{IUK>z$4LVhYbY*JTi!fQ?ON! zd0l(03<&4|irvBG0!qs$dNbmnG}mtS(f~Sn()|WJ_@l0^bVk@joZx+j-WK20c+C@* z_MlAAosG&AvvAcj60+~Pw->p#olQh+ZoIX0LZ|OV@^g>RN&0*&OIvSDZI30hsq{9# z-OG&=?8=M_xo$v}af%gOb{(-9^lh@|+2Crfx~%QcjI&k(vn90CNGrbFp_th2R&*TE z+4V(z{W9FZxH-jsY>DsX$$*?n9H}TAMXwATtSk!TzA7~)`s-wf1aHYqGG7tDTZLEl zolxAMq~~@do%L+@GI82_ixWH@r&z=pJz%uh^&5l!cv1FV&i)lcFe{D{h1Rfwk#VtUyr!yVGn%L~(i&(w0^-6+&04&rJF|N12KJEjUNg z&cDzomdZjgN-ZJ04vD0}(imZwt7J(w$?g((Xc_;(3ENr#)ZgW39!tqhBQ`n|${CYb zW?ILB6(`X*R{~_C7RQmsQwc6~nejh~*P?Agg!B#)Gx~h6Xyzo)OI@Z$q&~)lyNFb# zXV<(?8lzejhNBrq(red^Cr#$95tlrRqvOpWL0e*JwgqUlFyr=s6OLlm2wlF;iDT1R z7y37Hl7?e$Onfnx9kal?hMAM zFKD|&d#IQ#ESrv^H#)3a9FWf>6;Ob!K+Z_W z8xpt1efuTGxx@+gY?Syxn}+BFs4J7YwZipXl4C6f3NMGpoR_Q5JiAC${V{O%d%4W! z0d1NDb1s)J%|uxD;K!9onu`#HCU94i&o&h?3Q*gW6jer_Ih^2XTjDwb=o?Y4sT*iO zbCeAyI8S2`R4m0llL7)FtQJ7aO)f1S$Ox<=I0p&9z$D2yXcHG&2hFu=7Udzjx9IeD z6}sIIU*CaYXiC-u=)J?U(oexmxjUq)O38IWKHQoh+=ox-p`xXc>fIdT27pu|Ti~rk)=8KI6_CKf z;WwPh=E9z8#qO7z{3#T%!9!RJM}9)fDDW`T0I9pV}+0>c>FX*YmLOm*rHcs;PrsG+9k050Jozx5GCNk zL4lxo^H``(oyuA4i_`>HJ4~VdsE7O>)}|gUF7EFAq(}7!nMliVkmWXzk3f4tNSLh4 zsC|rw?)l!>h)L-)Az8%0atE6#VV@!Ip(T~Pfy*oe0BdF@8vzEv0^U)PgWa0{ed4TQ z_Ql=6gji5F88uv$g#xK=#8_Wih6#hndb{Sw)cl)3YrHxhtdp)#fli>H6<2|sRKypg z_#Plme1dDciRw=iZREI74yI#SeDaq=H!>f{@)B0b=s)7H1R|G(2~rCHfCCcQnTsq5 zRv_CKn36jChbBm`!h4r;2poL+GAQZ!TF4KEtt?J0#yIoI2ZuY}-W$qpnx(@&6UuifSgoFCgUW! zk#`waIy?%l>Db;xA*?BIOa96hcuZ?DuZs>7(b3u$N^3Nd?rm^QnyRQvodxOMeK$BXkI&Ry0 z;YwvuY&vdRYv$m^>MSor3znlkM(T6#J$ni|Kw6Zm6*IgT`ck!)8GpGpF|w9kRGZRX zn>JtDBZ>RG03%73{mQZm0Hv-1#pQuHa^Groq;IUocrlQ5k78}JP(gWp~zjZShm?p;ry@T>+xf)v3)6W}`9jafxr zUDN}ioQKPtkJl~-NqZ?B0FoE6P?k`^D^wp618Vi$Cj?^PSM+3kpWApN6ba^eMAX@K z(fN|eL+a+KcJX<9K11nHAAW`O-HW3-(YFDhZ_MVrQ^q8>;o-A7*FWkQw%dsM@0y$R zRew=w*_hO#ctd=}fFUui9=iq&KRpR9h@}NC*B$=%p21fcoLr&#o$LbT15Z1`gbfLh z5HjD8w4P&APyy9)4W%rP;${got8HdYkzt>mcx-yzk*)cu!&#v_?Ny)2SVtRlrN(R(`KYA6I;#OQKHWrGQ-aho5_vQC?J6l@` zEC146;es-OmZ)1fRMkAWwejrTXuwi#K@|zuWo^Z z{)%yRXv&vTv0P3Dwx5Jc#9j%D2Qohspg}~OyRM1HCX(hOzn^8rvwpGY28SL9Q zqX_=Uzq>*WnYZz?x_nC#&-88GhKyViy$Hy-Rw{^=`0-W=dQM zDToour$RdAI%Pux&X3*J;ORJg7XB$HYL6`H8R@YrUD8#vDU6=s=#=2!I?Ck?G>kA}8$-jznIEAtZw zcM36xFHLY}vyq>iFz^Bs^3h3BaYev@YTRVhqp&c6eC&ML<4&7botKaG=jl83k%-7) z?l-|xLwhObXrjGsqAQt@k^t?ER`L6->WfWUZ$K8Z6d|TAC8es zTzE4Kc-`~}y0idoA&I>&hvZN9L8Qn;a02Y8T8%qwf&=t22fWHB7MeTr|s{wQaIM0_kcZKoJixcD* z`G)Of!U(aY6I|*+_t_Jn`kRp1nD|@+SnQ6j1sS|t31T;d)$b%n@3DaDuN!tww$;OB zfYcbbnieJlG8GOvRT2$aa_Yohee;a-GK*^gV{RhZ&V7^!b_SH*-+>#1A+%P376CBA z?xo^oTZ<{KRU4t_$1bI{?_JT{{>{m=O&XTm2}kP-xl?zHMBp7nNUlxBQ2_7k1h|wz zeidh@tH=pzWN_O#78{8=5u zIEk90NbpBJ`c8$PPsZ!vkU7B)Td1`Lv^Z{#D6xk&apMuDJNzh13l4N3pjQm zFp<1DD9xt{Z%w%5Q>0JZmXL|W z*)r%^DYjLHhyP;Aa*Nes$xW>Uy0(YB6mX~ZI%97~enyDk095+@!Y1Qv|2Jh(GLLjp zRvCwe1#d=?bz->~nN{R2@(mf#jzwl*6>TEEaRqXvma~XD$q~g$>w2@Y@>9f-pAXft z2Z;_6=!Ype>IlS6XP6S<6z&1HQ+8FFuf=y9J$_*kad8A+W31L?My<74?`h}76#=!H z4q3C{JV!bugk;v4==+MT(s!N8#6Dx-a2>DQL^Q!N%EgWVnuCQU*AV`kLJp9 zYk3P;ubJn`c{u~gKAsQrSc*oRATge!H!SVsk;*ncqxVqCYpF68MmjpUWlF!z1XVp_ zS9}nvIs=kU_|Z>CHuuX8JvrTg$wLaLGkEw z?LLF|c6+T_eJAZrL{?WGUy)0{`Z6^0Zq!a?W=TP;*|hrFoYiNk$CGEATkW?u)}$`? zm6>mve9sOWnjJ7x+kLK8%UxCu5_qLBP2V0n+*yD}HAf5b@znx=j4=zqW1sNvgTx~UPNg*Fm4?|;F@ZC;C#>9`p^Hl&z7PhmUfhh2J9 zdVKB$rM0x97Z!rOC6b0%F3Fbe#n05udlCan5G!W5o#exrHP-_6@-2JQ^v&w zr>wkMHVb+yB`y2wYU*mXgvRwndQaK3L)T@8lCz`Bs)ZxhKfDtUX$;h5_w5=P1?e;r zzKTT7t0P3#dIg3dA^vjbtFGByUKw}Y|4>cKD?q^#^ZaU`p7&560>zsxEL3n7_-35gdF#9MQPU~1f$ zfjuuF1X)SGTGs=n{*#Zh=e3nb>9dO{%6=UhRdEf-&zmFX_n_=FB--4i!3&wWa~*c7 zX$#ghEkP$xnNnkZX134MoAFt!0)BIK>eblfOB&TK&0?1^UTVMD1RPVk8b4y6istLs z*u{!_Jjix1p#}4RD`mX%Z(Obm8@6{1FVDh2qMwN1;QN@1jrRLI`d~x`9`7NR-qY=GPq4nx-#FF4Def~EG?~|?$ z9~M!LtwReP?mJcA)bKpXc1WN!R`~A+8e&``3EB~>S@vBKUmu1sKYqGlj|`g+9@75x zY=9t1m2p2M_($ZvZWPrUBVD|GIP3N5_VKJLIPAyQnpbyzS=Y;%h6LTNX&KlQDt)-c zk7nFnzQe9hWjV+DoW!OwK|{n-!BT2EoOTnj{QXom<>xx^(22M+U>6PpHC=T6M7+!< JnFIi6{vSu`?*ae- literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/logos/james-mailets-logo.gif b/maven-skin/src/main/resources/images/logos/james-mailets-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..7e410647feb48d92080e84c13b1cf2420c7f0ff7 GIT binary patch literal 8489 zcmdsbXH%1p)AbcdNTGNogx-?SLel_(p=s#7hTf!05rhDW1%C-7lmHs4fT*E&2v|^T z0qKGQim0FhiZlx-_QLJ|`54c6u`~N(cXnsb&Y4|XdmFM*s176?_y+tBP$(3EK!}Kl zh>3}TAc(U0q$> z+}zyV-KkWnmzS51kB^_9UqC=WP*Bjpg9lH#P{XNFrw*ouhK7cRhet+6#zaKM#KgqK z#l^?RA31U)DJdyAIXN{sB{enm*s){Bj~`D@Pft{aY=c3d1Yl~ zRaMo+ix)4o*I&(Ha=F}^nwo~%+Pb>BhK7cwrlyvbmbSLG&i0Of;PH6f-Q8ENT)B4b z+Rg6E*RNmi?d`pF>(-q+cLr+fmMbgQu3Y8w?|z-H=kxjf{rv+214BbYBO@bYV`CGe zBje-a4<0<2oSdAVo}QVRnVp?|Iy3$3*|WL1x%v6I7cXACdi84d?ds3*@jvqmf4_|` zE-t=){d#$Md1dA8%F4>x+S&HL*{Qm3LuOC1E{Mh;Nb7yDg$KSty zfByON=U=9O-v6V<|Nln&e=YuR7XZW#5Q&tx<8k{k5#pMGBfRQ+*`TsRm0efOV4k#o z?EFYq?eJNgC0pKabEeg|OV(g1WgXk>+wFbT_=`hGt9yI!)sh*_vR0o4|EmQ1D@{|i zc6kB?UYbr)CT-;E{M1Kv&Q&_DqF-XxODF3>?y(gdkA`TwSCtU`x~)_noa+v&s5(*R z73g!oZ$|rmPv@(<;_mB#HD&Md-nDLG7feb^y)Siae}FmN=w80l=37xT_*HODHP0zG z_Uf3I!EMuf1Z%4^>f5N2u)H7O$$(wuCml}7+?-P6c_}lB^`x~#$ zZhN)7rZIYaoYgLL%c}LH8V-YY*uET%b2%PtEz_i9MTwnH2VZ5$XKf#J-l^BarG1wn zJ7`v58wNnzy@-4Gnw&7UR%=^Wby#=Alf^TpQC15{-M`^)I8v2GGxD}7Nme3qDuq^P z>&a@QT6q;yDxA!keO(r4_~zAFE6iwVVO6vq9Al5@f>c_Im=6#<1-{6Ido9l{Uq}<% z4%fsNks}<_7Oltdwjy|Dr5>)Dh{@*-*lX1DA6L2&mt$fs?l5T6XO$(>9Jn2c{i6iy zx*H5Ij{vb&(=kU;wTiuWPOP;Be2}nLIZwx^G!BO@&m^Ct)6_7rioL7osz5!ITAHW< zwte#JsuIzxYVw{;DxE+m+&2~RTJ>CFe@;z9&GQg6ZLdY-!iT(rf?Y$VssG1S~qDvpW4?ojvmJhSM{p~B=T50d7 zz*y|liU_HgL&nDwi&0YU!y4kT=PL%F1<_j*|FsjO)Pv^l(=l$oarf|r!N{73dTk44 zO}65@x*D5F^GNLmL{#G?pVw_yeJSYaOi{zc#Qxic1N1>AE&hCkMjc1b79HL4ETUgj ztQv7yN+6Xp5%6tCRMM%rs^4DP;nV~KZa6PzDMBMn7rAlC^3Swb#u_~$u2M-%HS`@1 zlnmb-K*TY6f?wkMttQ}`De<|}M}RJk6M8Q8Zra2ESf z>-??hob~Ug`IHUP2#_i2YxOBcTf6sDcy3Qw&I^Sl);dq0&)Dct zf0?bpPwJLcKT;dB-h5bc5$0HP{p=5+RdgltBRS)qg-8gG@~v;zVZ&&7F44;9g#sIr zOnoX(UaUHVRtbiRgxWcUVVt+kQ}uEnLbdQ~tD|)AJY`hVHx#bSadZ{|1zxa2pcYkO z5mD%Ba7W`4>Vga}YPiBpDbN-wlSqfCM=M}Gh?#~F1W865Q;HjLBQpt?Y|9f2w%RwK z=K)oNGsiKD!w?`5Cp4X`ApeV7Y%>CJ7>M;3n!Cb8LYmd0_txT&dJ;@14cC|FsPbXZ zMx=kwY4mTT`Yj4nxZ^ManTb)54aMLYi5%|U5j1kie1ud3_bg$EO7j6}r>WGY5=&Rv z!n-dNoU&b)suh;5w!8h*+uba!s=@lCU2=ViNwbQSdqvDt>(>>jz`>LelKb$y?qjy( zfwLjBk%Mdy+d~+@6RO)2GR~AoB}wBO5HQc7glq?8_)SWNT5RB zunEybac2}VFeStUx}b%K12&6oWz`%4!}Gu_eP3)qI(a~CiDd&eytnKo!SEg$ncOZt zq4vC5(VrpNI+7yU>LY=v-kC1NZ>;u&w~dPc{6`lZ`UnZD8m_gJBG~4(0DP3XF zwo71yYW650Nl4r6il}6JwDm@!)_$0V6G0EApm^iDIPX(>r)Q*G?Dy$R-GvxYF2*~!!g6*eU13;cYPCf*X;jj`C{2NO31R2vo)#uv_Gl*$$n?@@ zNEAk|-(X9m)_t$3=Lqjcgyl1j>(`G7&>;s;Dv0E4UOVUixxM0Xl^R=3%i+Z}ZS4^T z1pz$$ZO9Y`5Ddy!lgEX0^QIFZ3Ba0Qh6MOsIP=$@e~TB4Q~GMk(n;6{A%1Nhey#DV zmWTY3*-jySEYDLb_KR@AbKb?J*AKfrUX_yC+xv7!Pjj`Mf(4!;NLIo?)5kN}ju`RH z$8dYE4`CH@MV%!!&lJmGAC* z(!$D$!@8a33}FNY!Y5GhUSvJg^?a5wrSB%q6A!q!d7S#NYp`osMRzSs2E={AX+LeZK+Zv#r-JaslaO9WA{~LH zH{x)DD$<`=&;P?u3Z5R3v*FFcHy7Rsb^Vcgr}LXh?nmO%(p_O7L?RKt3o$zC{OKZl zfBtuHg)yp0s7?!4zO_Idda@I#zfq#kEn4l+-*^+rNeM94DPDVV%Qe`kOvDa{H+b3} z+{ocPQhoz7vldKH2kD8a052AaM_LRDSqRaPcmxIja2%mCo5&nKbblnMzX`}+4=|NL z2u&dg0DvY5#Q=!oZbCctG}T4qW3JOhN5E=0kV6LnFSqJ_!2 zHjO-l{whR?gH)^5_zx>SKN}KY&8#Rj9<_-qSA`RoT@oWwa1HT65y7!h@B%l9l~5V1 z8z3^3U>YeTVxA{po^AF8j;f9`jsjyxsE2*?GRi-aRCzShFZO>HH=s3;-^b3W6RSHXJ^BFRpCLPkUR9i#`jQ%osi?5slmdJ z5IKv5`$A+MaWKR}=1?gx$rA2@ z$uz6ewvKgEPz6%TwIs`mYNJ+U}7EfmKz|87TnlPdzUgWl|Si-vwK zm(|0oH<8618Avh&rBki!iAQBn#f_88Rjz2KtpxAA3bwxmk1c?IiNfvPA;MdLS)?zl zy3|$!Oo#?g^QqsPz-pe4n;$4HQ)*f-Amv`Bo-7|PP9aapp1`9Dh~n)4Dw~4HJeNzG z3@M*+QB8GsrZZJ&SMJ}=uC6axnEd?b%IzF(`Y--PI` z!n|Hr58seY5G+zyfW=b~EaOZi61;+o5Pl+5NrCE-p>-T&@aBF}qQGoU!Ou!$3cX2* z*D4PdDN*1ZB)$A+s91Yh?iW-AckgEhczU7`3746?aAdTNK06QeaAgTbVi}X)~&{H8t7TU}r4>cRL3r7J!J@Jh*GK&2*Vkjg(7bn2$WK;{K(P_YL zIiZV3*CT^}K}PQ(7qxDuI>H+#W%rw-QsjhQ+ZY6G$yI`a@c>Cw7XTJGa_C9{JmT{p zH98T@ar?)#^V6C)V|wFY)n|`4phfkX(NbA%&<|ZByN4h!_TYrn&AwC6BgnNB>h#Ee}~0a;=_=yxSFAPwyJuAnWuQ)+8Zk z$>N zg7^@pv_4dkk-a_{+U_oXejF9y*j>R#o*b^NoV=~L&{)zx5`S{6^#raJk2=~{kL;s% z`|`tnp0!}bp%!}q-jD#J;ju#>6z@q>8@_%Xywwxn!X5UgS0}t19vB$SC`J~B40Lc% zZVmtEIkLZhFDRrrB-EF01}p1p8@is$xvT|(F>O6^!y=6En^y&p zjF4`RiD0h85E?7RHq`Am^z98hbq<-jqXownp=RbFmV9yB6BXs08{UC>M034*97=B$ zlIJ%19j^`9fO)fEE`J^elV+$vG5e}V+NwG;FbRr3H7~@0mytmI@O?#RaQ}U()lIP9 zX}mjR-1gTHbB6l++tls1Acs_W(g2cWB@wR%5`#u9mTD^(#LtJERyVzouixVx_+VxJ znyH!mZX#UZg;4Ve{NMgM-=n8R$it}zsdErL&g49n7~BqG z+XXSs;BlO1#3UGZVG7_?cGIu?P@k2a9~TLw(OD4GqFe_K+c>l?CL9s)=s_W>Kx?#i2UJdhXf?fu7#3jiks1P9op=rSe^oNf_1pQNvYD=OKEv+u zN?|B&GIawc-E)`xX$EGFG`%`5W1iO=b?JJ+R9EYixCl*%_@qyCdRHi-;f7D|anQ4B zzMV9ntc|_P5N`*O%5xAaKEl~p*(MN`LV7SwMy<3xG7@-6Efl9XzYI@#sdl0|cydwt zD9RAmRl(K%tZ;|8rDU)~(p$OHNP@Q=?jZqs`k!9;Rh+-91OAKiI=8@Up1W0WrFEFP z2V6|mK^p_U!lq7&9gFvMZh1YDZsa3gI6_DJQR4lRHPg5CepworLVq~6wrUE$)`2Tn ziRYl5idAkk?`X>FN*7s??(P{8-}tR9`w}(VC9}1JD&${F)hhDYtC3U<=DM{@ZLwmw z<6?z#!guE6bc7GON8vQ|pzj|HR-2 z@xvz2j8O3$>}q7p#a7veyueH+{2s0S{rZ;ppKtf{LlXL$j|fy-=SUY>atr3G!Ty(O}SIhH5x8j@ge+e@aEVVJxeqk{Hv_huB8`H3dF`7v1AIF=T2FtTTdsBEEGRri z1@Mjwlnj`tq6mb7rxT$%+ED(=LLX6BSh@sSSkNaTY>O3vp()&4Rdtl_NdKF$j4;X5 zGT$A%TfI9Yh6rE!GU0m~!mi4yvLCoytg^XETV{J{F}f1hw{gQ>Z9Z1UDbf~HHRpzI z--$IIRm|&rmyJSds^;_qvE+!`Ey$zlXb=1FQOw{NHn5KRquW0=SKv; zf5l}_=jn?VEFa(3sI(90iq(wk$u`^{u7EU&SPSS7T((L7HMZjC=c13ido!glo2TSd zN;?s_=itr9kl8vH--ZdF`?op%xly5nXIeU115P+u+;ok89%(v9`K(B#00H~cL_-zf z=s>|gfj)0(IPbt{Y5dSslu0Czt2J(SK>b}>e4V;bTJ1s`>#c)Bnp$ORhu>IPo%fDm zp_`0DnAl1ijr%2+&(Ki!b{#U#Yxb^U!^E9-%Zv&3x|l}iv;LMR*6c_Vh+;XOq)mOO zEp_usCJw{BpAjsGGu(${^ZVz@!>oJ6j?ma=25q#r)U~OcZKb;+@6HH=BKB zmhbuG$O;^2a9}WWj9mPdn@oL7KaJju@W(XOMzK|!-ASR#CR(h$xp}Om^2^*kf>7w?a1l0)= zd&97S#>%;nL@=c;8v|FJ-7gU4(pe*f=goXt*9^VXxL^Iz#4ABv2}!A}UZ z^_Xw}1qVr|2mX=odxb}a4&VSgx;d>u{pEI> zM8gR4PJa>7Lmo*wuE)9|9VOAYHHyoxVJAbwFYFwMUp`#LmsMCAQczQH6R%hR6aw+t z*p9G0Z8(;*Qz5FieMusCm5(Ol*?GdI(;KE8<{f z2v)=-;3?4)f1@Rg+d+D0iNpXE<;t%R z<69PmU&p8_Ie?%|bOv^(mo2iMm`mkki0eXG8t?3&C$HU?P)%TyS}DRTRbHe}~DN({Qwvpb(Iox$S}bm5Gpbn$Cp-3&;U%&@pm~4ujcEttB(@ zqsdGo?F@8Yw57_SfjUXiMbAtb5v_O9Wrk^y8n2v6i5W*F2$P(H6hD?$KhA`(z1^6C z>xX|x9->BAh*1You4|NRqqIdqC61u_DT3-N1!x57I0uyTFVdzkp~omtZMDTLNq_>7 zeU-FJiH-(cb>L3#71dqy^c;JHg$UB#+}=qOG$*48sB#NDsykZ-2m$Csd)@Xy@mHy; z#K;TxK;}^iX$qt;ncR;S3$1hKrHUoUu;!xm%B_E2Yiv#1X`b8TZIc96MumVJ82rbDiJA|Mo+xmPJ+%yuR^}8Ju+KbAGf9ymu=6;^*3L zr&cV*jWKMs%apRWCAB#OiKT5m{Fb_d-}VBu(Z--9oD=Ka^L(Z=E43}sEY5%S`IDZZ z)Q;5Kalzl7&kAU;H1_HiZ^VDpv?UMbuSw>Sw)xK5bP@&f`y`s49gjyVSAVfm~?@%gVK zKMh6htZXM{+Xmi~d~|FazdyNhcK)pvgcWexINMH<5I9r4Sff1gw%W0BBIUL3kY7J7 z@74U8Yqs$~5QDXKl#a-^bC}O^+(-OwJiDRxWi0Y@BCF#1qVm}j&u8v@%`M4Tzw$ma z`2nV*A`K?Ix_h6b?}MXvzPM8K<)v$d8WfNxc4eB32E5#Ev`t_4x_jbD&&w~J+3D{h51f2H`|@kgaQcVT XyJ9C_etY@tF8uT+>(wPX0GRwA8GtSk literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/logos/james-mpt-logo.gif b/maven-skin/src/main/resources/images/logos/james-mpt-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..9a75b4f3cbac3bc0520312a1bc73e3118c8dbb13 GIT binary patch literal 5179 zcmb8u_dnH(;|K7wr*piI5t-*GI)sRDclyhuKv}`WN%seu(cN{KtsEkA> zWRD}d(L5wu9i?G(`u6z~zR$<&x7XwG`t4<5X>LGaY=GQBivrLeU@#a0fxuueI2?{Z zAdpBT3WY+W(HIN{i^bw_I6NLNDk=&90D(Xd6B82`7nhWjl#-H?*`p*aEiEG>BP%N_ zFE6hxc8y3Rl1L;aB_(BL_6^COonQ?J(Da^$9`1r)c#N_1Ul$4aTw6yf}^sKC`hsp7`Zr#ex&MwH#$<58p z%gZY)EG#N2DlRTAEiEl8E32xis;R1~uCBgw=T1#cO>J#0o6WAPt1D}~^Rck7zP`S< zs=BeU@m}NIKknVT$Ki0Ao15?7zu(b(f3n@ArKP2|B2E zkjs6-<#M~byL)?kpFMll*Vi{NFfcecI662mG&D3kJUlWoGB!3gK0eOl@g^oFCMPGS zrlwxJcrpFr`S!@j%a<>wr>AFTW?sL3{pQV|y!rm-&bxQ--oJm(=kw?0=3Xu={d&Wn zpP&Eu@#Dh6!s6neEG{iAEiW&xtgNiAuCA@EefsoCxU%^9^JjrT@O$ms#vfnSzkK=f z_3PJf-@XZd41WLq{rBd^@6BI7e*6&rTwedRvbD9fy}iA){cBCQ`+H0Hd;7=E&d#Rr z%kJ*3a96nbTlnkOFQIT_>rW@#-v0etC=~wwefW1cVZTX3=sqPWjU~l(?Gf0H>lS3D|d{nATMJELB>^|II*CRez>r6Jr(8Ts@dg zwu{!CVoMp_Qu7!pww&~A)ek)ECFXp;cD#%#>D^s-&5>6{%dVNSJnp07a-!-)31;Fo z_k!Uy@8@>IYA^25d%}D2j`$R*+w|0*FUn~c+hdr@(^BIdeBBXho6<8hWlNAZNPK#~ zsFlOW7*Fm}eU8u)dz7@#s%43d%ha_H1lWCxX-739vC#2}I zgPHKO;vu^cQSDo%l-_p%`JX?If2k33>kau={Nwq1`wmsT830I9gxpJaivwT#v zNa+JB$(?Tp%oXbma$b2O{PT$Tl_N_Gi?_PZ72$ycS1w4hls&Q1UF+U_?=CMwN|fS% zzP1|f_O@o&zc(G95u&u_QTY0%n!U^zNm5#Zk%UYznfEtOT%Mu(d>;h#E^b>u;g^-Jz{SpP zGD@gDjLE(dxWbamIqUe#N+_k&2 z`1R@~zouW&Y4^GuBRlSq#(i~0VmdM!d}LLJ)SYiUTx({VKFm4T-)|9L^t33ku(n_G zwE<+aPG%^{l4Jhitd(LS%{@50USiZngXqSX8?a~_43wS{NxOw|NIaQ0dz zB35lrQCdK*=FZxKm&dk^`)TedzL$r4^5;jl&s(*iZ+>Z-lbBx>h|-rT{_W7H#i%=t zj^N{th|iLaE?2sJJwsvfY*ugU02lGKufS@4e*Ylr6 zLV)ADOHNKHG9WT*p8*Lha=csio?4Q&w&jO|y`UJKLgLXq)*ndmC=g+Yah&-;oAd@` ziqXFfb=|+8&`d_|n7(BBH&g=HnFO*7L+|}wTl_6S317_8z?#hr6@;2A=6l^`KV7$@ zwYl)v4_j>_;nE;lqG2VmLy}rWx(UP(#=x2SnBH8pErMW>1Tv$;@}z9xDz|*~jto8p zysWCVZuscg$|J?ywF(IGG%!NO|03)tZ&=en@&br2B?v`IdL}`9)IG(ZG{`}h!G0$H zFew5BS{w_?x^`iIvXA&1P&V4y7IrN^Ll}uR^0$S1uMZp9ZBA8;DK&~r&;yZ07)?+R zHufm8WQth?+H2mCFN-W@s@*0Alulo6hl^)QZK#|Yid@Ul69VJo8J*} zPLahPXeJ!?3um2$W&$<_%l?jg`TP4g@Rl+z1ayZ?llIhycu7=CV4NW4ZiDt+{t`-` z+2BP4fK9QHRC@kXsm9dUG*8C;uKS?ZvRYAbs56;V)(_FDebHtLsLmd``6kkvZwQEB(j#b&I?dm z+D%dEGCf?N)->aGI=$&2P9E&a1k}(^7_pDUM1iu zk_9sD6T6n>WtW|MJqb{N8eEC3K(P*=!Cnty`qZR@PP$)6;|HZ+c3BE1*omDjf2KcqDYrN6DaS(>XMyMGSx zFe)oI1(r}Mtfrfvs}6;L!fa^rCy;Puov=FPM3lVgVj{WYwvz5oE^?E{nk`LN*2z2I zxkEId>2?DjwsQ($Bq&#)@y>>i5hehm(n?^LjKs+wX2t>tHseB7NSc#pu zLVvMvXHe6h;YOn}lerOvug6r97QpwD&zNex+XfxDy-dVvUqdzTJN%hx3IVzKqR5pR z>uKIQq{0txAe>P~I=O}PHndMitRp?hDDJhoW#w#q6ZY&TiQ7%Pu#q#+5NDh%fQgkHI^i*kc7}o2T!Pby8RC0D9*pYBIv1}bVRf9QuSG)c=kb>= z+a>6>*kVn-JIY9&eythI!244nBIZvj$-E5_^;ae`EVAKq5-FYW0Q~WyhyD{{tXKS$ zi90R%sPw#GJx&e+I>Bxa2)qDzC2K;AUZQYwR!i{)N<1YVRK?%;`qpzUVH`*Vv`ILv z-d5DB&_o5Jgm^{!nIYCc=H!f1ac!+sp01#py7Cvxr-8gtVUw_*1-Ky5u}G7zih+wesMCGCc`$FBYWW0hzE9%3a4hD?eYXT`2s zKp%3|qWGaMOyIdzlr9yw&cn@9@#}PaM|pI;1+eUc(hY@ubp)b8py5`6-VYxf7+(1m zHIhWw>l6x~z>QhBp|YaMdcYi=sR&4;2$(V?8my$?)D|6|$AnG9_Hgh)H2fi~n3aLnL%3>bDRiCY(1v`L+;nV&Zi#u23hLbWlU2$R~Y!|Z6KAb3Cs;KQLzR}oGQ_+w@#Q7_ps<`E zu!-9+gSuAW zdM7|_;p`tG2m1l7E1@f`(KJC4VisPMjg|C^w6p};IpAU_tStNX(sWjC7|_FtrGpgK zIJgf){4xvQpB4LqeQU@!*TkYA$`TML`_idrO7inA*1?N$Iik=*&VYSQao>M{+yJvY46x%+ z%Ct)24FW`Fu~u9PnOM>~RU*=qGccRZqT-i0aSL?(r=W`UavV1-cYqCS)B%m`1ZY-% ze*t0js{5yz;L{vRHnF^g2Gr5vFb+kHgWCO`A-Pd9djQfC^Jf8n-M2!zzG5{bGkv+@ z8LE;kMO1e#*jfhm6EMpmOn3#XsOLh^%|e-PcvnN*Qw}Dk9NvHiN%P<}Jc3jxprDF> zYvV39LJI&O%dKa&8R zfEGcKH&c9CKZx`Kxc8hAvTYr_DW{PgyX058#>YcutE%c_oNiX9Z2kR?md$D}CX$e6 z_r&XSC>}xoCK!|-1~Bs$c!kbS-K_#Lp6VyA-NI$UMxU z*l`KgxzZO*c#VhSoeXbw{V9MleFEw9u22`QJmtF!r zfE!G^MqH~U#YHS_=l;N8f+A0+)44tGHU8?rUH(ja=2m;@#isu6Vj;uzh>fcnd`lMR zF-|)wUkA8>1|dKlO~Upz?;_wmTC}RR_%EH(+eecM7CV$f!!Wb;b^c{D`R9K>7j;V0I^c|(U*H*UwMxtCamtQfqdz;kDUa1< z?{y_T76|@fFIwha6>-uRansG)xB;)^OImNIUm5@v+leHvHXco_I<`{}Yr<-&LIU`x z7A=vM7_>R^-sq!S!u+nM;qIa?Kq9N5n-ECbpM!8 z_BP164$@Eqy9CJPN32S@DSKe$rV*w(l^L8q3X?$`#wMWmNNcs77R{d}OH7RelN>s(u5Y=K)USu#D}H!o(mlt9Z={ zSlEE}x{mZl!upCwh8~ZMycrqW9pTB1J~tYjavl9Ia&-F5$Vq45U#lL(hEtK)Sgg|6 zyzAIPtZVuy{a{FbYr0UC&6#}^% i%IBY3&q+piJlB$+Jp9+B?)gc*s7Zs8$t(f@I{JSbZ#`)M literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/logos/james-project-logo.gif b/maven-skin/src/main/resources/images/logos/james-project-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..715a9bf970849d7564a7c4ac46f6512d6e2d8bbd GIT binary patch literal 7227 zcmWldc{J3E1I54Fm>G;2``E_V*OmMZ?MPVgzsp_gB9UnA&z+p~Kl7iG{Gvt6|9<|nAzEG<(XiQWWs^wr6n*(Q-*!i| z_G`0D^y1>@-9|4#oMYiaRv-}au`y08B()Kyp4*xC8-2s`2H_xA1d z%KE=QfBtN2YAn4}+}_sqYIg3$Kz}FiF#rJnWooP;{}})<{=fXc6CftyRWh87l`r(w zMD~Z;RPr05UH|gA`MNoF@N41|0XKfHN!g3Jw#4DE2Y(COH>^tK#IN*JkF3h2SQ2rv zc0@^{Y|<`boQ^D!75}g_r@+tkGkP>>q#n%k1PGist$Taf^BBjU9QcAKrm5JY_e6* zWt$~qMB73=d9y(4teu1V(SEZDLoucB3<`znn5W#R%qd}mwT7ZRyvAKs*XY4?`RIV! zEshOt@L7G;hSQsw0E%E7SfyX+=ia}ct&14B-Zhr1NoTjvugYlBUJfB=9YXgkIW=|LrTpezp=(vH=JcTaOl zs|`omJF`JKV2C2Ek}e5pTizI0-s<5n%F9vqy`^9fav~`c_nVi>%tx?$860YPS0)~( z5IrYEtJiGn?3Ue~*j?av*Db;D?+*aNoWnL9WO7+AR(25|rYXLttiFYjo@R9Wxng$@ zXeo9w;7~c9qI!&iF#y9PNm&=|e@|MExLc`mL;zyF%;@%crex-PoWkP+665`WU1?Vy zae09XJFDNF-ypxFN{OcfAdaxi%`!aqddykvTQu#^N!^DSAcibSKQ4x1r*)<5=4O1j zd`XULha;`W^T4gkls>%G>q{&x|4j#g(7l#xA3ez>Z*0Z1E~e>7`$W!vQZedlrAqE{ z<#d5tRC%_z>4eK(R%+IC&$N99EbAq-Y2H-q&_-QJ{khDmz3!kY2f}G2W$WX%P8$r0 zcV^$|LaR&CU!9G7erigJgbd_I95&Ql;0A5nvWwlEpA&+ijtag=7z@FEoJZu3G?bZ# zLOJ%b@5xRK<;!@drqi;^myQ#}ZK6)>)_kljMuR~%MQb9ba&aieAwXP`%`l3d_HqoW zqj0)%rDv;ea21{XxX+*y6Dq0576$DWrrD7X6rZJVyC8*)sQ_rd&%_AHfYT-%IMp2E z0b2x9bU|@vO7}wrd!9X3Eg>-j$F^CgFSP~xMY8Ds8D?tGXt z3Y>{NwvP}Q%6Fls@($s+%-uv8(0D9V<>feLI|Be8X)ugTahiQ9Jji2`ZHF>xBbFoD z_VacCu4d~~^)ps~(yzQSwhh4l$mORZ;vU<74MW!i{~(INjMBThuZ<}f1rJI-x8NQL z^`SFN_SZv=Rf5PAZBC$=;-C2nyH4Vu?JJk=DlvjW9=5kUBowNHzX|9cGM&?HNA@N6 z$Uot~gp~Wpk(b^`C9SyIH9y)|b5ks|G(-RPLli57>7vo;4)OeVfycW=FO-Pdt;DIsVl)x?PzA|wZ|3ZsA7RE?bE}>9a zW?dQ8&mIFqI4IYy7+;fSjtU0!)_%{t<{*$-lE8ecrc^|xCWnEE$lj~(CJwP-RSXqy z`vT%a7*Gx6x%ExELA)ygm>!mZEUtU^%<0@D9VG`Wf+h3WucXgv6Ew5+dl!5)0QJ|R zrGlNjX)uvs$Kdk{wgPApo`=xJHBiz#Td7C_thRk5=lmC2#Enwjt@?@5RPy#=AfY#Y zc>if;)C;~g)pC4C&k1~Ex7JfLr$ggQ1zW5^ygvup--l0g?<( zn&W!_y*Zloj(xNL`*c3bQggPX9&aIE)@D`I@-`-Re`t`g)cku@2hVdwke*cwop zhYT{DfeV`j|EOW#q_@2WOKfP`2yxz7PeC?!FrRsaf-Quep2=U{M*SLg#VRqvp=e6; zs^|b3qak@6oY}0Ww$$)kQwUrDX}wtC9IVc6|y8S0$}`l1x-4UDYY>aA;rzr3W=mPig-_BZWJ{kTCKZ7H~!J-N+@Rg zhD_Vbs}pHt8yXCHTUKtSn3Pt$?(<)vmOhna!du9x56|bo7C%_fT-K{GnZ;-m0qEG{ zpH_?9EqAd7Nc~2cveOEgTVK~IL%bnOG%Fo;?aI7F$g!uvWGx~~i!9x6YvRz8e&{c= zS0V4OnEZ0GE*sirjt0jHTFw5b@KB_8v3Kem(f&Dduv`$JWTND3S7PiZ`s6Zge*nG1b6@#l*QwK@6(c@Z-n!oA*_;2w;{zlUxF^1k*{f~X~9(FkACLqYjYf>8* zAj3aAr8VUB&s(oh+2>zjN4)Jreu~|uv13T|)wuq+p}5OTyYpBf?{7>nD^1!~^D)9} z-jw;CGNp4b?bDAOQ;s4?#)!I=KHfqhK*fcsZpU5mN!n!<+}1+Ms7{$`ZTk66oMVBL zk-El}gri-dPm+;vE8EFftFG(G{7~I&#VIGkw-<4z7YXTdejJ0KLte|@&~1V&S$+KX z0ky*chUS%Q4{IdT;IQ6f-r=$brLVHq`C&FWH|4#l`o2(Pqv1O-?PA_kt?R1Yhg-tk zya)L7f^_+5=~ZXpZ<(6mGZ#{$vDVxZvX}>}*NkixGQE$%mi$!ob}FpJP_pfhEAhU) zTJp!ZnG%970CW&SUkS zuAC$nYE)kkawf=0gw95=#Q4EO$w`NZtpv$JE@aAw6FY$vd#N5a1dm#gD8~nC;YF*1 z2D2uc`HY@)^V}|%gk_7J3Xt+ANRgl*OTauBkxiv)k1|0k9-0M;YcAPO>7+L~X!r)Y zg)Jk@Sj5xf%=cN(_Bf~eP6*1HxsM)>(~ojyXB;m)Geu6HS z)cp$~eSS0xIBvm%cLY-X8v-I6u)ob&>LWZ86(N4_5KshJQZO%h@;f>K z-6c@&K!B??Bae+sW8l7VTnz-E!6nG!fVSZnawr(N-ph0#hhMNlcChn0ypa{LDA8Uv z^X`?TzDk2_P7ShWOKw3;S9j0k1Keuf3m;@J8Aq1*% zAr%5(8kjg318oy#<&VSL2nBu$f!lbn#RsT;Go(iV{Z?QlD)jsv(9Koz2j%?Sp|&ph zsS!|}&hBQw9EwH{&%BAD_R1Q1*UoMl-_C81jdMESC=5N-huofn&%`Iccoo-8O!{^A zqHzc7;_SHtg!2oq^ms5$n+oaC(Ni(F4`!eQ2PV+BZsJ3c-LMuP1ce763gltA+k&mA zCxm3ip&PwUDgX!z04*UzpuqP1peY41rh`%fU&uf~lu5_z;sav+4gttz6^dk%A3m}O zR3`w+WLpbIfI!VIsW041$b;tc?1Z6|!+v5!RHi|G`0Ba2%oMg#=|uy;k)2@?hcZhD zi7GMOBnWp(6Oa2Y^^5;sWHN>W?jQh1*8mqQV4-Bc4Fy63;buZm3jiGqAaPp4j1?eo zhRO|K3$KJtR486EgGfpJCNNVW8`Ss1+nKPYAROkh7496=lm^V0fbDmGgkSn+1q$`o zawC`6Q&y1Z7ccq6|CiSLnv{)5!p-A2X~;N3h1ADE$$+FDOA;c?%q6KIrtuqLeCi zLU~gXo&6Pni}m1=z6)A{WE(yZ%qkS?fb6`;4!Hr2%*Y|{ytaj;4;Cl|%kZX!i)-Sj zmEI^mkvo)@oHqt`goxLd;G~(+o0;ly{?a4>))rO)21rCMU?#*U7MrmtRUzxpGfTBv?0JVJ%BXt3K@|q1Py`wY*lO)cB6(VZk|8oMaI21| z@=>T(JD&`3aovFAk%+r9ieL}#f|9^Woea%b6>Z`GsYdOhm2eyK*?a*|X8>EV&334C zWCJC82zlGtp3>HpH*yjES7#6KJAO6Q*m3faZK$vF@GqrHVh@gmby>GB)Yb_JMg;7X ztxlpJTOpyy?=Gm`v?D8`TK+zU>WwD-fQsv3|KHe7LMqf`C?Pqsz#q21}TMtt~7;I`UrO)h(oy{;v01yG;p}LT4>2K@TNxtoVX_P5wDtliP8B z7d`yvHq_eZj@5y-r99O4m3;4kr-o1OvH1Y)8a9guNK?vHB?@A$vPTR%Ih}x9NN1vR zZ)Q!W#zUJ^)8Ot2aKMN6q!_n_&@NJ;Xyo%7Dw%S^-8$--=V9vYW&_A>_E1`Wck$`I zo%wy=W1qTGp6)kde*28%Ha|T`zoTfJPi)U*OOIfI!6;9XEjD; z57m@TAbd$$cjXkqD@RBr2n$qWlQU zlltV^qv7mOt+StBbgWmdjRJDHfH74k>Z?@D`Fco*H7ei!aVwJYR-%dU+FGSuf_IGi zZ*uQdNbL5pUljbdQuPb}!V+9aTTm65=qeM4a3$Acq7jdAQ&)R&W<-?0V7 zmPZyOKE6SVk_Y*xbFsz8P*;v2b;>A(yKi?fp45MaPkllz8;sr#=}(fu)<2qvWrCx$ z@fjz8K}n=1YTjN5YY_m{amZV4fnrgFz^Ut*(D%$ zjhU$2b2+s8Sj0>FvX|Kp-^Dxh?_*YEB|JGzjP_=~^E^AzWhCBk=HurKXzQM7HoaB6 zX!d3j+RqsFi|DjtL)(1uJ7)lC`c;^U&K3+H0^eCg@`P@}>nrL;XJ@Dl3hDr;A0j1N zPS>%{&NqoIcZDyO!JA&e}7KGHRj_}Njp+- z(xT*bLLBdb@1*=HuU#|&8F5VWE9N2%=EA4s)F$L~3vZ|cs8??h`LK81`zCgOe(c0; z>kLL|JfE)#n>|%N6Z+^<_p!MP=ew8p=@`*I#r<*2<9>S05dTM5^^a=05-+)~A8MIZ z=?D{?={(@s;EUoaDNMa@@tXH`d%v6g)w>=L!b^DXYMYAajP~E4jYYJpO=*00A;VT%}3 z)R^1X*rNO6nNDSOFPBd*(>VD@cfQwrt{2p@;<}W-QF(n23`B{; z_fK74c=SNGlKnBw_${7ZuH67{63La>-s>{PSq)2w)u9*fS+|MCj zv6FkqNyopwUHA~Y5Zkt5IpNA&V%q-vyZ+KQE>PZoRZ&1lQu!9Uslp?2s?HlpDHpG# zNuF~b#1jA=27E#1ErtM4D8J(T-JG&br)|Slt5nsP=^I2$s-U*jYV}34@TcMIK6Z%< z<4xIO_x1BlJ2}IO_{F)uxSr=`l{s}U*LuF7Bz=rJJ~qIOofvo0)L-+fDTxS=|cpK?y4 z3ED{a(4w2X{Jp~?`QCSPLEg!jm;4Qh@GGS$2Xs@!clwY>TQXB}T`dDh1d`=WqRBxs zJy$8&7%y=%W8IS&330BNuDY+d<^Bwghb%UevYogSBctwYLoq35ZgzFFv~xD|Wgl|Y zJ+L#~)hi`5RCf!(SiviF^;%t1%j4SNIXYfLQ7)Qs+IOU{wZXt-)!D)fJuCzYn$V_3v`rj2ac zIgKf<>V%|ksBRBsT*v0hYdN$vENd2KN>gZCf~mKZ^gK1aw%Ce(Zc;6d_){^|y%122 zS3555F~8aAw3715C{tP%klbaNTz&V!_ZMzBkiO&|KD@R*PJTnWkJ}pTKVP9v;R<~7e)0=~ynjExoujyqIseY+A zF?MIIb|9aLw%o+!vE)n+M=-$@I#2`WG3fg@wnWl)V0ICrUnq{22w=LnF)PDTcFEXH z!KS?md>b;!10|-Hjj_^VujwpQiIA7p7@B^<^<4Dc#Vpl}ZJ(H?jn|>n==fkMsT=Q? z>NDZ{2QKCk{H-)#$WzEF%>cYmlZ^c4mNvcC>rQq@KrlQe?ANx{&>Mfs`O*Nd9U}0qQhZtPF~p-8<}ppS+{KR$;-AT z2?51%zNNEOev8&Y)oHQcgR9)7)`B=`y|1xRf6iV#Rb1tGb*?1p`Q*vs;)%6|yeC7< zn~=D}yFwQq?`k%mOrtJ#%(qM}K3IBwSf*=URnwg*s;c(TFD_^PCdL zmcsF!wO0Y1OqlZG=#Sy8-==@Ou*Dx+9&s^!yFBK;|5$W)BisJxD?hzQ#|zVGVJ#2H41jm5+f7=(PS-jwIkwq*^Kiu^rUy*Bsxv3a{f$Dl6^c0b}#ADTXxRawATq6 zNj5|XOcb$+?(9Xl*Mn-o=`CmBZ|a$N&@LoyM7@)~_gzXIk;vKi)DG=mfx-GFa2%ONrx-#U&LD z>UCL7UdEv%_Y4x%+ZJuZgzODRVPZ+YM=JX1mwh@H(%U}jl#|7GS9aKfNlQ+ Deg8ll literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/images/logos/james-server-logo.gif b/maven-skin/src/main/resources/images/logos/james-server-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..f69394f6bbee48b5b336395a573aa484fe1e05dc GIT binary patch literal 6944 zcmWkxc|6mPAO3tk+w8E-%ze)>cNs;Y_%OH9=^LqY!p6C5~|M5J|u1;GmLv_J0U;+RJRY#^L#+n)$-(9#+ zy+3^Y&w6}p-1uGlNG0VswXXG*g(dO&`uZY+!B`s}&P~lsA(7YD*FJoB|F25w^6WKb zd99Ji1M9yA*2H4*>UwK-`ufKY$$R6)OMgGF{}C@Oj%r!KTWpd%yu_b>F5GSvul+J5 z$1bgZUlp%brx6yve_35y`8z8-Zejk+!>YIX>X*MCYpScS+S~8<3O^L~&+P1r)wRDr zmzS?JTswcZq@(55)cg67fyaFQLjVB&)6`r={zm}7`2X<#On`)#ewY`pk%{&wQXk&ai<(K@^JgErzM-gvFd(D2gsijs=b ziMEO;C26XnVoXu-*%Ie`l$z;QS$$kQDm^wWBN5NZqe>T^t8ZvLgwn$q7@*N7GLmgk zu~(Y)JCx4or#3z6f9w~Zg}&Wpt}hwSxqn5!CQqriZ{XjTublPuskUt!+R#L*o}z_P z;&|qLNlE?h!j;v>v^N^EZLP$E7yv=fB#PjHYWmSGDbF=6w+h)%@Qfr7;U7IGq-VzC zw?v8dHt~{0bazl|Q_ts(QPtv-d=>$nLa{GH)O|YjbxCX=|IOqT1b3uF_vyGWVtPcsvaZ(clg4kUw_ryM zS{`6SG-Dx~#(|H$N`FO)PXh^x6j*8t_ncT!lPy9a@Hn0zDDl%yRJWu;m_((a?4$BC z1X~)1j?ml&r-9qw#tcX;JuAvJw1^Wzi9k759T;KLfMg|E$`kBQxuViDel4LrICBB3 zxKTBES!@g>{UR3El;n!=GEJRfR(aM+8jZhk6AmS^| zx9&s}NrH-FZXS~rk~(3&Fm`BOzM>}SxS=x^RD=-(&COhG!lt(zITQ6lE(9kj|rZKWx!)+CkEM9DSotW zAL%$wc2hPg;;VehRV}d{QR4PZV}fcllaH5roMV6GSzil)z18Mxbf?t+_G3e*wSP<*?VC1r68u=L)VR173Y%55{^Mit~opR}< zqn*Rw8IV0rP|d2ZzgDXrNjb>r$8NtC87F%}{tu(sa+s1jZu)eaAwfW_ooM}QxQE@a zlgNb~$z;1XqhVgA{i@m`!AA6^$eoLIvauuwXABhh0DW}}5E%>f?L&Z+Ckvxz2J-KOohq*THAPi3)8RUok zqZ35y58bbFwEeY1`Xz#-M9>qEAm>d#ec?(AYYfWBHnm zy~Zk)<5B?2Y&Ou=uBrYEMr}5no%Zu7)nK`$s8YOthXYN|M_FiDk!tbsByc1~oUTr* zNYl&?wc20Dg={!l(g}iIz4y#q2Hhr&_~^F#+etCCORUU{Whv-zL_h^_iiFL8TU zxG3-nQDosv^?`SLH3NaZFk$0yV%sZXbZ; z(*HJtq28i2bxL%2)Y;%AWf&kN*B@wIJHOs(vGKLb5XHH|LB@!i4s2cIv?r%hGJ9Rr zgg|Y#}$n)kX?dhIZVTN=oTa2CJt21Lp!wbFCB|ciprB-HZ zwi^B!3~XhE;nhVfRR?l0{|}XVexPiXMvV$~$rMB7wZw$z;Y1n}VVV8n-I4Z3=X2l! zxyZfiHTKspeyNJKPC*eaPXoG3%sO|!3~Sj`XZ3mDYGBwDBKz*MI;UfK+bF&#9D1r8maluh^IZ(XHL_sf(BxSx1z@J1reMKfis;a9&Ejp;TBG z3lLC_-0tC!|M6|kpC8$|f%gV{@;r-96DmRpRiDiQQIH`d`_r!rt=gr4g?~2o)Q6V; z8SML5P=czAD~*&fGK7MT)&zbEJR8JglS%vKz6r%8Iy#gf4el*Tkb48EOMV3m-@!k+ zMxOO{uvkJ$FvQ}U7Vo4oL3B_mH6jk`u*?kTe z?vCGXD&Z>Pf$6l@dQa}2@6NB2QD1Y=t(!qdI)xHnsvfW&zkC0LN2(@9`mLM@s4+k2 zsu4+H8|1a!8a^lySXWXH<}{8 zz?t(y%J{`g`r!BBU6_saWwcKLl5>+DJL06{Mk3}OOp)b^GPSm_03-|}HCEh}&JF+f zjy`#x_f4|*l6+K!!okrW#d>|pFalUd_f1O=Y3U|Mu-|_>ex?7ja zq7DQ;f>EF4z9wt_@zN7LpLSf?LPlQxl-lu2V$C;!{GO!aD8YS>ImkXqnA2oTQvk$E zMy<;E2lv-^UxyOxzEt@1#Iym~~groMgMq*${F1wcp$Y2azZMePl?F*vUlcr!Oc9fe1PmrBY5mk@+FZ zEh4V?y}E9Pn~G2916IDpRkd^@Ch#KFgBx~@kFp;v4g-pNcbEU1$>&7twM{IfsN25- zgLUVs&SMJ;&B;1V>3aiTVw#pgX^YdV+M-laO&%W|0Dzc-T!hh&r*xth%PrPZhNiKh zBo-J@5K<&c(sW;xltU&5V!0mo;LTyXvcn=zePl4_KMah$BopT*1|P6LWbj1|o4S@r z3aQIwywtDzU!vzU9+Ep_-)bcD2T%C3{_VBH%P#4;Z4rW{zW+R(aA(LP-qs+@6t+ih z^4N;DGSxo1k(VI;E<(30#I}>lE}8}6^ccpe0zLTz3nCPT%W&RJLj0CE&i&wE zDnOWRP1`(;2>F08l|SB%+DB)k*)!rr{Ydu@DUPB9Q@=Fxgfz>Q6l*`EO&zjRB=<%u zNdw-T!IbKahN!>LimVt=5M?5Ql&L$+OPqq1fC+~kDt)`ZS~y!$O!mKnDgyUZ}FJ!_**y8jd8NhC)h)`Fev@x*LGyQyo)>2e*s;%q+ht`7rg9(YKRMo zCjmMzM269wKIqqE5XVJGQJ@WsqC>rit#W|dHI}w8FT@*hyb>~j0a>iqb_SqA@*>h8 z6Izk{Dx}Sa6XTp8Hv(ypJu(e$U_^M8A~Li+gX4z7Xea= zCMO{T542`^TG1dRBg#w!s&GLwZHOQ|e)L3{3Jl53KrTv9>lCEJ0mEC^ik#D5xI3hI zU_Ml)!$&|AXu<**if0tbrGgX$hGDW@P)x}JOlUf^*GGRJS8UV^@~4#Uh|Z~MN7f!d zqL>#$bIy4(IKBHzCrS~QIfOzuTbUU}5d!Z_^|Xb+(d!_Mhj9A`k%9%yVCX4S&U+1* zF_K6?S;}=#V3}v;dfBv8DT9={oh@%gg3N@#cnl=Xhf=U*p$=+4qybG9Km>~V$Y&9Z zs3zBZU0qb+FNcfSNMnqn_>Muvihhuc_3RKY4o)(zEu{@kwH=Nu@JPW|Z` ziKs({sJw6tik76K9H*x#c_0VS;wefC^j=3JsI<$Pzd(I1q#j*Og5?SX?3wv9nX3@v zf`ToNZO8>CWSODC)KdRruYCEIA#hH6*+Qpb07_d-X6MQ z4+HNE5I2|&I~Fm|7miyo;cgbB>9>7S7qLviEaXDtN*7eP0KM&uwy2uK<4jdH%=$NN zosnINhWNY!Uy^k<>OgQAPe!?RC#TR$$r{(eOMhR<)klr<2`#^>l?C-bnj2Lp;H3+o zktn~+EZbx5xCv#WEff557bUq>&l2ri@pfd5|zu%0C{)I zC&Qy0!mbg4t4JPbBp|6Iq#ief8PO?cT#&aU(g;b-JAw4b!-}`!kb$2NVwnh3zm?~A zPmP4ZdP^*JT$*}f(eOjImqQ!)b`=U}hPLDaW*p4q!Bq8VZbPnae6+4wG&CUr5^0S# zo|IG9!GaP*vGrZ$=(}Yqe(9`+wZmn7qk)b38j@}()xlQp0iJxv%}#8Eq;-8)?!99H z^$sZ90V*=;MRNvxar-@tq3BSGGWV(0<%YqQjYF4M9i-7^$n_?|Vn)ucC7+80-EYcB zj@K?_<~QeJU-+pzWd_OH-Flk?r~<934ysi*QJ9M->72r+zNkYtk*f#KrCFT(^eHm< z=Dn*JO%}g-#EM2t1$P8QZJ?1f7-vivMDvw~;KUdAAR;5NN8fc6(F&^l2~#|xXB9`0G_*(nHd zV%>BR^>5jRdUWj}p5I))kAUYxwr&7E74kQ2eYaTMWU%#&AtF$@Wa}z|{0CynU`9D% z6Z9&J>!fGCNl3=Eu~LkgktY2QM%|9Mxfm3ad6(WEO1iLLt%HXOpRCN1=-nlHATkPS z4fk02jaZ!?X0V219N{y=4<&S{cwvKh5YQ7*l;HDyW3?uvj7!GI8P4%d7w<%lV#e>7 zng|EeaqUqb266D_=|wsIHVm&Ht(yf>d0_nP(5c+Io1zj1=YfAmME6AE!H8jJPLF48 zp^G3A|F&iR!lH0!A?OCa3z-FzO;Y+VgtI=x2d5&`cLT^Oz3FO&LD(#Yj0HTW}^woeLb% zgM82Avf7&)*0A~w@rgbM;i#~8=C8hKNcGmPN_LGTWW}aBhJuU0jjgDGT{6@ zZ{c)F5AvEynVOXqo8SyV6_*XWL9{40>VoD;Ez7#=}pJP?K>+N)SI z%BOr6cU~^(^m-pW=D8cvJAyG-S1^7l7rv2-V=lys(8YhcG(;Flf#f!}^G~~N-z!u5 zeSq^t4dTYmk2{zE`U%p(`QatMnv#_Ho4>t+XR_rJXUFnKpQXH0HTr~Nj=yLC%8%@$ zruc?Oy?2(kI7FP?{hBlcUp{TQQH^%{-Q6y#Bfe~mWE+f^bNnA_zfjtCgdo&2_oYY&L$%SJ{!Xd2Jero?$zjZyNxkPXj`5urL7bl$tq zhuS-%r*2zMlV}%~xQN#tn@i2q|0R4)cwp)3qfeZ6!XKlmOT9LyM+zo%0`OnB*Iko9@$XyZ`=s_Y_A5M{a^y}f1fxHCbUep{ zVvq!G;eSla2SCAyI%N@O-nufD^r{@w3*H#;US=_-mOYTJ$j45ii0+q>_d`6wFN%Bw z+@}N->l^ZYT$}fU7*0rqKVcy(G73S1+PT>>AVR|Y{9|VS)-|lnDENm1#7#=omHWu>n zW;BK|i4+z|lw2y-3Lzomtr*`|zMsPRsxqVlY>wc}%oJrE7@DdUvWkjFv@G^GIRsc7 z2|=1WF+CIw-F@8*(If|7j?=`27W;(y8vC!s$6Av2wI8;ht(s5%Ja*TxV(?qp>ii@LwpigzE-dgfw_;neJY(XQzRBfmcQv7e_FKPAQWE0nt zhj?9Q^~koqVe{}A6lk}>#X(UXL>Xa`4m`z0JG3KGHIdI0i|o3xim4vbeu+9gYT)X$ zxxka&mk&rJ3ur5dkW!pff(yfw-hbwH(ELo`MWp+=`>xO1*hXcI!L7dE*Z+@h(ZmN4vY|J_Bzna@DkqjBlpQhQnl$6SfCZ zQQ9XA@15C%g*I&7R@F9#IX=Y#1=5@}!fcbzlT z@ibPZ7OGwIfsT&Q4h<&Og$@{$MSdU9zuuXqk3ZHNYK@}&28!ra@It0?!n9pRW9jFO zkE!?1=Vd9sY=4ufmf-ROQxP%~+hPn7yajgPJ6an3!JiDIEb(Vern4r2<$=}DcsAy4 zIW{^?qDhxCHLpQ9x74S(Dq!Ze#G}h)ZH(WFOGH*_RPi%Y?zvj9o@Mn zIOfX&H(h#(rt7%Nn90o8W}j2}I7Pf_-ty`+Nc0o3u^XqEr=>jn<}ze#is!O43ly1I zs3(;rHZ;TL^e6{KcAZLlI<-V+*&%gk%bPq@>A4p=<6$Lb(W}JryNr{v7p8LI@beAA z^Ma$DcTc)qN?WoFuc(F{axgmjxB!%eC>> tag in site.xml - Make sure that the <<\>> tag contains an absolute URL. Other will cause problems - when being inherited in a multi-module project due to bugs in probably doxia. + When inheriting the banner the <<\>> tag contains a strange url (e.g. '../../../james-imap-api'). This + looks like a container ULR but not like an valid image src. + How the workaround works: - <> + For the <<\>> tag (add it as usual) the site.vm replaces any src values by 'images/logos/asf-logo-reduced.gif'. + + For the <<\>> tag (add it as usual) the site.vml replaces any src values by ('images/logos/' + $banner.alt) + (set the images name as as value of the <<\>> tag). + + The logos for all the JAMES projects are included via this skin (see src/resources/images/logos). + + <> + + When a project logo changes then it must also be added/changed in this maven-skin. + + <> +----------------------------------------+ - James Project - http://james.apache.org/images/logos/james-project-logo.gif - http://james.apache.org/index.html + James IMAP + images/logos/james-imap-logo.gif + http://james.apache.org/imap/index.html + james-imap-logo.gif -+----------------------------------------+ - - <> -+----------------------------------------+ - - James Project - images/logos/james-project-logo.gif + + Apache Software Foundation + images/logos/asf-logo-reduced.gif http://james.apache.org/index.html +----------------------------------------+ - \ No newline at end of file diff --git a/maven-skin/src/site/site.xml b/maven-skin/src/site/site.xml index 87372b17f7c..24dfed3851a 100644 --- a/maven-skin/src/site/site.xml +++ b/maven-skin/src/site/site.xml @@ -28,13 +28,14 @@ James Maven Skin - http://james.apache.org/images/logos/james-project-logo.gif + images/logos/james-project-logo.gif http://james.apache.org/index.html + james-project-logo.gif The Apache Software Foundation - http://james.apache.org/images/logos/asf-logo-reduced.gif + images/logos/asf-logo-reduced.gif http://www.apache.org/index.html From ba8ec80984be2823daeff9b18a514ca3abdd293d Mon Sep 17 00:00:00 2001 From: felixk Date: Sun, 6 Mar 2011 15:28:32 +0000 Subject: [PATCH 266/541] Fix banner inheritence. See JAMES-1203 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1078489 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/site.xml | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/project/server/src/site/site.xml b/project/server/src/site/site.xml index 24fcc3a4109..7948adf094b 100644 --- a/project/server/src/site/site.xml +++ b/project/server/src/site/site.xml @@ -19,15 +19,22 @@ --> + + org.apache.james + maven-skin + 1.6-SNAPSHOT + + James Server - images/james-server-logo.gif - http://james.apache.org/server/ + images/logos/james-server-logo.gif + http://james.apache.org/server/index.html + james-server-logo.gif The Apache Software Foundation - images/asf-logo-reduced.gif + images/logos/asf-logo-reduced.gif http://www.apache.org/ From 83e9987df3d98ea9e223079b68e847590c6ec3c7 Mon Sep 17 00:00:00 2001 From: felixk Date: Tue, 8 Mar 2011 09:36:34 +0000 Subject: [PATCH 267/541] The default execution of site:attach-descriptor has been removed from the built-in lifecycle bindings for projects with packaging "pom". Users that actually use those projects to provide a common site descriptor for sub modules will need to explicitly define the following goal execution to restore the intended behavior (JAMES-1041). See https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-SiteandReporting git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1079308 13f79535-47bb-0310-9956-ffa450edef68 --- project/pom.xml | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/project/pom.xml b/project/pom.xml index e2b1a67bdfe..15795dedce5 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -94,6 +94,23 @@ http://mail-archives.apache.org/mod_mbox/james-site-dev/ + + + + + org.apache.maven.plugins + maven-site-plugin + + + attach-descriptor + + attach-descriptor + + + + + + @@ -106,6 +123,14 @@ ${basedir}/src/reporting-site + + + attach-descriptor + + attach-descriptor + + + From 1c4f6e12eb0f74ea51adf9304699921b68890bc9 Mon Sep 17 00:00:00 2001 From: felixk Date: Wed, 9 Mar 2011 09:51:33 +0000 Subject: [PATCH 268/541] Fix usage of new maven-skin (JAMES-1203) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1079714 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 91e7cc564b5..3a80e916f19 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -25,16 +25,16 @@ 1.6-SNAPSHOT - James Project - http://james.apache.org/images/logos/james-project-logo.gif + images/logos/james-project-logo.gif http://james.apache.org/index.html + james-project-logo.gif The Apache Software Foundation - http://james.apache.org/images/logos/asf-logo-reduced.gif + images/logos/asf-logo-reduced.gif http://www.apache.org/index.html From 298d43b1ac9cf7b7c48bdd97c96b4df5c90fbafb Mon Sep 17 00:00:00 2001 From: felixk Date: Wed, 9 Mar 2011 09:52:04 +0000 Subject: [PATCH 269/541] For old sites use old skin (JAMES-1203) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1079715 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/2.2.0/src/site/site.xml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/project/server/2.2.0/src/site/site.xml b/project/server/2.2.0/src/site/site.xml index bfa026e2310..912c6753593 100644 --- a/project/server/2.2.0/src/site/site.xml +++ b/project/server/2.2.0/src/site/site.xml @@ -1,4 +1,9 @@ + + org.apache.james + maven-skin + 1.5 + James Server images/james-server-logo.gif From 984a7cce403f2decd9fa90745c5e8bc6910e1eec Mon Sep 17 00:00:00 2001 From: felixk Date: Wed, 9 Mar 2011 09:56:04 +0000 Subject: [PATCH 270/541] Move configuration for site/technical report generation and switch maven-site-plugin2/3 into james-project pom. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1079717 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 43 ------------------- project/pom.xml | 111 ++++++++++++++++++++++++++++++++++-------------- 2 files changed, 79 insertions(+), 75 deletions(-) diff --git a/pom.xml b/pom.xml index bc2303ec3d2..602d9baa024 100644 --- a/pom.xml +++ b/pom.xml @@ -62,18 +62,6 @@ http://hudson.zones.apache.org/hudson/view/James/ - - - - - org.apache.maven.plugins - maven-site-plugin - 2.0.1 - - - - - Apache License, Version 2.0 @@ -287,37 +275,6 @@ - - - - maven-3 - - - - ${basedir} - - - - 2.2 - - - - - - org.apache.maven.plugins - maven-site-plugin - 3.0-beta-3 - - - - - - org.apache.maven.plugins - maven-site-plugin - - - - diff --git a/project/pom.xml b/project/pom.xml index 15795dedce5..a3c87c96eb2 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -94,46 +94,93 @@ http://mail-archives.apache.org/mod_mbox/james-site-dev/ - + + + + + org.apache.maven.plugins + maven-site-plugin + ${maven-site-plugin.version} + + + org.apache.maven.plugins + maven-project-info-reports-plugin + 2.3.1 + + + - - org.apache.maven.plugins - maven-site-plugin - - - attach-descriptor - - attach-descriptor - - - - + + org.apache.maven.plugins + maven-site-plugin + + + + attach-descriptor + + attach-descriptor + + + ${basedir}/src/site + false + + + + + + + org.apache.maven.plugins + maven-project-info-reports-plugin + + + + index + mailing-list + project-team + license + + + + + + + + + + maven-3 + + + + ${basedir} + + + + 3.0-beta-3 + + + + site-reports - - - - org.apache.maven.plugins - maven-site-plugin - - ${basedir}/src/reporting-site - - - - attach-descriptor - - attach-descriptor - - - - - - + + + ${basedir}/src/reporting-site + true + + + + 2.2 + ${basedir}/src/site + false + From b842463b6a3ec3dab22492bf467462e300b0a10a Mon Sep 17 00:00:00 2001 From: felixk Date: Wed, 9 Mar 2011 10:46:28 +0000 Subject: [PATCH 271/541] Update configuration of project-info-reports. See https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html#Maven3.xandsiteplugin-VersionResolution for sample git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1079737 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 24 ++++++++++-------------- project/pom.xml | 16 ++++++---------- 2 files changed, 16 insertions(+), 24 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 329fbbbdd93..365e63ee0d7 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -53,20 +53,16 @@ org.apache.maven.plugins maven-project-info-reports-plugin 2.3.1 - - - - distribution-management - index - issue-tracking - license - mailing-list - project-team - scm - summary - - - + + distribution-management + index + issue-tracking + license + mailing-list + project-team + scm + summary + diff --git a/project/pom.xml b/project/pom.xml index a3c87c96eb2..a7373f04c94 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -132,16 +132,12 @@ org.apache.maven.plugins maven-project-info-reports-plugin - - - - index - mailing-list - project-team - license - - - + + index + mailing-list + project-team + license + From 04ca3687df8df6db71c7e13ac7dd97a3c2161a14 Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 14 Mar 2011 10:12:54 +0000 Subject: [PATCH 272/541] Add Remo Sberna's logo proposal git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1081300 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/resources/js/james/index.js | 8 +++++++- project/src/site/xdoc/index.xml | 9 +++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/project/src/site/resources/js/james/index.js b/project/src/site/resources/js/james/index.js index 1d420bc6f9e..4727e2048ff 100644 --- a/project/src/site/resources/js/james/index.js +++ b/project/src/site/resources/js/james/index.js @@ -31,7 +31,9 @@ function initIndexPage() { switchLogo('images/james-project-logo.gif'); }); /* - for (var i=0; i < 9; i++) { + // This should work, but it does not... + // So we explicitelly repeat ourself... + for (var i=0; i < 9; i++) { $('#james-logo-' + i + '-preview').click(function() { switchLogo('logo-call/james-logo-'+ i + '.png'); }); @@ -69,6 +71,10 @@ function initIndexPage() { switchLogo('logo-call/james-logo-8.png'); }); + $('#james-logo-9-preview').click(function() { + switchLogo('logo-call/james-logo-9.png'); + }); + if (window.location.hash == '#logo') { selectLogoTab(); } diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 7f5076a9392..bb8dd5fe8f2 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -301,6 +301,15 @@

    + +     + +
    From e967edf3dd7c98e26fc381fed482aafa1606c188 Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 14 Mar 2011 10:13:55 +0000 Subject: [PATCH 273/541] Add Remo Sberna's logo proposal git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1081301 13f79535-47bb-0310-9956-ffa450edef68 --- .../site/resources/logo-call/james-logo-9.png | Bin 0 -> 21761 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 project/src/site/resources/logo-call/james-logo-9.png diff --git a/project/src/site/resources/logo-call/james-logo-9.png b/project/src/site/resources/logo-call/james-logo-9.png new file mode 100644 index 0000000000000000000000000000000000000000..b67d4e7755a3fb019f8c2c9d48c2559a68f64907 GIT binary patch literal 21761 zcmV*iKuy1iP)E4%NgGiCiQ!R_+-`qrvGI< zvDdb-2^f{_;lO+!Lk>?RI>CqaNG;|k&Bp5eU0=>%i=tLv)H}rI#EK2^72=5=Q8l12 zg3)>jwe|1NQk8|)jS)}Ykr^>PF-?c3+S2fDowfD)RyTcs>xng>!S{%jHsMybbxQkierLIHD=#hl#>)H6|b5u7qQymEM)UEfhs;Wvq-OaaW zkHlUA`7eWrn8%D{#5UT@9JnJMcGm}(r6?OK3+E_mbe;9ncP1u`7I5QQ?$-r-g@j6YIHTw{X zJxhbSzfXhtS9BIYJ5ixRGn2Tdle^8J{8jug_P5=IW4aK4!@2aRB5(+?R)c`M2Js=;SwqM&S5Ozp)%w~Tg0|pe8Lhs- zG^M8z6cxW!j~U&lM%_5Fqss_;@-a1&RC^uuo&d{q2tFH9s3TyON;G3Mey@_kQd}t& zZ+JMFDK3T`E3PHw_GiPvoQQAj2ArV-AwL`I@t3J88UUNi2$ihjQNNGnhRN6e^8ubo z`_oWYOa4hmGtM%}@cU_TmFK3Pq^Iugd%LG#FM;d<5D_mh1ekfpOme?n%*iXt@Qq5P zepHCTmE~++9A@zT>BPJ(=m#GY8SOCCR-_qo+kS={scbf-Ns(gPYkw$WO$@|xy|%}g z7t^{!pjlm?F2D**5Y6zZ*ZdfF+ax@#;Abh0k&ZHupelY8FYgfWOlF8{icjb3a^Jxa zHVEiOT(3%c=3vRO)@xHVO>66N2*w~F8;Kf0smshG)dyb3m7x29w$x76LD7x0h!8Ue zkzuc*#zM=JETI+SG*m#(Wxw7U9Xw#P{K12nEqapP|_q*pU{jeMdoVHtx1MnvOhE zi+1-t-&3%cK)&MmPO)5+<>#akA@U{|guXL^g0eD9r<@i3deT~&DBPM&!?ZM-XcXpe z^>_|2$g^w@pGLgR2dG)E_;fy4Q}9PuU|3nSWaZ-VEW`|tKx=~pbOokWh-RnZH5Oop z$K$Q_5!4NU5}}w>zz2BsT};n7W3c)(s0(G4xxXuJfE2eBwHgc~b0`C>%{1GV+q7*U z>9*ph1*KfdGDeV=;)*XC#piv2t+f-}K}~gtY@ys3Ck0NaMkJdpj3d{H;x$Tf&1R|3 z7$!OXR?O&YTJDUI+<>i?T{e8RjJWa1=%_If--iovJRa=q4BS`@_x**~BZp#CZ9_{| zA>k+{E>3PX(SV1Ru_KXfbp-bxizhD!su}=rmT%zR+2`v|cH=GIqu|-y9oUPm*l)Px zO(^D~F#|a`V*}&=IvLLZ8|Q;%m{YUJ;bY7-Tg;ZBhC3p|^_bftrgK0n*1`r$*SMCs z5B@9@FQphxHo=w{ehp)hj*3k>tyEjtWEu{BwP|hilkPhBaHJuaN(y0ou3uZ4EwZ#3 zi+Z*h6DV?Qd;)&`4^3u~QKVG_b)%HJ`@8vSN-A4$JR7AkYcTnqrP}Oxpk{~+vNx(| z6Hq2)!9!$-uS`w51+iXYb3=xk-|`LyYuUg=2D|U58m*McI5Ol>TFhD++%) zA{(jlj2B;;jn}EejcumES*Nv4EkFZJPM8X_nHEnib-`AeQWU&hua2Q6nGN7=@{rr= zr@#!6ZXJHuGXGg;eC8im;F?|^)YQX%qYwmZT`A#M413gY0)Vq%3DL2mF;YS(0(H$$ zU57@axMfvTzxyG-c=S1*TCqYKcgOwTQ?Zvob|bPwGWNhhoHs1Uw4Wcz__9*M6S8S? z>!9RO(>oz7F|~ax6)QAOtyIO5k1(7A37Lw8i{-8%QayrHTM4jAVre4?1(blfOx?=S zk{46FEYT*<7#UzMWwSMrP@amVpK4>{1PU4=SgfTYI8w5*!Wg>Tt*sp@16np}v!oeO zBU94d1{dQ+-Qotw5+$Hp+2jt!Ck~cTNt4%+h~I-hT(1#(3tQ|KT4S5pW>it_YoIX& z2=#mw1cTHTA<*b0KOCgcNGHt*;WKKfHvJSua|js&NU^KfLJYq#m|V?7Nkb%*TWU_f z;#u#wY1{mvbhS!W5*fJ<{`3%bG>WxkB~AMb!OF_QShfZnA?6K$fYTbLwsISPf9-Al zb<3T){!6>@|3%nKAYU>bJ4cQmn8N;bl{mpP&YO^dQCmW&z#w&NHC6lAL>H_|u?}nu zIpEWe5o;{ITpwOhEd3NSyuXA3V7VU=are_ur3b$*rPUlJX*qsEo(0smj%RROST=6inNiEozjHCVz;(FkF3@vP)BNWbICM6WUD<`3u#Sf`C_3q`SW0DoWSYmgEV(i5-8&X}-%}V&J4Q znp%`?^&ZBJXvOq+ShWFSPLKh45puE(K-p4Rj3@Ih@{11pqHpIzC^rpnmjUV z2-6!Ykh(^UVJ$cd-ZHF%)D11zX2cGP7*WDrEFGv0>8f}|h#4LN;)sRfQxlE3WcXbC z0!?878l$4{y+6|X;l*J>eFmrtRU zhMF0mWt63uWN0oy$47xtN~1Xh(+Z&iY3@L(jH%?hSs0|@$cYRHzs`E^KIAYA%k|Kz zhZ1uZvfOAU(;7mCZQ*FJ)(1a5oK=Mzur6E5kcqWyuJh8=fdev(h# z(BCuppri46y}h5_Ui68t6oH6H9xw+O3*-VhbhU@Ot4o^XvHr-0fvs)Ze}LzAWh}xv`86Hm&#cC4}#gA9&y)GfZ z=eYPyo0uDxT!~>yi)-5TlBe}JMya-#A-pu9&T0&&9F-Q)pI$=IEywCJZ$8A)9of@H&n^?bsc?m3xr@UkL&c5fiutn9Ft!wB3r!fzL$bFjcMYZ($Mft~#C%MkoWl zOU$NVlQz@h5pUEhEF(V-U6q^huir2I;Dc3p) z5|FT}u7_AuT^bPGB&O90b`#?HlopRenby%5D`TC#jg7$;s5|2hn;}czMj$oUc zOA98=3^QAFcuLG!>J`uW7RyZWgk|_3jZV&W-Ecv*yF~JEHx-f_QB0aKGSkSYIEEn; zZUbQ0emn6i*oz*q+X+NO1o$^_!tU-%4;T&H0i4#KLVx|H9RAW6xn;y!9ZUlrEz7WN zH()HoV+xj$p8qVi;jn!r-n)h^T5k=x3O2 zB~VU-Y-O7|T2--{Rjg!bj^g-w>YHH246@2R6tq|jj`_*71cNk+2p~Q$6@ek-yCHBh zP(EUFUMl%c21N*s5~SQYm?BBR=N`qN$Qx|729j&%64VfRv07?8sni=|CDTd46^krg zrlqFKRyPGzXk`Yiu|;gQn#nW{0(%*oJ=LUo2CHFviRcu9tf$%BYHl@Ba+-u9M;M^$ z3$YC&T3)3re`q;x9q1#gG$IFjT8pZSqGoVu;#)+totXCPN!>Tpw8)BOrngC4x34<3r@ zEe6(kDL{!DK}I%*@T*ICsF(sx1sW;yrsFu-cr=X3a9WH4f|`MFG(%$_vc(LOMm`~Y z_{>^1I5TB1UTm49+0oZ2Glxn6h4{r!n!TB7W1Fs)Jp2d|Igqd}q0%sEpn!;N&}vMk z)n0>ph1JS z0XG8-E;lYqEf-gs28d0nQGvJ?LtKYUT$(j1g@XDuCSGZhTBD9^XRTYQ^$5#B%1~_r zqa4!=fVASWg}P`pjSUO+qt;EVF>Ru0Kw9^X3W2bPf^w7WCJ*_R#ZYfLEuKOO&2(JZ z#%50*ej^Q0gETXjMj1-T&Y&n(LWOr<21L`yV+&hkDt^tx5R0%eg$(y2Dy52;F-Ef8 zAcKuhbftR;CSGigqSaZX@kaBC~a<6xsHyUY5#aUb%2xi41&Y)B`Qg3OvLbP&gm|MP49ewIcyytt71a`Lu zQV109<~}5Y4V@jSg9Z)yR(^i|d6!;#>D_<$!ymR7hA~n^(rF_QPxXLI2S1J!ibGng z7T2^Gq^)F9tJ|c4Y^?_xRM~<@w_%t|Pz``C!;v6RN2}XRgKp4@wM+TfTTR(O;*RCc zP=mBei($1E16`MhC&U460Luv={wQ0G0c3bhn!QtSqiL9$%0PPqwKAM+O(WH=WvlP& zq>%-^=zFg2>$Fz!pc)qBw&>}~?t?hX1C#iKK3%<#YU)>~l_@tlAD z`L7QjKKwUh$BupH(n~Krthl(?^!xo2zV)qdrM&XWE6ouZ(i9~vBT9xHlN_%_ELP%L zgz!*8j5<~7L7G78z)VM-62xhyj!NpHVb(QQ@?p9|Ykt>mn3xQxH_0gXG6pYMZh+hv zRHbB*X9Tdl&`3U6k^Ef|Gry9Y_wDfPw7B`J=#H48=#B043P*xD%0g9~YueAYDj`RC6U@Iq;6Jju_# zz`WgXqxYhJ*xdxO28i<28hPoCO~9>R|N7Uj`@EG#S> zGGxfoty{OQ95G@3I&R+?oT zS%eTm6v-CKWCHnGhpWS-#mGQ)9}Q5#hFGCwcp&VQXq8z@dRmE?e!dk?Ijz znL*fHNUc#ptxWKQZ3)=qr{U(LmpgB79u%C^7>rFJ>XZ_Yc^NIT&lr~h`RKtJ)vT!( zXX&SirRomNM+!oO*To1wU&FG6wcLEiLP}IW4;{bowlDX_?#0eyw-Sh|#zf>#z@@vh zAHARyI7U@#&p6|Zo2N~iwlq6Cd*hNNOD-8ceE84SuV0^@l9G}d2m~f<+O)~CENk|R z88fapQbYGB!wxIaYNHmBS~Rv0+f>A-_h8zRVBA8Y$86U{T$&MT`ZOdaO*u8mDWGDb%m5Vf8Kl z;sHkp-@l%vs;XxIx9`6Dx)-|$yFHX$MEtlcNL0<9#Eokg*T~}E{ zb!`(L1sv*%0i(TMgVcz{u&o|)qd|swg5-oVsK^*afu^E_5K@6Pl!b>-5cDGoEu;|B zeaMhhU^Sb4N66qv2-WpkCHayfIhbk^W1eodrjZeg(86adH4ny)31L1aVrSv^>_bc- z!bX}s^#hu%5o0x+l7~BgxhcVF*E=>(qhhG-gm=;8?sMXdsCPZ6z64xWZTVimQ} zWTfGDE$XV9`RmmG=$&82&AKs;8@`OT_M$6xJAt%AL{fp_zyRVAs8&CUrvblDQuZ>S zKEeKGpd6?G)~jl)hklxK=gz&+@Asb;2m}T+H#ZxlrKMpYB^Ha(+}zyS)YSBy`VaDQ z{N(+!nw3?heC)GnF6>&9(QGkfg~cEzoyqB`1YJLs>G|YoD&Vrsa{xijC*Y*E5l9u4 zZiG}RB50%_tY?#Zgba}&DoQIAT5Sy%UsN>02UK~d5Ql^vt z@i%zl-zD0V@96%x^i(d{$4Yke`RlpE(re?% zo@jE|-9C^GsA?0iXh+J5$l*zfR;y~VM3WE`CQQiQwr$(kqN1YI#>U3l+S*zVkXl(; zX~$wQjm2UOOP4O4+e+&M;#tH~JNk)Ny^P#qlGl*VXfut>R4>gbnMB+If}R+zIRdeR zAgN?KKB_&FB-KepB?Towj`6lu+6PF`2mk{~H5+t;lP6vgjp}+T39A~Z#N0!P#NKC1 zU^>25KM~EL#oj{HD#ngw;)}hP(&QO>fa{DK1f)662kY^sI*2Egs5eBdYf|4>%Bs~% zdHvMKxIa-i|776*cIIO4QV0tcEa1^cALYIG-otfWGBPqKEG+CGlP~(QN|sx8woHFe zQc^-~Z7pY=brwJQ$*#|n^pzoyoy0*&$}QO0hL$W@QoVTb;x2)2B9Z}|4IBeZrQ365 zlDExb@U~12Hq*#(g)ONg$@0WQy+ed4bH^dN6-N#Pf;o!2hoO!Vk;8~KFF;cc!fq`l>aI6zS!2e0Bh#G7^dNTS zW{mk3B5Bm59?I(aFsnY?$Rk($`ST3rlY#H;>_z($uy)-#rca+vES6Al{GZ45*I!Rf zO%1>M-S2j3z5gu)G9^j5`8(TC=Qpv43@08*`+q<|H_;a0tpOZA%p$`Kkz?f3nwAH# zC_WiQi<3_(X((kl#zaId8DO{SHe)}@c0Jf)k{Vl~D|{0$9U61v-oczkS|RG0T7Xc zfeV3IbPXTZVZ(-%W@cu3!r}0vOP4Oa>;$=ZWt2#85CL^)U=)U?kcUkr2TDj%5&RUH zrCKWE$z%c5nnFxOqX-er!?r8gWEEmZ4I)5T6r_bL(uuhc-6ItDY{la>x3q!1FHreuF4fkF2A6*H1CTVnmz{E+Dc6TrK2wZ;o z<-Gjz%NT~SOGspoClC=C#P)Chp0HB{A|l5C=Kx0%&oJDM3gCq!k37=N&(A+A5{cM` zVT=Qqir@k{M5!dE2MVMBn=~q;X~iU}LX<637?w8aM8dj4%bl@!JVMwQNX%YFgOx$G znQlfM@!NWEifhknXz)!58?H#0G+#^)@w>5)f@8PD{sG8^L+Bn#!$J{Q4K~ zFu%G*OWQjbD#0&~D#8|K8Zx%!@BPN1_3e*I$2~XP>(fQXC(ehnN&r{Py%74Qgf7f?51#E2HlvJBUCU603;5$~KUW5{(sVViLPK_`VK z&j3t2Q@oVxN`_znVJW0hDycMzuGA{jJ^+qiiE13!5}JIMfh% z?;Y_?PSL184a^X7P!Ri#dRpG7;Q?A%e)p%m|8bRWh4|3Ze=A&9F;tmz#+lm@h{xkW zM0zxD%FD|sFE1xEGmANM=5WTGGZ`~_bW+^V{SDsRh-PQm?d7D0&)UHo+iMG-`?R|s zJMY|cd+p2RmtW4ej{G(OzaLc>!)Pzxe~sk7fk2Y=fAm}X5D^b>J@9?vL(A=$4?GCm ztEy2Ekt?paqISrTA!c=THGpZFrVk*Ut>GZmz7)dlC_?TcZSoByl|sVIqtr7L$Mz6m zI1y()&A!1n_820@Vu`tqC*}-IaZDpsb#jVEKJ#Oh55d}Z98n3up~q@?!F)_}En76o zl6e)peCd3iX&-_I&mv4~5Lu+*mXZJf zAOJ~3K~xZf;BY<>Khu)k^)-gDa({bGE z^|G{NIq7L>%>VF19(?cto_+3FB9Tb1^@c(rPCoe*=A3yJ6DCafqEBO&;DQUzi8}q%$zxswQJY1VZ(-w{eHinWy?OJxOfPt3nGXZ32N*e{V(wqLR%)YWW8rejlhUV zKt%2Wo+C~kjlcuI3{^e4GkE~~^Pm5$&CJZq&C1G(R#a4!`Tc&)&dwH}&({Rd%%&xl zxmpeltz(s}c1N(@*@G|knVgWc#SL)6+d4z(r{wf3j< zd55p&5RyBrpG!P8ymUrzI&NI?GO$-bUJ_i%U@_{Xu!5@ zT-U{MoUhcjYSk+K{ph1z&Ot=D=GyDH`s!=D><@>-{NM+dA|f5zj$ltWVa5>mN%n;( zNd&2h$W-Fl$0h@1z@LFXs%m1r7nnPD?l;Gb8I!wV!-f@^nVDuJ5~&+FaA4+=B}*KD zm#De9cp~2}8jP=XO|3>jre-#^&R=Y%9GvR5q@}7@9^9t|XUtHVB%Ody*!Iq5{&M=g z+^?#wW4pDPtkdUz5rYQ}=D6dJ=b5LTqP4Z9WB=1nJ<0Vyxt_v;LIlW6&*bd0&f)B{ z&*9TgKjDD~9^mPxpQ5FuC1Jgb7A<7aqJ><0?bRHA{0YoC^Gqg9n%pll=8MK}e)H=t znwN-hPl_az~^KvjG7 zm59iBz;B5sQ+^P*M^$V4s`$S9?z?-`s8Q#<@x~j+7Z(@*F&qxB4uwL8rlzLOn>B0J zOn~Q(l9|IsbG4>nReVC&m&5o*a6fvR(uxQp^1W>OQ#r?OY0)i7oXcKxL+80LuEM(Y z8~Nogf5AWg_LnYl)22=5$tRvdh)0mSLWkebbzNFpTY2)yC%FIq`&qJNai8t(yYFaD zKm815&z?yljW^wN(@TLsARG>d ztDBpfFIlu`QFB|yHI8{v-yCzBesk;%I%DRu`t9j|XY{xK&d}@E>LGV+(VU;G(}{b@ zW7j|g1`jIY#x7bnP;9! zT3XNZJ6EjujO(tuhVkRa^8Jf02j>y2OuJthQavptJDEIra*s_$qfwrG@(E_oKAve)r*QY(cTrhc z*+C|b<6?h-+sc)zc=nm6yY$I4O)kFla$FZ&6&x2pIPLT~6c!eBk-homo7udjtm7K> z2YW1mh)57fHq%{?L%6DHtLk$*)0Zo+yz-|2pM3Jk6;)MLp0;`&RdsqVxfi<{?L(HC znVHO*HH+fnt{F2|uUW&(ue^$zq|-1E2ypVrC-eOCFY@lY?{WV57m%5m*`xf14IB8? zFMrPD$rHKof^&K6tv88Aqu93ng>84-ejBdaH7;cKcTXZCBNJ8avRRgwAN=sgUHaVI z)WqeNU)CYhAMCL{5D_^Pcqa+b8dc5iTWr^0(xgf0AAkIDqI3a!@dcr?4@6Zv9;Wj0 zavr$<0j|0BnlAErd3h{dvf=e^&huD9QQo9WZ1 zcSPhSgFRLQ;R_5P+ZpU7kKGFq!8A<_!=SLBfFovnjs5oPx~f!FRTY2z`~CeUkM{a4 z%i@F+PUOiapJLv;`CM|zrR3&z&v*Sf%F4?4{q46gX!O@!D%dqtRV5bbI$7 ze!rdeaq=mr5)1}$9H)a&yKg_Z>_=Eu*OWVR=g!4--F|5ydoqE1sT1h-V$XtzfWVkB zqd9BNoG!;ym0$kq=Y0l}C4=JPVt(?I>sh#PF@L`IugsV+v&T2M>$?2s%{Q5Q(fQ0g zY#Mj`?p8K#*s#N<%gPlic;)4ny0l?g7U!OS(RLa~_pNB)K>qLKu8A5-N=mrvuDkkm z{(CZkd}&ko_hQe4h!6+{IN`YC_{KNC)#X@AOA9yO{Hreelzz>R>jKNNIQH0CJoNCt z`C#5hTz2`7C@AQ8j%RgsHTV7bPaJ*ZH@M*3vw8WY7YT>M{n9?}x%^~#l; zdh+Zp=7!(z=gqg@$1u!}ezg;fs-kUkc02d+&DUS!XE$`sRCem=XK?@h|3qEIFr?S$ zkUf<^js>1cLUf&~4%>-#ih=JCk4zm-^1rJesA|%hPuqyn32p7{M|_zJB|hb{{r_3< z^|X_RhDH>>K={p^1h@nqX`fKffk zc|4xTkACzc-{qHIPFh+T_uqd%@4x>(XPtExGroQpjtd`u{0X<-b}NrR_E?v)vt}K~ zpYOe|OGi7!m-UM7Z~5*7()n{~Ss9N%_85;o`Y@X}Z|<}1{STPPtm9AM@Naw*uXp=p zj<3D)$GrK*YaQQ3g!3=>KIdI<5w>k7);tmrh^q3#OXsp^VMh`=48!2P59TrDpo3_$ z1bf5|6Nrf900$7iv0H$5Rdw4ARo4Hue*s*Vgy_SnxHJM3|?bqa5;0ody9+QIK z?C^V#kJ{XCKL z=WqRv|83;rI1cZ>|2_{r^dPUl_FA7=)KXGXIP$3PaO`o%Gi>+>0M@Qq&6%g2(nb3S z1cJQ!#@iiE7pSWFmWRD=FP|J_4Im8`t1V|5wD2+1lSC` z3fu`i1*{U0FKdzPT@r!X2Y$$oKU4?wLv|*8lLy2f^#0&(dM6KvKb$x4#ghjlKbdhq zU?K5-B~2a>pCHyw9_`;tN|xdAc<@*r4xc%b@11&Dmol#Fa_OZP$J!ERo$T#5=G<*;%3E;V412W733x&bAW#&A-Y~w zd;X<$t#dZ;Sf7INOltFiW0R?OCox-9pXg1XErr5U?85bdwrtr%QPH3_)g2ZtUcxsI zpGi&4=gP8(@WKl(GHK!@3~jR+dw8`b3byLWZ0Y>j?fkjR!yWI}M++A4*kh0I$}2DL z@aWLE@e?@a*yETn^N5Z-CSCf{g9)RmG&MJK_Gzb3Tl+ZyXJuuxdd(WLGJAg1`b!{} z(f5L4zf#p?%!?g@h>QYOBq16D(o{9vr)1)G4k!K)_8fNDGaMkKs;x=1lLmYQj7*~5 zfvTUUCG4TTY~rR%UT<>1THtgb1UyP|guF8tq}ua*9}zhSc$dV>oGS4pMpqKg0v90e ztC>bG>j&lM=d*QdDPY7&!Bxt(R&e|6w{!b#zwIKs&#+<4d;desHdWs>5-aZ8ztwk+ zK+t$Pj`m|sO^rP9py{e~E>wt(bc*qboZ`#zM;rIgqX3ji`P@AIW!t{KFhy09jzLM1oWG~45BE{egFtWBzm@odw^-Ze zo#zhxiz{ZUmJB}HK!JqE^3&$UGG=kz_cB!koqqKcr z=VLuSoT{iMcChxeH8nLcYu3?JR#adZMwj8*⁡m@6G#&ii&ccfA$%kf9@H|%07R` z3>rL`qrP)2-#qf$9ivU^x+tHA{de@w6)wNze3maS=_qfSCi6f3l>H}+N04q#RkvS0 zkfZ6FJRrVc_7{mS!~X$*#<5IQpHbDPi9dYFkO#oTem0j(xP7mFkhY}HeUbO4s=81+ zP3CJm&k`WfaQ8>5`gF1z@!{3(=<8lw$oAyn0H>(xw-S*@Tfb|8lZFi&mazUQQ@Vx< z8HRx&!eNI_=j2mP>2l0_#dpD#*&p;>o9< z&-44c|HL=GbtGP|m(80t@#jC@#s3|D zEZ1H2W8Qn`?S!K=Xq-?k{=tvCWF~VQhwoo_0ko4xH&vuR1d^;jAQ|&wXRupB*xT0d zO%$g00CCN%JNn~Dh2)5_M*2R%+1^Q)B)XA)yyRYs-XRe6c z1pKty?iyfU;wDvh$MQ$2nv}NGWi-Q@Gwo`7BA0f0$m(ZBJ=8*jYhjyrCsum5}+ zQg(JW6%`ejrrBe;`|rP>Io-nC1Azc5R;|CzrVwb>F5(i&wY~ZiEj1kRXq3fQ@r}hOEh%4PGiQ7 zlqEdi5I8(n6gEbCNe<#*rL(v;fPJtaC?j z0LhU@9dT#dE`f-QB%W-jJFZgID&qEgcZ_c%-efR>M=#D7akqkF!N8*aFvSMmU5(!>M!+Sj^< zri8;`e)jX9_siVq&0Oh^DHDlAxZ;W*(%Ra}*m2{y@S?e-rp6z;cB0wQ{H4Q(kKl(_ zT*dP*zs}Ep^&1X4_z(=kVEM8Ves{}nIQhh5x$U>VW_ign(n6V>dCmo0%2!ra^3$Jo ze}5)#!X)c=_(Z?h92j3uQtl&7Mzu;FchhwtDToJ|{k83LA_DOfcPJ)MaWL}?upm9NsCqgf}gy^m{)s+M(Y@4LWnh!ce$xU_9#tQ~*g^F>QOp>Ll|dV+mk zk|#s}?zrO)&N}NXPCDr%UVH5|F1h5AKFbU(9?Gewp4MgZo2v59fBcQg%F13%k@nA> z%XL5A+p$ESZ@u+5tXjE}l$2C{{j1;N5BPB$XS-OF9Zi4?@pW=$9DW41-Ek+6J@p*t zoOb~Q1%w(`nL&vV%&7jX8RlW1;kqIjRKLEL}*F>%I(SyIGa&*13H9cf&BqFDT%wbI<3|C!gW> zciqD`zI7x%pN}n@H}Thd|H#G-UEejaSd8z_olC@a;#Wb8J%>OOZIl0qz zD%<;dV#H%gJ};!Yu^)c0b;P5ZyTc$pk7t#LtP_#@MC6QQ2_;$N=jU_&1sCA=cU8V# zdgVn{uU(Dp#&Fwc!;P=Pv{R!i+c`~9%C~Oirk}j)0FJAD6G)qiob1r$7pZ~FAaRgU zceL)pe*BX7?9a|v5B#k2jy6ps(XtVJ5=h&;kNvytR^kNmZh|5vFjYhX#7(H~zow^D z_22YNN;D9p=d`ySa%|5JC~0CeVHrmZ8)~gHCJ6hLqh}m>@$ojuer8E z>*!o}cdg=!fQS$ZrE&a;-{ro)-_PIfe~9lKd)#*IU4Gf6G&QxvwV5R9okVh`&Q?|J zdz#^nUl_uS2*g`eW{`S``nzacX-vqSUfkME-= zv!$o+iMGyl0eF30GBPqqN$EO%Qe9omuYUOpRFfNp+3l$VMdUc*fo#bjnJCr1+B1m9 zRCK>SkE!ZQ35ozD8fnOo_*D7c&|}<0o5M3v==$j-UN8GHRV^n@O5L5lYqaNK(aH30 zB5G&s^nKTOP}?a$-?O(8pt`zx*#7(P&%H@Z{^|)6#*X8(IcIj+=ejOG{L$q&C{CNN z!es|dl?0y`ESS&V{u1|pU-qLPGj81Ye)ai_&`25@8hGl7$GG5}Gdb;~**tjvKWJ)d z+)i%erj0mGas=|FMSdnin3=w@dE3sy3_Y1;pb}{th(tr@Z4hTzKJyJpTCOeG4Z*QBe`!JN0ym z1`h19zjVtMo_gxZxDP}Vn=t*^+O?6|+8VCA_G(<$W#-{W@V!${$LI4UbbKa4XN_WK zVcRzEzVjchz3Rstcl5XT-7UZ2v*kTUV+4aiZn@>wxHC41`gfZHwarQR67dON$>7&J zJB%zM1;l+H-H`^AiijrKfTcZD*%yKI<*Vq)jOmO9;QUVC6A?mh_a~A3Lg1B7+lL8c zc4@o~fU16|s%Hba#E0#FN_wk(JiQ-YkY@0pXd23HW)GKkcPhc{qGjCN!`5&S+^jVCKMWz(tv(G-`cennQSx0}1Yp(ba@BHVjUh|U_ z4IId2mtD^K4I3#cEW|X8-q*&JcpAB)-efvqwur3MK4yz1gSG&y>xln&k`2aM$u2No zh>yDLvgzdXLLefNK|F}8GrF(in+$L}mfqBT`@OG?cwd zq48PNZ?|pjX61NbD)C^t*(7kPuV25Ox8Hu7!w)|^iB_cJug7CzSspIB@B*HG>M52k z{d^Fqp`o7p{&X*MFFFs!MDcVXk2p#65w0$6$$U`$_22`%|K7Wprpd2wzJ_5T>7Dv+ z{~N%`eG2vuy=fqcd=K46HA;v(M|;AXbP6PE8+z`Z{x3!kCYFc{1iEMcZ6S9&BN8_`-C(uSN-LYat|EFWMJ2(dn7{IBgox0tz zJMX-chNc!=cjru)Wy?yq>koGT@coM~W%~3(@pwFlNH_B69m)DXM1*iS%u6pm&!yi# zpW}`?fGBOYrUf~u;Byia`8 zp*xy^bGvB)ljxh2IwR3b;uGC|>CNYePxbe7`rhGhY9ouc_&hYdn7CQDU5WyUFDH5? z@n};YaE+?=%Xg)!E8Cpw<#clx_m#Xj5!#1M4Z~p8vB&V-v(NGV`|ouek47W>_P4ik z)6ag6x``*&b)VPLeTcWYsflZ^yna)t#qSjtouzswi zvoe>X$W!9&njVhji&uRS*=y`54M$TptgtAqd+yuev8O=N~uCD z+vV-r+0lylhv(b8UAuNniNp=$PrJuj!*=0VM}1CUwclYYw_1V|CBA*JxSaWs{C_!*&38Vz96*_W(jPvb8Db)^m(x&LwfL|Iu z8*Inhh7yVbv3uCx=F;mlwBZ0}J*aY{QYt}20^jlG zzAi^^S)0(ILv3AJG@>1fyHZlf%E~4y%S=f0^wg=m^_Jc)_N72PXA!RatR;(B{y`2( zDPDZ}6P6QB z1x{zRA%oSj;d`0nZw7K5!S8-t2&_aOH9!CGV(=#RhvnW3)kvt6+J^U$crQDMQmPH! zZ)jh;8td_XyC1b#WHB4j}hEmsYdc&~#?VjDd{Nf7$ zq>avC(7-{6Q~OZ3mM5;4zP{bWu!~AfTo}T)^Me zwd>Ex%*TV2ttA2CF8`QeA+@Ma1uxty1bHwDRa^Et@!TVqk#-!4ZW6O%afC*F7wl|DL2&hc zlau+!`~_~iiQ7(~%-==y5&b78PvXp(Gj#6UnWv{c4dOJkp3AP`tvJB7^=j;_82N>T z|6$Rhg=A+h26WFgQR?L1W*V&S?# z6`Jn<1s`wUprACr$75*Qiyd!jCGd_?su=zDen)%|0xNwM!xa>&1NOTW?UYhEXm8b1 zKrif-%FmTjU!u7%3ebU{ddUmM1UT_R6TK`yjdrw)#{u3i9DJk;g?9b88NQXVc zatP1$7?QtyIc>YOt!+QQ>M9P0v&p*nva_$o>9p9H&|=Ap{0)TWRE?XG>=~1YjjXcr zEihS|b&ZZ4Gh}LU6(H$+{yIJJ&7Du3?_NHr8_fItXH}vIy@6l&u==ex-^B|!OX>P| z-s$G4X@k3u(iMbDSxXtt%|vpXx!zDP|5!h7R$*Uy_B#(Pp}6oylr2{~U%k+{F8Pt# z?^3rXJAnh4MV7xqZ(dl%PN~VTExMM$E+!jpxbRy`dGg8_m#1 zb`2iu)5b?=nwa!=um<*?lU}Qtm^f-G=R3_ezVGi`!20g6@$vPKHra=B&ypl1`4dPi zASRvgU{8rI@cl!t+_Srbv(W}om$6~6LfV8zs6P=C+pgcB9(>$DI0*sSGbz3y&#>t6 z;Sf^tR3Pl*Emw$#L&vGq#LipiyX9irYe%?7RvDpFy`7$Gvrr(a*8WT~j4F87t z{8|2yhWD`jMRoPlu1oXi!g(XEO);lLaw0=Z|6i}q{1k%SYp$#bp4WM9Tb&n6BkH}H zBxz}P6Q!T|uFgoe9c*WsBg@ycQv?>9Fdm!Za+f;*GU)syXz@TyOb?h&0KKamz3r}S zWo4z$|LlJHZp$Qo->UP2_hM}n3u4WfKRj8KDd9O9)x;bsH+_zC{f;~u*qj9XGi1*- z(kVXgh*xZ{8o-*C0|)D%!T-JyRAz6pjJ!p;HLho~)?A}Hbz+X8jl_MZK)%qc69RrS zt^zRqgwgbe%eNLJMd(CFXs4^^qb@giYSvQiRb8LnqwqdWFzpHBZ~8#aB-Rxc(pP4- z{JP6;j}89;6soIRbfy}0lGKUyhs@rx)EF{3b3N2OyDT4gQRO%n@~=-zOY0!obe4_u z?uAOfj*bmO8+ZT4HrySLwZSo z%{#f0N}w%W;{AWh!$=zMra*$7;BYejUcOTk<#gi8=TtKz?a(a`n*cIN9X!*>&H}3G zP(sWSM{+cqg4;rR1loH=Q~?sP5$#E4|E^IHgIm}>AM*V1teG?Oq*Iu2WOFIJ`oCSU zHC3J>WEI8T6ma>^lHXLWy#1pluNLYF*Fu5|<+8hk_s$s|7&Rt@(Ih8!cPozsz zRdpS|1#{MyIbGmj5ME=meT^nk<~6KDcd+=XLLH_bfRX-=yWmpD^*#sphkmiKp9IuH z$3*!f+`Ie+4=BQ0?70uGK0F-GA5bHBZf^deu+NxtX6V-G)A+Retxf?LEYCmD(c~7P)a+cl$O1p^lbal{^`p4DgdrU=3`wZYR>t1eI zL5+0E+>X_Y#NhC*0ep$=a9-qq8y_7H`>h8dB=WK-6j=&GN}<8eC^r_q9q?VefAy+z zzvu$apWBUu4Xx)ghzlisFSg5n5ya>EY>||j=(gMqHd*dAUP6e_R{x#5SN3v)+l)|D z=U&~;QcgI_7m%ZN+_1^5_SSQ-ECH9-i9C4PtQ#6-@729fBfs9RYc%oLEz^AkY( zB`&svk7Uac(m2SXXBK(%v4zo;|Nj>F0Aq2}l@BpFV{4gJPyI%P(|qRWsE&}ZaLrOw zYOWS+)G7)Fztc$+v>45{RLjIc!k}EhRZ3+enW0X>Dzk;;+-juZd${2I6l`E(NzbiU z=f~Tvt*rufqg*Tjr)IUD+ja^e7aT9|6C)i3nzphdMm@G>SVhr|Z?8gL|GkYFHK%59 z3vN3IaWS9RvE213y)jd1>nnV0jTw*X91`e+-g(1<%SKO=yib!cK95gAqd#F!e@egG zaF^)n>9Lq7HohnB8ah0TFt@OXjE?3I6ijfOt4%oxwyC%z`_=BoSo#fpNM1r zm8quB?okmJcO124qIYTf&~$YWj#%{vAthi9wkX4YO_eF=0f&( zcYb#@i~5#&mJBbz;^Ob}8r<+>iHeS%lVKbi8)J((wD?UVeEt|S&4alrKu^cWs4Pc6 z-t7qeYxC$(s3Q8aYO~Pc9j1GYPc2vpX_n9 zb##=!**6C)sJQ1AeZG3e(%xdr%F2qs>t6bevG0GdKIC_v?R1bya%_yt2HwFCs(TOP zvCt%7+Sv-QI6PUk!6#c&ODz@Rrhqe%zHaTcU2R}aQgwDZYA)4KR-N8zsW<5r2Va*F=UieX~7^i zH{ZJa*J|>GqrkMN(&2EXV)+zZlp4w;SIzWj9cOtoQ$sTO2x`R6wnXn!xw540|D0P? z+kMYTLrR`p7>VzkjK?PNUXx0U@h_jkys*-s2ystaJJx(s|3l0G-lj1${_vL)tH0$x zY>}ZD0?{kAz-v(P3V^C)4CWoIMJ@}?_~XUKJv(!C;_f)An>TM(*p7tBy(JzhL<(!q zfnBvWkmc0PB<&*tJP|9at6G|xvICjYQ&j`1VPck@RQ$_(zurQSrJuv9>P#AZ^1h@l z&!9hkEO%X1_T0s)fj*I18WaOQvw*@d^8e}eDzq({?r_daR22o95R&`*`+oavbl}M@ zQ&y>M!*+!0kAo+2stl)5@~nxluoItsvb}hv86}4e{Sn5VH(oic&rSd85gI>nxO!b6 z%y9a>!z*8_q(&`J>~nrsWf^{#**%`_+^kF+%;u(-?&+x^>S$!mZ6QoHP+KJ{6B^HJ zbDMiWCaY{T?wK}gbvI|W#qZOK;B4}ov49mB$i+=({prgV#BQncq-=W}>+VAZAD`N- z$x@E5$4YT5Ng$Lu=H}+8Kn)|Kbk#IypF3A^US8{W6Em}%b6J-AiJThAAPgxRQkO>~ zCd(QrLTx&n92_mix=18sl*YVRPvU5noJ+(dvKrdK&$p36u#3iixz87srfSX>F+?%(TSRiZYMYEc`Wsk->BxWV4GPOtq=v;xaae zwYG^MT>2o+Ld)ms_G_XtQt9%&dWwg#g-VyDELKXvVTzJK%NMixX6}1G@(H)g$IR_M z+1`K$Z_QK<94*v-Kq&hh;n)CX7BxY*_PankKhJ)m_zM(JfQeFnN41B)>+$PtS>js) z&TGfh^VS1F!J#AngO#rT&K+%&nMwyW$kw-S-&PKK_`N)Q#u=iG8XQ%J<@Vq|9d~k}+IzyVw)}2mX zS;Mr_G>g~jGZx$>G(_y|2pydV3SngXXJl|CB^5=*u#fBvqIT#4EJ$){t1V&V!bx>3 zj*>*f6}H;mz+&|f1~Y}CChr?oqNu^4ogv{NG-mkIE~)N%YYU}~1WT?Cg{}AgQU=_} zGY@78k>#qZZfm_RA3+2V$^eFWC@E+} zc+S+QF^>2`n#`g`Ga_@iF8!t>LE}qh|Dag)EDn}dSsNxD!nobEUpZWiKqC<}J{$XYG@>X8!7+G4<%NypbAq)dZzhb6HuYJ5ah5YX zH+N)u`n_AEq$!eKe57=ID>F__9v}5yz7%xAN+t7~ss{wfL`FtNM07EULZQj!)&mC{ z-%Dx_Hzvdmz5akv%-GB0xE5eV=m*IPP>!l8zdI8+=H}-E&K-!!=<%BCy$@&4fDBd5 zkQlp^=Hcnt6!Yo!#0|1(pVfM7(hIj^MGH)u0_p*lYjS2*8az4bJ%+HZ#YlZ(=xpNk zAixO4RgNQnZOQ~hd+2J$TFp6(`gS39cg^T~qzMJPmCTzgZyyY3r3#i z`3ZaCrDevWmR>>0870;)3?v4N*R;$sE#>N>K9L5FT_;AV<5Og<6g4$9K;dbY*o&LD zl2B7m{j}Hn8c3KT?)D{OazHjJDhjpw_1m`(pv>`VP>f;h>PqBX#SP^mngaa20t^gN z3yeY9cwRgiI*XHGcNjS_gtqO{qZ z==9yNQdO!1uOtNNkQqB97dbc0*cLN*9Phe7RA18fScEqZHY$-E8;rCev@P7ftZK$v zcB7rvr6J2yf{c4ET2%!0dQunYN(j^$&!$T#048#12pgxci)}#Gx^shER)1om7F0ma zRB^7}lgz6oSGqa&y#w?UA|p$QB}7ivNngBpQTgA00yr0%_e^3GK_mGZ<<5)p$|@>z zqY>j%5LtP7g0?o%s^w~zWt5kZ(R00pOSB(UxM?}@*;9#b5=j-Hec)YQ|109uW=9c zG@rzTA~vWO$m6~hQ+*gO+H}O(_R&JZu`OOez9Z?WLxL2 zh82n(O7l<#0gad{VhieR8r*D6dBIj|B+ZuKsf-a0YrJb`>e}_t9h3yXl1re8M7}^G z83ts|3n%E+^Ao`t3Z$$)4}-9f(0`H<5|cdzLL@BSFc)}zS>faqTQgQ}t#NQ@@0bK6 z{vO~6CjS+sOL>2&t{(h6HO(FG5wO9TTgA{4EZ=hy)(mYK-^+-&pc7!-o`iOO9l14G zfbLd;$>zt@o8Z=+ngqIz?>omKHaN214VC<%4OD=;wumH?as;I)7g*u!-RK=Cs|OGR ztB?;dxTK~r@e2|ZF0MB3HFp~@@>Gwd8RyxkvvCGEB#y;Z6ee~r#&8e}gIhb(H zBQx;I`!2tUD$ot4?dM+0n4QD_d%{pI1Voh(Lh%C_6No8UdO>!SPv${CW!6*vgu1Vo zLFf0ryggT4yCQ~-YWvzcxv|JI^2PXmTb1!rmQ4Fsc_+4xFqbD2e7*Xt7Cv8Kudp(X z5fq7<)Y)^olHPs~{U&9ly5}p8nxte|L#Bv_Nu4Cac^YCp;fKB7-IyXg@>})n=4yWe zR%`nEpS>uY)n;)_nKYDfPY>W+;jPc~tpIFZJSCZoWV_!%Mw~RtOX4)Qzw2<4dlLL%-KE#5q?(Mu*uSH zK~u4>r7A1g+oZ-{_hqFcul$*YC=0qO*?p#Ay4<47{^W^66JOZCb$QPQ6fdS?w)PlB z%~ZENVXt3N95-;uvM#vz!!0uq8;>jEG?XgTtb~6k!)3ITrAglKwM&0Ay>7qv#E-fC zK!}fzLZf6@qT$An_4X+{2mt3o^M1-FU`CN7pf1Gx{)+g$Bx)=@|-I26Bx|%vVa2FS_T;75b;`Z&^xcMfS*t}nP!5m=j)s9H?OxFE3 z9z1a|3+NP>-7PA$&TacGO8u)X8lRB(Xm_H-^qQ2nLxURBhFbTj;hOdrd-_Hk5%)u) iiT}4;q#k9wrZnF4+Y5#hhJ))$@m@SrhZoDg3i%%k?%5dt literal 0 HcmV?d00001 From c7bfd26343fe99c6d07826aca7b9aa40fb40af7d Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 14 Mar 2011 10:23:04 +0000 Subject: [PATCH 274/541] Fix logo proposals 5 and 6 size (JAMES-1091) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1081316 13f79535-47bb-0310-9956-ffa450edef68 --- .../site/resources/logo-call/james-logo-5.png | Bin 3355 -> 8422 bytes .../site/resources/logo-call/james-logo-6.png | Bin 3774 -> 13523 bytes 2 files changed, 0 insertions(+), 0 deletions(-) diff --git a/project/src/site/resources/logo-call/james-logo-5.png b/project/src/site/resources/logo-call/james-logo-5.png index 24cc5e27316adf0b76de349b6fdd9e20dec2ca9c..16594a476b6f942342ccfa9c98da3d5fc139c9a1 100644 GIT binary patch literal 8422 zcmW+c1z1!~*UK&;EZs{ZC0)|p-CavbcOw!@OP4Mk0)li3D7Anz(kvYU5)#rcA@J|_ z-{+Y-H)c-EnVD0QpsTHdheL$}008jRR2B76^%knUd4Y+#7voCuqAGMhc{Rfqs4Miv zoA;=9Y;RRFKL7wo_P>HgHC?fZ`Uvq?GW9p`a`X?f^>qLQ1qJcAc)I!7+j=|jc=-eSR)W_L?=Xf4l$)m~MQFyzEggsXkQW~pGVpqL}3K?s}Y+8K0Vt|8jG1pUGzChA)|^SCpO z2RGhI(?>e)O%}FXgzs;>JN>qwSiNm9B*|&tWIAR0{Y$$RyGrtgFrsoX0q}6uM)W(8 z7va0dvP>&VzEp$yX%dPC7a@{`NxfT5_f`7GZ<8ya6F9KVO$-|}CwA{+{`zjU)_1@Q zZ9LoX2&)moS54u;Zh`8<8SCJqXpA9$H6_0NCsoz5apfD(0(RU2wN`S6AxbJ*w(7xYpe~JB3$L;OUqs)S)OO}wi`1y! z^A&I3>awP932?Ep3yM9(;UWx{X#miN(zr9E6`v)&+X`af* z4Mso1SeoO?D1

    sno-0Y&^^zkN-w_&Xz!bv+tk5Dh& zMGZ8;Q=!jQ0MZBpNxFdZl)gEdt`GUW18%eo7TkGd0o!VeiiP0*Yb3?I>-b;mJk@Ng z8%jbO2R$IVXj-nmyIHa15;4uOlN=9Lpng2-9RVL5jA4wTV|{Xd$qVn$cIEB`nhKhq zy4OKPJa->AEG#mkBcjvQ#?6Muy9OoKUt0RWHIM_@SUzPPcX3K1ZggE@<}Zv};MEWK zmh%?Fmc(drhD&xYx+l<6Ke?YNIr}#Itgr0CaY^VwLYsqYVQiqSy_yd5z;d^q0 zHbr3kCu-_8bcK%9p2Ecc_A2Q?i-4d!s;M)%2Ot-P>lNM>9^fymm{O~!}U17 zsr3hiJ<^x@fz;oYh}Xv8Hl*!F`AVMWQUu9DLedi1w+PfKeyN6rNf{&eoa}}Zsy|Oh zj5)3AyL$hs4LzulC79OJ*_xY=OGS_KZCGj5c^Y`(2;4}cC(VG^3f$Ic!i*MD3KL=V zi4Co69lGXr$M*EpICHe&KLcOvn|NU2^9e~0%m?d9JN*Bqz%Lr7uvCcCrh>iuLf#_I zOfi_sy|k``Tds*ESolo3ezAQz91;N>%B3n^%-BbXQY6qMUhY^WVy#@$IQ1L~?q5_2 zlNs_$pfOV?c}Hy#W$!~`x{mE`RC24nWoWSDluKnjH{)~%)O{Z5-sFWZ4_iJtmz4*; z14G;xR>ihp-CVN0Z%SK6nsw;1ygO7zZ;`_TX5Ki}*#Pyk-tH2oC6d~~gn zSwr;DzNu_2t$}ISQ*|>1lq!cqt8lwwsP#yN#SvP%$`w!^>+<&o{*vD z6_Km9D6i>8#Z)X$w6>q$TXAlqwMuS4b=KBjiV7yO&O?VTaR+V1`d3G%@}B~xcV~3n zG3{*8ut~uJ;a(3irnSs{^%F?^Uia_$yR#+nk=V3d*ZKxKCPC3^VKrc?%n@GP-Osz( zi{ouLTcjjMCmb$Iqn+f-I3g(s?*^)%js82EQ+CCyO&2=VHu6j*Igo$<^bj9br^}3 zNz?*Y4(3g^kCegWd_r%#@ZaEjOP#4XhWQ58J3&V1Bf00ayUX~r*6x}lV92JLeiz1s zf~83)5n6XbTSRt1qGini1Sbn4Jc+tDvo$`;_08Diw`U-RSRP(7b00BR&%|xh9ZqJ^ zY-*Z5=2mJ`2(3j_<+e7zyV)0as-sAI%@mm>DdVp*Yz2I_wFC13_8^84ojm`0`q}aK zBNK#Q4PZmN>;peUF-0t2QS7YWcLcmTw=N%o3JEwk4TeJ6J7YTRY5>MBe4VqjpW7cM zvLcLrevwi4^+JzrVqy{43rpcqjTlj_Dg+$noBhcWCL69ynW6iV8JEk7bVHo&q7;9; zz#m)lk15wDyT8P#-%SztJKmQr#-kWnPZT4d+%3W>0M75Hzdvs3*)d8|!0(~SZ**vw^r9^e1`Nlp)|cGWBs z^zJ0Cdcfx{y{E9}`p&n0K2t8Z37YMUBm)2|D}L-tUrKjIA%2&C6%SlVdKnx2PvGQ? z*7n+G89$St^+_R}#Ccpniii0tR(W>Q5?{rM>gfovbMYKYa}gR#zR8Yd2dj(Sejs0~_en_IpRg0wLfYM#+K^4J*#m>+-{h{3mD{Y-YAYOlS4T#()AXV*Pu`k{ z9O7|9;XnNEH4vM#f5e3cfXT?y^8VFt(nOR5mFvGh0zcW$ADPEMaCbw8eDTR*DBm}G z=yC2`^5^~?U*cI^M03Z+$0!1XuO+PV3JQgrBxsFkG=Oz?-xy?|jVi<@I$gkr)$+6E z#()bAe{}|TpcJ?hN{7RVS(gM25PM}d1sE$e>uj5{yIBOsQ^6F2k6%lI)e+K!;=pit;XA>boPnhMCVb^E@?On{a#+I!O8i!J^87Jrjs4}txr)IKhSb!$TmzVIkht!- z+Kk$o%W!f?wOD^-709tWv2q=^0iRB`B7S35-yGG3qnnW|CawbFSI;7Zr9q5^WXCnj1=n z^@GjdTYa|G1tXtuoG5eg^MTfQ*SJC&j4oBqWNc33oQ=XdpmgE(@^jQq%i61D^L>t5 zVQt^|_9BTK&D3LPo{aPR zzD_%o`EHnm)rKD3!M$0JqTub?x1Md_TxX;-I|2oJh}kE-A3gnX(8|l$y)}et`w;iM zzx-u`sh>0&1bK7vp+>V7KZQxNz*uFLxI56w^iMs;&l|c^9=>-heTR%y-HwFZK_8gu zUT2|p8L5VjQTCX6e?`Xrj0L+{&(DFO>3K3j2Q3^Y?Z-)%evxUDVo)f2qDU zSOh(07^(F-c-B*Wd96m^?vhi^o8FzIpBQfC{%jeDsm&uN1wfg3_`#`@2@Md@YSN>- z@9Lu%UvfZQQ*O|GMb($Xuzx1&49AwW%x)Lrz1*`TR!Lnxg|U1qk_bR(>9reH^V2IO zugHQqfCY}GU{ettcXrSrM*84&krT-3G^!$}|I=(k%}10S70KC?5jz%gCU$CPK4tS% zRIzKNI|$j5x-`pZk?1J1YcWb-59IdI9<>lCXVU0}Egt##ygXY4Kc=|9U# zds7eW(-)G_Dzb`1wf!D86@`JR-ZKLB2*yeucSi*R&DXUChWDcA%0qee31^0miL z!xY8)kAY}LCNn||79i1sW5*Qu#7uf}j99xe6^~J^pwC=inkp}oclcM$6doi*th+<$ zQcCMAeN8>Ex=$7*373wT=v}&^Is7zR6nbDNN1b*~<>pfUEg8 zuKz`+WyaN!PHIV9JAyZ3?5MiGs8L%l)M6xQyWuiB7w0Hv%zpqX?{AD@xXj)!@TY7n z70a5ge@#3D#~AQ8ecr}r5L}OvoiURK3)1{2=>NhZ%E%uYDqP=w85_m&E(gVGNX0Sq zHyJ*rjXgcwF}@64+p=_VZ?t`;O{v*`R?NVBw`|^PMGL5To{IExMjq6$MoNuZTFpRI zVno>fWFw?bCbNYPw_=ZZl^Pt5OK$<;wyys&v^Q4k{D&#MlUpAaXB#BJor~uCMd)v3 zDz4wobwT(zPK?%$=3W7lW{=rB%o5(Kz8@J#paQt(wwH@It+_`BvLi2>1XIF$WciPs?06 zp>Ww@`!*Jz5Na{Av-Xa3Fb7m({x^ojSK{*4oDGq)#)?HWV_J zyK)2U(9>Mwcdoj{ei*Ckswm#$NM8&33lZn-d4NH&`8nZ89_N(TxI|*#G^`I2W(f(W z@Nfd;9{hMRXT+To&=i zp5J)j*&2-8v7ElHbPGIskV>4&H^cpiXz;VrtVj=rPbU3U+ES?)dVo*yBpIV|+^jPy zchhCAbW2z)6CbyntBx{Io>-oEOf3-1si&?QQDMIQNJ2z3Q8Pl*9_WH!Ps%l&Yn>_V zQ;(Xo^C785nY`)66(4_^SN$rl3z)aw&vV{{QVD~^cmlYbb%Jju|Hg^y*cZgK=&TSI z0J?z3)1x62TYINm;>6YMe1LxaAo2qrgs2>}F5|n|x0v)K+TV#k<@~M=uSeG~DG&Vw z29Wmc8V-DVR6s^orI*iUCR6QkV&l9QGb(wJ<=$CXWz!BQPI}JxI<$L{F zBD7iwm61UR^mq5~wZxyQYpNFg6>xQq??Jsco8vtGl3AwwId8aEzOvjJtiAabE37m+ z*xB*!^7pyK6)nniaq@sV{qOCi;4tCCU?1&_(deOmkE40a1+!eFX25jet4i^^j% zzzf$8O8M?n>8KHgIW>HRR`$uW#F~Am9!F*X&jGlI(M#sJk@2&-{8L2s?Bz!ot4HW- z=8U(%(S<`|e4B0yrVKIsi&C^Q&Gw_^yaDBzOvI%*zUMsh>!sf^!pmB5!ee0rm z6b@uv`?SG5ieJ*s&FJ&i^iL_sEGQxn(5MO3s?6j$Rgy!>^zBx}yQAuy7YsjEpcI~u z+EX*&Sttn#Q+Vd>*MCq{b@js6*bNfW|4;V4BFRDVXm`j%>fp)}kD8Y-KlziG+vg4n zdd`rTe3H-HR?!K84|Y>_?_I)hlSxJ8h^ zQWMj0LhI$!^T78sPn7`#9e$Th>JDDg^VbTU0>rz!Z-e;A-FDm_t0=MVhk*_c(KPIy z$U_aX!sA3iHeQZ|QvJDaoLyy3FT}}4p5(*0z1@IrX^tMDAld0kpJ<TU8*g6vW+yUi}Zl+swFZCPXMNP|I}U_FP95$j5!%)2|pG0 zLpvr5j|qEXN?JZ5!jl3*reck(zFc=C1$OpZAU;V}%CuQS!gC+*&m5g*_7s+E0$CV# z>DF#1rLz+{DFyWB;>!b@5nd(TPSpw@`@0+eMEJ6>aVVNn^~>8O+x&R2?O6rc7i1c+ z;0*wm>=Daja^yS}{BT-h6I_zdjEx`Q88&fpJJgL7*Qz!9gIq+!YpH{WZ}sQgkk5>L z=3K67eEDn(YD4~$753C+!ThLDO2Zo{C)vqOT+S=JNR}lh7zz7y|5t@yphz>6E-}^T z47V7OGr69khL%x+2pc1VK zydFc;b{y3}O*%aIBiRg(G}^Y8E7JrF?rqN*u<_X$5WV(3X#XAM?Nar~q!X#mu=k*A z3kq%U#O@BM&U7-Rq$gn+HkuJGt^A+_d~eM}WXhW%LWT7z#vPf1(UblLzu=2his`&| zw1^_>$hy`0F75Te;oV$yj_*aWXu^JX^G4c1Q8CWu934AQhh$5ixM0-1&`IMAeeID; zyqR5{#}O?%+t+WRN0#1HXTN2JcwwPqMonu}&@U2n+!NrS_31|O0n*$ zN+3vdM^n&m&o42H>}Zy(nA@B%YkKcLbd;Tzp)c_%;XmuKubP#FLIMFgO83L9=fCI0 zh%)#BRF+JiN558gnY#uZ$5WyK#}{qWT#$zi?F|ydzSCiN$vT|;*6cO)cP!0P;CvYAJ~qiHFBjy`T4xPfd=IC{$Ie=f_5vxhO0WQJdds+ zi2;D0>O`lfVT*Jbm`s-)kC|T#a~)Gs9~6%)f;h&)D@?-ZxU^390kFt(DFFk?4o=?L zV`t=HFUldST{9Z{j5#^OpHf6Vci<`eSwPf20?6B$*eEm{#uIyb;^~f^+Rkz-vbKP= zughTYmPiuk*ugclIpg+^&Wck_hePK6tQ-KK~8y5><8X_bcu&o8VbZ>dTW-M zDxAKMgKtOJ$$!(n_IB`ifP?FDm1HDytlnTJBw>hY{UYg0c%xDfQ+`SW$|GYVoErig z+<=lW!fMs1{}QOJ3q@%UT`x%y&K>9|=m!-=;sYMk2D|txW)xbUFdJZN3(0p_3n5Oe zuie{IuaBf>IZftOA2SmDF!%^}_j0tK?M+>E(8TCOm4D$!a@$c!jel*rag?J6y;aEw z0YMrLvbfPJcpX*}3BP)AxD(#8uBH|t;3a4@@tvaoNw8E0;_G_3O18N5#$GY?@gbc* zJ<1E4CwiiheS5`~(OdpV^RcUyyOFtK#sl|?I|+fUMOBCy3Yk0bK}BvF7_w!zyz>!h zq}_GuRBd{1V4T9V9+|fUjlGBu~n2Pf0W_V5@S~s&*im06*D&IjQV7~a*xD?T;Z=>Oj z3gBjMpSGV9ekR(SLp)UsrFpVR!y5cSCkpq%?Bd%PVYItmRrCQZU=V|$Bw&l-vc=>p zSb*rtFaF0eX2On~F}3MC&?|vqD_AOHbvO?AGc|8T6exV z);$L|O`5Wvg@Px4P!VIj=sIQnJev?DSe{qaOITjqRyS<1SSv_p{pI?zHAXQipcCGP z&bCS%iffukoxX0=uotq$V^dId&ZL>rt6%aDfT`+4eCA0?T1cWiot^i3r5=pKm);=b zH~zlPc`pYalk-B$)hwelC|9)wgoTsIQ~lfJzgoj3RJGeUIZT{3^II>^0YftgMej-DiE}_1i~i>WOSvL_e;&$noQbZ(uj@He zKbEWivr1b1m`4Kt-X2MheIeQUyVo#iXG8>6I4jdxN&pM%imnx$##(cLUa{qxTl>JN zDHmCig5FIxara62WC;{158oJ14ePJjoUUr6P!x9sr-V-e#9+Ia!ueF|Vgz4KBX*@C zWm|-yi?u0>kukLMOdaMbCTatGfW91?l8pya0ORo{t2Y!S+-8RMD8UU_5SiH=sx73p z$0*&0yhhURSz;-T)0fNHA#2i|tS2_qBqQE_CHPdc=zGcYV^d^N9$HIryhFvNFcti(;nG_S>J7d=}WiR zu`oF}7`+yf5k?Z&s+6X13}|*M8t0{*7_vxrEF1QN$Wa*;m|928U$*H00!Q&A7#6G-m6XaQ_<~Xm ztP=QK>M-G(34r5GPY^c%)Av3Uvkt`PL)Z3&Z+-LH84SrUNPjw2O-M$AkZNe#<>$1s zEKRRSk?fN2=@1nV)`s3dy8Eg#*!@0^AxEF)TMUo>)@H=9#r}YjlbM8-%*-oO@2IG+ zhey?iTUWM^|6pA*KtMA?H?XmZi-E6h7J!^~;(mA90s+N

    XW0JskfQ^vM2STiOEGzj5AJrw6!Ucje^qxF8RnQ{izZTm^a(HkN0}NQ(u5>qDIT z?gFzU=r&<`n|N8;2?w6e*DX!l^qe-?GHZE|kpBLiK1U2n_#H`5gVNP1!RuXHw9_AV zAQmF4+-WvDIk$4#_jbK>bBARit8guBizta598Y3zhUwph2_!#A*ii=tO#XKkVD|kl zOqD6nULI9MLrg$6UU!ihm5o#l@gv0Ws?A%pE_rJR$wQhJi9CC_%BKW6bop#Z2UX)D&t+eG~zlc?%~ delta 3327 zcmV+RJTgB(1R%^VKOu}RWRNBj>3SAegU8T3adfVPwD@#FoOMTS0mLhmfa(M~J z_~Ic6NoJql{o~9elbJJ*070AbUF)nld;j*?`+MfM_x^wF{rl}Bs>(3{)p9nAb=@aT z!}_ENe2Q=@)l&LNllc2k$Z84Ylvm5Cz!!juqrxW#{yr2EWO1Gn*C&3DDWuo&lAMV$ zo7FPVS6(eez=es_(4)pH3;Mo7;AX(4gHyA}rvoL4`(p~}Rcw^uD6;@irerB~Vak1Z zuXDG8cwDnI(JLTpB5=jajbj=rmqCaJ(sgRqS5 ztE~}Ka0vj5bv5u8V0hZo^NtS5OcbOLN5a2!B>b);;rn}=(2;>y2yf&4v1OTJZULZL zmIHqekh%Z3m};5U%OrhK=m;qThS9yJeTtzjusKJ8GgvB9fC)LuETCGB`V7){r!3*M zoN~i0KvRwq6M-v_B&9;ocNOCDdY%%q5O(J&GmmN+bfhSy!$_!~kAbzDKU^tkgH2~7oF18%2F87}~n{FDKGT_K;O`>5R8O^MnVgK=jpz*eiAs(*4U2hl#UQa$!*2Cay>If zBK;4iO|N18lvP$l8~~*sT|GD(zLtNtEx<_VG~gBBuCzKI0cP47YsvMz6mpc*k?xw8V6JJ@g&R}k*8|_joA+P0aIbq?7rfz1{zaKZ3y*)$f~H(_ z-hWIG7Yk@d*q`HXhy&wUtmzKRP8bP&75F*bqmTg0fw{KE{1+D~IIIz}m(U8}I-pVE z8PLywK0Z+*NkYRw&lU83;2mHv=)ZZ2;%4AwU$^!MF-p8YF_)bP0HIHggeR|$L(7}Sn^l}A`+0y~;%n9!`zs|A0#02pfH`o}Ro zultyxkMfWDON0@3R3q737CWewju>Vc^GP{-4WijrGV;dB_S0aNIC~ zwZKo3c`o`SfMQaEKpkxy_#wb3>=%J{kjI;~{$&7zJPQzKz%Y?3Y>?RsPc&+@86ffd zCxNdfC|3aQYhtc#)cSuv19JqcF(=_waxw4&Us(qSX{8;Qf|AQFb&JUx35k)=kAQlg zvJV4ub8_;*A@4&rYuy&$E6MaYi43){&i0o3R;sa%ZPz8O0RN+PaYw@2LANA@l899( zruZbPLU<$SxiJ#ybY$Ad8=&9x%IkWCxm8m8D;Mr=*7}#5H2QxN^1-DZuLEWpO+^V{ zQ$jzKA|xZQl|<(VF%k*@KLft*Q|>9?8e3yM{??<=5t3Xjbejjq%bg{a5?<&?_$5Pp zH|R>AXVd*fE_4}Bi?~VN7hw+v5csK0{G;RrdKXY360r_);2~gxqO$~j$&v8dDyc0b z?E2H3QVYRCPy&C6RhJ(|Q!POwp<>{-_$%WDV3w`1jsiIO&?pSac)@{WhDgMU6I?6s zJzx~bGC^keJbSPQe3FLwVPHktb^mAxZr3HPhQJp=!@zsMxr#oWF!tHuvXab@ZWr2# z6HjzFH|w+|?wUarz#8BpANfY$B3okzd}IZo&?zfZG3zBRosZ1i2vqRR5*(%BE2wQdj4FhU|ris`r(WQm1+HE>7P%4h0+{!4yF zu6cbQZIn?A*tqn^;!R*ABu31B%hL75Yw(YwYz5A@HTGfdx6F+~M@aIBWmjw(Ya-Bo zB7xl_I;0PN7ZmL_eu2lS8X z?OAf8A4?Ig#pY~aiw^-qD{B+$z8sP2*@}=-^$y-Ox?*p>n|__>3+<#3m?+PHd@%nakOzgi#2Xm40+mp zsB|zNTYepQFK~gavD~Y?0$~A*@Vt?Yj)dnp67Fo&k?`?&n;n35Jl_leg7q9gfcT?T zQhR@sBjH~Q%mDT%n%||71uoW7V0?cD{;^VO{`DZ{MW9rWrHPgw21=FE^^VlkR8sRC za6HIkJ!mF-B(M#aw$8=Nw@p#`Z1&kt&?bJ?8GzH6?n#Tt0Un@ z90~sc*iP4hvxX*(cE$|e*7_F}mMctEbUAj0WG`UhYEXcb5lZ}j_kas+jXhIv zyM<6wRU8SA1eO4o`;=(~>YFtBeZLB-BwT5bL7R!L*CY6i^$3X!7=Sqy;!TaZ@V$S` zcJHcyfOC+K-$?FrdW5Aimi?@yg;0u*%cX^XH@`1mMcldvctVz38zfjULv@;Zuu6@)`EAnifiF;X~aOnCm`Kb`HtU;QTPaT}6v^ znXR#&cY;Eos@<+rm>(R?{QfhTA4q?f<-6c=JDY3<^8+M0Kx*B9z~y#Qrm9Thy90aL z_90)@oUU_u+?18w6sKZmoC?iywVJBIkLn#v?oB=!tA;k>OD)VdwqrgI-UhHzA}5|K zwTZMyGT-~X!cL~ga`I#mk<`3oz1xV-bErLkj6_CnC%z0k_x*UjH)JdmW;lO@&jN5H ze8&Nb|HYBo+1=ZTbmN+uPL~x5BcUR*xWX~_RFvySf#tyQKE?I{cY~?2F4^}V^m5oc zBOc;N%?gE07S=jNuLKcrp9dKVS_Yzmz6(}~qEkV(gT5-rWEXY`S}tfSSg(RQ3OkxK z`edcl-XN$7d;pA66z=Hwe7by%;^v}SRAa8@U!NLr1 zu|{}2^gM-?&D!uvp)YMDG!mGTxQ1mZ_8zbl__3`qZ~rw%swky`#rk}fXAT<~+E&=q ztPM*6s-*TzMc)Dmx>#Fm+%py3sK@|e&jU)SYr!Uk@fP+<7jwR#8x((Qnxbb2vRiRG zKO+;wD6Xxb77|nlSjdp>UBZ3Erf7>0zs~hOIeXKBa>aT`aYqX}!NrPO5O>jHkd4h6 z&8v)rGjIlQBQVqN-4oaf{1A8`!%qB`4!(ipYwK{3K}wL4N~yWkLN)^L2=b9)IxOUL zMb{}(D!AK5Qf{^rpQ3*-&_bSVqrJ5VYo|i7;_kAMr(E!V6%X9H-+8V7~Zd3G>!CWl3YhC1GLH7uf)o)}ZbP{j@ z-lxy!0fVy?eFx7&y9)T7tugD=%nVIgYuBzv$?w&{` z1xa`q92g)VAb4phF_oYC;is5ELHwNSrSZFeDliujX*H;y!w1SN;^!LLQA*nd2nd|> zzXHs8WjpqB6Wdi>%T?9E!qvmr*&N8j!-K)v-p0k$*wLK9!PzqFiVp_}hzLkpOjzxA z_GONTkNV^5%gzk9huO6r$^eY?s%R<^QH@Tsj-*X>b>(0!eoNe!ZErOS(%dowubs{N zQp@sk_gT3c8oIKOklCnAI`9CwSuO9hr=Ndz^k&E=nUDxb_w@=b78}NR1m)gqR<0M=cGyzO)cMy1^ z<*2r=erZxpo6yK9I~=Apd1%wcpCR>@*kK2Qk#7Ib=FQcWBc6;%Sl4WWq8f02c~BiT zune}SdfgUPb+%+(g3s>F#T9d2?f*S7m?lb35M!NWH90}N@T=sgxz(BuZ{XR_BX9EJ z{4OVE2%JZuw%!XqOESLi>Gv(dXfZoEKovxutUR{V`|yNwG#}Yle>f@jf4zY~ud^G( z;4_sl$rC__Z%Sl!QMD$dOuLtJ|Xn)UlkuRYuk0PwanNy7M3~*3}XW(+?9<9XiRwF#3U&i)`qT=#0M8- zz;?xmKdw_?+ye0+3>F|mSk?_*!vZIF(aa**FH7?3yMB|Aq~@x)pdxUb#{KB%K&Khl z+CDT)C+MAq`OY~-LuDpQ*yL(P>dn<*<)k^3K$rNizCxH^#Y$G)2#X>?#85Q$xR*Uhr3BwDq7DU zc7*;XU}pTw%5t}rg#a9`*lvRh7N%{f@f@$Mtb*AtrQ*@!ZQ|z9=3C>+zq}^_qeaTL zq3t$QoFFSzP%_HOD1Z@~l;1cMOOpPLBJ%6dy!a)kW*+CJp}uxEY4D8po4Jj9?Q)rxq3?c@mMzWlk}@3F z0^*PLYdSTAb998B8{e5n1Io{EGOwxk=cWR&Sit#QiRhtsGM&hgdO9*-yVFX;Te6)Y zbs3@oCa34u2w>8dl`zw9cgq9b3w6(Te5_3Jdz=IGl~XoxlF6n3t}AjVi(-j^u<@#o z3Nrg3_>>gA{xOE7WOEJ9^fg=ROxA3}^Xg#t4al|OlTNCjsv(m(D@k9Rc~UY}t_*(` z{A)8+TisJy2aXDtCw<=%Q@0%aC?4{=sq~C>6UB13#f7bq3>HGObLoz+<1P6WDgM{Q zbx&nyny*kbB`_~N{Ihl=^Gr4zV{c@x05&f%Yx1HAnx0_PC`KRMU z6?`Dhb|Qs)I(T|VUV&T6JQ`erIihjCFE6({3xf-q^OYO7iX-2-R|C?IesUV>vkl8} zS*hVoPs6cVc4q_jGt(WgS zcA2IFZH{uU&0792Y#F7e|6|)KZPVWx;tc|d*DJ_T*y96f@Zr*^dTFu5qJ{Oh)K)*u zxTB1}JvYs5gPg1+TrrL3{$uYgY5jY@P}qf1vEfQB;t;)JwaGqC30WLv2-QDBNPqO$ z@t0KH$GE-HDOM^pyXCi3-M<>f)~mM9mi3{`Xq>BMe+~x?S#{^hwV0+J>8KdWC0+y% zoyf7qA~6-jQdOb+`g*>=_;MHTwFxaFywEOr?d8hkXhKm?GF0k1iSuJBs)n zXbl}&tZmq=D*3?^zanmi*EcM-jduVaCc#406;gLjN+TBxA$_oTcH+5$1|zbx?_MI+ zLY8zT03UDjhm(nIjeO<#k&_GgzjjGUr@n?~tvAjse}AENL|yjdLg~6lJ^M-NoPV#K z<18oc1_|?oDc=dkFbfudc3Xz=U$LSbLL=YmcZQFoX1aGr|FQs>&6wo#$9^~xqgHLH zmG$;hu!^gY2~pUyR8@{SPBkQXOfr^P3?CIgqrMv(#|=_;vmIJCOE1PmbLdV6#4aCJ|vG2Y~SXImILr`D3- z-B>!~1jo!B-t#72d>=SqQ-G_B-kzbcunWVGDW9`^#dMzGE~41&5N>Dy_{}A&4Pl;tr)5JbiK&iybnkztRYc zZf-GXtu>U*ciCFNYlfhFvH}AaGOU(%*)^2ZdogR-Y$`S?$B1c@r?Qp8vQL>uqNLmn zS9*K@!vslrRfXTT*1~r9v5Z}yt@R=J+jI%mat->~IN?=p&})D{}+z}{mWts61L4W_zfOTzvgj@}_duS34l zf?dqP4HMa3#zD5u>HXJ0#lZ`-&6S%y_tDlleC>)LdWIeju6yWLg%YxSEA3b!-`$`z zaH~P$BoXqf&W~t<{}U~?A}lqop{KRDjl(!cIkzs5{TO(;W8{Fdra*|&*|ZIunQ;V-0ISoR3 zj);3*sv)A}scf;XLI2iw0VwqaPSz)w{&uQmNE7Wxts_I6nCHCkg9D0QvQO3(^>bLG z2G|m_QYG`e$rRT_3W(j4;XRTMMQ`j_A)~}}Yajw-$;e&$kZY`Z1S@X2k3ER16z{9% zI%;jO*fIS9r7LdoTlP#KW*fXt?Gy>d?KYdsSeOU?N_4GHZlCd(sV{t~FA9xA&);;n z{8o|I@UlKfLgY8SLcxE&?p`ttvQ3W%RvtEN{7I8WQq+&mNgq)v?2SN@4&h)PrG4%Y zHz5u7BKtiLZM)M050idDViOVIuuDU-P5r8tO{wzD?R^m(e<@Mm+9el$QoSBKYARj% z&EUX8omo*D~-;kWpPHg3`DfU%Z!S4GB?}a1l1Kro&XKRGPl+scun$ow` zCtCWZiy#p5JnQ5Y;?Fn2KOv7&g)O{!mD9HRNA%B;T5`P^1Z%qLE7J^uww$?DcZ*a6 zUDu(FFIOk^#q{hyf3%X za8@PFt&b5{SLNz~{+NX(Y-h~<7}KI@6}wcf8yqr$@5J51>9^wf6M6dF!)byahe6Ws0&wpO%fz zj{SZ>gY$-S2{QIs{yvqh#)ZnPK3w+}u5+=aO&66gWkKCat*1z`gJk3D%XlNL z`q`R(cJ1o*ANl7WhFMZ7%qlx)v3u4z2(V=5jaBzCTWlOm5i7C8iakb}hPxn&UsLbh(|gZ+Up|Utbb9XP$WRY z%BgFOBr=9RfW}Ouw9e0GbGqGL;$wb^H%o~({Vh^T5fTJv3)g`&U##q=R~Odr*>Y=T zL0abcY|I19z*LU}APa~`~p)>IM+3nNRIC2Jb z6KE3x?ouKdW0ynqvzIr~XP@6Sn?PLsF?P@AXldbMmd3F87SNs~Z;K(wJM>q8HRr>apU6T^6Y-niNnqm=M+F+vSy$)6 zr=AQ_Q5EIc9E*pljPG}|?n9mTMRyhk!{B@nO`^JKHDruumvPch@C`pQL#iMd@lqghjE?wQoKQW7#br8bV? zKC0l3C6iLDWD0NeyHVO=SKUC-D~F~U-kh@%p-z`gR>U1+yPBfNrcd=otEOMWfv0To z!bq|o!Fo9dD>IIe0D@n(0@eQ8ELnE&07w5xYTgY@J7&0ybhIQwFN}FeW=|CznC!Exi)sQ|347Fj zk_d5QbV-Rxb0CF4!LHe?^*N==j5OIQ!QkFO-@e<5&}yutuY#QX&$7b8MXK4k7owN& z_TIKc{EwGdfY1gS0$Fdxw7{fWReT?rP6_^CnOAJ%SJC}9U%DVYKYv1<->$&5?It}1V~xJh$X)`A+0s-`(5 zQ-?FCxo2mc?sfsOaWPukvy6gGhlQ0)P5~!E@l6*9wolhN&YZyxXcwp)Ur@ONuw}+s z?M0;XQ1hmfS4vjid}rQwZ2AH!f)D%k6zGjf27VPIfLm_%SJdGSR##tN-+9x8PxN!t z{pdQYETyiWLxb`{6qb85n67R2rWKi~k<=BZ2cm(RU07;^fEtzR{7jyt4Ma}c{_<=6h)6@v~56lHhI?;8+g@0i}I!D+xx3Yt+dDg9LK7Y^e_3eDkJcQ&Y{ zCx>qZ7@)PzQVgFpzFKlVUTcpm7Q`+;Mzu*x$L|&s9u}d;c#slS@N*jm$ zWcAz%YMjm`jPaQRwgcDm`+j-8SI^WQ*T$VT5NmrGXi0z9VmTyUjD5G>`d}d3S0ll& zh4?cT0kl`3W5u?b2Zh;677e&FCR+{P`n;!w34OUfcJKikZc6zsoti>8p-jkO^_6_{=l_mFRgNOEsP zln}Z)24^+UMzUa}=6;aR;tt98Qk4R>wO}6LU1q@%U#;%l5qlo@C;7=0{|7+>i&AoZ zLX^?l*3`ap`1MPzep2$2w!4h$Gs3fE{3}I>E^$;E6a~vHgpzf89*yEM*WT%^bm0q$7-8a`>yq_psW9%;L{!5dP$}#n7@*5R6wL@%cZfx zI9&-m3r>qy|B@A#vX(jfw~>36*)}b25Vsg9$%d^ailVMzZSZF{E!EB7>^@gZYvpi7 z^+(z`vd5EhHvJu!#=>@N=R=SAdOm5p)S9q~oUx0%CN?4_lEmspf2sQO)r)V#-SJ-} z#`8Gtt;zaUpAq#ATfI_c$pU4ywsKRJhDA@!;&(DN+Fsu zL#2=pu0BoFIbdOFjk@tL&_5m3s5!I52IM6Z4I+~8|=%58&d%VUgH-Yhw!9wiJL=G z0w%QzX65$z;uawyRXlZyWeWCgzQjjIH9y-Hx)gNp94_YV?&EjpDCA|^bD%Oq|EVH~B zJNdDHHzgD*1;wnjFZ^Ooxpc?oK#y8ClR?Esp}=h9)=!!M+(TTt3y!WQ8%r4cV*R5c z$s)aEFo=nC47X1!sUslkvk+j8m&4Qwf=TFL9Og$gdteqQDeW)1hr0!Jh0)fkb?ok) zt430ihjut4MAynLDnx+ZJ^2)2Zsjq@rd z%f&eiwm;cX!;lB{4TZviZ?RS%<`3y}LvxDH@S~iq4)GsF*4-M7ml)p+su7_kqviu^ z>xAN|Ob4W)k6#uE`7OGAdC5l7VWFL0D!mGq_9bzV243B4nNWALEl;3ia6-Qbb1s0i z6-piZ-a-u!a&E)k+=Oepi&R!lH^cXO@Ne)3jv1prcn*F->V;AIo3AnAZg;GfQAWK18v$kYItfk1dQXwMA*rHZ6OIutJ znpf61g;4#R!8hMDEj5IGkkV$tdr{~di3YEM%%C65$max=-3WEkmf{Rk_oAJ4#LgF= z+X?i6e`xIsx?f?EWY{uBX`ONBK@}# z>P95Z{q-RO0yyx9?^9?r#YB89o?`olH@~({ypmF|_LEq|LCJ~|2N`&igx&0=YhkSK zvX7{RRji1_b)*o~Rw&X@%ZPS*n$C?|$$LV%I*a2p7hd7ib7VaQf_?LJ3lKv{uKje#?)?bp$)a+@?@g@+9W!_rg$mh=Qwvv;&$r?w_;opy zd)|{MP%uD~NM;~@OZ5PcEF6rWjR%3DG6+0~<Gf_{LQ7BYKjngV4%ga$ zXI3!vZTk2xpNl8k$;i$zWLzp@P1 z3!kgb{)G}Ty53wMUWQ^DMNij`DA(YdIZCdZi8DrbY$f&gK$@W27ESMvG6~W=8~=44 zX=^FCAXet&-kfAM;u$#0*XTx%U{eq@MLY(Dm{;|_XwD=G&jqa;ulmq;KTPEvSe1?203q&@JOSn4TMP@Wn=f@#a_M zfnHThYf^l7%V&^gw@Ao21mj?&CVq15##Yn}c`ZM=Hg`?GspzV~5#Ze2TBCJLpm#5^ z{%VI2b5_pQ7~SrRGHnrvK)n$9snWTHoYq?&-_535gP&}lQwaIX+9KZWU|x}FO=g5% z7WG$E&K`uOuu)L=U#|_lit{S&>~YBuGI-35v8B^~9MjV{i}yQic!?v5Ru3L*X`3?^ zT}7Ao;52wA98p;xh#R7t5>u)xoZW@X_`*}0H+jTvW&cg3QdmRkl~CAm*S!?{sT@Sf z^P=lS(^`7MVsqT*i94Yalt??GylWBbYWJZ+uyKvx59xO%&ovW`YGk3uEu`*Q#}n1ZweLY_>c0=cbsIm@OR0Il4(VxCsnd35Iv~SyJFyBs5s#`K6^C{i=Qsk7p;uLfk4v?g5nq(K z73Ab6Q@dn2bSm9}dH}HK*w1KKHEQ5G(v6vrjK$;;KS6ta)abTxdcHgJx6K}?O;pV=g|p%)vuA*X+tH~t-bC34Dw2XuoBKBoLT?t+ z9OyCS3bDSEfa0nDdT21o4I7rB9=u#z)0<7+m6pS`JCrRtnui&$TeD##UZK*c4U@Jc z<&B|kVeD$PZ7t4gB|GR_Sa?oJNU-Jz;bmJqrKs*BFMZQ|R^#^$-X?G!c?)1pE9#p= zxF+dRN%-5R-?yf}M&|)39N!9ZkUjxtwErtB zRj~eYZBM}Rlgvi>uEy8vU3*E*%32o*ohJbLWXV~s-*TxYZbj5DAJB5~cr$koeL%_< zHZzC(YP9p<_!bgAwN*RqF2C1z-k(60- zVVyitX;?Qa+{Ia3uESiXVLFYWcL~JKBM2wz`v;lm+&k>ilSj)bA}4`7_FGWK^Qqm8 zK1FQk+7rBmjPI!ZCT7i`X~(7GKRwfY0SqT%tw}T+^yn>Vw9pxoCc4s0RqqHl#Z!4s5LO)`Vcu(Fz> zpw%hZmzB>g^7dEdMB;h7sb}k3V6LwJ?Kw*5MIG4g5)lV7rq-XXY02OVC$Yz$}ni?^ym~Ji#n!dZ)rF zOJ4})wSM5)l0a)ry_U1i&o}i*UozGb{9W&_yYtrRFc6Csn@YVImuY#i2HZGS?Tqk~ zf}h9HYt`$AxSX#GHc)IX!^ymNpyCf!oY5Hh7juFWrEa7lJRis;cVb=+ad6}CH+f(I zp;j6`&IZ}@xys);W_bVd*l$nZ4ZVp&q2^bjD{&ChjY5|`O%e~Ogm-Nw()3744eX2! zj5IPMl*WI9MeHep7t|h_Nez=uPgq6CRIuUFuFQJEPFdDUs~&{HCWlJ}3wiYE>n2@j zzn&bkol!7-Uat1}JuPR@b;6Nq;O1nxb^$!iwq)p@U9oiFLpS?ZB~zEKg!4J1@Q;>^ zejlYtm;Lo6C{V1_N(L)rjVxyNT-NF+%SSHw@C z8`<4Y6Y9&m@Oki+S&e>lc{;@ibVx?DNbXI(QH3g6t44pE7{4ZOI3wDu9n$e;0Es5X z*fTG`!yl}7y>*^4Z`QZ&0m<+hH-$jDe~Zs4D8Cxp2m4kR+{WG+5wGU%m*pBbV>-%P zmJX`rwg)pO8_P)}AOA^lE>j;!Id?+aZVt?zL4XtxU4==gtT=xU6C1S*C%gl(v?WsVky&=c=qKm8(c#OMBLhM^uq?K^1koIr*1TY zzcYD=a=6E1IX|Ewhi*qJ$0x#VGUp(qj>;Q|Z{VeoOwW%MumM(z>|K(e+&Z{-Bzmyj zHWI}qGHYbFd#U|64q$8TrJEoP(WP<{`~#+vleml!qZRPO9WJb<8FBheg7n&4;V~Un zg;klPjD!#fi^=QkhpAsw*Q?6yfsWJ9c5p~LQDHRelMx`+^V&^8T0sn{Qh&@Ba@^H8 z4X4+H8Xt-d#N@H=n`$AnJ{5SJn@w&8=-CIs152uaZj_1nTN+Y^LOA|mvfv=#la;B4 zc>XtyPm$I!d&;T4U9x%{Q`tA5MVG-NrT#RQOAL#rkrc{kD*GqM{(Wyf769tQ+4{zjtzcx9{L1HDFY1*Y_*71~F%q9Q2Xj3+5yWU z|E?F4`39k@XKsPj0rTQ$;wRNkNWY4I6KPuKJmCMawnkxYq`bEq`Hvjz|2-e$)8V9rTl? zuq`1DCKxWzh|@Hlf$!AQ0W6zYrBaVxT{;)cy^9*2Q8x%@{qvEm#`UH;;6T}>+r!_E zc5W!srvaaEEA&VLIW0R@7)-MDk;bQQ8rZnJn>pr#Ab~TEqgG;z+}@`XC@#HWe7)kB zAMgLhcUpf&CgvdGx~^oFJ{V$G(3EG&Tz9P8LClxi7GEG@qNSxS9SL!Ed`8N?m;RDK z_0uI@@id-MB7;FMrV+W2H)t1_0ptqEFZ_VxnWh8dcx1wL?^B$CwTx4;HjU% zP(`~CY6w&_$PHIR`HH*sfK)Gj?WOoLiCOKv{bbt!IMsFCQw0hVqxCEua#q+`v0d&= zrCw&kGgMDIqq+t6-f={}DS(gSs6{$AkJ3$b)qe5Fiw-$2>jkm7X=Txo^@8at5HtC4DKjfD76rhS*6jpFVdA|5vNu1=w-W69RKf~7@Jr7 zoE^MJKe%)OAY5*x8jtErx@(gRUR5N-fI$1xN%<=-?F1AezQ@_5j_1Oa7+#Sd$jiPd z8{(#_1-k);1k=#Pinm_^uXV%dRq3Zu#dQwy+%_);tNAiVt(?Hftn z!?x>=S7MvCoCyq^CepYvRl#U5Fxe{*%Uk%NqY%OR$DD$oqW=0rNfg$r^}%<>7{oUr z!pI+1vYzD@YTkAz0cAvA|)EgJQNDD_3J51uQkc5_iUe9ZcEwyEBO^|q693HTCKF7S z8P3-wdt@8@MahHqK{#<8&ULT3;bEFl`}WQOM**N2 z;WO!}n|jIcV@Dvi$D@)Y!nLV4@8IXn|8!5bpBb_zC71B32Ru3R?0VT4q+*?lgf zKqOg-j~+Efco8FGPxQlg6cQ6a0vJ3pE^CU#S@I8}?BqG|`F|wlq92R*ahJZ$T+}d0 z-nwYQrT9S&L^~&>_q};=ZcIMr_m)@mrl8h=}BG9}`cj z7U;`zGl6P->(>l-XeMw>pnP|wMZCF^aRccG|xJbwuU_LA=J(i|; z7?=Z29gYxjD{_t(OPI*!f5=G6fKJ55-?A&N2C(;B&8OI)Uot9E#pg3%`KU=EE7no8 zHQG@|()YR5>ElB>;Vid31maYKf2s3x;fz8mC@=X(N{Nv9X%xq8kQg(Jtckf0+#sr7 zDkmAp`iybmiuHhHizDWmVi+S%`vpQOsC^sw_Sa7rxHw{5Ryv`fwMI#C#2H!aSz$Da z7gOC`xZ(A8ON*86|2}>poeqo1;o`rpbqp(W0GjxTW)Vu?Fe3rr+1!hSjyhLaPN{+h z5Lc*xxr#Sf~;fKJ&bnugO9f8^(8x^X@N@;Bh^D~ z9EJE#>fPAUM%_R~@xL3v3-{AN0ug-Pcx{Ej*C!BufsK)cz-58dFX`l;EUZc&*w+`T68135#KJAs?JJVkShZNyspRVbfJE3D+7!;b` zrw)?oo9_dMxn6WfvESCM-v11N5XHA75%qNgN&x3DJnnUZ=#s<_;iKJ%Beeg#`vlah zBVgWhD+t)|^%_!{#d@OAAN8FBtq6^1Nv)eA zMs51QNgA*$%^Lac?8s>R2&Ol`iRwRE{~mHZ4(!HITb$4-!@; zO8VZgjzE7ymucn(v3g9rwjq&t98{GEAbdnj=LqA`bS>0<;I%Q&OYtM}5o(KYFvbW79O8r6HTMS#AoyIQ=YvKqF|--gKj z+4(Wis+Vn=&$&`SPf}yz2qvxm$OuH@jH_%Qu)(Y=CYIxLfXx+^lO8cDva78A*%R@> zoT!OEUH7}TLVz%%@{7RIfFL@}k!{(t@10BVDp(KJM?-xl9?BY6VP@&{wh55?=#w3` zUn1qH&lS|gsIn|u*fXKs*Q7B1>_UV(QV#}rv6TEPn6~;gyMd%l*#l>pnH0aEM7Aea z8~0|`3Pqd^;f*~lWrAJzvsisA@Oj@GcLnosB3|4*5>a;Q)7V4U#xRe&1=&SH!l8iZ zOghb?Ah~g<;^ghyce7Y=-}C%36DFnH2{4>7K2b%yy=)Rc(cbjTXs||OQdG| zEii0}b4fgz2EwYlsUE&6I-zOp!tMBBwSV!)!S4Pnu^##Xsee{ST>QNydqbE7Oyok4 zxVWmrM~_b7{VHzRy*P)kG<<39v&BQi!R8uVgTb@o<#Kr)L_k(r8WA(2jUz&gOTI={ zZ+1MMVRgilfg4f2!e=x6fL9jiCjG#Y3@isUWr>^d+}LF|Hr6ODnFH#2hhD$AO-Kf| zN0kZuam%j%X|`;VI78pSt6!qSHgY*BxbJsX|1g8dm+!NbxuuZGK%<`@kbtDc6~t;p HjDr3T_Mt|{ delta 3750 zcmV;X4q5TjX}%pHiBL{Q4GJ0x0000DNk~Le0001F0000f2nGNE0K+7V=8+*93j!nn z00JZd6RUM)kwzzf4m(LiK~#90<(qkYROPwHzt5bR$(|6BoFpVH$xPS<6tGqWaY1nb zOM692)oQgBueViPS{0HA@ygX+t+nl~wN|UP+KaoWxLXt#R#ym15|)Gr10fs9Br|i) zbN@IK4N2gJ5SkW#pU-^e%)30#bI$KP=Y5{%yd$d0u?7);@!oVbyB>Rvm3#IwP5+55 zf~&6$=p)#fCXwNJOqex;$NJis_Bg5u5fP)Sc2$k!<j8!rXc-tIMi-pJ#`JK4@?UhmqSjfVlJtUhj#2eQER2O~@O%ddtVM){eN{E?Yu5 z`JR+($U9w--6AsJ$&fuaqyI*G0;%CIpy_^2YZw)YduoVCR$tkCR1*Tw@Q7ZMc1L!V z>+Tuhm)55ThsyA#^GVUMF7Jo$Y$q|Uv9{$qgjtSYLC%HTyG$yhwk)V4xSw<;Mp#d@?e3IM9jThH5 zePM662=Pl{v0n;X{8G5%NE>t{aM@a2y(^>UwOQVE)^!{gzK5?2(E_fp2Pgct(HgfV zXQgK*mbD4D{e{NZv%>>*l3|?Q7q)iSL)<`rO!V_FiOL%L!QIke8C0s0uFGi(WyuMx z*I1d}H}^E8CsS&iNSf;zsw_7{A{XgE^~K6N|7bgp`bSn9ZmQAs+eX&C5)-%5djqL< zIWa8NaL{0sb$vLi^)GQ7vd%(e8}Y_U;_%rcgHtTm7!ip*QZ`v)4z|R+z!LK|OU&DU zEip$QGlT$KzE*#haQg1RFnLeskgd;AU z@rf+yO&csR(=0J>vBWF~wgQE~=fEOE1799fgaE9m;1@Mn)$ZfiDi`5%J;UDcn~0>h z4vI{22R(R~rPk12$_SDh84{i*?&ErY!%HkNPqM^(9M}Qe0}R3;<77hvuNWFoIEEfs zZ743)H#TLqF7u|A>nZGuj3ZC}#Mai$nzPrh*-UfqjUDHan3t)vTFG~x7EF?SH>-N8 z&k{4&67x0SBj7Teb+`hUWN6?{LjzX(@y8q?0PA-1v+|Vfk$66LPb0=iAjkWEn!UBj zqhljOTXLA<{V-#zQJ1)mNZ5|}j7wu;azrHIQ1w`1{t);QIHz6nv%ok*10Q!a=a?kq zw^drxbeTPC_sosVaBAmv?lg>1=>jBf2`%}QlK zcja4RW?Evt2>cmHY1j2fV3whOfyM*PJtheOxO$R+MY;_Re~X#tQaG8~c;4=64r=`k3#Q zWVL=4Ut8gs9vUrMBBNS=w@Q6{g_u&%kge{Njp^@`T0gTj(=#Et@h%a0qT@SwOH2>& zIB-b^@e0f_H1JS&?KvzD@yYyKUAT6FJO}nWO~h^*DupAyu_m%A4(s14iL3{fT13ix zQh2Rj7Wi9;R0%w5V0>O6#qAe8{8IFv7LjsA77LMWekuI%{{4l2_qfnc1$olIDD}(y zN87)AIuxwlq0Ob1{X$dHW{-#M#%S#yS}g(nQqeFYWN>qu)b?MU9M&NW55~tHKbZaA zK3ZbN1255;41k*tg$y_hLh_|}svwJi*A%%5cmc?^p?Lq1dMD5VawkwHPz;eL#7T-u zfL6tx*EZTOMVEko-VUr2Bfxar>St){tMVxo+MkSY9+$ga(qvk0JD3!@Vj>r}&9lTz1>ORtbs_d{Lj(66 zsx3Vx#Dz5j2n@tMy<8VQQl=#{1zrIrw;!j_-@<)%nJz4U6!dx^Qz2Bw#_?rZQl#)3 zV8S=!^;+PQfw;$Q)`btZ(sTjnc9%mA3a1Fv_9HN>Oc(w+7xzqHkHQ%}Jr`BAYIE!b zuB>f3kgfJi+iZ+THXCTr3Vhn!kS%5DYvY4u#Eq3(5=O}FY2pz2a+};r zy)UT9+aMQ4WyC1N)|1u`;9V__*l=nr?)g1E7l66Tb#ZlSaC3}N#zYM^pX?c6zbqSM zh1%2yGc~IwY($dXF}|?JyCorQ6z~Bsx(iV+0zc`0sU6*2)H^+&%k|D@+m46H{2UvZ zrcS8m-G8LLtL?~w9WFqzzxt+M8vq(e^mqsjjH(M1$o!MOQSPb%%@z^yQMeW~UNKhr zWd8kecpk3Ml8xOwkAq@$95+rKv3rSZTIIc&Nv%6%NZg0IT?dmT!}plln!hVHxjHE^ zC+J##M(0Qh9FMuAWA=S0=&pyfB{wbY8+}qVr$CBIEu>1}VPIm%i3+Yb;2|j5gGLb6f%-aJP-tb?g;lS^>(mWR6dYpBC)ffinc|$Y)+F@L%26 z)ivI%V|IK-@V$hcThcRJ$<_!v+gPQQI!ba~1L~4p23=n7O~5&Z2I>!2e|HHnqu*bD z6C&u1z#0qpsav$T1)xBRrYPFu+{VDJvT-5E^W|Ey;$UOTb-~-f+XYheZAG6Fg~yr;9B2rB@dmL#p+Q$N^>&W zh6aGM3=MQjTzd+aUkWD!JN#1kE58)>>tf7}Kwk9tV}Lb06agZF4sRRemwBUqf$stg z;f@}?>aEn`y};YRbz|k01b`e_5HHAF0M*5oA_nLTzsw)lHc!zpI91hN!*%=mU9vU5 zCX^eu${jj487n7?L0|30sNP9^j2DHkfU^w^Z0b$DZeS5kjs6DUQoj`bH}Eb_v~(eG zeRS+z;7I^gRi6~TC&(p!DQpCPsR!4Uf|M&d+zW}&^~3i6gTk)`mNXH&%qN9Q;*i-2 z{WZGdFlxg*kTrfOdKB#OAZOwvi@gF%%!#Mrd63f7yd|fNCue8@i4FU(maky0D~Whp zR{}E)4OI7*&NjG!>A=&`-|0Bd;T6F9I49`=nt)5ov}8})M8&=Zs0Dt1>SWfs1oQ#` zi%_R%tGg)Il9zE3$T0$Ufch0JF4vM*qy3u|nFAy_(U(jSc(j~54>>FD2usYAXo2u! z-~@n-?O)-q+sD7J+Q3pmY_P*00h5me8358&C-Y0;c;ISaJa8NkixaXg0q!l+lJy-Y z50o3@;z%505GgCwyJ~uW)36*_5Fd{62SiTzE%@2yfV?i)s&7pC#t^ zf%||?yB1qeVi9W!b*0M*zon{k4_DuTApb;v9_kZVVon6^0y_O=p&eca7P{FT0d7;( znMcZ=qk8xIfnbRli&LGwj&^ml4zPjeaCU>N1*euSB2`Dyw*5SRL_}_g9@eYsqwU(y zRn?^j6(o`g#H#AH1N1))`~Wx&$WYZMqwT|SGW0E~S|K9;0rUqxRMoe7erlaziJ1pn z3;c+#OCJDX;0c^+ZKnuIMEa?APFi~l9X%u#XF;nKk=Z!W*IwXa5!nX}#aZy@0AJt~ z5;p^5aduMdiq30)TWobNhqKu$2S~AerMuDcJ1*n zFcP>3Cn4Py)%iM3P3?P8St&R-L}Pn0EHUGvww@dP6dd5(EnpS!T2%I`!zl{(7P|6~ zDL5CqwOxBQj^~&-kyl%)`cs^X9v}Vf#UW=HPO&WmsO})=dEgYl4@7Xhu)VGy0Q+#r zuZ`;5iQ`3WOL6k1zu|aEE$!}jOH2Vq;CS0wU<;6nbE7p!KTSAZ|DK_N!;a2+8{LYs zL_}0oMZ~45cC_ts;CWST>@e0)RV#Y@_4qDiem$;>KDVky4kqJZvj3Iwf9`pr;@7~> QW&i*H07*qoM6N<$g71YAvH$=8 From b41181b6c025771c7de646bb969238adc3677904 Mon Sep 17 00:00:00 2001 From: felixk Date: Tue, 15 Mar 2011 19:27:08 +0000 Subject: [PATCH 275/541] Add jsieve logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1081913 13f79535-47bb-0310-9956-ffa450edef68 --- .../resources/images/logos/james-jsieve-logo.gif | Bin 0 -> 7014 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-jsieve-logo.gif diff --git a/maven-skin/src/main/resources/images/logos/james-jsieve-logo.gif b/maven-skin/src/main/resources/images/logos/james-jsieve-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..9c7e34fa6758ff3605e782501deea7c7c18de0a7 GIT binary patch literal 7014 zcmWlcdpOe#8^?c#&1N>+un9(Y#oTHp$l&(L^^Gj=g{`~o}urSYJdH#I*G>4a&LX!LQ=jUs+ z)bEqkstTIVVh;TI(f@O8ZEfXGYj*mdh1ukgV{1#lKmJ)=TlzAjwRO9t?Fo?tX@r%Z%Zpz>|DF`bTbPe{Z0){U{pt5Y&DE<_Oy)kXzYa$1 zpM3Rd<>&8j-+x?gtS&uQ)ZTn+dV1<j_ZgXHnOwUS$5 z%5qF)8D+V|?aF8sIbCICHox%fIc6T3ve`=B0LMY6#igbv;tO(g*EX! zrKIB1Pi#lWRiF*@@2TV(@S1ub_wD9nO5JKT*O%cG+^^6V=BRY{^uK=dcDsRr?)Fxb zRw<&czOsc%;&8@&85x5`@$$-b+CLidtu6RS0D$c?WhHj~7wwO97O;M5xkYP-fq62( zL4Woa#9mqf?_qG|2cO)3cAeKX9WP`E%4=mRkI#u2SJrV&`4QgJI^ApM>1jrV$n;c` zTMyJ9Mkn^d97CzT5+K!4T3LT<1l{3AnYOe+dJe_7DiXP3bk^6XpVN7oFu1!#K=(nl ztTQql7YrR6tYwGw-(?XB8%~x)4gF5;+eBK zjx-L9d-TK2_vL7uP{74>*(_pD%HLy-;ILKz18+OYU%L>V26QRmX$Hd7qYI^oc>ks# zfq#0vx4}O~7OO(KtZX^}60l3$EZyxQdyG;2xCo3pUy6hSgFG5NS!H=KH^s5e{Gam? z<18k@Z04>uWGw;uh?b&rU}2aFC-khFsjC9kmWG_qnr6ACpZA-c&mgoLaAC+Soe!a8 zfdKns6_;9fVu&QJIIgH|9*R+KX~A0_m#TeV6HEgD#LQc$jcl1gMmK8Ycy(bk@BkFe z_Z_RkZ%YuqH=R-D>DS)(?Zmj?yZI2J*+PGmzvZa}lF_t|voCtN8p=pAG}Sl8D&}#| zqbSt4?xqKsYG{o-b3P2sWs=q)!g@BBizRhW4C-8{Io(^jYXJ zvit~#H{fn8(9C|)iC>>hx0fa4?cqX0<7^&!Sqh1Ob_Dd2)eXuWB>j7;da$s0Bo_ex z^(8Uei5dg;(pW=!0o2sxYjWZO4*}JOtkM^U+{RZLHE}cik9e)V9a{+Ao3>5*%CYfL zkb=X@835;Prb(94j`=PZ*LM>lV(AhIs7HSa60}+ZAK^S-av}6a)9_#$hR z#(|3_osHT0oiS3jqNj{UvVsp5-CNCAfQwQj+kZbllii4x$7-{u>pm>T&{QPUM66vp z5c`^VRJfL=sdS$`fqF9UejYCsx!;d^rgpGi-$i~?-?)mIK>HbCi+qAtw1Uw6*3V5kag66HWq?(5aT}d+Mk9aI=h=5#E^F&~ z1ILqb;agZ5A0r-v(8xw9wPiqtf2*|#{n=D;oDsH+*sML9lloQ9AgBtU?h+yy*hc{- zrND2`s7ar$1!kJD>p+$upy;3+mLq^3a@e|-65_f9_C}5-9b-efB9|acv#EAO8vu0K za4OdbhhS{(2A&}upm~=%DgkxD?bx0U6@hX1(SJa+4F(cT9Fcl4jkT5XJIf@kJ>vXC zc*JBrtVx=!oXJUc+a6>x;C zPt4CgYnSZbr>tBFo@fB&IP|C5b2s@Uzgc3oyemaa#gGsk^Ll?r;A7~~HA7brpu=r# zGN4ReSo>ds!jFcoj?0e}(LbrEFySzDyMvTnp&_76YKGR_0HJ!WfBLD=_+2M7so=YfWRlRQ!CUrMQ${11`owPB)zEaV z?XkK%qvk{qlenCKI=Nt4%ak~HCcI3$EN5QFyfkZe-R0TAMF7~(1Yrw4{4!=KV}DgC zcHEC4>?uT94Wp;Kt`R}yzp+>Y9ac@2WB=>RYOzm#ZBB`a3 zobwKmuNo%cv3tIl*e=-dAm%0>{2Sanxt9Ib?q#Z#D!n}f9krg5^? zlPDb_hF=EJF^8znB7MEutpzg&zb$xy02i%F;!Or&`${$GQGvJK9;r9Ak|M!qsp0>6 ze!0sW5Z@pm-RD5kJ3X6J(lE6b<3vj(Rza|l0iBQpjJ)Utg4LQMxc-6t>U7~1+3&hZ zn(RluzIu`H@*CiUr~k-w3--~58QCh~i|yMgF&3|{=ARsY>E_h=Jj;XgkxKPt;0*?h z#5|uUv7Fs_CZF9wAwyC$JqfB(xWj=7(_ZFD=w%*OLYO0U0UJQ^)otQ39 z`CV!Eo;p=ex8?inys9dXIb2ZzyQuU@AK$=H;&cKn%mN#UtHxa?Ci24t4$C&ZmPe0Pxn1E@KvyO&sc!0wPWH3XEL8#mu37 zx)}-~+}?;*Nwo>W=7YsY&@^*R;O#Owp8NEo-PDVVj;V2&PrJB^VN!jQ``0bBv!8x0 zoOcq;-@5L-1~5zVK_YM*6(9hu6AmP#L;|J$d-s$+MzXQldgdXaPD)zrYYRKyXE2b5 zGTbg*#@nlp3i$33zNOL+o07(UlyI~nR~zlKZ;LOHBEO6leQ`}#Rj=Ng9*pne$Su=l zv`8R55EwjWF={iLSAKw}UxHfd*0g13C6r{9-En>*pV$|X z?1Ch2^g|sh$;wQ~I#II2nMzdq4yzCC$0Ja39O>Y=++sDLCIExtle8siR=|l`1*QY) z$Ts2rpk7E@1lZ8s)CyJV`}Vs#LMSRsq~b?F#aG`It}lYRY|`4u7jRe;Zz++MW#X-d z<;WxZwUN{JODy{Kp%v;-aIvqufR}!pH(qk4_i^fp8J-I%W{c2&!Ycn%B&ww)i~|5V zbcjI1NE|V*wLlyKlc54M$_Rx*r#(xQ^iCg^%8$|0~OJ$ED)k`qD)C(Z|YQ<@ z=|&V-X3*^k$hPWAo}hBj6>?JKX;5J@3GNw{t7F3y8ngw09nPYM`cQrE;iTev>b4+0lEDJ5JVx-L8di0{c|$1grqyLuhAy>A>j!86!0O^kGE3nP zTJC`hMTc6v3AyrM8HVpdhklmVSV9=j-4s5T`~*r6W!z7IXw-O9F0O!nrK%P#TqfOL zE)*K*IrGrF?xBJLIM)xJabR8Zp_jP=;dR!i1~>Eo+wR7}ntZ@fvlCj=RDx%?U;r=e zA_E$nAT#N}b3?eE)Uaa;Yr$<0*T5Y5`iIlF$Sa?+Dcu3( zLqmm2H11)t;&VUrtuj=`i!z=dj?QWraZOMcc4k0|s+ zVF;5|Q@sZ#%Tpd9>%I^e4b1rj-3A9&pukFKO+5)PrAHm~A{$Adu|&O-VR{rc^j7h| zhiuS|g~>*+D$Uhebm!!CFxB|(O>?X|0PAhNV5AaKWTmkWZn-#ta@fPM^{-~~qo3SH zHyuK4$Uf%4ZQFSrJxulYF%~>K#MHTlHU3WnS*0K9H#}1TH*u{*Ww+s$+e_5T&+B1| zMCET0sKG5EBk-0Fq(fe%zj}={Rtk%O`?FK~f9@x%eJIBWK{e7}4cfa5QEfj~P$6Y) zj>t78|FY)^bkW7wUx$u4NzVsiCX+V@T3x2kac?; z`}RTie%m0Rcv3Nsl&tg>x{?e(%mKsnpD24h35}&FttOtJWh%3v23{|QdiZ0|zz+66 zV9pLrWMETyBsUv<`Zn8CL1Yhz0!Y{phK+CF`G%wFmfPB$k_dOATIDW*gZJ^Nbd*Q* zvrMs^R4nw)=x}kU_NhZP$C?#ZbailGNIL!2mr-j?=Oj~Bd@!R+>Jv);<8!BN9j{)X z6IS61t!3N!mnV;-H#70~M4}m>;2HkbULPRXWhlh61|zKJh#&UUZ!NV(QG(_2M1{Gm zrZp4lMdH+L{MK6rl1*oQh+lvZi|o$r2w+5qm^qbNf*5r@^v~66nZ;f0$wlP%==a8` zq$lBoDbd1ahH;k$pAwOjS5*OgtGM zuS~L#fFx=>-|^Zn0@}hnyTb$pXNd#Z9Y^MRH)iZ`I*cB8FamAEqzM3&jo`~n2(J^P zcB1~@k~yhBVH5SK^In^2JE=PM9isAM@VS8Ep( zYp!vse;tA;k z({hDP*undbUpJ$??QXN%@ln5(j#I!~SK?OW(~v-ABJ`|{d;dL&n#R8vYzdbJKx6>S z{rcHn#eX1VhtgQro-p&+ zUH#K}7d_hX)rYxXUGA*tLp~g{`ws5zi9W~YnkFU*hkL|M#jEWh)Z7X5eVLajpJ(mA zT>#STSv~s(a_8NIrZi|MQ2W&mikxvF(1tM(Ko|OCvW39?B;cQgMW)2L=i~D;&R^>% zQaz|%@1jtBcf?*pR19eYNrF`ByxUobd<#w)gSkOVoEX zYWoy_`RWS4a{BB%{io3my=LE{Roa?zf2-u6qgL790+yh#gWNUy$g0xg^4|x}jqRsx z@0z0CIxi#0)Y&U5z~&_uGSIjUf$2dng;~VY z8b+oZQco&SqNt;jewND|l7+PV@|F?%H=wL-C~X-L!<}*&*t(W4+G%$}I+HnSyFa>S zA8;=*^dD<*zP($FajXmiU2%R#OO=gE$-Bal@1Pzbw zml9};hRRV_zA{qjn5%@FOq2*cjA@4*IYBYAbmub)#)qg9#y?88^mpF+Bv6!v3Mj&3 zPnGv>3y@!MC~}YLxZ0UNH=I&x|I{&9IUb{w5Gn}c;$4#+=+rM^T(pe2+ualzcdY=; zYwpv|{k?obnA!a#PA84%{m;MXL!V3W0y)1(B0k4K#LZBk%j`TyP!|YobHr*u5sSue zEdG!QER^W30YGi3{`$HrRy8d-vAz0{!pwUy+4~Byl;i6MoeiD3#Byp8UO*%9slmR} zHizp#uBz&sYab)qFV?;FB#@8Uka8~!qh9`M{)*E`& zGXOA25c`~wG57U3{ekO-G}E%lER?)ra8#D6K_dtAnbzn%ywm#A(r)+0kKQAmQNkA9 zXQxXee|znTqowVWBqyjp8}Ko zuURJIai(mLgK}rNS`o(~Lt#{Bd|;D?%0wYUmv4HdG*@J;R#9D78mN^TOTS*eXQ@=W z8l&)Y*0xX&j;v2H-N&cMPx$f()8U{QxM{(3c02Y=c6RZ;H|OT7+s*8u=Ki_3=kH{V zUwv->^5$=;F*7yldDX2#dz$O9Mg{-ipF?eVCsqaPc^ZP9wE$mdh+*)XC_g?g~f@358L5qD^vt?{8})T&0zI`GxN!x9I1daVfGr*~IqpLmSlWsYu~z>Z4sDDOxsnE7N2> zBviABqVB5V7nf^R3-<~`wjYTyV%3Hs&rhMv#30$P?Hyg0N8pHIO)FVdPwiBN7BTww g0RpC*o2tAd#xPv0)vGq9>zYkTdzLU4P$01Ff9Xxc!vFvP literal 0 HcmV?d00001 From ba2207e33f323694d820aa73dc4605034e98dc94 Mon Sep 17 00:00:00 2001 From: felixk Date: Tue, 15 Mar 2011 22:56:13 +0000 Subject: [PATCH 276/541] Add mime4j logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1081978 13f79535-47bb-0310-9956-ffa450edef68 --- .../resources/images/logos/james-mime4j-logo.gif | Bin 0 -> 7418 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-mime4j-logo.gif diff --git a/maven-skin/src/main/resources/images/logos/james-mime4j-logo.gif b/maven-skin/src/main/resources/images/logos/james-mime4j-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..9d565f2762b3baa4268dee03038db6ac07da3be7 GIT binary patch literal 7418 zcmWkyX*kr2!~Jbz#+YHOjj@e=XOt!TShHojij?jYMNv&`$d7 zwZX@>x3(kCpMU+pK0=l^5*kr2_%W_?ae7l>d(n) zinJ>CblCRV(565j*x0_Gk+S{o=ZlPJ!Rqg&?JdFT@=Ik48#Ai}FCW3u>SEh{!N%H7 ziI^YTD;t81s$}Bk=El;}m*11q(WWME_FDDV)PCLix8~NZ+xGUMJ||9w9Gm>`;pgV> z)gP-34GksN3Od_6-hE!+4h{D8^#TC!KTYKge)jdR$2@kdhr#t13vGXmobH zM6yJJEjd(QYX%LM$ddIxQnXEDs|qp`KfGm)+932ct>Q*2ZH0 z%D7~UiLS(GX+D;1)Jnbg?D@!<*eq=4LlaG6Y+g^LW`Be1(D3N&$GO8=TI#kB^&etM z>Y8Lz*@W@T9wJd|?bGjVffqyV7v0YP4om?!oQnFJbr)h*OxEr275&*e)Q!=zJq!a8 z18SsJO#&_1dtO{4FtH61< z^xH=(&VBdh@&H*$I-3Q2bj&2=tenVJ12M1eh4ty_xA~>EcIa1|?ru2}m?a}a_aK4j z^(+D=BIA+jzfT{uWk`l5;v=-3YCRPSsKzLo3heSgZ~%m4iYr=8n%5A0ocinjF!RAn zuYBxiaPv4$JIeX|Typm_DqY1`cWJlDEMe_fCL6yOwfIEi;h3&<}B3X7>^GEP-igyEFQ=3fYgY=*Cz8Srxi zmKkJE+${?fPQs{0stfF}Ir4T|_xQatOR(-7gY#(Y6({lUSFM>zL=5Wh4y!HfE05BT zeJ?94S3f&kG(4bdBp3brwC$CXh znjK#)0$A}slMWB)o9_roYkhLY8XW;4X+4_ml%fb5D%lavo#@P{O)$Vbb+p>}66EOV zs65555X9kZQg|)XapyV7Dm%Kl6Udw24Qv8-edy*A+w4Wkr#A93-%waeI2soguJ}{r zDy<@skhbeoQs>EQ%tVDNkG^hgdLGiZoPX&R+wYHQ^Oh{cl3kiB;1S^!=2 zC=~#Cbih4w#Va$o+xZIHmeZ>sl?&*8W@PyjG(?ZmofHA8 zxo}bza@u>yGwE{Z16Ype$N-3Qn0!CqL!m+(G}^jWEEga&Y%RE9(J-*%P@;qm^BLJC zQ9pX2S~O!3)y6Y!?&i!($FYE&%53!lsgK(PW>5LDCqnHx{@NlK#3S~&r+}tI9!}-l zwhy2Lar8$@QluweVRw_}33GXTr5vBQ# z8K|T>Z#3$jkQ2h0+DmQHd$9YDz;aEDmdw3^#edF`CK>yev#x{yqc;!OjS79eS9-1r z;?{IFbuwUemo(jlT>8@X$HGK~>!d+CQO4D&XaLAP*>KeTv0J|`1cU~C zkC-a#dK{j$|IVu){s%+@^3OE^K!&ugO$j`Fzb_<*;Z*k4V$PK2NPy?At0s%N?k#a+cR2PdUy8Rf`ay z)tcoP0NUA}bf&Zw;;h5Q_M9N?d#tm9J2S9AntSf&e{N~iVeosnU@%m7ZllT(T9NQ$ zy4zSNbCaS-*L1ZZXbjar2RV2FyTPUC?{{f2$!FZthlJ&6IuC4L&ncR-cD~#{bclG& z(Wid{AG!S!un$O7a*uS$e)y`)9sn#FkM-HVW(X^$Hi*Z6g&6|+_yuDh(VX9VLIm`Q z2fJR~2-=9y9s^=Tn78o~j1Z+*OMH8z`qd)(sc_pKQ4a|W-V{Y~R63%xe)XVdK(b=k z`c412lt(#!pY*#{9Yy)qpN`%h8clr5aL8}Ggyq%7??z;PY}@IcpwFp1>AGP{KZ*NH z{LfZ{Ec|jixIB}zl3R2Grzxm1-#2>hoaR#6bKdt#+bpVleKW56a22x~m>_D0Im2pFQ4{$F7y}x<6qWBOn*J^! z|L3|Ya`8QC|EB@uskYcZdE-LE^_&oSE>QkP~Q(d(s*_Ruk*WyVQZ8 zPE_=gBkIZs5nS^}Tr?Ah=iL@7Bc04JT_G}gOxTbM%c_XYGewW(Dkgmdg+iU~U@z$1 zzZkgRDMZt|WDdqLOvBgyc-4Pljf#5=N)de_3=hm;7|n*t++so!9H32-OsW)j9>>iZ z@9{(v+~}vSK1F0w!;+7qgKOdbuKVKw?DrN!%Xa9g?-d;3ajcS+&kP7h0s=N6ch*=Govu$Bxa3>vk3TeXSjsVuDe7!ciEF1yy@Jbh<4VRK9Y=aQQ{92Y3mw_7-eyOVb3({@Tj_}T zo=}4m3GUQ{OH#fTRQ*=p#3L@*-Yg=r5d_d7H8vFE9Tdwk*jopSzk}R1qO7QX06)Nx z27MibP1tZk3uH(KRJc&tTbRrSMQH$u1{t#Q^*NxxX9$v^6_#?rlt^4US3WKPF6eYH zWP?vpY|={x7X&C31uEPVq7|SuAAC3Y;P+c- zvJEzcP{|O1mqdVgG|%vWGgODAe!?z?*_632ddpz<;CX6fs+V^>Ha4_(9pk>V1db`%an2xrm^_S z3Y;8J?Slm;)`6<0SPp!2%K`!P@qBMDw^^O)viFzUV8jDnTSKB z#R6cn8fri~Pa^3>mWR2g`)ez-%(98^kyE8O3?F1}mToJ9?WA%QHr}oB%=5WhI4-2* z?V?BrrfQ{SQSf#VOBRSS+=K{>V#bja8gz@oZx~huOPQk44f+YJbUpx=Yr1m0lLDZVdpO4K{QHGo*Y{1b*T`LA2Qym9hLkmA3k zlRmjCyP@nr`;W@^G~IHU=F%G^u{TcDYbUCU7IWe8a^d&YL0=jL{#kj72NBu>jQP`G z>h)CdE@Ye}DgiW4VNFQJZN?2(pH@I-0I|tMx_k{g&mZK)(dQ+Tp$Lb`OKq{Ai%4$7} zo%Vs2j}-Ini(d}EF3$!tjuPTrIeR%h4%{wR?}R&Q?KVu*??wbJ9toKAbEL=jHe!w} z!P0d-E!o}f9MUHXoQ9<${UwmZuJDRDtzKJ@It9m-kgi8g#`Qk~HLaR1{BK)i;a?&Dm62y*y6lTYjL;H=r%jCS1-r@-UJ8<7C;^5rNFuQJB1B&qVPxUER{=jB$ zp=}r9YY(*F4}9TB&D)$9zO#gEoalLwGtjk!Ock^}j_+_JJxW+jzXF@)h+$9ySFUIoiFq1pLJ7Q3^ar$na8Ei&mC7ND_tYq|sM z(05{%j^EHa^*pJ^hquNmhS;HW+J7)*A66M zB2{jjihI{NYVrGw5{j$$=8Tz*IdD1a9_{`?NT_^Gu64`6{s}Kqcc5EohadP+BW&aO z1j#|Bt*@KH5}l$dwGUZO4H8Ly9n?+8F8tO`fS5){#v(q{IZ6_ifhZyqd@cX{`A8xp zGhJ}TW+Wu$2fPEVycl?2$n~<#9Vh;~FK9v{6+?*xu7&3;uMD|6RV7gBFW=7z?4J7a zx6Mhp`}R%udq8W;htBx#BV1k-0VeOp(QS+&Ui*Ny$TQnsBvIvlih>fERwxh}Q*H|FHh zKMz;u>-SE(c0Y;zG9c)A>mpifNGEqHd|fzPp68jO4H71vEv6-cg;ULreIXv>_(g;N zvPGmtYCM`q%}RXa*XeKfV!O^5d`S@f&ir!DiPofgKnVWx{lmzmw!TtAP*9Wth%g>b zn^=pz=tY&m^z5&ZPjGoxurIHCGIRqX5b-x5yX3H zIqS&y?#hU0%o$@&A*Zh*%)9N!hrf$hyzmI+KPD}_aT{puSIK?ke4XfXhBtCU zxQ`~z<=+~p4_Dwk*!~HLQOSa{Sasm%TqPlR+SCsx)!ey!!t0yA-h4<-*e=0JL%F9$ zjJps;$l7bdcKYM%zu*6r1>N*7+w;c|D5=@ZfTOd4^g~ek1^aCygvb~?YfnCAG_0fu z&bvOfpl-Y+QKnc$6N@h&bLlT;Ugt6)8UTs&fa@8XF5YWy@TxD-K&MfSdlOLpm%!Htl0Um zY-WnPhhW$ZolEO64#_70o>o?Pi#Gg4D+o7z?e8MVJ3c!I?@<)e%A^K6 zB-&oRXv|Np>&q5ZJ={(9v4^tcBzBLU&6oj25Zrzj(*2xLlThI>;q!&h-y|Izc6)H{ z0pU11+&1iHYyB|LEN2UjZMxd_BeI9sT=EWWc}G6SRnXo5GV6 z1B^?oD*s1fmn6nEf-m#b%Np5v#ZW?hre7}G@dhy08;nnqQ92zq%tsS5%t)rRSboKe ztCBj-8DYyN1GVBb&*Hn(ez$cFQQVJotNBEQuYOInPK6WJ)Xnmfv1$DIk=k;V$YZ_x z!kE=b(uKl3Sb+JgSzG8r&nX?gAnoAMJ4#!NC~~gw+6x6?n?W?iY;^Ya&D8bI;QS6` zkdBe+4Y$8W^t8xKQS$2yv5{E`OGJd{zGP$|I8tJ&xJ_ @)JBreST?(L|-wT9ua2 z;Fwfs^py0tAO`WpZgnzdv$J@Q24w=q7bXH`%311WAg{?d+gxdW1Juxi~+*bCLi8=pL#9${)Ez67Y;i#Rd z%!5iHAUa@XlwD2vbgH|43rwTL0_c18~nH|$e$VD z5cNG_h*J)!SsZE94n!*(Ob7vV!S9W4(*glVrh}p^6l2T-#f#|}16Cq2k_U@~5l`~b zpkE&{bu6f4O^+HxqlJ)QybmRl(G+##8DXDdd+9r@RQ<>q5my(OJjzNlxm`&(RqUYf zA1ht`$qe3dkI75k-4wf=e);!C>8BJH~HTK#f&c>Kqm!?89>1kCBnmPersW->OS-&&6+ zC?Tcro?7`1UGa&NQ`;Ks(3us_VfiGg{HQVCdphr0*{Yh{k~%6?&kO9QpchZFaJFhI z*tyq1|8>?{1~^Jw0j}TnJH6o=^j}`lBYEePuxqy@<``i(Dj=fQ;5Qyb+~|4o6yYW3 z;%k`5V)&i9m8@#eGwfb-t%wyTWi4Lnow~9U$#X*=^N(kUMplrX?@ZYtt?bkpw~}?r ze8Jw1;+s1=;wVj3HrzJxEx40kt^ecpBbiUWC8PN@CJI6xYr74u|Ce8Dy{|5FhYTsX aXCuGP$wbFAjyh6hP*A_OER+NQmj4IU51d{A literal 0 HcmV?d00001 From 8eb9943296f444e2196848c3d9231adedeb87aa6 Mon Sep 17 00:00:00 2001 From: felixk Date: Tue, 15 Mar 2011 23:19:14 +0000 Subject: [PATCH 277/541] Add jdkim logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1081997 13f79535-47bb-0310-9956-ffa450edef68 --- .../resources/images/logos/james-jdkim-logo.gif | Bin 0 -> 8111 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-jdkim-logo.gif diff --git a/maven-skin/src/main/resources/images/logos/james-jdkim-logo.gif b/maven-skin/src/main/resources/images/logos/james-jdkim-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..9855e0250d5fe7ffc90d20a6a19deb95bc14746b GIT binary patch literal 8111 zcmd^j=TlRU^Yu+gLT)JDKtdBRp$1Ut(gc$bq(kUUlrEqk2q+em5<-y@X$k^{NGBp7 zO+=+CO$-R4*Z>Pv1r-%6`F+06zww+GJF{=j%D=#lEgI6RF2nq@cN=iy35=mWMeb1gfnwpy0+Sr!aqi|G>b&;Nak+M~{XF1&4)& z9Xoa`A|m3%i4zz6PDMvY$Hc_M#>B+M#hp2GCLtjqUVfmGO05YDo*)`e+wbQ^hQ5(W z9hDuwks|W+4mCMBnZaN%naqro)XdDxtgNh@oSeM8yn=#)qN1YW{KBhOua=aQl$Ms3 zmzTGtGuUi4hr_Ana4IV+tE;PPYisN4>$zNRV`F2>t)~Cb($dn}+S=aU-r3&K+1c6E z)z#hIegFRb!Rne1CB@6FZ9iUB_4M@g_4N%53_N`JaA;^~WMpJ)Y;1gdoHsnggwv++UloIpT2zg^6AgY+P^>lRzC9AzW@EXw6U@A?c2BSo8LD#H-G;8x%uzw zkL|zT`TzLeH~8QG^0$8e`?s;RwY9yy_51hlE&kRvpU>a=_wV2K-@kwVqxmoUe}nM< zW7z$_qW`xG0GbbYfwERj?A{c#xcZ@?ri%VFNYSR$s+lu*NlG{T)ll<|N4W&^Oj+xe z%He#HOZ}nYma5S!yIrch+g5l)TMjM3d$9hgno}L3{A;Ybn}d5zDAOix1vgehzhNUs z635r>^s>2K9DGOH_YAw0?pC(u&@${fCSEu5Uc?ouIh=JW z)5lNUobOLpoz$xjihNBj-9HgK(xIW+6XJy3TiSVh@d@0%7&BPknAT;3NnMDo7q2hP zzw~wU{cyo?UT4hhLfS8v(yrLT&}GHt0=MUfgP&A>%D{WR=H0k!_rZFSI2W6ZQ$wiZ z)SODkCi$oC$9BhzPd;ssyrX`zW;ITeG;x7LcXl8=qkU+41*y4Nf+xG7qFqUDXDlsL+feH@UO$>Z|9I-Br{`@^uOtMxe@bRi-e7 z22qZ)`>`x}3g}Rj2*)_K>sz>7FTLRIr@}3WS4pPe!)uj`a8!g?HVV6pb)fU}@~ifj zs>7<0z`v1=kyCRa!N7+7?A5T)3|<`l+$o(U1IVS#aJk^i^jP0)e3Lg+88fl z+>_HeR2|zgQWbRuE||^Tw*s4X?{g~i3ilHJwLE0v8lb|FoitvM-wl`u8+X&q@ww?7 zMTb4|I)SBef)i1NFXw|Y&kWb(Vl)3BITov?Jxx7G)wE^9bq=0gRLILI<)Wis)x; zq5PdEpt?l9u#{ zf#)(htA6J?gN-Q3&ddn;#ttwq@H8ba~AT{SGq{BQB+h&FYqsJT;3B(W>{luV? zm0~EdGa`CJ#K$cd^Y4V54WAyk-(27GWwu}>Z-NLsH`$e$n`n`4u1aldb3}>KD{#Rs z^@Y;SPCHOFK{s~BX)z2>RfwfirGCk@0dsK<*x&_gVuIH#yYK2yQaqv)V|{Z0iNYsD zRfs!)0tb!j&)(XfBmqy#G_Z>CmG8b*_%E2xjyUP!k)&g>tDc9{VG)IcuBOQMd9gF) zhOLxmZFenr9#HK8fCh%I>@jwlVU)K2)PC4{yZJT$@){CD`rXmJ6(A#Pp-Rgw)zWX< zIYV!u+VEZ&CDa&`vff%PIj<%V9GGdzsKC6|AxUGrc}65^sVY@0kB-CWk3c9b!zA_P z(<7Fjp-Q2KYP0Mf1!p}=6}v5#jfpuN0OkZy)(oG;m1lr30j}JXBqiaGy)&t=aE;yI zgQr6e#-|C|&~AY3ht)^_07RRi(O$8MZxQBxyA-jg zUZHm=%%;c1pW#;*HFrnldDXtC27%diNZ8~(CiyX(%C%$Rf06Mp`Wi_1iUfiZ@x=1g zbP?y~M%)q~$G9pG;y<?07prKpf)rWp=G2qze5-nC#lHuC=1=?0&Jb zZ%284{*61X?oHkaPr6fdmRRF}_7w!c)JhYitb`RDxASwV-QU21cdsc=HD6z z!DIOM;9Yg2tdn=!-h2)*qB!v2$@|I8g7kD8&;(Cjy7pE;I>fo#d8ftrDI80OkeE>{d-gP4Bf{Na;$K;y66lw zNXtW9PwBOC&rh;C`#I1$MQ{Sh-GX1gG0+J*ZIn?}@&|EOL_i%fHCmE|(Mh>)_ylPY zy6cre@3#GkgNO2l z2?DkEo>&}@cZY&??$yzhizW-;NX|@2*|xLKB4cmoJUjkjrt>1(imM3#s(v5%rh77s z;P?IW``1R#y7QqOPd0Zn@sCkIvp=f8HACz&v;rIN9!lB`yNhy)M?2xnlg_(s!p$M{ z=U(yJb@a(9dDgrMHhT^4*}?6S}JsN(ftsBUH$=+N`y3`e2@2F4gi2{;(u4u_;1qrf*zP$4@`3%Y)@90 z#i3*T&U{Fvd-fXt6-$^A41BYI(4(2k-EecEMRcb)W~rPyLDp?ek}dB&7dahsMdBEi zaxq3f9&tHRfD#6LbABH80S;gZ-X z=)52hPrxoSVWMovB+A#F4OxV0H;{3GN*E@aAvXsrB#0N&Ra6!d^CZuxwYze~kE4-+ zkr3)xzr!PjlWEkE!w4T4Nx`&r{O1W~3^MI>=t*oeDi#UvjE79ofM3s{4i6aE1d$1z z2BBGL@z6PK+^7{O&x6Uak%a_Ir1;*lO7uXrms)kyOT)wSsTr<8-kJ<2Ypn}$fd(yc z=*1KX#VP3~bgn?}1#CrHBoZAR3fX*?h_}^-*IymYtHK&I<*595rg#DAYBx|GDHZF`kXtChyHQ& zssI)S=Rux7{HR_mhLZR}Yx(PtG>sx9E+BPwUi>B&ozQbk@B=EZsEwr#CssfP(gAAhbx=`VihUBp%X1Ew#uTiBJXi2v1}79523;;oeUU8Yl=7wH#<((c z*DVIw922R}V4phos11~zFQ=TA53v+a00g7f(Yh1SdPL)xV$|U!*x{~>v*e%zt>ck& z5bUBeq7-xIQ0D7!`NYJSC``c|;shOCIEV6Gff>`QnSO{<;dnN?*jyXO(BUMpuC2dE z6%eFO@vV2NrDCr01ig9Hnu&=HY-G$jSeO)quDG#BEmutYM2yAB>*^OxmjuwwK9(hw zEHy|N0CIShSJiBI85Qg~Sav8mgra-XX(xLfB|HrCW}y;TD04PLUdx981cuSUMT(rh+hong{VSpAALxII?A~j~}xrqRvg>Lb_D1fet zJJWE-M*HbW%w!$XhJ;8>RG)PLQ=3?Q>R@0AsyK=(M?gf)8S0Fvq!JLq{5y<%buP2# zdI7IyoV4GYin|hR22WB5TCYBZ!JI56-I>K-3D8K0g2~d+F?HhUUr~R%a3M2S;0@$7vp9rsW|9#Xvp)0Ch*2 zG_x1S!EL<|CMk`x66O$ExJJJs< zsV5#kvzOF>yuE5!=ZEK1bg=Tp6}x2e=CY_zsgyS;T#Vw-752?OP`IsXG}}g2PZQrj z#7^fwSar{N0bM0~RC=F;Z2gStuqS*1z9~Q*;`f4j3ydnz*+Vd2x`v*)Ts{Gein^W3 zCUO%yc_TRAK7#cI_^yEwL>6a$mHZ>nqIqm5MSD-RU&|e1HJuf9;dQa>~ z@DjF6bRjE}V9Z_bhaHzqQkN-#bA|cR1I%Ph>AGYEBsl&HeKMn>mSui@9X_{Gr8-wt zp4DLc92WFnN1V~U>WJb*@)_$!v%WgPq`Ta?Jgk3ZBt8XSdP#Hw72B38Tl!GIKLu}l z4D=7^)OjRgE%BIwaqw3&J}IqebAwj>pQ_!L5yKpWT9nh>rzn`nxva264E<_WxgWli z(0Sg3I$7I6Wh0B+kZZ5Ty`d)?T*1%S{@iO^={(7wqx+asgUw5A;@anqo*&gT@(?DZ zP;8(`Wn^#niT*!|gU9=5^9HqaFoXz>J-p?-YN$WTYF2^_cOzb8T`5m&yOecLPg_fM zyHSpJpQa&R)N?B=okQYx;X0nm)pF`+9&(woTw^k57UOUy*a5aW2<*X93_W_Sc)@la zMPRuA)|2|2M?QK?P6MODRU23qzrLE@zX7t@=t#etYqoNw>s+eeGh9l%shq7|Z&8r~ zG`=#S`sZlr9I7`QU8)6IN9z>&)6^m`q_3cFQ=dTtGUz8KU)vZ98*LHB3V(DzD>>TH z0UaWHDDg(YJ&?38U__o4n#XyRO*8FqMxbY())!hdp) z>A@%w%v}V=oBSy5?@@iAv7o8o>mAAb=i-f*v+g-vKe66v`wOn{E%X4qNp${smk{>u zl6#-!3y6OgiX(gEpUFkcqa%aUq_BO|ngLJyN8vB<7emmoCWz~FS-t+EixN-e@8O<} zv0&#NXfwEo*Siin?KD%gj+L#=`~{BxfP8v0AmC9z@1~z){x!WSv;Dri_ z#_n^X=SN>ILqjGWf#iqK{EbL`!S|++4GK^LW(5rGZiu|1u1RvV?z^9t&Lc=2-xAlp z$!Jy*PygMbG*(NyjEi`zuz4o0!4Hgo4KrpxwRb{~8zSal^RJ53CrWof z+x-G%qkFSL<&J7tsz7N# zOY*Tn#OEiwUwqszgAF8m;DPBKmtnE^)i<9;xxk{y^F`4z=o?k)tpAud{YuB}cQ!*X zxozEsUK#m-u^?V%L(e;fPtngJmd_Ezi!VsHt-(&M%68sF#)e@ATmss#J8Ldz90&j_ z0l|IOI&ad?A|>#1vP)s$ywyG1S65@eTS#57KqX&OEd$ph&Q+JO77YS z=HZ{Ekm$#}5~Yu^m{*ODQ?_N!LR@)yb&lV_qx0u4%qtqVY=p&iOmoDqbkC>oeeg~H z2BC=;F>aX7&ydqTk6yDyI3?}AP~Vs>GyzosqSV((f8Ex9>?01CY0(|=it6gjwqIv+H!~9{6-r&f3y4xdG7PjBdm)| ze2dio{%lm1_wK*ovPZivVu^pY z$jRR)8oswqJdJzxtDV~C`enjQY`J}7>tpL?xRLxh?Z?48lxo&D-!vQ;;;UW>^WVOn zJA^qIUy&*?@f#FRdL8)>@*{gN?tBx$qLK&ECb_5>JSgb6mUw^t^Xq7rH!whZV6x7o z!5te^$eLE&A!po4X;YtOiOMn{yTQ!4I!4W#sHmlb0qQB$hAj%pBmQYbY3nkbsU}W^ zBf_-G1|MFiT8{Kk9t))hI%cCh>`RouoPMG{-YivSQvj&f;HYp)^l7e*jv_(9Jp3_t z!1r-WiMd3NTy5ZOs$6~?&#TMHoRx5LAKuc1B5gb+HZ^Bi%|Xl1YS+J*-#AFdXb*>< z2yp+;pvVdx5!XnmbH{8|Zs2MqMU6VK)5A~e?l(|34(-uXvH3PA@~B< z@{({O7ky!DLruL!=f+TD4uUXT+hc-M9VbiQ+CM>?;BZ9W)GFZ}74!yi4%_uR6f&6c zyNMO$UrDCAaWd9KdVok6rCbHZBN9nQ>8j3uOoVatS3s4R!K>OJvWw0zsG28ik(*-q z!&|T6ApWeL^KH&(J=nE(8VhR^i*7YetsKe}a=N21J>_!c{qg1=V`F8UjTj;$&(ZH? z+bz0;Vv3Thtbj{X?Fdb|W<11psHI4>kC&%E4;9qpxC>Q@+3Zaez#D|BSiEvn!hD!@ zFt)Z363uF2;P4(nt({V<3(4HwD}AR2LH^V%=SU0ttb&Fbs$EF)Hr*`_pX!Sj7cFM8 zJPUk{yw=5Sf|An-ew(^BimA@g{hsvgNh`P6@2trbN1X{e&i1g?Ey!j!)}p|`Yo1YH zb9kM+uoq~ci8;s|(OSH8;OxBe_^fh{i`A3x%0cwUC@G9?dvUB!md`@RbO6^Dj5P_j1mQuUCCju zSemAZiui{v!}@p&W_&Np#w_}Vf@thjb1^5gtpPE29nj(pQ|kb}A~_ZaO`2?-#M6Ee zG~i8rF`Vi$=~^UkEb+>!=SB*jyGA(e_~P|xn)p6<*h9CO1z|^clHnKWd685t8u1m` zC{QFglIkhaPYcZKc4OGy!Q?j4qdUKd%zF#9*sGE!Qc2D4Q?(iW(0+ERO;kWkQIvT> zw<qomn^t{4rRN9Q0p;wxFi;8dS8sqmt#-H&BXFM5uCZSn};Uia&)SBGd*{jtt4 z6EsAvU~-u>%l8a^Z!%D8PF)I3;g-(jg5di)y8y_QfV4?`;YGUuFT5V403{Fx6os#v z%-#H!GLuImeCMTE5^BW1ObHNk4rab!L#eZ2mj&$w0T_+|ld^(ABTeW=Ctbrcogb?` zDUYOrJ_x)GvM{WG)8a~WO{26dXpL3rW{AG3FRnDZ;BDuUXH(S%A`FE?vw~&qxS9j^ z>g;xHps7G%wYFTnLpH{>>T7{TN8q4yN_~2T8MV&VqTcP6`t+53Z8e8PRvaE++*|te zi0j%z;fC{Cta!2*#oB6zgO*3vv+2gugU1eUc6r?YF@5VIa_!J{o5E$pv!*nQ;{o`) z&*ha6IKK8%G%w%<^^x*`x$hDsME|bW_^D^NuOlNuElj*8L)uYQdp`MT4q>L+-CJwo zB8~@}_)NLONNev94kPF;@3IB^wypf&>ysJ&2~qf&*(ZWvtkt=bRh_Y6d#SgRL6-YW z*GyH7!ge0$WGEc1H;=G1JV_T-Q|i2UyfJNPv~BTJ)g9Cw_q6h_hvobe)#C>uFKpgD z(#TTCay&2a0lrb5&1T?z2J0M0x1YK)oG)7Z{HS~|E-DHIB*H?UKQ#C#Lo!~wM;z-lH`y3Cw{|L1op-9; zEwn&0XLD4rzKJsI$ZR?Mk&QI$VO><3AO7|5Qr@x6vXmNl+ literal 0 HcmV?d00001 From 3b8d798cfb07bf4facf97f3c1a5baf0f7cb6ac96 Mon Sep 17 00:00:00 2001 From: felixk Date: Thu, 17 Mar 2011 23:57:00 +0000 Subject: [PATCH 278/541] Add jspf logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1082759 13f79535-47bb-0310-9956-ffa450edef68 --- .../resources/images/logos/james-jspf-logo.gif | Bin 0 -> 6568 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-jspf-logo.gif diff --git a/maven-skin/src/main/resources/images/logos/james-jspf-logo.gif b/maven-skin/src/main/resources/images/logos/james-jspf-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..e586fe2e9fc0032d8ec7037cb0d22e04616675e7 GIT binary patch literal 6568 zcmWkwc|6mNAOC*8yKQE3&78wDw~^d2w-l`sI`k|@L}>}nNS+O$kU7frRFmY2mJ*d} zb5%x-h94~0TU!$h(2yW>R8@A=sbRp$iejZMTX|*W$FCQ!w4(pxoC5-?(;tVrFhsGT1A+3jlyZp)mXb|BnEG<^SRTnE<3hbeiMAwh4hmI&iX}Fg%g0XNv?=4 zMBp+_&rW^*5<%x0s9$MAYP-GX&s(QN&Mt0tOGm2(^Q8D(#IZK>F1EBb=OmIQ>-uS^ z)Z=$*T>YeO(?yXfQss~1bPB_-K$}eYJ5IhY>V9!mzz5u=cv7zdazBAN{6zE;gL=Ia zO`(H*N@#j;x#-#n@HQ?xG#ZU4UC z0@+|^d53WCLnV{wb{{=Z0|=?Kg#iG85>P0Yi9?5i$*Z~x66d03ewL@2MKni@2GxKe zdWm)p4x*YCWGx?1>wVPq82-B!60!syqvD71y$FzuQLU8GYk%Y@8)#e3NkLO3pSmLn z25t6^IJqM!>dX+`Mt%Y7k=BoshXd6q$jvNMN z`|H9`&Qk_nDTe|==w(KpXrjeYX8RGoM3X zbfa;x^D<)_=!o8rwickd`aodwBo!T*%ID=hmmTgq6t%x8CY)eN$cEdq_*rlzipWzr zDfe@Q4I)_vY(tw*X_cvU5q8CxIH{=;Lrd!$&M?+VW0dT31cs2kl<$3k!1A2R;*eGvfl3KLk>2k&Ab0 zn&EEcQeN_+rC?utN82|owD#Cx8yM|*o=F2jP0XZV;{*UoDIZwdZ7&$S%)XNJ_s%4( z$-t&EEQd-b?$H>oD)cWXuyeJPbGeeOHFOvXolmeufkGxpNxe(DJ82C|ez?q9E;S!X zJC)$@hyN$l@V5a9O00@JNeUsAd~l8^7azVjPcsh4!j2=|_ixi+N^v*&Hs=Wc@M#~P zu-!uR6?o$VQTQu`_(U(X?8o2>$J>|2(;{RS88pfF+3pilg{`19!Ed~5LKjA zUrZH!2zt{-&GB?%qK6wJ`kDuL&xa|IaN(|gKR$@+ib)t0bMKimvukmFu8wmmY8*jZ z$~+fk?&Ec6Uw9q)nLO8NQ&wRjfu{`@Ab(;cU0h?r!a}4I$R__Am~vMkOJE~YZ<&Ng! zw)3)pcN8QH{SHVMWp^J(XvbX3&5HxoF+Cfh@$AW$$rCUv8@Ha@E1LJ4|zi4d4RQLQj-_F`(iopg^z( zVuKVy0AqlGTHgr%)%`|8oPmZqT6Ck@X00*#BBnjZ^VN8=6*03F(%vSfOkPE8NiC)} zyG7xc^S_FXGS5Z(?YU zdjBF`2wV2M=|8aXv~9tJ<2v@kQM3JQK2ZeCt<{Y!N}?)`9C!;9vixwShJbK)l+Ldm zaQ*9tYyI-)$=LLqY$E{1u!6kZmtoN#0F*OdWJhxWnvta_lZ!K>)3OJDl0T&0JX(RK zW?e|QIUn2flc#(t{}ht)rr!8O1L>&r$y)1L)E{F_j3U{SS|iWKJ=72C1FE%oq3ign z{P^wXr-m3_*O26ng6olt>=VNuvpRdZtJGXzUCCN@R+MV=jqQ4FlNi_5I+TYuD~Fq2 zayo$Dyyxc$ct-VSH1}T~tBzp&B>g?KZVtp(J{;-`WL?lTte?<=>nftqIqEV$A}a4V%z}7QJcU8^wwGc{;rI;g$wxhw*?9Rm?1J(xDEbu zEu3bar&xm-lT*2}7x^B3FSL$Hkc zqrA$k@i!x%6aVDg*}!j68MT0`g}qiiG(3d3vBcXnB|;J#uVyNiZ|E+B4TZIeq1DFQ zoPR6DOX=)wmrny9Glvm6rXVHY@THIMLeB@w>G{RNy)RBX-3?*O5HcZ#Q7(i18iB2@ zS=qF2fYOYne*w&cMnIe+fR}R7isY~k>tJQjdq@Id7QTm$Cje^9L6x@+#hd=YIlztHTks( z&}5-gH?@?78OhL2DaPvXRygtK7D(Z<%p%$@c$9NdMid6%=V_qfBS6__E}gO)-aRlt zK{{yx0w20#Ma<9rO^@EKc@lW&iS-Ws8NZ%Zk5zao&G6++k)!98j5GTLEEvj31oM%D zJLM+`;-JMs$FoDRhjtD*i99=;8Gyb81Dx0<$~N?#ZL1waK>RXSXzSwIb3f7Ry54T8 zkuBXDE$Q2Src+(ZNO940iSiy5$2<3}XH57))L)*vZ*6USO+alCwIOlQv;@?n;KmbuUIGD+xl9$CJqUA zkY=IW7%*dY$ILpF3-k%C*O5zU3k$y-GcJUh&*$?7l{ZP!U zRqBv`ELb5!DjcMkZM8A>wi*(~niM|vwlLrQ(1zQg!s~VDx3E;q*EGk>q0zi!s(G#yxN9A!5NX*zs%%5~xg^VI+tyNqA^m3gb z{$$KX@5E3>UI3SqY#(>6|8UBrA9p-tXINy&jKxs~wyFYjV?b09q zrjhGLhx7;l#xdQP0Jt#&+>;?oIYb_VevHEqLJ&>?@N~$AdCE$--dG4}$ct~pZK|PU zD$C8{Sivz=s%q0g&6Ap$Hedq}DtxwEzNb-<6 zAVbYRU4nBPHTY7G4YR zv;lvpH~^Z-FE*m5Suvm^pDFni<%j!ViT{1fV%72`Em%Yv07+v$mHp*!2t!f8^-`EE z18}NJvSCo=qAcnZ{P>LT;qub!$Kf^{zneEWlDNFsoXh|^Z_+eNPgvnB<@fT?akZd1 z3c}M-T5BOZP_7NY78+rC(sC6Fj4A+Zq+t7J5Kn;(_@}98LU18;>U+KhJ&h`-&`g!7 z*Gvd<$dCe4OoEO8I8ah16_p)Rhfq?>6pDq#e^YY(=wj@d%5qcwMM z3mp;Jc9nVF!o8WMMeoR<8;iA&1YcY?z-p?T@e;tE?&yAnY@vY$ z7?w-#3n<7fQ@gKK87$1(bCJ{TQ|BSusm0)g`k(XNt_oen-ey)U&WDm10xiQdGZM_h zkhW$Hq%v#N4dLLeYPqP%*U&I|f5wZoB{%76e{X2MPRY8%t;O?`{LL&%v`+Y}016@- zUGTN31*7+osgc;FY}DmzJau-nbk839&BvQdy+p7j^&)wHWA|wie<$GW(zJXAn<|1D zO=;$Ul`Rh{_XNwnReMRxQS^p_agg_&Gnv+)Rs}wn^5^0+h-_$F=x9KJ20BkG2~Y28 zN;1!D$d-BzOtg_c;8ot>C8Bc=ToCkI@GbuS!*iP*r7&KWt1Yu~X7*^d3Bj(t)z>_e z=c&h`C>O6O{1A6QM^^t*0M(hpstJ^{GW?enz(wwSgF@9~LuTIqrDk%4|9LwBI9Lt~ zynS6;etomV^(z8)yIFnPNYZ|nz>D&R!4>!kv(1kKcjYAQKKTr;D5N0_x3>Fe+gmtT zlSQ6n5#+)Jj+&h{l0$V(&7Y#{Kc-)sm_shgA*5veW8k`?ImxOW0~13>tCIBs^AE8L z41|CIgR~ulLChN8hoBCF)b66|C^`Gi5iyjWmpfm$jeTPqUl=k1By4Qb=KV$D*P2a0 z+62Hr3KHee_W62!5L_^a=^H9{b2XItH`6!bBm@J5sJuC_X?g|1-Ug#LpkpEBtfgFo z&!8=k+R+52IcQXQY5a8`t|5Vwj{1eHITtLr6}RgULU!xLN?W@Yc(AJGldZ;wNs!8K zV@=k448-=i>Q)G^wP;_$G4wPltG^WF+7pBd9T}y-FW;7j+OrhHVUaJLD4x7yvL5g+?>g^LbWrfmPo^E*+*6 zAh_KsawzgG@;!s3On@z7uGp=DWi+U50Qd4se50=hiIM+O7%H!;uEyT&q8J)qhMRQ5 z7xGd(xILR>cmK+dv0Cl%^cIameRhmHG{BH7?A>s(%N7LJ{d5nhCHt*H+Qv$~Q?${a zfG!=I&1@O)2ekI~UwMOVJWawe#Nk_b$4vpf48ZbFy+z|&?@9mN;FjzMJaH8swS;|k z>&8nF7Apg=H6C*e{Ch4&v8JGpEvU9*XpVT}kgNA!f8!_%A6TL=;*oo0AFzcEnqH-( zI^x99axLOvU~Y$XJw0O6+iIS!E~MqODrC+fuUR{=PmtS>9L!5Z~(0X$wy zd_snO|87&P6k>}};Pu_*RHkOuKj%zjc)L|332hA-2A*MKNHg&?DfmDq)lvZIvB$Ox z_kJ>glg`4)FX1`|9|V(SJ>Nqp;PM*V8loD z3<4&8EFi0(XT9I(}Gds{a z5tvn?B>7_tRB+&_RfVu(6?W#J>Yba_#qmDXvZ*az2BTYR;3C2-Ti|;WDlJ0aLFX!} z_tHLn8F3!QmV+=+d~a0Q<(IqbZ2RE#<>&J5G`=moq4xcG!Y)P*`!Zze%Qu`e#4h`}Ppe z7y%!(HAf(?`eoc-_XyZySa9QeHShzvpNo}LnVqE&N-C13D_^T)8@-r;kDB4L%IEs` zoD0=IV6ta^ZfL1*M08Mb)57jyen&qgh8>d@xF&u8WfEa)+4LG-xZ%2iL$SgY9mS)8yEGS(*JH%Z#rFq z)6*)!cIC^~|3rx;TV*}OgU9;fZ)G!s&=K18t0Xn7^z^_ipa^^gOcRyO>5!2Wl3soA zfTZzsKQYJ2La_Vmr<^YlEnni)vv)KM+zLW?Uhzh4UY`5Ab({F!&kg@AP~fHv88I;A zRxpQO8=Om*)PSf<9k}L@<(fu3~;biibbo@D-;9B zeef{Y9jI>sTqr@YBxcir$qz3Ff`$jfr%mO*^x``(An;XruGm5b*zmtb-@%A$p5WCl z9$f$U(w;}{A8xVyfjuKJ*d2f^w=8sc6)!w_qu{siN(yVXw z{D!$neS6^WlcM5qdwj+QgW<_!7vsT;i#v{KDk(_lcVXYJ>#HbtO0Cwq6%{d3Il3~V z6WJz>A&?0&n<`gm39Z}Pt#w!7p$C{u>+28f?A-Cc_84VS+^xS_2aZSg$nZY)p^5In zTXozWbj_dnyoEbxYEqQk-0UuMiqy-KE+?iF2yrJ<64NWHYR;a}x@vTUBag7pd}QFpKbTB_;XyUKsCk2^h$YnJrKC48n=z5G`W(LHl zmyAC}Q*0Ui+C=(dqvzE~|6&8roiE~SqaPHhI|qh1AAa-Tw9T$Pg+iF|#!8x1WHb?c zKX_7}x%x$%9k8L;X-8@I{<3*Vkyfokhr&7OLhw1Gvb)BmwK)z*QgGv>>=L42S4>C% zQ+Vd!uFgZR2Tr?IBu3o+bLp0^Z1ahBK^lnCwEXi^G2X;)wToTHIHAEdw|C9OP8RYzhUpZCnuTwlFB!}9rUX1cXHC1K+H=0l!`BPDsNkY7<;Usqw#pl{}@=b`)n zUP{b=%}*as^R#@pg?i8Em#$-`hu0>Vx+gsb@rq;%6F~E zyZynz?{Dk#XmN7SEOOIsq2Cttoagbuuaj2`u}PeuA>GxM(IJ{wWqUq4bMKoW$Dcd_ zN;!ZpFIQEXG|tAihsR20WV`choiHXwuDFvw?hkvBKlW#p~w2x0G5NUHu6MIis RjZa3E1cgrR%mx70{{cwL98CZK literal 0 HcmV?d00001 From cfcd46625b5879f56a8d0599663c25d685c0771a Mon Sep 17 00:00:00 2001 From: felixk Date: Fri, 18 Mar 2011 20:11:46 +0000 Subject: [PATCH 279/541] Some fixes regarding JAMES-1041. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1083036 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 32 +++++++----- pom.xml | 59 +++++++++------------ project/pom.xml | 77 ++++++++++------------------ project/server/2.2.0/pom.xml | 13 ++--- project/server/pom.xml | 19 +++---- project/server/src/site/xdoc/FAQ.xml | 2 +- 6 files changed, 86 insertions(+), 116 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 365e63ee0d7..51a8d9d9788 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -1,4 +1,4 @@ - + + 4.0.0 - org.apache.james - maven-skin - 1.6-SNAPSHOT - JAMES Skin - Apache JAMES Official Maven2/3 Site Skin - org.apache.james james-parent 1.6-SNAPSHOT - + org.apache.james + maven-skin + JAMES Skin + Apache JAMES Official Maven2/3 Site Skin http://james.apache.org/maven-skin/ - - 3.0.2 - @@ -43,6 +38,20 @@ + + + + org.apache.maven.plugins + maven-site-plugin + 3.0-beta-3 + + + org.apache.maven.plugins + maven-project-info-reports-plugin + 2.3.1 + + + org.apache.maven.plugins @@ -52,7 +61,6 @@ org.apache.maven.plugins maven-project-info-reports-plugin - 2.3.1 distribution-management index diff --git a/pom.xml b/pom.xml index 602d9baa024..d5acfe98723 100644 --- a/pom.xml +++ b/pom.xml @@ -1,43 +1,41 @@ + + - 4.0.0 - org.apache.james - james-parent - Apache JAMES Parent POM - 1.6-SNAPSHOT - - The Apache JAMES Parent POM - - org.apache apache 7 + org.apache.james + james-parent + Apache JAMES Parent POM + 1.6-SNAPSHOT + The Apache JAMES Parent POM UTF-8 - 2.0.6 + 3.0.2 @@ -49,9 +47,6 @@ 2006 pom - - - The Apache Software Foundation http://www.apache.org @@ -273,8 +268,4 @@ - - - - diff --git a/project/pom.xml b/project/pom.xml index a7373f04c94..2302924bcfd 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -1,48 +1,40 @@ + - 4.0.0 - org.apache.james - james-project - Apache JAMES Project - 1.6-SNAPSHOT - - The Apache JAMES Project - - org.apache.james james-parent 1.6-SNAPSHOT - - - server - - + org.apache.james + james-project + Apache JAMES Project + The Apache JAMES Project http://james.apache.org/ 2006 pom - - + + server + JIRA @@ -101,7 +93,7 @@ org.apache.maven.plugins maven-site-plugin - ${maven-site-plugin.version} + 3.0-beta-3 org.apache.maven.plugins @@ -146,23 +138,9 @@ - - - maven-3 - - - - ${basedir} - - - - 3.0-beta-3 - - - site-reports @@ -175,7 +153,6 @@ - 2.2 ${basedir}/src/site false diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 958a4260468..9e70c48d3ca 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -19,19 +19,16 @@ --> 4.0.0 - org.apache.james - james-server-site-2-2-0 - JAMES Server 2.2.0 Documentation - 1.6-SNAPSHOT - - Apache JAMES Server 2.2.0 Documentation - - pom org.apache.james james-server-root 1.6-SNAPSHOT + org.apache.james + james-server-site-2-2-0 + JAMES Server 2.2.0 Documentation + Apache JAMES Server 2.2.0 Documentation + pom http://james.apache.org/server/2.2.0/ 2006 diff --git a/project/server/pom.xml b/project/server/pom.xml index 6a40dd8500b..790ea290180 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -19,24 +19,22 @@ --> 4.0.0 - org.apache.james - james-server-root - JAMES Server - 1.6-SNAPSHOT - - Apache JAMES Server - - pom org.apache.james james-project 1.6-SNAPSHOT + org.apache.james + james-server-root + JAMES Server + Apache JAMES Server + http://james.apache.org/server/ + 2006 + pom + 2.2.0 - http://james.apache.org/server/ - 2006 @@ -67,5 +65,4 @@ - diff --git a/project/server/src/site/xdoc/FAQ.xml b/project/server/src/site/xdoc/FAQ.xml index 48de313442f..0b8d1865236 100644 --- a/project/server/src/site/xdoc/FAQ.xml +++ b/project/server/src/site/xdoc/FAQ.xml @@ -27,7 +27,7 @@

    -

    This is a living document that provides answers to common questions about James, installation, configuration, admin and running not already answered in the documentation. Last Updated January 2005.

    +

    This is a living document that provides answers to common questions about James, installation, configuration, admin and running not already answered in the documentation. Last Updated January 2005.

    From bdfecd2f21397d6ba3acdbb41db0ae44a410c91a Mon Sep 17 00:00:00 2001 From: felixk Date: Sat, 19 Mar 2011 06:30:55 +0000 Subject: [PATCH 280/541] Update parent to latest apache pom version git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1083143 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pom.xml b/pom.xml index d5acfe98723..2c36b7fdcf4 100644 --- a/pom.xml +++ b/pom.xml @@ -22,7 +22,7 @@ org.apache apache - 7 + 9 org.apache.james james-parent From 41fc6bc4be5d29a79583f99d2903dddf1b783281 Mon Sep 17 00:00:00 2001 From: felixk Date: Sat, 19 Mar 2011 12:06:37 +0000 Subject: [PATCH 281/541] Formatting git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1083168 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 108 ++++----- pom.xml | 471 +++++++++++++++++++------------------- project/pom.xml | 256 ++++++++++----------- project/server/pom.xml | 84 +++---- project/src/site/site.xml | 114 ++++----- 5 files changed, 513 insertions(+), 520 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 51a8d9d9788..ac220a11e11 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -18,64 +18,64 @@ under the License. --> - 4.0.0 - + 4.0.0 + + org.apache.james + james-parent + 1.6-SNAPSHOT + org.apache.james - james-parent - 1.6-SNAPSHOT - - org.apache.james - maven-skin - JAMES Skin - Apache JAMES Official Maven2/3 Site Skin - http://james.apache.org/maven-skin/ + maven-skin + JAMES Skin + Apache JAMES Official Maven2/3 Site Skin + http://james.apache.org/maven-skin/ - - - maven-skin-website - scp://people.apache.org/www/james.apache.org/maven-skin - - + + + maven-skin-website + scp://people.apache.org/www/james.apache.org/maven-skin + + - - - - - org.apache.maven.plugins - maven-site-plugin - 3.0-beta-3 - - - org.apache.maven.plugins - maven-project-info-reports-plugin - 2.3.1 - - - - - - org.apache.maven.plugins - maven-site-plugin - - + + + + + org.apache.maven.plugins + maven-site-plugin + 3.0-beta-3 + + + org.apache.maven.plugins + maven-project-info-reports-plugin + 2.3.1 + + + + - org.apache.maven.plugins - maven-project-info-reports-plugin - - distribution-management - index - issue-tracking - license - mailing-list - project-team - scm - summary - + org.apache.maven.plugins + maven-site-plugin + + + + org.apache.maven.plugins + maven-project-info-reports-plugin + + distribution-management + index + issue-tracking + license + mailing-list + project-team + scm + summary + + + + - - - - - + + diff --git a/pom.xml b/pom.xml index 2c36b7fdcf4..4647e56961f 100644 --- a/pom.xml +++ b/pom.xml @@ -18,254 +18,247 @@ under the License. --> - 4.0.0 - - org.apache - apache - 9 - - org.apache.james - james-parent - Apache JAMES Parent POM - 1.6-SNAPSHOT - The Apache JAMES Parent POM + 4.0.0 + + org.apache + apache + 9 + + org.apache.james + james-parent + Apache JAMES Parent POM + 1.6-SNAPSHOT + The Apache JAMES Parent POM + http://james.apache.org/ + 2006 + pom - - UTF-8 - - - - 3.0.2 - - - - maven-skin - project - + + UTF-8 + - http://james.apache.org/ - 2006 - pom + + 3.0.2 + - - The Apache Software Foundation - http://www.apache.org - + + maven-skin + project + - - hudson - http://hudson.zones.apache.org/hudson/view/James/ - + + The Apache Software Foundation + http://www.apache.org + - - - Apache License, Version 2.0 - http://www.apache.org/licenses/LICENSE-2.0.html - repo - - + + hudson + http://hudson.zones.apache.org/hudson/view/James/ + - - JIRA - http://issues.apache.org/jira/browse/JAMES - + + + Apache License, Version 2.0 + http://www.apache.org/licenses/LICENSE-2.0.html + repo + + - - - bago - Stefano Bagnara - bago at apache.org - 2 - - Developer - - - - norman - Norman Maurer - norman at apache.org - 2 - - PMC Chair - - - - serge - Serge Knystautas - sergek at lokitech.com - - - Developer - - - - benrdf - Bernd Fondermann - bf_jak at brainlounge.de - - - Developer - - - - sbrewin - Steve Brewin - sbrewin at synsys.com - - - Developer - - - - hilmer - - - Soren Hilmer - sh at widetrail.dk - - - Developer - - - - noel - Noel J. Bergman - noel at devtech.com - - - Developer - - - - danny - Danny Angus - danny at apache.org - - - Developer - - - - adc - Alan D. Cabrera - list at toolazydogs.com - -8 - - Developer - - - - vincenzo - Vincenzo Gianferrari Pini - vincenzo.gianferraripini at praxis.it - - - Developer - - - - rdonkin - Robert Burrell Donkin - rdonkin at apache.org - - - Developer - - - - niklas - Niklas Therning - niklas(at)apache(dot)org - Trillian AB - - - jcheng - Joe Cheng - joe(at)joecheng(dot)com - - - Former author to the mime4j product - - - - - mwiederkehr - Markus Wiederkehr - mwiederkehr at apache.org - - - PMC Member - - - - olegk - Oleg Kalnichevski - olegk at apache.org - - - PMC Member - - - - manolo - Manuel Carrasco Monino - manolo at apache.org - - - Developer - - - - eric - Eric Charles - eric at apache.org - - - PMC Member - - - - felixk - Felix Knecht - felixk at apache.org - 1 - - Developer - - - + + JIRA + http://issues.apache.org/jira/browse/JAMES + - - - Rob Oxspring - - - Contributed to the mime4j product - - - - - Roger Fullerton - - - Wrote spfjava, the first spf implementation in java - - - - + + + bago + Stefano Bagnara + bago at apache.org + 2 + + Developer + + + + norman + Norman Maurer + norman at apache.org + 2 + + PMC Chair + + + + serge + Serge Knystautas + sergek at lokitech.com + + + Developer + + + + benrdf + Bernd Fondermann + bf_jak at brainlounge.de + + + Developer + + + + sbrewin + Steve Brewin + sbrewin at synsys.com + + + Developer + + + + hilmer + + + Soren Hilmer + sh at widetrail.dk + + + Developer + + + + noel + Noel J. Bergman + noel at devtech.com + + + Developer + + + + danny + Danny Angus + danny at apache.org + + + Developer + + + + adc + Alan D. Cabrera + list at toolazydogs.com + -8 + + Developer + + + + vincenzo + Vincenzo Gianferrari Pini + vincenzo.gianferraripini at praxis.it + + + Developer + + + + rdonkin + Robert Burrell Donkin + rdonkin at apache.org + + + Developer + + + + niklas + Niklas Therning + niklas(at)apache(dot)org + Trillian AB + + + jcheng + Joe Cheng + joe(at)joecheng(dot)com + + Former author to the mime4j product + + + + mwiederkehr + Markus Wiederkehr + mwiederkehr at apache.org + + + PMC Member + + + + olegk + Oleg Kalnichevski + olegk at apache.org + + + PMC Member + + + + manolo + Manuel Carrasco Monino + manolo at apache.org + + + Developer + + + + eric + Eric Charles + eric at apache.org + + + PMC Member + + + + felixk + Felix Knecht + felixk at apache.org + 1 + + Developer + + + - - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk - http://svn.apache.org/viewvc/james/project/trunk - + + + Rob Oxspring + + Contributed to the mime4j product + + + + Roger Fullerton + + Wrote spfjava, the first spf implementation in java + + + - - - - james-parent-website - scp://people.apache.org/www/james.apache.org/parent/ - - + + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk + + + + + + james-parent-website + scp://people.apache.org/www/james.apache.org/parent/ + + diff --git a/project/pom.xml b/project/pom.xml index 2302924bcfd..89b7d1672cb 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -18,142 +18,142 @@ under the License. --> - 4.0.0 - + 4.0.0 + + org.apache.james + james-parent + 1.6-SNAPSHOT + org.apache.james - james-parent - 1.6-SNAPSHOT - - org.apache.james - james-project - Apache JAMES Project - The Apache JAMES Project - http://james.apache.org/ - 2006 - pom + james-project + Apache JAMES Project + The Apache JAMES Project + http://james.apache.org/ + 2006 + pom - - server - + + server + - - JIRA - http://issues.apache.org/jira/browse/JAMES - + + JIRA + http://issues.apache.org/jira/browse/JAMES + - - - - james-website - scp://people.apache.org/www/james.apache.org/ - - + + + + james-website + scp://people.apache.org/www/james.apache.org/ + + - - - Server Development (including components) - server-dev-subscribe@james.apache.org - server-dev-unsubscribe@james.apache.org - server-dev@james.apache.org - http://mail-archives.apache.org/mod_mbox/james-server-dev/ - - - Server User - server-user-subscribe@james.apache.org - server-user-unsubscribe@james.apache.org - server-user@james.apache.org - http://mail-archives.apache.org/mod_mbox/james-server-user/ - - - Mime4J - mime4j-dev-subscribe@james.apache.org - mime4j-dev-unsubscribe@james.apache.org - mime4j-dev@james.apache.org - http://mail-archives.apache.org/mod_mbox/james-mime4j-dev/ - - - General - general-subscribe@james.apache.org - general-unsubscribe@james.apache.org - general@james.apache.org - http://mail-archives.apache.org/mod_mbox/james-general/ - - - Website Development - site-dev-subscribe@james.apache.org - site-dev-unsubscribe@james.apache.org - site-dev@james.apache.org - http://mail-archives.apache.org/mod_mbox/james-site-dev/ - - + + + Server Development (including components) + server-dev-subscribe@james.apache.org + server-dev-unsubscribe@james.apache.org + server-dev@james.apache.org + http://mail-archives.apache.org/mod_mbox/james-server-dev/ + + + Server User + server-user-subscribe@james.apache.org + server-user-unsubscribe@james.apache.org + server-user@james.apache.org + http://mail-archives.apache.org/mod_mbox/james-server-user/ + + + Mime4J + mime4j-dev-subscribe@james.apache.org + mime4j-dev-unsubscribe@james.apache.org + mime4j-dev@james.apache.org + http://mail-archives.apache.org/mod_mbox/james-mime4j-dev/ + + + General + general-subscribe@james.apache.org + general-unsubscribe@james.apache.org + general@james.apache.org + http://mail-archives.apache.org/mod_mbox/james-general/ + + + Website Development + site-dev-subscribe@james.apache.org + site-dev-unsubscribe@james.apache.org + site-dev@james.apache.org + http://mail-archives.apache.org/mod_mbox/james-site-dev/ + + - - - - - org.apache.maven.plugins - maven-site-plugin - 3.0-beta-3 - - - org.apache.maven.plugins - maven-project-info-reports-plugin - 2.3.1 - - - - - - org.apache.maven.plugins - maven-site-plugin - - - - attach-descriptor - - attach-descriptor - - - ${basedir}/src/site - false - - - - - + + + + + org.apache.maven.plugins + maven-site-plugin + 3.0-beta-3 + + + org.apache.maven.plugins + maven-project-info-reports-plugin + 2.3.1 + + + + - org.apache.maven.plugins - maven-project-info-reports-plugin - - index - mailing-list - project-team - license - + org.apache.maven.plugins + maven-site-plugin + + + + attach-descriptor + + attach-descriptor + + + ${basedir}/src/site + false + + + + + + + org.apache.maven.plugins + maven-project-info-reports-plugin + + index + mailing-list + project-team + license + + + + - - - - - + + - - - - site-reports - - - ${basedir}/src/reporting-site - true - - - + + + + site-reports + + + ${basedir}/src/reporting-site + true + + + - - ${basedir}/src/site - false - + + ${basedir}/src/site + false + diff --git a/project/server/pom.xml b/project/server/pom.xml index 790ea290180..0a9fd90a505 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -18,51 +18,51 @@ under the License. --> - 4.0.0 - + 4.0.0 + + org.apache.james + james-project + 1.6-SNAPSHOT + org.apache.james - james-project - 1.6-SNAPSHOT - - org.apache.james - james-server-root - JAMES Server - Apache JAMES Server - http://james.apache.org/server/ - 2006 - pom + james-server-root + JAMES Server + Apache JAMES Server + http://james.apache.org/server/ + 2006 + pom - - 2.2.0 - + + 2.2.0 + - - - james-server-website - scp://people.apache.org/www/james.apache.org/server/ - - + + + james-server-website + scp://people.apache.org/www/james.apache.org/server/ + + - - - Server User List - server-user-subscribe@james.apache.org - server-user-unsubscribe@james.apache.org - http://www.mail-archive.com/server-user@james.apache.org/ - - - Server Developer List - server-dev-subscribe@james.apache.org - server-dev-unsubscribe@james.apache.org - server-dev@james.apache.org - http://www.mail-archive.com/server-dev@james.apache.org/ - - - James General List - general-subscribe@james.apache.org - general-unsubscribe@james.apache.org - http://www.mail-archive.com/general%40james.apache.org/ - - + + + Server User List + server-user-subscribe@james.apache.org + server-user-unsubscribe@james.apache.org + http://www.mail-archive.com/server-user@james.apache.org/ + + + Server Developer List + server-dev-subscribe@james.apache.org + server-dev-unsubscribe@james.apache.org + server-dev@james.apache.org + http://www.mail-archive.com/server-dev@james.apache.org/ + + + James General List + general-subscribe@james.apache.org + general-unsubscribe@james.apache.org + http://www.mail-archive.com/general%40james.apache.org/ + + diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 3a80e916f19..dde14383d2b 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -19,63 +19,63 @@ --> - - org.apache.james - maven-skin - 1.6-SNAPSHOT - - - - James Project - images/logos/james-project-logo.gif - http://james.apache.org/index.html - james-project-logo.gif - + + org.apache.james + maven-skin + 1.6-SNAPSHOT + - - The Apache Software Foundation - images/logos/asf-logo-reduced.gif - http://www.apache.org/index.html - + + James Project + images/logos/james-project-logo.gif + http://james.apache.org/index.html + james-project-logo.gif + - + + The Apache Software Foundation + images/logos/asf-logo-reduced.gif + http://www.apache.org/index.html + + + - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - - + + + - + - - - - - - - + + + + + + + + + - - From 837e92beb02452bce5f59c073a6629bd5ab54431 Mon Sep 17 00:00:00 2001 From: felixk Date: Mon, 21 Mar 2011 14:53:29 +0000 Subject: [PATCH 282/541] These server docs are some left-over [1]. They are there only because there was no better place. So there's no need to build them each time and to have them released when releasing "project". They still can be still be build when changing to the relevant directory. [1] http://www.mail-archive.com/server-dev@james.apache.org/msg31624.html git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1083813 13f79535-47bb-0310-9956-ffa450edef68 --- project/pom.xml | 2 ++ project/server/pom.xml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/project/pom.xml b/project/pom.xml index 89b7d1672cb..b3ec4f4a90b 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -32,9 +32,11 @@ 2006 pom + JIRA diff --git a/project/server/pom.xml b/project/server/pom.xml index 0a9fd90a505..2ecfa96cc85 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -32,9 +32,11 @@ 2006 pom + From ebe70d7a87f90a7bec636a79860d2a5a20ab02e9 Mon Sep 17 00:00:00 2001 From: felixk Date: Mon, 21 Mar 2011 15:09:48 +0000 Subject: [PATCH 283/541] [maven-release-plugin] prepare release james-parent-1.6 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1083819 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 2 +- pom.xml | 8 ++++---- project/pom.xml | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index ac220a11e11..e3a3029d48b 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-parent - 1.6-SNAPSHOT + 1.6 org.apache.james maven-skin diff --git a/pom.xml b/pom.xml index 4647e56961f..7914a3861d6 100644 --- a/pom.xml +++ b/pom.xml @@ -27,7 +27,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.6-SNAPSHOT + 1.6 The Apache JAMES Parent POM http://james.apache.org/ 2006 @@ -248,9 +248,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/trunk - scm:svn:https://svn.apache.org/repos/asf/james/project/trunk - http://svn.apache.org/viewvc/james/project/trunk + scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.6 + scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.6 + http://svn.apache.org/viewvc/james/project/tags/james-parent-1.6 diff --git a/project/pom.xml b/project/pom.xml index b3ec4f4a90b..319dcdf2157 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-parent - 1.6-SNAPSHOT + 1.6 org.apache.james james-project From addf3da06fbee1c204bfc4eeabcb7f027d3d9f34 Mon Sep 17 00:00:00 2001 From: felixk Date: Mon, 21 Mar 2011 15:10:06 +0000 Subject: [PATCH 284/541] [maven-release-plugin] prepare for next development iteration git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1083821 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 2 +- pom.xml | 8 ++++---- project/pom.xml | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index e3a3029d48b..6da5d79f883 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-parent - 1.6 + 1.7-SNAPSHOT org.apache.james maven-skin diff --git a/pom.xml b/pom.xml index 7914a3861d6..c8f8e564f84 100644 --- a/pom.xml +++ b/pom.xml @@ -27,7 +27,7 @@ org.apache.james james-parent Apache JAMES Parent POM - 1.6 + 1.7-SNAPSHOT The Apache JAMES Parent POM http://james.apache.org/ 2006 @@ -248,9 +248,9 @@ - scm:svn:http://svn.apache.org/repos/asf/james/project/tags/james-parent-1.6 - scm:svn:https://svn.apache.org/repos/asf/james/project/tags/james-parent-1.6 - http://svn.apache.org/viewvc/james/project/tags/james-parent-1.6 + scm:svn:http://svn.apache.org/repos/asf/james/project/trunk + scm:svn:https://svn.apache.org/repos/asf/james/project/trunk + http://svn.apache.org/viewvc/james/project/trunk diff --git a/project/pom.xml b/project/pom.xml index 319dcdf2157..998c0aab784 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-parent - 1.6 + 1.7-SNAPSHOT org.apache.james james-project From bf6f36f7184532b387b9dddf06a6918f27fbf416 Mon Sep 17 00:00:00 2001 From: felixk Date: Thu, 24 Mar 2011 19:21:32 +0000 Subject: [PATCH 285/541] Update to james-project-1.6 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1085084 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/2.2.0/pom.xml | 2 +- project/server/pom.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/project/server/2.2.0/pom.xml b/project/server/2.2.0/pom.xml index 9e70c48d3ca..c8b4b3ac71c 100644 --- a/project/server/2.2.0/pom.xml +++ b/project/server/2.2.0/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-server-root - 1.6-SNAPSHOT + 1.6 org.apache.james james-server-site-2-2-0 diff --git a/project/server/pom.xml b/project/server/pom.xml index 2ecfa96cc85..bb16ec561ba 100644 --- a/project/server/pom.xml +++ b/project/server/pom.xml @@ -22,7 +22,7 @@ org.apache.james james-project - 1.6-SNAPSHOT + 1.6 org.apache.james james-server-root From 128f201b2006e6c1276d4efb6a90aede77490ed0 Mon Sep 17 00:00:00 2001 From: eric Date: Fri, 1 Apr 2011 13:53:47 +0000 Subject: [PATCH 286/541] Update the link to release doc - Add summary steps. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1087708 13f79535-47bb-0310-9956-ffa450edef68 --- HOWTO_RELEASE.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/HOWTO_RELEASE.txt b/HOWTO_RELEASE.txt index 7a1c4b5fed8..354ca670b07 100644 --- a/HOWTO_RELEASE.txt +++ b/HOWTO_RELEASE.txt @@ -1,4 +1,14 @@ -Howto release via maven release plugin: +Howto release via maven release plugin +-------------------------------------- -See http://maven.apache.org/developers/release/apache-release.html - \ No newline at end of file +See details on http://www.apache.org/dev/publishing-maven-artifacts.html + +In short, just follow the 'standard' process: +1. Prepare pom for release +2. publish snapshot +3. prepare release +4. stage the release for a vote (don't forget to close the staging repository) +5. vote +6. release + +Don't forget to add your key to http://www.apache.org/dist/james/KEYS From e0796afd921a0c47f4cc4088defc82db9156e281 Mon Sep 17 00:00:00 2001 From: felixk Date: Tue, 5 Apr 2011 04:08:50 +0000 Subject: [PATCH 287/541] Add mailetapi logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1088880 13f79535-47bb-0310-9956-ffa450edef68 --- .../images/logos/james-mailetapi-logo.gif | Bin 0 -> 9121 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-mailetapi-logo.gif diff --git a/maven-skin/src/main/resources/images/logos/james-mailetapi-logo.gif b/maven-skin/src/main/resources/images/logos/james-mailetapi-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..085d23ec1d7fb2e39e948ea3ad5e6b66d384e48d GIT binary patch literal 9121 zcmdsc`8U*$_y2Pivsro$L)IE&9b02blr&?>E{rjVEZLK6iRhKx80s|`J2m#5Aqn9% z7_wCqQmL0L(N1Z7RrBfn{WHFgAMQE#hkMVt=iJ9V_i?Y4&2b}RzYs_O@D=zU;BYt! zg%S}F5fc*wK~P*=9EZb6Nl8gdOUuj4@7uReR*Hbf_Ir%wk41_lQQhXw?OhK8Ow zbLQ;Xv**s8i;9YhiHSKM6MO#r`3n~=BqSsxCMI6GbSYM0xYo?9=5){;;qbiU;k)6% z&*W04+2gE8=IS(TU%Q@+S>ns%jI@; zb#-@l_w@AK?z++2+uPsYKQJ&bG&IDosof|md)0lD$NT5YavhJy8yOkl^ZDcB;}a7T zQ&UrSCnsiRX71g)H#MVB)2C0Dm!Cd+_Uzw(|9$jw>&MK@ zujQ5BUngI@c(Jy&wz09Xx%qN)bMw`!S8v|DdH3$!hYug#{d)cO_s`$2HwAA$?|gjs z``fFXot;mgK7Ia!FJHcX{kr@6+jz?-~ZspxBve8@B5Em-v!@) z2n2%fzkmP!@$1*GKbih`|F1Rv|2K-?;Sc~209yYm^?#fIPy!$jEpN@`45y(aG`uFb zRijy;l5K@`XZ2W)w0_v~L}$&Nzwzcwd7G}<$pUq1v)5!--E=YO^i+k-ji4!dhyPgE zJmX;#wbp;qbK&*8W=h-fn-@P*-CEq+PnCu(Ow}*6xZfCI%eJ_d=)}24J&@5PI@a1= zzSfLcnAdFfT$`%2+k0BexguZLxjMb!0jJCVg>qss&6n=%q0lzn+qpJ=xKv|q`YYJt ze7HqSbvjJjmCoFIY@b7ati4;S{p9L&N=LqBy~Rz>jn~01>(Z>Q_-8!r{_ro)@|3N^ zl-R$6wgX`Q{1lD&G%#v&{;2KZ|(H6mKr#(i!^ArcyFGr zO<&)C=C%5ElK!^j$P1@=YH=gI(zU)fxH9CEN~5n^N3DOQ?+5KToMXdQW_DETT}3|D zg5*D?Qq5jvQr~Rgo@r)kH?A`EjN{p9P1fI@r$}DSw^e1UD5hiOdm_qF59|IFU$5F+*)T- zduS?ZWiwH5af)xG8rDptbE3q>_*SV0sw;G>3TIr3$81(P(3tauI2qx8xDA;CYB`E>$(q zHLuuf1g%v1gsGWjF)=q$@_b0;{Xe7aglVEXi#04^@YX5ogx6$sxnsoOOVzptD6dUgpSi{Kt%yw_!E8*TbVRd~!(Qf86?RR4rJl^F;!-Kfos!R%ZXq?nYHdBC zF4!)Zs6hZ3I%3e9oWV%#%qb(*vIKfa?1h(;b>s4wD(hRSw&!Q(&Kzv5~eJ zsH7ka@NZLvqe&knXq+UGCz|Xy;x}Pm3BPnz{E!Qinp6Dt+gsM;s++R=Th4zQ1_Rq8 zVmc-e15LZMi;vV}fvXKGO=+(bTq9-pM(^hDt88nQ4?JMJN5}BUAG8N%p`z{<@$L=rb;;M zQZ5{bgkVOIx3&k9!SdNj4S~B~7GYlVga``yg5d-=t4IxkVVNQgTlsXYyQ#--TxI-N zxve;Whl$`RAFi=R_jW5vbTYh@2DVim`f0(M^ivf;r6U?oc2r!H9|!lMcp?BErUPF8 z0DX+CH!u_PX)b!?GNGoz*s`&jTvJech3&#yWuF7Xaeiktjc zDsQ8tea1#I@)ck5kbHp7FVw`|cwLs?1e_@C+{qKFD!!{fqFAAfvp4%xxd$TDg^FTW zw@z37%Y5$VPZ6N>OcjfD03}4yUelO_s<0UKO=x0fhhgL@<$bQOhN`Wzt8ZVPr?xQ31kaUbnowl2SOrgn8#$r09>(fg))Eiqjo3W}sU;)bViTS?_6kmkItyW! zD^U&zkTc#rRScUkX&7%@QE6UXvTWGKwIQrPa$=#`l*5p9d_&9omfUihgz{($bITWS z7MjD}O^AP!&Fd{XFCG~=5)RphP)GqCUY00P2gni$B~^bGWgdGUM3ji9f^R$*H7dH% z9`lODtU%s=icP9we99#ZP99d+XSPIn9dkE3#NI73;~|uc5Z8qPgcV48kD>C}!Dg|5 zlZ!X%7nHJDnz9$C7oK3?ShdJEW~@Zo#uG8M};u2Bg$?0oXqoZzX_-~M{5L0o}oK_j1tlLJHmZnD;o#05dB@(6tcni6`(cloaX zsAy1Rim*7c{iC8HuIDx7iA}Sc{HlmIK3w|R?28d`!~R*z@C!NcR%&{cAi{Xriwxl< z-}==qWd7}>%l$qNTC<~so5W({x^Mw*nT&@UwXx(zgn)Q5-s1ghYaWkwR7(aBlbSpW zVLiQSaJUcL(Jm0JMz$C2;yn;#A0aa-WI~^qHzPE5@@KlfMKQO>FkJ3O^0Q|Z1PS+T zKN*;;E6@Wpy?h&}XRK@pMI2|Q4Nal9H9?_@FA$OJmcJF>`Q+#FnoXqNu&ugYImYnC zF=FT0dkBd3=y`mTA<8R6LZRVHm1ywQ(D&Dzygi=wb9LXDuLmq-DgXsD#2{YwXv3^! zkbP-%?wDlT!_ro^uMj+e7mDSuG$PCJd5GjZb7-~=KA^W$AZF7?5&sA_CN3jV06GzJ z?zzj2%61MWOujq&z%-jHZy1064M4s8w0}>$v5;cO$|$)k=bk{~-}tK&`eGy+`o0u~ z>X;{q4Nt^76`cW0qgce{TX@C&eYQ@|*Z;npE^2s=(WqO=((sXdDwKVJ()^v>^;T7~ zw!}7%ka8x8`t|yO|8Cju?Fc&V8W(ed{_Sa|@6^#6r))V*GgbR4>E3zOv$_zY4~o1yXG9jou}Yj~lRFxij$zS@f&Cc3C(#D&J73m*OOUS5R^7M76HuU9bh1b~8nAAoJa`Yf8!25`)<)F*Rm~(TOCQvxb z3F+Sx@5edv)6M-n*}H2Iaef=FW@vpF4k&L^F*nJV#!t1mI;2NQD&XCadC)Io&K+ZL z)bL*zU9=GxhujAGkbnXi!Qz2Fk?B78h?93})HQZ63)FOg-Rx z>CW!KX64g5D9Q9M;!*$vtqA)P=t&i@z{3pi&)m`FUWP(Y>se7~MYPu#qBt%Qsff~h z1PNV1T~9{c4y1X|K++1(9^&IBiIVR`bQhn6gn)4uX!`if!3+33YxGhMM3xKDCS$C- zsJM`neT*}t!Xu^T-e>X1o<$*VFqOmC%a=TEj)%WfGLlJ7us1*ws^yM#8qg^aF%D?# z>*K)z^Fl!1K-$SjFfft^n?<9Bv*{bzLVlMqDSrW61R@1VuY;mHLjinD=LA*)gxo3t zy-UCpJY9m9gERt-c5>_}sF6m9JTJj+SSPR(lOCD$Dmp8r(C#O~yE6_EjkhlUbV8XN zEYCAlO}8i#RNGqe(Cy@_uc8<_x)2N(B;)D6T=0W6IC>s}h6G5)fj>fMKO5PkEYJW2 zFp|N4gJ>L^IUJ zd?(XC&VAn6yH6>$$Iv?(?+Qp-Kcoj!H;*3}509Hg1^Ml#Vd9`BnW!B^VI25t6RU`KqlD1HfMl8nxHV2QHwI5jTh5wUiA+G` zxR6s$m~W$6i&&L%c-FjRiNLT#;kbMBtdJl6I8a*>TLdRIo+6FwUWt?u5tQKQ5C{}V zZa`|x-4@TGyPGQlZ?LSQIfIgB`b}1Abo{nV68t17`{6G8+O$a zU)oE-r93FG9F{EM;5ge7HZD@tcw?(h13g>wtbz!T1%M455E+gj<4A&8r9WJqbyp z+RzvbEjrV2PNrNp-++%PiIi#G)-|IjIAee+9@e1@!R=2J@$>Yux&B{#9WoDaqX~6B zX&DTw2gr4BY`t6*kfSPm6Aj$z1F_klV**Whk+atr?43*Ka>CSaCpWM#c5CvDp8HSU zL6@@7V(yq07CQNdWN@ZCGZJ+vS!kgVCAO8E>-2}u$ozx*{Pa4?@WSn6Xmn0E?Z--dBLS#TNft}h+3i-35*OIwfQ*0%C>(kq2Q$}-)P;GSzjm%UEb#)qvOyx9jEn`*#(C!t z?;P&nq0er^wRsTN|EQOMkaY0OTqF9uEj4RfsT_|qC*6#9Lw2&z2|cJXJksUl&1eof z*B8Fg$vsqnTMxw~t+~KIL!((}hGLXums|%(On0)?j_ftxhNodtRH5wtGE{s2HIWny zgN2OXB4t#Bog-;_y+xl(yTUZu0J4yWQ-6J8e`8|5?wdGyiW^>2xIKYJzI`JsyUc3= zj`&s-px$tA7&5XYR1ZiJ9yIj7IK*#)oSH?XgEvPfATca769_uXL7U@q&B&P26(PYx zsIqVIh3^BU0y5Hd8j@8G8JmQ}u3!veYTBHtZghHgu+S&d24ZKC!L!g2BV>xzY4Jxj z>3Fy--sC*5N1+K44eI``29W@e2KHHwg9RKRT%;#%8&Q^cp+}>z*A~=`q{Xwad?r@n z@pYIk;B~VV^tjzcMtc0sZ5Kt;_yY$GZK$_ zDl6UKiAg7q$&rxNPAP4^aOyI&j3Zs~8Y692G4?9&Y1S=-9qI1L4&fGQ!iY;5Z&aRj zv?6(?&txn%5;Fjiti_M{@y>sKA$6|`tuu?jJ_J=~%48M0y6`BIAljTK$iPFqZr1(X zI-F;6v9y#W8#O6One;gfb{?T$YwhaVzBkMa6MK!Tmlv)j&z#yW_>i*q;4+lvZ;7v| zs>hG*v%$1-(IvcTxmiVOUX2-n5W6xM?R3}d!B`C!T|ws8anSb!l+$&yL+x*kj}0H{ zj6%l|;StV~BVH9}!D$i3t)x*jZ1)l>#ZA2eOZYFtE#q%AMTj1FU+up>SDF4UlGn?i zNkJ(#%CbzzZ-kW#n%IFbbp&dsyj4}YEPZOcPfC1ArU67N$RL{MFoXvRC6VY@(pZod zXigq8+m^cIt>~J^k9&-GlrG&mTT^S0YsQnaf;?`;^S_s)D`t~_Hlz6i5ZfafDTDlq zv$v$G<*I$9<;y|0^X$t%d9X>EY6F-n0=R2~>bDp2?LjZgv(hi_<6d+Ek-+$+W#Q#X zVlJn<85mz!94wKk)~#r=f5am^E(OsB?=Ve3=Vt+>d9QzQ^!DK{UpRYEDm7KMMh{6% zLU30xEegtUzQuXT+&6u;$O=N{bhimQTo}fBg z#I!<%upIirRpF?oecHme&)%*&GD~=L-|rGO5($KoGpyr_;DgImZxE9T5ttW?_g~^h zKF%&&x<%U|?uRKSrFAC1OfDsjMUx0kylGiH+>s(_u>Ri8lNl2MKLeo zANmiT!n?b(Hay=8oqE3kEyi6|cydpU=(*YUPuCs9Tpf^{)~Wpht~>1Z`C8AV1sM_G z)#C-)cTf6f23~$u>P5O_0?1BUM9gJe7jO|Oz9V}8As0sAoVS#&P8Ha;3aaUp3-!I^KNUy*fA}KE}T-$7#WLy$k)l0-;e!$R_zkqGG5QRWP z5=4(HWZ6g;eusPRf-5xDFutSR2HqW+fJ{*^Uo?=D%32wK~Z zw{fTHJiR{>@4SoHx18*VH5B;LiZVf^2pWvDI;f2$UB!KMkks{FyX%ZW%AvotK+Jh4 zQB7q7Zw#?=JIWaI(tF){^+P}>&Q51L)^+>k#kN!U-8cu>W;yz)_|8PDgqWG~ex=@p zBuotW#B~{}tE9Z|pX+Ytp_35-isxv`NiT?(@5c`fcY$$kW6;HW{d}q~iAtz})b(Oal+aH-SGH!4SGuy3A&fKP?E_@Rgsp;xvUJ2awtUxMJOuTJ}`S zK80cT3Ukigk{!+0qB_P_k}s=dp=+2t4xbuc5u&V-QUzi#Ox(`Z(Cw#UkarsAwxD@s z=^Yod1Pi#G3{}CAzq}4Y|BaZvvyfBp?|+3p&mO_`8l0BuFJY=@wcB|^`P9*9psMbE z*yTiSC-=ueg5+wpDWDiUnyJXKpA1_F%ganLH_Dck)GTVHx4Nsa3w2+p(`%J`JQt>1 z>y70RV)L`9^J8vZszK>8F(3fo{GannB^r=r1~q)IISH~%rBThURx&l;$xbFlWlWE}*h{6#PKUNyOU9 zOX^Aqj%Rn8_^?Yl^Y)4kA~BP@8eak`FNc^pwG;*4zfL-Wx>EB+{ci1{;xFMBKN0VC zll)LOSwF+v%1(}L@*jShTW~u2@4AWb=Op_cvzVc8Pv=h%spkelKagYNz7M}DrlY{EJtHV)WHfs;xe$uGTLlK!Rdcu2i0^8|^Ki{%V z1x^H~B3H+qRpkS5;g*D7h?qb_40fc0GO2Eo!KS&PBRR$|qsN+e0rlyr%JeXu8brFD zvd!xve!I>42$vddnrlY32{3abKVPHIGfnG2rHGz=+572p#|-v_2^Ba?g-saRdl574 zEq^Om!yy&Z(Er#4eve5rJd9&YiuruEBOg{*p0l9O7q(hbHO5d6iws2BRH{3+jy(-u z_m%jwDQSr5CJg2;l&FHtJsyxoo%%N+Q#$qUfGwSxFINNHrF>E<#TlM`KYAO!Mle4t z5)042QSBAixX~WGAad8)(Ws)>EW5XDxA2YunEJ9;J)mxRW-GUC*4nA;^ax!rrI3mn zQWeiAG?wW1^vYQ;lj$T=vsENrt~p(~n${|tqiSb%FT@(~EDY2rRBM;6&w)%x*Izku z54C!29F-7oO4!}quF9U*6nJ$wJjcUhHzxbo0ok|V>=gQ%r=^=-8RH*Ac+MDVLZ^)6 z6MbODiM!;*RFSY!>)$$%X+)~SN#B(E`WpRDrrmNn^zQ7vlmYyPhQUQ!c!bA#{Sib} zH?Q0+_w1#g^~7|Is%^i9q?!h?{OOwwuBW5rBX@lF6$JI)GkJbY{6us}yxnQ&MQ&A2 z(VMN@{2?cfK}NqjH&tS{+|F7$su+^zuN13i8E#S_XS$&pqn*vRAf;pr?2;P8)iyN-Lf{K;sTRHQsOVw@S zDqgG`v-hI7LT@Qa6|!XmcMIv13VWMDdXeJfRv+D<5?BN=3=Vk7(L@ur+rrL{(zl?ZW`Qc6&jV|Kgh5mw7c|8p`tT z)$gPD2$uf3a!%x$@) zyDwF3&5LUd7V=ZX(!ma3?D(lBh#6zGsIrx1C>$)`*xPI<%RGQNa{+gJHzUsQki79|%wlg1l^=<59 zrFTmDdV?Q4Wb^E5r1g*vC?r8@vaC{?ki{vDfF)LQuItPzJ}4wA)rHLa`^(7Lhl?47 ztu|_zj83{tRN=~4Y4Un`+HT4IPBLaSMCrM5hm|`Tg2mQU`|Q{P6;$9+`XtdXQ6uO2 zYi0GL2`A}afMjCsr^L;KS1T`-4%G)KUt*Ov&#Ztn@?c$=fqIDekC2}z)EHoKbiz50s4rfa> z24PEA_(VrPce{Es3GEfKDp?U62w4@cUJ}@AQ7O_c?u|mLg-*^%vjy_K#SywPBnP)h zN#pi{zrTDwd8E$Y)XHl^Q(RwLbQ6X=hnN&UTUDcV>dolVNKEv-vS52S6*EWTj~Gjh zd9?=dMJtAJir5HiQO~NI^{X)&?*mmYK9oDGjyZWa$im#1oJC*nCH%kxeuP(%HEXiVCRMI;)M!no4L&_Bz;Fm^g-hb8pBL|t*63Uk0MJNNEZ)Y?FUf9e;@%80b^`oFsvWdubf<*Mnp}83ch0V za@YxJ^gExscfhm5qwE)b30w`{xIse5nM*oG^^2) ze;Mroe|&$C*+IE@pw{}x;|&naG~$LbD@QGEz85+ko{Afr*HzQ&L@D`Rdf<5-b~Q#` z+kU`8?cb`&Z^unNT1bk}vsII@R(#IP;@68h20gToPEeoE%E11mG#aZ}>eXk9OzK7b zSn=>r?Iff8-l#DR!w|v!wFC>kQ7BqnYz}D|p1SB}*1ndY^4vj00LFg6sN?34f36~u z1)W2my01%E_4*0Ba-cF(1HbUbt71M&sWJfNuP?VQoBFi4YQJ;U29AS2)M zz-}_ui;P(3iR7m5Q63f>Aj7>VC<6*u%gaTnKMfIbwidF1<&87D6!0ng;b!>Q6uj~X z!C*wmVno?>L?vKEHFiWTeMFr-LaZIp=pNDJk0>X#yf#CPy0ktgrBZu`3YZzBr4)UO zQG?nPfkD8iVeIIk^id=BsB!M-!P?Oy{85wnQT^`Gqr0QW;1;GLe2Oyv$P9{t?uP3M zsl90)Vd9Fn)Jv>89yyuPh;ryAK7NipHNh{jZfV)#SM>6;QI zKe3^;<6+(7XIv$ndVAB#VfZ8Ij%K;%V3fTgomJIkL3pbfpJ5Jw%9pI!{s^4@^l?V?-@7QLzd^GwhaiD-OS ZQ|-G`9q?%`Zn{%>y34?>NdyHP`9HjfXDR>y literal 0 HcmV?d00001 From 445a31b6ca7a0496aaeee9c957ff40ae6a52b763 Mon Sep 17 00:00:00 2001 From: felixk Date: Tue, 5 Apr 2011 04:16:37 +0000 Subject: [PATCH 288/541] Add mailet-base logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1088885 13f79535-47bb-0310-9956-ffa450edef68 --- .../images/logos/james-mailet-base-logo.gif | Bin 0 -> 8795 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-mailet-base-logo.gif diff --git a/maven-skin/src/main/resources/images/logos/james-mailet-base-logo.gif b/maven-skin/src/main/resources/images/logos/james-mailet-base-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..52ce0b5622dc3b1b97912aa1959dd17473904e04 GIT binary patch literal 8795 zcmW+*c{G%d`+a9IGmM#er|jzxC1fed62>k{V`(9Uq9n;)*&6$vu`f|$O;L?~XY8_+ zJs}avnj!l(zt8t~&wc)Q&Uya4_uO;tqklBo z2ng_TiT(#kNlAHm`Sa(`D=RCjsj0~yb0=OXEG#T;-@ff*Y4y0!W^Yr?-=^Js_sYC5^G;Fb ztq*VR&|Y6D$u=*|y;GHct>)eBk6Cw1b8Rc~Z7Sc}Runi?72T^Yax8!6R#oKEKzr0c z^JpyfZKhcdR%^AC-fJ##Xs>wOUgOkM=H689-CFguwZ^Zr(WA4@`%9Bwf17_`U|?im zXk=t$OiWB%TwGF8Qd&Y{YHDg`X6Bm@dFA23jb&sim71TElb4rQP*Cu(=mU*LD=#mv zEh(+4s;aNAZ>|h&s}1aEi2ht3)Y%Z#*%;s1nB1C^`#U{-p{%^SDW3cmfluD;J4)tUYe<>LKLLKSL8yn0UA1s<2 z{V>v3@_nFUe5h<<{Yn_oA8c(wXt9>9M-G$*Qf1y!q+8`KiJ`GbM9V zbxXf$o0^*1+S)ohJ9|HO_V)G;4i1hE4}AarePUw#$B!T1=H~Z$dJZS17Js)c{_goZ z-~DH%e{pVbW#K=LZmx8!FZVJQ2N)|8N86v*8N=(0iM@@Xos9|R{>ahM#Psy^+}zyX z<*B8mrIo|Q<)Z_}-(PF1vqy`6n9H007_)2ZE1Uo3cebZ?w|?(zE$nQq93IZ@?ac4( zt{m+wFqw-?=F0l|`t}xMb8BnkXnliuw6nd&-1v`&yE|)pyBi1l>qmQAM@MT%M_aqQ zJG*;_yUg7^CX=~)bab@$-~7M!0g+ue1OS+T^#9iXc>+K&fqhm10~)m{2z6Z2s*{%0 z5(b_y%rGdoYN6Y(2f+iRFeBSLBj04)#sAD?i9IuT^W}K2^#*;lr!gU ze411Z*x49v`F_<})$hQYYo#()Sj}(G(J<4nd{O`H{?v5VpyV6neBJRM91i9VUkmoP z`e%^C@5d`$W<>2CICo%W?|29uo_1L#dhNpVf2YJ2Otgd_Z*j8x8g;v_cD?)_-{$?X zvfagnTB}joudh^XpPrQ1I~sMz7~X5Tv6ef;gpXMZ1~H|m+zs*k!ufBH=~e^V`AUd&^buME9gX?Xpv(E82J!`kI% z!c(_JY`O0}y8Kl&?`eaz#}X3x0mq0UKpWlIcMqe=SU#S7 zQ%9aVl}regFbz=Re0DX^Po&dEb=%?JC|0UYZW>WbYr(4RPX*zgALMd!J`_cq&edb% zyEzpgv88?W>ZaJb7Q3v=6p>xNtS?Y>+{zte9EA5AdZ8V9`o1=tD?%*(VSj0^^0*jO zoBgyB<33u7HWih8vuP&9#OCF~pEoeh=dlr|g+>SM_v=c#(NekK1Eib|TZ`<)G#Kt8 zbb5q~n&D+RrJ|eu&c^iD?fWm48_IyUu+s)?F#fR(rpLR`J%{w`Z>wHj8d4baC^gnN z#aA$8qRnd`bAG9cRXgLQ;a;HfNSS*~tkG}B$Eom-X3Z?(%Wfm^cr zl0(&1+i26%Pmv~-jAljd^`M95zHhg;=M_Gjzak)>>#u|o^dLczPOTZS^$w+jFGXEi zPCuQyaYvtbp2hyk9z%9*0;AELJNXHYq%~+F`N?31!mrJigvZ@=l-g$Yuipi)#$VAp z*dhNc8=4qVfRk$*`;4nMF^TbBI+bx!Ayvc5n9S zh`@G1L+yjUI}@fZ=Npi~6hwf0XKBD8DpwkYziv4)C~a^`mfCySrYA>V!JKl1 z)sF8#@*c~N?FNKmn}DZ{=HJ;lGN(e1VdTyBD=#^8)GP;1@L%qhHJob2lBWRVDDn8M zj!QZ^_PpDJKboCxiVIXU-)XAJl@@l(4I#G0UKW|=Q+}wY;58Ngur)|=at$4P1x&2- zX_8?mb>A1V6RhiMlgWpC4AS|X46D8-lirCib|XY!9e(_)xQ5ITZ%*BH=dC?paLS0^ zCou##^nO`%#~naGRMvw_8`VtEaVLRq6cuJ}>=ElbD~f$K8l+WkA9dR!Ctgzwj7Ut3 zGWN1@pw0qILn!F2vg}CKoN1P`-vq~P{+%>99o?Jz3j$PaknQ0Z_ehiw&9YFYmH*z7$%pKzGgA+;~~q{8vK_&+)^vmCmhn=3b9 zzpuA&NuyOR7p+PhI=KsVI_NgU#w;#_oc~-7b@le5Sv)YD zr*#`;f|I8ZJBe(Ish8a6A=fS%oX_&7Yv11{hXv1xa!>7Xsz=T?Uv^n9L@J#Sk);Q! z7%(CWCxj6xZfPCNHCIVKa?2eE0}`?5>7ND%bdA#YtW{ zO${jR8=5GF100AN!TYAa0^u-)Ol>#TTB}yY?P@3_jNKfJdN+TM+lLCfwnj(%y`JM2od~j3!&T$k**-+m&Wj}hF;3w@HPE%tvow>J z!B+W9BKH@#AV>OlY^g0SEl=|GhehNq@|NOepPs<=`PL`*hy3_~1^Gt?rn;T6r+tIF z{2m1cOtQh>dR+muXa5UR(dSiS@-o22{;WilUDq|^&Lq}#I49UlXs&|t=oGW*-4r>t zCK0ZB(lzp`$6Yp^s%B-Z=u2I5QH~S`sCcRhrGkE6@nm_3FtLaH@mpm(E%nosDrM*wIMNat)kI zR)LHYNXbzh%|Oi{5xH7ndMf1D)(Fmr1HuWv6oSpR1?>n~Jg`e4Yy!pirdD8*xy;j~ z3vzX&_s$n4GJAEjN@E_}>dOisr@Sx5yH5J!0wx z!WH%eo&5y%2|ksNWqmJv8N6CRWyNuabD2{k0x1E@u<2knC1cPgI*0IeK0un?c*sU! zKe?=?S8Z}FQSgfP*TFfb3!3>WA$9(ibGdYQ~8YAB8vMi4HI&T<{6njzyLwINqulp|09 zFW5{lqJ16!5nv?(GUp-QQ!mi2$h*&ws(DtpH6*9a4HVf5DIfZj?C3n|{ly;lMUKsw z2#=;bLWtlJi7fYMtmzEYTPpM-5%eOO8w2dwEx7;e^NOj@<|$0!UV^X9-RxhKcz$N?I*j_56u6a}A#pj={Vf1Cb$02ZDEqvT*( zQ|v67SbZ|g>jHS^DU8Jyd5&mqPYr`X*sb+Xj>z+#>cEWw5Dd4^Q18+pJ=Ku|XqQ$U?ByNi)-H-$0sL-6xiN?>tE*qBPUa&u-IBP2O0r8}G6)&GD zu7MVdCqTwrj#EXY|CLAZdtF0+wkUwPKdZ0^rP`K*tBJhzW5%$Xekx6gla2HQ zE#fItj%2ruSH5Ic$)tk7Q#%AcK_(;tW|DvkumQ+dQSxT8zwOeh6Rux(VR228v`I8w zAQ$W=B5hgEQ=w{o_YdiCNd^lRA5qziTO~m7AjA{EoiY_=Gc|fuMY=VeEOR5sm3S?j zh&Rgq2SEG4jQrQEkk>HzH1%q*jA(Xr9h_$c6vuGO z55ZtoK!g;cu<5_KV1sf1tHZp$5Y3(R!7Hp(B%U4Sh=BIPS@*!40j^bAkm3M#hsc+! z$;my(vs9tu`YnU1A_OExz& z3_;|xH=rUoLo^TV!xa$Ck*;}Y2>V$g42plH2H+)1Ik0B8HSHoAh%SldsmYHp~(u#2+oXC$YhH_KT+Yrh1vjrEM6$kFhZqme<4tM=ElY8TE z-w3?B1ZDA2VOIQm(p!AS7|w@|gpY&uH@*K@yoa0Q!c72~O$403_?QumY;z-rt#Ip| zN-nz;D4G`Izi*lxT5K#? zh-hNdX=6Jiv+LL=UQbU)i?BXQsnWTYR1r)_Jq1=%QIT?(g@E!STdY4F!B2qX`j}Ku z?p4b@KviRO#!0oL6FijN{n(9}gMVLrp z%`uyL9GG>CirOcg4SSEX-{Z>(iM?Ff6lsI@p+WXiQNE{m{&5Ob)1V-znntg^!wLx} z%B^RERt0DQkp`Fv#*Gg6v;i;raEnW(WupyjwXg5r1S{rE((oR_3q!w2VBYitFQr4qZk48GzIjI;9zV zz(7mXH3=q)l*glS0HmSsTp+A2f*Na4RL<`KTHQojN2enDD*-a_gn_IfqrJ&CC`vm( z0$8OIR#m}mq8Xn_hnrI2EE#^Tj}A4##YnI-PlJ+V)+hrw;R2W>2QwmFJ;JlR`0jLO z^aMp9>#&96;&F$;qS#unG%cR98tBGTP|HBj9s~NR4l+*SS*^i6LTBOklB#X6j;66Y z&}O6k@(^a62unF8RT|PUGw^7w|5Fialgxj44f`<~i9Q^#D8>j(A>o6dCgKgy-3t#u z9}H(Ao6t84-Y;dmUXcbTs&jZnzG^O58H-?(0XUId#bV2@1HhYz9P4tdFIB16{AYfe7*RoamxkS#>ayO&?)G865eD!? zk*je9O7S9*U`sfCkk75)hYgm>jvJ?N210N|tNxdR$DIcGMyRi(Xj~4(82loVXNBt6 ztT+d1EZ=zJOY3C`1sgX_Wz)dz{NdcLFZp~f{k`6tA|r?Zm{K3y7GSwTM&vRn;3gfV zDTfFpp&S`(N(>mZ2@_0(sn{T*>8#NdL@OEWBBIpEh)^1e0$>$w-Ee2J(x(H{OmKr! zNzZKf_9!AFu9y)j>XUR2v{CtrCJrSm5-%Cb|bR@AN)ureqIi1 z`@rQ3mF*1yJ>Lgz$~htMvH@6LcJ2{7wu!b72A@-P!z$(2g9B8R>7Tk8};c}kg7`b&5lGcT}YpWqwtmH8od2HVX~ILlebF^%2fp)TxmwHqyhFRso8thT@H z@=(x?e%tUb($z>!mV@{;AZ-mT$?S#p#p8Ij7T#tLSk!5!AI=5FJvFi245w;pi}11p z8h{^8mBz*5yP%pFV)@xWjXAiVwtPUqr=JZEr3pI3aN5fX|J{v+C2o^nt>JY5P(U=9 z(R+zMZB;jVUsRX^sC(p&BE%pugN9rEqkvs|1lll?n3j+YPq*`@Y@xzb4y%etZb=ywU z4yLrJcCUEn6=@B}VHzJrUlmq+9Fcr7m^S_6SAc})Z96%IKl&6= zaYu=F$bzmY>C-iE)`VqL9>31?4- zZ2Lt(O78tmL{!yF=V}Saw1ViF+=!DBtd!yFjthCI_p>{L;`yGDvL}I^GdjnEW{}yw z;p50!RAK_^bpbYTDkY#V=Zng6^RGX0rG%ZoG>+4TVsgcu=|*aPThkr&C^5M|v|_OM zYsLZP?#E2um)_yZxm+_P!tQ@f>_UP?M**2?()-_{FyoB^u|ZKos+g6G)0vi0#iAI| zA)@3|E8Zx$wC@cw+^4f@Cw|GO{!tIB6RdnJAWTTN!>u1zR^<3peDfDH43<8voc=o-!WILPmG|YTVz(J^ zdU=FRtwBYELrb`5ykSj8t0snJo5acKf!FgZgI@mRH`c@^WE;EK(N-zyJxw)s-~9B3 zbb=9dNo>h7UignFnTT)S$uiCITjY}{_P?(iDeo7$yjCFcCnrkqS!WP2(0PQ{>jaUg zb^S}a;d>U#hvL~>z$5YIk&5uYr&-CW+6RhOnHRJ??s9cMF3a4qI{%mqHwUVNhdHT8c46`^K!)i3ve zcYI0-x4AA*jz|_?9d~<@MPCuSTE<^{>1AY#+_)%HEj0Wntd4t0Sj8)VzIE`H$ndh&~Vj^n99t4`7wOzh!bMGH}!W_-@- zH-(HC?Z^p<1!#+((Z#*joFQQ*5umXH%~B(F`|OI)9q*9*C@nR|f21%6TlbPvMkUrV zg=>Nx(K)9+emL2jB=J5Xem?zCk*n#q^}M)?kOM+C#L?L<}I9kYN@G&D2XSqW?+!r%>WK_C+V}*%Bd> z^|+6xI9K@2O@w(2CA?cPXj6saV|7GRDE=1jZBu66q=D-%8(Q0Na?;VvIu9PNYKro) zYW>O#(X=C43*VV=fPV*~|B?<7^CeP)PacD+9tNN9Uw_pNoI0nIEEcI%-PWt)Q6=-& z$<^k+I(H)g_o>f;ciGUIk3T!MN3cC6lWkBZd+t+9k;G-^XrjzcF}7nK53Q~;tZm3o z@|t4a6JAeiSK*uCcs8&7YRBf}4US`4iFFXMr=7Va67etNgXsx8DwD6{zrBq)$P)7b zyWn!lc$ta;lC^-rCPztzPWd7sViXa`mXk`m{YMJFbH`$NIBtz6;!<}t$3@E|LG||E zeDOJvNAKSy%QV4+!pR+qU;yfIm6Y&OYWHrqR;)ESkDq&{^VCnu7kgbhjQH+tWA*Bi z@Umrle1wJmkq5r^F!ze{D67;V>&F|4GRcQo(P`N1n5Uyx<)yOq^Z&YX82^qn$clQ` z7|hGVMKF|_Bj$_NTv8G5zsEoJj4Zkp5MKAI#dP->(qg{l?>k7n~J6%vg*7#_9u1;lhzs?C2`TBwt!k>}p@T{hocb zH{=q5v5sqo&LE%3VIQ9}y3sM2)tlpC4+~feQS32^^`;NGZI8Ai#HcZzv%hu6X$aN6 zmJT0-KZ3er#7Yl0C?$HTnE&C3t^y@N%( z6FPfP+_r#DdAGg(->tPK)N+7O{OLl)-O7>Wc9^urv6)m;FondWfO4&Dvv=vrx)>XhhR^_ZF!nyn^o58F8Z_e^3 zVYA^r0Wz9aqFGYNE0^nG0#5$gFY?Al@$MrW4S!2Wu$=rI!{s{w$Y zn~!4l7~+lZv_97`w$Yy@#k2JUavv773!eo5hzDQdTJWm<@1-;q-be5kQ@ZC};=*Em z_qt4bOCsJIj&V;rYK(p8VRL{dV`w7P5zm^?Ud7s%PKiDW75k~}Yy0@zOwN}S$Nq{B zF(@f(q+7zSu4u;RWtD?${#6$-_uedwbsh1$z?aLSiM12%w@;jEfzjd2FH!O5C8+l? zf!Z3Od|f$PC*BdW+F119@&9$ojdc(&T1Z0b#&pYzJ0>VQ4pn@3(LL^pdEER<* z3U2*S+Lb9fNbuZf=8_1TQR7H-k3sA5y-020pQMKEJ6iFTR<#IhO?`j;bj`_hPidke z_r3pe^Wu%KAw6%4Hw&NsSh7aeesh9{zjOnLt0 z>EypRNWXbq4ex=J$&I)Aev8){y+PH~Sa?9V^O|ZYO!b)g#ZNP8F}JD@Yw27b znn&YdO7sg{J0Usq`Ib#cMRNV16htY2j__?FaA>^R{)z)d%F>lqiYt^fxlL0{W{{V}lAN&9S literal 0 HcmV?d00001 From 45c0d74b8ce7a8ced44b1a4b127730578bdf45ba Mon Sep 17 00:00:00 2001 From: felixk Date: Tue, 5 Apr 2011 04:27:15 +0000 Subject: [PATCH 289/541] Add standard-mailets logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1088887 13f79535-47bb-0310-9956-ffa450edef68 --- .../images/logos/james-standard-mailets-logo.gif | Bin 0 -> 9293 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-standard-mailets-logo.gif diff --git a/maven-skin/src/main/resources/images/logos/james-standard-mailets-logo.gif b/maven-skin/src/main/resources/images/logos/james-standard-mailets-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..b6e8d02164f4b33285fae79e1fc32cdef235edcc GIT binary patch literal 9293 zcmWkzcRbXO8~@yJcN}*gBV?YD5Jg62-5F(fRz}E9nHgnw_DW`DcXA}FQ)VegW}&kp zp;OcuiLx_(-{1T7JpVnf=a1+0em}40{dz7LUQ|}Q6gxXR2!j0l z{6a!P0=(k?L0Vc`US3{NQBg%jMO|H8TU#3d?kaKx;m@7-IW7MGhhlj@vcaNJlZ~FTB1_lNO2L^=%1&4%$ zgoTAgMMc42u_#m`8lB3)k&4CM2f-u|%;4wG;O5R25O^RgoG&6$EG}LkCzr3HQYP3T&1o~(bTNb(yG_cXbBeX(9x+jF?p`5`_kCB(ZHb9 z!lK#2qSe~^zi4xEYOuF|>*(0-;_}whv)$LXJuvWXSXjHMDb3Qd+sWyjmDQ++N9XnH zJ#KFOH*R$L`wzIf(p_98{rrY+-RcPr9*BD#l;PzrS-&`9JC&bL&(EJIE*>o@`BYf=B{6aS-aSS^!9qd7FEV+8O#V_`Jyl;nQ(8LrS<-c}|4UIHf`_^=MM@L6@cXwZ3-(Y{=;Nals=;-A5$mh?Wr>DQn%*^!ktiFH0 zIyAI6IJnx;vEI?K(bKaxY}0hZ~1~HjWODHr9_e4vzM=4-eOO zcXxJo4|b1s_l}N^b`K8^_x{WO$S<}FhXBA4AoqVI{9h9Q>IgVs6*8cbJK|8>vJQRJ z(sxOqgi(<}{gduAex;k!ef4F%893ckA;TAx{v6D|P3}rl!PgPnOxA(s-?K({|NZ#2 zjO2cLA^KqD*O#OhmBVEQIkJvRXQbQ1NqdZu-qn*sVX`bgYFKlmFGO$cad;Rt)qH;G zmH*!Dw*61Cj+OO>-82SooW45TtKW?#bJE!vf^J|+kUy%9! zUpw-Yyk{LO9-ogmoV5tmL>6j?{rj`NoDy{XQ`p~))*mLXn|^)4e2l6{TCV+~9vxj= z=8&;Td~nJ|sV?nx>))UG{{}Um4mN)|=SLleo%%g%Gf9Z+JgSH|{%ZFxGmEX*=D;_; z*;^WZDsuJb4tcBRoc!ar?MFxG&A7{!@YPEb(c82{Gyf;!FAze$?rtB||BSu+Xl*+a zEaU{-X1XN7>XdQk&pk-S`Rq{Q@`SwGATG#`K8XzN{rMbh=s~1@?sd^EW?9%Nmc@@G zmI7vmw!)0%2f~F4vx%>EbxI+@du9 z)O69^((Gr^_o0G-mR4q&KQ(Abi^*hi*Nt64XOmWoGCNq~roUlQ^nbXIrgy){NiTa= z$L1o~;1yJU-_`Ea?>7F0?;o|p-9dt|cu~LyV*)GXnyu@CWrkp74Sb=9){!Z)W~i=TQ6R zfI5n7NA{WbHi^S6pFPyIzk*fuQG3PgG}l;4l(!KvoF%9&*KF1j4gzCQ;(D2ocJWYh zQi5sBa=!Kk-O^al=M}5RJFxDSX@feHWoj_i@95Wd#m@9Q3@$KIm;e`FTaH0CxQ~vX zUv=oiUQ4+svyC)wUQg8E*|L-|kL26gW=17;r;D7VM7N+sBLiZQAzd{YZ@fMzWyl9K z%iQ^4Wj4XjWbrWFTNC}$W_DqUGJA#vNuBLL3MZ41=Vo{Ra`{ZPWxeiXf0sXFoThkj ze}`1fb44MVa<~WKY?uxI);4J=q)Dy+t6KQ1itV~!besF@oq4qL<5)>G?NBld>Hhd1 zO)9pBb4llb?lgTbfYhp9!@H7+SwpyajM}Fwl+xaXd1Z4xWs6fOOmnk zbK&fp77TDvI^0=HTWsyONoBr80XV1#$!U3{4_)FF$7^ZyX;hB?sXE!$#ChPm?`bR0 zgf(7pU)GIfX8SDynjjqQth+joh*44YF>0bG8YT1SY1{u%72G#cHDh#PlNkV#iRZrB zYiJMZ3vQ3jboxl25c<~X#CS!K8`YsCuy6-|RkQ2|+ngrPmENc8|_+&FPA^(_uISf$q01&c9sg4zln(kvMpgBg!uztxeNV zNhR^MRJwM0<;4tmAXO)=`ptG+Up9~cK-zRsSS~O*_sJMWQV}o`3;>ao4d@9@ywN#o zW+>>!ok8zX=;G81#Fq(N+C?b8HRmcn8-lAFMxH~IB4Y$%$uME2{OuDT6Sej1fG4SA}%9 zjA3x9MTykBpcxr{>U;+a?-=bk%&rR-8IUWZg=0IhF6YG>D->aJ473)m6a(s~2!JcO zeW$xQ@&Q)tsCA9ENN5={WYEV>?Z9%ieUsfzB0R?bxD~m9M*ab8fq1-l96*E0F)TU~ z;jq*49WMR_qs3B^qIfkJfjAdy$1cf3M4%%qR5AMH%L&OE=AgFG-+IkG_C#q1*w|On~kV0H9HncV~qAMIEZpTrm7m zy@ZP#AQS=GXwg`{Nu#u!2JFh{d6IXfQ0@r#?^ics$khwCgc0>q)n_%T6B!9UZb2Er zOqT?+{U3TW6OeR~mx&^c3H#BVy`^}5d4bS6y!)#OxPm(tXj#jzHs)G^I(PadzBHIO zxgK}VjRhOpN%#Z7DpB}EBBTto+7$1(;ok`%2u*JobLltnSH*r*CMs5OX5g{zp9iCF zH_W-52?{OChV^eXz5eA?t6+OYeVFwO`?_1~lRC_EedV%xBcc<$&MHx@Lpn^30Rwiz zm_-ur>{}TLMp6pL832I`u!Ty)u|ZO(0@zh9zhIbHa@5Ndr4mp|ivf9fq|kS^MYP{}SzID9H1lykH?-BlAcUkFyBcfga8vhb?%6 zh+q)GvNgaEABiQhu?(|!Tm%IT*btm79!C>NcMZT8wPZdf99qiek%@rTC#T!qJ|uJ7 zckpeHF-v%?Ydsdm#okPIV<1t_;{0tx&~*u3i2>*kz}Y)kr=HiGnR~(dlTjnia8i>0 z7~T?D4;f6j9IuZ=nJ2Ohb4b!c0X)Ep2c)ebvD8HLI&yjksnYF;y@leV+Mvje$l>(6 zG;d}yIGh=IipIvC=Y(>>j0Ug|uVG%U0jl`qL<4Y_2K^@uGN@1`lHVaC+5C~;W@yGP zf94@M_K`CPv&$^z4{=q*zR-zk13WsYB1#<`FZymXCZf_l$=58{n=7J<8scj$ue?Sj zRKZm;8l0Q0r0>oFY)6@(7~LVf(PB`VgetX>W`PDWv2Pg(T#vwMhDAcAH)ama1^~zK zs4ommC*!X4LJk}PMbRG&CRjL!g4ux2Ib6^oHHpOq;|0QvXeci-%S~$Rz89!Pg$i3C zPEp}Vm$)0P4}EtZ-cpAJJ&OrzedKXc_+D1rK_-R^2jQke&JvkWtQQ@neb}<$69;#21Nkob+flD>N@uP{AeBa~MF8!4q_c2r@Vn3f3S12~RLK z(*j1vpz3pF#&cPQ6VWjbdJMrUr39 zFn%UB+p61er@}r-71cn#m^Ny9oaW9$)=tyYP18wOp<(O7urVC~f(pt~ZDx}T@nJKd1n(TM)siT9%aK0wB7@3-j|eAayJHICmDI%c*r7|t3(HPDhrEy z=4QW;Uzeca-|JPYkLFo0y)hPViU{o-*RG>*gni43t_OIV!K|Ysi#QtC+Fx{f9L>fV z=;;Y|rC5AW2m4Y$F$Ay^56VBV@U18t`V3ZW0}rLa&x=_1H9*%HG}U;FwM#~<$0mAl zoSa~_)c~IhR67Wi5SOs8_JB5{3f_F~#u4lW9>T2vi6&wt#l;C0#yC5o`8wHmJ2gDO zx`B=)QT0~;J~fd-zUebCKYOC1g@2%c`)(-!rGwO_XRMshV1zP&ag(hSeR}g2OV%?0 z|NM~t3}OBRP=J19S~z%Bo!kO>yh>`=+|DwguCmo;8a0PRmSb0Ivgy@_AeKk7!X&)@ znh_|pTo2=vbt7OKr6vAmVoT-7IuVB z3Zp*u9}q8CljvQ2$ZU}=d=W9nJz#`AQabf=1p5axR)(l|tf8w>r43}a+Hq4(YhuXS z)#r_F#-0U&<;c2sMga_j<($lVXMW?c$SxcKT zo^pCDW8*X5#M42Y-Me{9P4FWE6>bhlCm^RH-u_HOMRYfXMO0yi1MmH7#)Pt-oQUmM zDsN0};ncL(W~4yZuW$SVwlrVtM6@7=+gW$pJ@~BGEwEd})NK-W>km)=Fu76AxvpgXd&l>Ag5%eMd~>aI7R(-3T)hc;8bK$ z_35qGGI(zdum}W=n$UFKF*_VwCxr;sVRR6--$fNuJ{7eKtm+6do(k!i=f9O8PgEZmuiAu%H;4T z3tzZ*_G$yJG9q(us%>z(ZIInK5NpncU2C~p?F7BWcJdNsJFT9K z&xE>QPE(=v&fwj|AuM?aey@H_?&C%q?ZZFrO*|xh5vi=xkqHy@`(DGvKqjuC6Ib$h zi0H)t4mD5I5)F~wirC1+MAOd;XF_his^BWdG-dYjP(N_4)$ll@_lakTud$~K1sWUk zOpadCn`r1bIwai={pk@O`zPUcDuN5tYzE&S$v_(L3hPh6PbhYwTLZ9RjtDwH8V8aX z*pK%t_GAYcAD%I6LCq8kw=~XhZ?HcAeBs>snH3x5-Mi}zQo$0mG%Gd$exPOVa{xqZ zzIagG4kb+7b_8dedjDJK>CceXgqymTxY81dgY6gcX8=diLoB~G#M>Et z@8z&>9EbN>4L6m}{|lK}+)-gNmB_%_JmH=x6_s>FaZ(YJc$q(R>}S$2dWOJz_Eb9v z;UaNpOQ@AQpwsimG};JAm-N?bV>02OBRha1A(H_1w>XqoB4Eb>NE}TybsG-CVz8&n zIXxV~tInB^6kz>{P8cS(L_cLWvKJ=Cv8V+SsZjB1+F9POyjN)ty}{i#U)O%6XxjfkEk_&6`b`y705DNIecSw^(v^ZfM9-t3#awK6*0Fy*;T9w9BByn&IfH=rePj9Vwcu9CPXz7yTHgTl)Ft)D%Tk{mPfgB6&f( zPG-)V(M1}jO#0mt@mq`*FZSc-lkM*vjx@1%)Y-|KOnI>br%yzH{Qn7W9cY6uY9q0ezq z5w)d_>>1O|(PyD?S(`X)x;g}i`8C@Xb-1?~WMdo~uM)kX6}&^t5KZL?oBMJOJEP9V ztz}W!ogu1y7qL73-6rr_N4C76p`swght2$pIw9KCM_RcT#>6DuoV z#e7~B`0$fVt3qh7AGyGK`AVJRn`n9I7m{!8bMLcHCp|xLA>?qURxmiWvlGRoMel6t zDJu;>@zo%Y+Vk~&6cRgBcnM8~zeVbcZ`ouxA!&(|i-p&zUthIy-88JYe!1aIU-swv zvI&2MZ$XV(;kj#K!bfj&{q!pw)Ega5xUN0@G1fm?ewq^7fJwK@{b62gbmMIL;+RKr z<=bkf#uCSWw^voSQyjvcuY8`~Kl|j%)1i+#Y|+uf)xGIg5Hyh+n}takgPkfn3;jVi zM57#DK35I?@$BiDyJIfz-bP#*xg>g92(F@ZPgp z+(W-5sS5CwH)~6AiSGO2@5yJ`WPUotVt_^aPT*PotCzA;HO_ix4Ns^y_@21k6S4L> z95t0B_+HXkLNI)?pIDsZ^DKk+F8D7^?C!?yZ`Hqh=9RQujETbIzWudiEy(ZIOYs>a z>Pfihi@I5&jeq)2mWLf}EGB)3xG95f!i2V-)SX5YrmAyf=W+sbMmNo$vNh>ofCUHF z(-p#3m)3i;`SGbR{xmqF@5J@;ag9#emrHFLhTevcBVNd)aoipnMwY{Vs@KZdueA0S zpVPAcUXtDQz7hvL*^)ty*y}Knzs*#x78$={^z^*yYDdip$Y%ebd?#~vR8)O;&a-`D z$>it2?WbH)8YWp&W1>2l;p;u~fj)lED!g2+pUx(C)m=$BIka@;Z(xFj=`}%ix#Ea< z!X*kUC@N4)5gV>bz0v(-S0@_k(z; z8`Q|H`jf&Je?K6@!jDpKd&@ez-ei1bID8|k5pOw|T}n6zkufO7hpM=yPIz9O>9qQr zRO4vli4>fCxOu4oZ38v`oV!zRqY!6hvF$M^Ui(lq%xB$Tsc*j(IiN8-{`BTUoS;v) zBFmUV;U;gas_?#hN!6n~9(s7sLs>jq)^jXI(?y`)j}=Z4GWgQhbmwWy<5)1n*zaX% z`ie-ziN2m%gYDBMeypp;i*`zue~K$q>&Jb5bp3OQgtAQ@x3AYYQ$4Nq1=BsQ`ZpEv zQS|m&z5eqFjpXC2g|}1sNnsitP3p>OBauK*Ro^5fWoK(fdZvl{bS7}C9FkP;9s*r6hrU44b zKXyYqrCB*@7v(zR@~;6BYH=$cJT?{M6WQbPe{a0=+m2w@^AkiDM~DlO<8_@p zl0*SlLkisr3pFG`mjf>O`o*G(d4^ALr1hW9Rl}bg8X}$UNaBIm>Nk1}=T5~queIf6 zb!R0DNAH#Wpi5^*uOx{@eh@N7Sn0fTU(?)XAbf5PUsTOUJ2hq{omXw)s^9T*^#4#U zHXe%&A3G{N--MerWh>3`!^v1el&+d!>iZ`-={dv=q!a{1B`>b#{@xhmos-hKK>p7= zv^*@PS++hzeFWR~jGZUPd!ihFyDJI0c^YM7xE{ni-iEQWtPDTelo`!$zTpQUG*u_q!*b9_U&oln;nn{DCEEK+_IskFi@&eF{goud_wh92&1lZ2v$d&2R#`P{M+XB7&6~5AaM1pVW-K zvGlVXR10Agw2*okAw zM~h1g?@##b*s(I$o!6Jnqhc#BxTwg*z2va54i-#j#+AkjdlPra+!GzlLSXlVpLl7%l=GmcNw&u^o0UQu4rtWEAp+>eZgRK zGwNhJYrIq(PwW-?+p6=r!d@Qo9ZB|nFO?sx=!*RGdIw*kV;5&7u^M7ANG~t5c)Xg6NG& z{IPg9?j07L`%)KJ_o41$x+yWBW#!v|cNgPYO|`dN$|74Nw7#PiP1ndd7nqOkp8kB4 zZgz3)ni*zNl%=U(Ec0w~ofWSA^o_MR(W3V`E4lu`P!svFxyQPttmf_zcKJ#^qUtAi zQN%d-Tutri1YKM?nb6z#Df4;6`)3}kPxQ6N2xxnXuESnH??A2we}uc6*mB>TsZIh? z0$C#&j5jiT#w82<)1_TzXM?(pnAS2b%i5kUf4C{&65i>1!gLhvJVLJ1051#;|V5{oVpS<`XCx$7v^kq(U3i7DMBCcrW>cfVwhApA4)5=AEt zJ51LV6DEsWleu!ZtoEc3^pxs~7xtkOw`VE~yosIafGJWR0?;K*mwbO0{t1!%{#o|M zQimFi>hfJw6V(RQL`BHS2cX1?sP7~z-)lQaF4!B091se_88U)GWh8m7##+>7nUio| zq6U*tnh?q0{n^s{(Bh?1H99IjI- z59#g{A}KG;+2u^cRcfjB#?GYn2mw9!d~UOesxQBfhp^FOjSqKjKEE;YHE&?7@g&E4 zk<7pt2h=;!8MQ71fCK)tThIJ(Kd0dfy;p{VP_ez2z$9tVTkJ#Q&Y=>k3zAl<6I?7R%a-!7@oysOl}Tt39~{9R&<0yiR`e&@ zJ1eqn#QE4F!$Z$#xg-VC63=DQ8p>$)lWOu=0ZuA)!Q2i*feYbnbZ_`AM7rp zK?>GbOHW`Y9V4emH%ia<`>kx0P1+HAdn!P~SSf+e)(AZa&dgS>M7T$)cg#ksWa* zSl?+{-+n;fdF-7-jlQd1kCVwoOL*dCo*p-c9G{538r(Jw5M+ zgwVJMP){8a&rR%0a5vy|?n{dAOU~^}q4XW4HW;J^_oa>XrO)@>x9YpM(U-|%n57(( zt=ylZ*PmTfVQ~MW`2IX)L)0=dtWP5%v{g~J;n;4IKl;TllGZA-@i8TjJbhoI zL8fex1P84A+(I1F{NxKZ>l3i;nN*#%I@Aag`5z=yo@; z|7^@Q&*DU2&n5Fj(c`js47I%m2ImKc=GmOqU{`5~H|X?ujg;6tDfN2eS|8ny!GjYU zCcy?^B)*kzRAJ+0Vcu)S$@#(AjX~M3@F51z(46GZH|3%4dPDP8LksRhKZ1vT#t$)b ThZZSAOASNIU1oFaC_wXn>ulhZ literal 0 HcmV?d00001 From aeb59bed01d54d25075e9aaefc032eab2eb47704 Mon Sep 17 00:00:00 2001 From: felixk Date: Tue, 5 Apr 2011 04:35:10 +0000 Subject: [PATCH 290/541] Add crypto-mailets logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1088889 13f79535-47bb-0310-9956-ffa450edef68 --- .../images/logos/james-crypto-mailets-logo.gif | Bin 0 -> 9186 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-crypto-mailets-logo.gif diff --git a/maven-skin/src/main/resources/images/logos/james-crypto-mailets-logo.gif b/maven-skin/src/main/resources/images/logos/james-crypto-mailets-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..6ba316b3dfebda520424fe13e20096d1f5e9dcf1 GIT binary patch literal 9186 zcmWle`#;l<7sof->}q?v=H8f8BKO>x`=w|ui|8_<2t_EQ+T6*9x#X71+@%ykNVU06 zs1X&ZMubZ4T`2Ew-{&82emc+dcs}FHBO@ad6B9EtGfj~& zvYu&>l=L+~l9$Emcis5ods%e(L1M52vU3-k)au<`)9KehFOq7QFoZ z;_6E1`dZlLM#Rq_SAPGw23Eugy=u3h)9JCXvGMWoiHV7+v56_kDXFQcX=!Qc>FG=+ zGb<}ACnqO2H@6@=CqF;Gu&}VGsHmi*q_n=OB{`nOVwIPdS65V2R#sM5SJ&3o-n)12 zLH+%IG&D3cH8r)gv^;Kl*w)t8(b3V_+4=P8)1HdTxx&K5<`$3+g0UbN4}ysxm<)nx zAeatC>mVxw-lI z&x?zTU%!6+{{8#X-!I>G{_K322d6>s69~?M;5-O^+XRimcDDZh{rhk5KmIMh z!f!Yf0s$ea|2N_PPC!r~|0_*LAj|er-V*YL{W#_4X z9IT;KI221?3V0Toiks-lyKvU5OfwGOYw$9_C2G6S<>X*%{kzt`lU3QIb1#YtEhDzR z?s^q?BIfGm{$Aup{d9M-=+&a*;rNq}dsf*Ud%biXLKyNW`xJoyGv3uhtIsz>nf{GA-F@P(~Lhfi)NVG7VmWp+lD0aQ}!vg z5-Hf%>-=cA!-A6u-&i?`VBuRUpt;mc$}s&oMN;(JVdlBwu2Ee# z?8*P}^#S?kFYTj55{-_;>5W~=rtZ8wBYyvP#4)P;_QaAhEogVzD7ydRd?0i&ct~AVf(0F(C;X*DvGiYrD`Jvn0Fj2OX zE*qJHg=rS24=A2nm0gdk%06|ks>(b_pgJZET~|9{S99&X3ug)f!%3!vXy6XO*Az~F z$x?o4wCoQGz>6=REeK6Cm8@7wJ}l?kJelVD$kk-MvLadb!WlXghkVdrq5OhBCT1jm zvGr)Br{IgOH)NEvQ_^-%Sk6r9p@T*jjmoMViF&ga3~;IqA>EkBKWQ1G#eH)xlyAI| z(*JVud|r;HpqlCSMk%6`V7Tp(ZPX>B%6^Pdt%X<;CmSYTI<_7sS*=N&N!uH#XD=bQ zxp8`4F}g=KYkL_><6T|O|CC^yn~i^0*?lp*P`rKx9&b5SDF>@7g$r9YFWB$B#PDEX zblyG#p9l#Soe@j6$?LRNBZo-8vNCLXr4|bhiq+USa>U04e`+=zaX??;*9SpU2{=qn zyB%o?1_{SUO$0zqBxQkEAT4Srh-j2jCRWizsG>IbkNyVKqkqCAXf!B^FDDy+e z>}EdfQ)qMRxakdvuxLo2`RMf;I_*g%Vbe@of0^MR5ZD3K>1Ba|o8=xP(Gyw6-ca&u z3}TY)$(#zgz57KT5UsMz1H8?eLmNy>R&GGxWiF$k$-8qx&Y5y0^A36cm#@E=kdx+T zf8P#p#Pmt&5lL8D107LIOM5ctr_A&bf~ze1*iVg$1Pg0K46GFp%}Hv36FC=#eKXp7 zybu0G*-3`hkQkf?xWZnNkSi}hkrZ`;OLb6jxcVDVJ!DcY7Wn5H?S zkaytM3?dq7dPy$!eBr(tfvB_U4wZ4{-;Hr5$_~!aw90Y`HTyjW89-WYPlfo1t^Uw- zR)A@b^(Na^L!d0#wr%4?CsEK)K%#foOtAG1(^eyVAhve%5~5R72^Z;oQ}@`nWD;2} zGRW0YKsZ4o%=a)BLLRUC&QZKot3ur*iy$Zw0?0dLsu@KD>NXA+O|jmUPfSo+p`nhD zyB!kQFn71v1BYJqkpws{4sFdoQ=yw%I7{{c%fku~G_mngbP)9Jrz96v-`%;ptmCKIP z8)~_~tDwwyqYm}7HAf_s{GB8=GD?G!PI5c?vv|`Pp1$ih4E~Vz*{;M{-cx5VyjWV) zUmZ442MvT1Fc^rpC!~|CnEo$g8M3HjiAr$Kdh@`3&({wvW`&IHdd=(jUblGT_a&g1 zo(%`IC0u}Tje7sm?ZatZb$8XhaK0K(YEPQatQgf;Rp+*e*_NQJH0C!wypGUe*Wv7D z5*kLrFP?9t7h$$y`=K6`l0PAZa|8s9MU2vu!oWO<9=W84K?r^4llf83ub z{%nh_y3dT(C0O%>k_xf=AQJpTAMfyy*Nwgy9Ju>@>{bPM{+R$Zy3|KN3Kb8jt`D`u zK+t@gAj`$2F{nhKy==C9$R<^6iUM^r#Cw1KtG^+oB_zK>md4pz?`q;_=u1wco&Q+v>Ih+mUa=rfez%aFBnrAR z$A~ojxR!p$#8}mCjHgDz{w!KzTrJ|zu(yi(K5xIg89ZU=??x^7#pM+FJ2j^bs!=mE zjqsO@!JJg;%aQ88?%`~hA2o=gkO5@=4+sWa?Jh?PEWFB9l6gl?4kQT8-qMc8W?ZmS ziG(ERv%E3JcClnrPMliKZRGrq{ugCLAd()7^dWN@-NZKxW-Rg{k-IB3WRXEv(Qs54 zj^$0y=51|qM9y7M^Q>EOUbi^7juOO0OWIxfZ{o)EcDnGDR%q1=#v7yk&y7Eb#QGAf z1geGDhWIYzPl?JogHr=T!fGPc+J*|_4L?-EF9fUqBCQ+yCzvH)2#*VgE-rjFFz@5Q zNXgyAtiCh*A}N@-wie>J)pPd?t{GP}tnDWE>2mV6kLIcUsp7tD(w4t#@YriA*i56U z@Myl(e+a1T8Zph&C+<*f41G;tnhaiTbY>bs*e^0pw;onLy*^0t6@PtJa6XE7<3^e{ zu2k~cNJhy<)vg}d*AjSyLI4aZWXy&m8My8Fh;b{aM~#H775oT7rYFP?>wW?hLs4zc ztIY*$grj7dy$^(3dAfe`b2!wl(v8E!PyVzxt0gYSh9ViKtLLyVXCy?!QxF=3=McJB z*lZqlf=!U-To)O^=CQDE_&{zy;7JR{H-_1S0G0hW?(~Nv7#MRsI$IZ@uwgZHz?Kag z;715mTz%3+Sf=3TR`3CtgiRiyhk|uZj7eo0p?4>iFCk}0XlkYKYPK<)~( zY#gFXju-S!O{PUPB?As@m^F}4cMhQXN7vSbKlT7F%n8EH={scX>q9~)VL@XS;?x_} z90p;NjXh_BTW=Ko$r8Hif0^qZQ-1m2K+B2atEhId*eBf{+&%&2$RnpJ9QL#(tMo~T zuRzeN0!s+b7$%UH4D6>+4>rULOk;IW5T!g|l10s?`SbGt_6h{ThGvEceWl>SX;i@x z0U>7Qk~Q^N2w=sAIk0YecmPj4fSNZqICel0Bmw4~Mq|UQn7~851pJIfBmyr5GNIBe zfn|!4{+^_8Zc^22m$o>AL2Gn@#`#1V>ITZ;K(_~N17^xLWyC?pA6XTyD6}#}9bQR@ z@*o&<*wP*prZGcsn(AhaLXM!Qx{xn)0C}8>J`UKl0s1INm_6`_Lfy**QUxLSflQ=# zuuehnegj~SJ+L<_0Xc$utsE`jo#w)ZIWvKJS}>22oy~CPFteo^pcA%YU)IEb0=Qj~ z2WQ&c+v7v}=K?aA=-5gFP)FcQEA*?Yg{{v1Ix+Yni{N!!KJ15x2or*Bgq7VwVZC$V znqd-5K>HXqB!!6?05VaKUOF&rLtQurI7SLZupx2*fE~!rN;JrVXXe8i^V$9-aPQzA z$%2y$gbTgFCE+f~BVIdI-+&4pat$*9=u*_J~eO`Y~E^1`~_|^v*xOg(f2? z44qit>MOxYKJ90*uOSlaBN6}wf*Xl+n?vEsiUb<-sN-0SX4v(!K&U-6$^eK+0gMD8 z`Ai^}?2jCY$7&WBv(o156R`eS&lYYVr;qvZvR0#RzDNcJXu%JNK#YP|SY@IN3o0Fg zS`9H9P?U3OvVYfh0@D$K!+2l6g-&FlyyH*m>zutrOP<#CkvSujRhDQmB0(TRghGQf z>oUH$1LJ5&Z#B@)qQ2*skJ{&rBm#XP8luSp)VG*MhQSyp&A1`T{P|7Gx_s;C{8L<* zJ*L!NFx-_1JfHG0@ZkxnBIh>RA!DH+9A&B zHa6sT@R*sq6kNtZ#$yuP>6=@EP;Ow8fcJ?$Jd%S;UZ40o0XaMM(`??$K7MSwUY3g*BD- zg4o#r03wm~(nIl&2w{zvxK1HBRLCAausb#n&xhcHBndwuc+ze0W6BdCwWCGQ873q3#B)wy%Ki?f5%)R~1G`!>?4R&; zBL6jLgAX?X=4ruxk$@K)7C=iplr5nxjJw@{o+OIW^+fMKBrKBAkt_ij-ZPV4>_rJ& zNn*|%xn0v5XB>+!Sb_bydbWi};M33cQ}6{1&vtI3=lD1aK)xYR+ak1PtwHaAHAR() z<`X65_bL$<_HifSi*0q%*ZJ z6~Pdqjw54NdML8JF0#GjkMH9~1kXPPY&?MqX4q5IBP0}QOfJP40Re1S5HZ4-BGlsB zTq#44VP+>03HGZB#6X#AVO3Hgs2l*dbvIjvh33<6M{Uq^D=>pa*fI#gC-KcxGz362 zD;9^p&3h)Z(j`f+l4(G1X=slY5*oIoM_UMdmhRO~bmt06g_&K*zqhpG;UJJ%apqutRs2{qHM{ihs`MF(4nRwxS~<~ zHXoPV*{?Ic|A`1rk_qjnKg-PK6f(0rh90TK1EpXamXme{3w`1?4!K4_ck!|RHJlM5 z_qbUXt$Z2M!VC*|6FjSgUv~m)t%7L(aK15M&4%6CYE3&11oFI2 z|KddyBP6W~FJ=|PIj>%v-2=2;Eo)u{aJYJCArBvxPq1j7&WKR(u$ZHQ=yJ&0BuLR$gV{^E3IX%CV3|%> zSP{BW50&l`8`~o7ZbD}kp$qI>uLOZ5`=&Tf^y(|=4=bgnbO|Tt zw;m4Y@cKlBPQ67USv?szy9fPX=@L@-G<7o`11;GniqjD!&Oo+HAMQ5$JLMT2oKnpVVdyR$^|bcF_?E% zkkIERGxL0w5c)o0lk#{iv{`Jew1988Lxj^$N!+lIW|gC{e^K@2guL&h)|Jvp$Y>>Y z>DLNgg*EWkNFX<8!0=8sesiLq{?-hF--O7GeyO+0TtrT{?2(V!Vc|WkbFt=Ms=pIz zOUCNH6AZpA-oMa$P_y6{dX~iTeWvwc0N>@r*)RW!boJHai+zdw23`R~adYL36dz_Q z{NX*gC8SITX#V*|feEbzkuA z{Q{v}k3uxfN&5HAw=Z}kyH!%|bi~Ml;xY@h`IMJLzgF$2zMf7d6wEYjUo)+HWFI_^#+dB2ov z^|P3rjm5z{_4k58()i)QJL)BmizeNCxhvfhkHgnCZi#m6w|sfz?^L^J>{yan%+lm0 z?49~YQ%6@_-;TxQ+m9nxzyH2@rFQ;h(XY?LaU)?c{fk!H1F%j)kjago-xnXIUOfFO zsxb1$7}Ff_Aj*mJ`rhKI0$oJ=%w=wEKk-qTtgrHkw;^FYDdGeNZhqG~Xvf4@zv#Ob zBAu-|I5g~2{)Kfozddvwm#Y1-vp;DzVd>nPiBG#1JEw2fT&#Z_Zgl7Q?S3b_qr2Dt zY(CzfTWjXX)LtSPUfgYZWpk@4`>S>dzlcAylb>YT;NOKTEkd~*EWNUkS)*~g`8P+E zi-+#*fNe|NkxWq4N+|f;WJyDRU5Jula=FmyLAyk}8780)f9^N@mb<=# zU-I6dB6NGqh36^l?Vq7o&Bxb?grca)-=C{na^Iov)cu$^XDrlesBTiewpe3Q_qqN2 z?x+P()#4-3Ta04CFvHK!!Y4z|v47)+(yC*oM&^qLzYo~ThsegMYKem%IP0C6@y`AN zM4>H88GyD>sIWP5M6EZ?Lx*b((N{&0l075G{(0F}??!c33)pSaXuMqfS=#DoX?XhL z{V{;k5b}+C2Jrn4V<1S=E9pzMyAtF*bX_3In@MqL8XPf*n2<~6t5{>iEtZ5<9c#?h z)vv`n2|HP%-0M@kX&gAOa0qseT{rZmh(2fU&e@VukE_>6`^9RiT|*w$E*n2r8ld}@ zC}*Ut`IQ;o);r*HWd;4lr*Wlos5Jb`L{E|hmAL*s^Rn|kMl@)t&1IxrU;OzoR^Y;t zb({+q1x*NyX$v}b^6y(};5q8@?eHNNj!Nq+M@yA?wOmQnr`^ivsNZmh$l)kjNmAYk zy&p9tQETfdM>Hx#hniq$=|I)T+PCNBx|5geMO8PY79|n{^QEogB)R_i_o(lhzaAxI zDUl%GqQbo&UUb);OW8)huF-pwn(cVEeCnbv?&?dpeOAp()7${s^Ek}G=W@YQg`XVV zCP%Gz$ocjS;fCX^JumOA<*M(kZMr`rtQ{xB^G1eeXfSHS?S*26%1<79Bc{keE50>< zt6+2wI&itol9se3c;G{0@X^siied64QJ64Xm1{X^zB|^Bj0Dey4N9zI%aV`_u7|Lym7vtsF3u45^+?BI)Oc1?vlLc7qa1X z3s+Yo7DYO5+X_DxdZ@$IYZ=cey{mfjpk)`@RCOWagY%5R;5!!t=|?BfI&|dHLrHz* zcm>$>c@-I^t?@xuqExJ~-|u}qkD{cav+b)FOrwzYL};duSmt>|sJV?`V^6(qqw7%} z)NU=U*!`1zsiips0^<@HsZxQCK@PS~vBv=1j$fSV0`U?`z=EwC=qsM)WJp|xsY1^i zCSA34`XJtZ_ZPxa?V+Tj-GW*}%qN)-`4fa#0}&fCSh*`*=cM@pGV?_bTzAK(7(C(L z5bJ9NDYg>dH*PPY>JoJDJnUwx4n>Zdy632G%n@bPV_LgwopX7xBAHvW_?t^GEmJ#R z$Cm9aCXG&F=Bam&GHKvmp^hO_9MjgGUQ>6mZHt>Ba@?Ef;oGys0K!dYfJEYW(ZZA zvvNWmm_2xhz2{y(KODH2h23^0Y)@J3rcVZ#PEHFE{ULOo+#iB^`&%MAfZowZ6w@x#o^hgOQgoX57e6we6#_j*?Or6xs6Ep9AZe3+^7ZDKmc#7+_se()7EuWoz%6`**yJmV%4 zLx3x^-zfDsv6ows=J#I4SVpAl?8L59-+qIH$=6xwqZfQ0xtGa0&pP8nXf)9+Zv3rf zbG?{O%aC}@A=A-4@dmvuq#N{PIh`TlqkGbn6uy5=?K2R$W{{^u+)p!a#eO;(?S7No z{MO`f&7^FNnCAzDKh92mj0(G@<^bH8F4eap_v$EY9UX@XkDn;I?i6KkoW0q zMr=;+jtEu^wP?So&Fo+}s@j+$CXw-=8$az*r{!HcZ*#TI%=Yle2}k{HbIwP_XX!ke z8~d|eF_a9A4ylyc%}q|0v+#iwwvi0Db~gmXFif_9)p0E5X^Nx&3?TECtXw!sI49q(5Jg4pwcp~VqZCQRHfzmajsH0mK_CKb zBmM1pcRyIJQdjbih4YjYpCFjzO^6WMSR|}~MCqG!k}#iA_-g)}rt-xFDsNMdRzNW% z*V-K3>1K8rMp2IT=l^}VEDUlZuPn;7m0nYB9%-UwQMw8})Lh&`Q0G{mBC2yAtO^=iE;YMLaiyJdb zZ%cF_#+xq0*+jPXb|iX{;T9qA(+g|~oKg?V=+UY|3>nu&OqA*2(3s?4zPaoMXE(fy z_=iK|CDM523RYdjS^jCw4MPcV#UyG=K`&EP#`u^w}!9t)iw zORF9$w;pTX9-HtU+xQ-H-}{mIT7@ARXiJPjK2k_E?K&l12GUCrvz7#UU37X~t$N+u zda1tFRHfcy@x2~7y~p9b?v=e>J-sKI87F6ZPi^#`hWF9L`n;9;d}RBKH7YMl>P4}2 z*UxKc7!W2^P}*mzU8D|J2apk3yDmzl1S_QkeY5Fe10h5IW$s5^3_^v+Jd)XugE)In{t`lM3&^M7} z9vMlJjIe#=32yL|&2_7RQnW`UEaM7Wce1=lPvZ#Z&t6 zj{1qQk5$@*Qwxb{(UI842V}Y=QFS_l53L5%L#kVAlRU!I(k_+tcyl9~39Y`s0VVZbNhk#OQyzy@^)< literal 0 HcmV?d00001 From 48d0a52f4b7809c2a1e209217ea9e824bc9be8f4 Mon Sep 17 00:00:00 2001 From: felixk Date: Tue, 5 Apr 2011 04:42:18 +0000 Subject: [PATCH 291/541] Add mailetdocs logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1088891 13f79535-47bb-0310-9956-ffa450edef68 --- .../images/logos/james-mailetdocs-logo.gif | Bin 0 -> 9007 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-mailetdocs-logo.gif diff --git a/maven-skin/src/main/resources/images/logos/james-mailetdocs-logo.gif b/maven-skin/src/main/resources/images/logos/james-mailetdocs-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..b9d08ec12d62ed05b09d66b5ef6cfd837dbdb653 GIT binary patch literal 9007 zcmc(D=|9wqd+f?=215ncMmr&?_-sRZ9|WRANTV~boUAf^rr=%3JnX13Jtk* z>ijb|>&WPc(|<*CLqpESo;!bre&I}P-1)Qdi5HSCUmW@?f}4zECNr{F=^0t++1IkJ z=U(Hdr{xvgD9*oev#6l7{MPM?aywCc4Y$IfJAoo*91$nl_Aq(XmF{9DwTD%6r`n@8 zrL3{$SYK){xAI-dEwBExz`nGWhPqSzS7`(30Z*@;9K3$FxiN5veQG#2YA82)_{Ni# zd#6Y8_-(D@j}FC*=Km!rc<`w0tfVw~;I#$kXySk8i*2;LLVb%s;7}eZpPnx--``{(P)%UQoXv{53T2a^hLTJ5kHx zQ~qN2-KFk(OM_D{CtKeS@t241uZ(oOA9?lq<;&(@D$8*7^zzkhE1{Qcwm z*4odlk6-@$`Lp@?*XGY}e}4V=^XK=U|4D!UkNf|KU7-Kr|78J$+5*+1w>dU*gvls{ zodNyL72Q_>9p_TV7H&_Ls#)|*e@kWGb>iX7ZBF-i19=9=>H-GtRSg!BLY|g7wN?+` zvO4==W}vlZ^foyeqv6c29jkQA+j;WCvBJAF31?M4a!8fW>@8QTSHAypGHl|ScbIcq zgI{Ie&CM^&#T$Iugdkk6Xd?P~)8Ms)*NJUSZ@VmR!L#rogUU50YP4f^xXzk3=YU6YDwxPpo~fG-^t9O_)qH0MOho2uSpk1OrIj#L z!)xW45PZLuE#lx|oKZ=S1dNkmk)6zjdEOI=*Z+D~l4d^naL%^R4n8bTqJff;C>nza zS1!e4P5Z47%I5^r%Zqu0OAjR>n-qnkyIevU6c{Qpih?vGvO;~M$HFx7BdeqECYr3s z^2iP<^OU5?Dbxn3Sr6VaDQ!pQm!^6aQ3?V zRB1UR_56nwGB@26%k?x(@b(d*7F=$s(fuOIw@5IZA+vt*@6&iv9()1*~tSw^<0ws&nv&EcPn^_TX4e=nYiJMvlO zRI68|%bPczRM1;uJ_v%gP7e;;OZ{4n#bwkF-YuM?OiUNw=-X1cn&@%n@S7_tAj;cI z|K#+UjKQDzlk88c-QfkEphLaVx{ZIWUGXbUMiQw_`~S1bliugLa4*Nf;JTka%hRL6 zfJI5oKVG}y7f-T~a~H0ieXpnM`RMp~K(OdufHJ@wS0+)kIVPm9Y9xbYv;GvRmRh{~A|jgo`wPhB|G)D0}xD zyU)LW>CsbJ{_!eYf2nWu+o5Gbk@n5pzqC=% zlaakhw{NNcL9Z()EjegsNHeeh*cBP|g{kb7%vWdh0}vuJx}oiMBOHx{wL_;93)+Ii z(ziQnvAws=6&|0mHxYp_5rhYKf%BwT^o>+aUx@BdbGnJa989<4Inu1i_~@y9zQPgy znR8k>a*5xb+`VK9fQT2qGB zJ`_2rVCck+4hzudoG(go9rx5ql64w_hvQ`q%ZZ5C@O%jF0M+QEMhyF8 zTm_a#OWP%oCS&)<13|Nq<>>Jg%_1SO#EPZlAk6lT(?VsFQKTVi%HfaNgvO%elN3D6 zVoICvSddb-GOzR~)ZQpw0Lf_0c%Zh;=UI7Ll*QI6`MyIC6CQ?ZxqubC9;uMO`Y~}K zfq9rv7DI%=g2>)z4xsK^Omu0BcCuq)QsTUyg0_CxekKO66c5YrNvMF`W68Rq@x*{- zif-?v7p#x-=olhucOn4uXFn#Wm47FHmb&-?y7C8_S>{*#gO-$aRXiM76<=-G#wwM> zWX{8ox_JU*nAQC<=}w%-}QCWCa=A zMWQTmHy7ubJg%&}{Nv=nSfR#^aI+Ly|9?;c!xHEr#YKe!j!V;z-2h`7;RB7$Zt2^f zvrHO`3pMPKOC-}+{Q1HlO_W*f*6Z06j?x44fKDopf(uO7Gvb2o_sYC-x{?}jOM0k9 z|MJWGL#@BV4I}4sy1yT~P|Q&3lcU@iu%8$Ac2c39!Qj?Q#dEvm@WYE1G_7FuJq=;LyJ2F=Q|eiJb!49sqP8zC9w~5gX|Vz>Y`|FOI-8 zQJw>I+KV<|D`qkr>VfNugF(Pa2dEwhJnH}_Y@!*PwIc(qg+=<%#~8p;@}UUqNAii()ZAWg;-JnBCRUQmyIwJoFu^xiG18@<7}+IIk-^mzw#6m7*ymcn3w9} zrw2s^rD2#D19l>q48oB?zsOatfB8v2pHKFngOR^y1bAON(SOlhUaWpv=87{ zVJK!G%^lEEiV~NYm4UqS=|z;l);Fz3*=^R|b;{D_ewJsygOQHC*;REeb4x*9dKzT{ z;eGY`^E?}$4!HNYYm=@{P*JDS&!V+3kSh4oB_Ne^R)GXBp2ZeO7{BxLU|J9~y@1!_ z9ux^gvyo~jPx=e!HO5~*tbjxmthr|4XEg;6ifdQUtbQaJPqbZ%R0i}W1~bdlz{Ifn*)+7 zU_MM?T>V0>f*c!!setgRpqROAD@=>XeK#Bn4jCp)78+919OJ~3{a50uu5aq^!?Rmbpj1ML`fNK}*HjnB1 zsNx1`CE#QQSvm;23ZcHsX?m3RWZK>SJg_$5-ky-}^a$uz1r;!WQyUCK(8XdR6y00^ zH$j~JdJR&6?8?6wW}OsyuI!n002+_!&;y?JRd(sJCrCWJ3Ei+?y*gGcomPY)gByrI z{Sg)QA3>&J#c8RQ+3%xLt6?qJi55d z=7Y-t+68;5%h}_=kksX!pUnQuJ90sl%4tfYB$Ey@7{dWsO0nBL>p7y_w5lqtzN%+m zJ)Ie_gG5S)Sv5%++PPt8YpW}qQmeF5u@r(J5BM>+FN*&a!U0kKRCOYE`gX?qHenx#@-DSqt%!B0OyaYQ^CtR1txa_19##uxu8wH z_nVzu^`ECuW60m@)#y1ab)pgGaTOzk=OLQ*Cjv3O=Q>_MT??D!(|~(Ymw!k=9pNto zlYM}Wga`}kcj7q`D9aas7yumt>~ILKYfN=ms+F*a&1a+PRXNVmpwtPccRW`!n%`A; z@SdgO|MH=i7aY`RkiT0JljiRI7Gn9V-PYV9hI++yGhm#7E7Ot*H8WN^133Fvsd?}x zW?{$Jk7dU4WczE}Tz~~<03mRuGGo{f|5O6CrMZ8PGwPz_s!=k|N-8$_njUyug8);tf$bGw z(g&4wEsm9u(eZ3(;WWC+H?v%d;-B_HLQqL`(=Ud(%)Y9N6F6`kVo5 zIS4vmp?u|x`?)!_O(Awt*IADPQw@#nWV#R129ClY+){{H^TSMh9>%0Yza8Ip%cX#b z45T5q+d?-(vtg@^bA*lwHhMD@x=%VN*fu2EHuP^MAHB++U%9UN4%5X$thI}wEfKl# zKwUFd{Js(n#=c*<28+es{?G=Ey>x(m2~vT1rvC(4fkekXc!VTutYa0aMV7Po6tpcm zDdx@XAWH^3L(-e(1a=W%$|OO)0M?LNq#?jI(4mi^5Oq+M2SL(6N6?Rgxj1l(GdQ9d z2i0lq1zNs}G5VFG5e%do2$K3}3ue4c#nL4~qZ!1^L!@uJjpe{h&f24ca;^*TjYol6 z4pffnEjJ6FAP@ew%X?7T4XGHk7;rzFg+Fl%ICCr6KR4WOJUt);Cwg=K{IwG)Aaw!X?0n}qSqsU9p^s=s;p=n>Lj3Za+U5h4+ z1qUSH^jZD&c{H+dG|6Lh0tUu1P`nVm><(CJ)U!|ZsgsdNn*-f8Gwx^_G*F64rNMp` zfE+YHh^^Vj9oAeJ1qZ3Zd*lG`6J9($3RnOenT`O-B(DwJ`UC|hFGS<9nhdz*FmTwXmN51#l}J4s4HOV_ zj=8+P9Q_)KubD2vzq$n6K5^--E5PF*%20@G`kR6iKoc41E`^e5@U1K4iRF_=!v*l; z0>m|PC)NXZh5gDb!txC;?<1(NU2^_+urQCxEP@AAD?*X?7V}X$G+H zqgW8c+B5d<9Ja4{`pW=zoP_Ofp2y4*gDI`sJ8%)8F=y%`O{=vPz~yXWTc|tMe~oF% zT6l~J+q7`hm*B)zr52#x7nrY{+ODw;*R=-7?uGZ{oI){AZ06rW&z%i=!=KpXJNA86 z^2J9P@8?t~R|XO`YzYz~W_1PnOxB#Qjf)UWH|+)tCDR(SO5_k?g84Lt`m(}=VC6rR zf556@j*wM0-T>fu2ErE70!EM)f|ur(t>z7FwT=o@<%I64CGUDq%7~}kO_G2y*ZWo- zp9PP*p;}Z*5`I@jWE?e$#po(hU-2MD4j)2B`yQ~IkYZNRy!1(!}luOTLwkR7P4laFkyXg1M{pIk+m%mS6cmHr=RcnwW93)}&GCn-~ zw72B1Pt-kMFSfLfa$qsn;kikg<#>_7YpHMij#kD8-iq+0tfkhB0Z3SXVsFT3Ioh8~ zu3*9SeDVGk^l5Q=Z?=rMsO3Z>2uzKHsd+96FdF;EB?f(=3@shAagq~=S6gs`>`Y3a zETk9g4cK~aAXr3l>~l2jOT1P*t5tJc`KTP0NL{ka$KMAiZt=BL-o>Ho;G0fy^J9FQ zsZRGJ#GXl?1Z{q;*}XhHuUg&Uy`iI*Hwmgn_JQ^1tKi*SImja(Diazhs`PrNTP`N2@9WL$fBE|B z-}xqWFRV*4A}7Tb(~#nQs@iOHN8QnVZM-|x`y+40yO{t|#!^cr>dYMr*&8mOc-f9- zQIN`DEUhg&`rl=X$ur~q%mQ00w}+r~7h?yt2=ftcO;KLv&QX$RH1EA9%0V^ivR`#m z1S{6KDTK2MN2Km!IB+xTLfm(^WoLMnw8=Nf?GvC()0Boi84fNryxgUo4Ka&)WK1Fc zU1O@n{w;Uc!ksIT4;D;uwEN6z-vK_CtccfGwa(N?eh+rj@YY4@%WxD_V@5R zcipacKJXiHj05%IL?MbZeu~B)HBA!w2dGuqwe49_Pck|ZSGS~UR)}^$r+P|z%(4JA zv!d{FCeC&LZd)HBDaSfZ3GqGv1PdI`AF4XCFA>yT@VjA0N~4E0w_qY#d)M-v@DXbN%jo~TPByYK_#QyU{Lf2hm5!*RP>vMuDbbhlDBX8ppBU3yG_G!N`j{^Iun=`FEyW7iH>6 z`sTUfp_=6Tfua+xgEUEVxVzad;(j?n^m^Dbu3@nHspA;Km`D+0;}t?2LT zv|HTmZN@42tgV@&x@af?QiC&(XiZdcTrWnYnWvnq{9!m~XmR5;GQk8oTndiU9%DIC zncEIB>n(SzvJg?p#xu1>Ix3+~yf^1;Eu7sVRkhxh;B4!cXZnpRF3KvO_bR7e`snAk zQ1SVB&4cLX`BbP=-ji`#W(X+U)ETB=PhJrJP(xk!ik);UrQJA6U-efTD0Ye?_TqC_ z?JS=;%J|#^@BP-0)3omQ&iE?+)aFiA>yFSy?K9cx=ZROj({q!iTVG7Th!8EqqTAPL zDjh7^qAH?7zB*}n{}bY2RhpUhCfO90w=T@v-Q5p!JySs`KApYSNN4BXd-7nu{F&yI z_f>Bk&E1^t5R{LB*u3u20Ov-6*T0PI6;{B6;V$iPQNQgzBKrq}cFJc})u-Ir^>=3t z(W^c8CtFMA@RC`)@ifyZxUI%LJXBAHSXFWKj)7S?4{n6k`97)YUNVv%XjH2EQ>2_d zG^|fPc`r@hm(tz*(i zyEqIrs+q18X+ZG_+A6!0Mt@g2ZH+H<>tVuDc2EpGf0DLrv-6v)uh@^+yhfJk*JWz8 zFR#3^$=gx!S=I}Y=kI`NFHC;&Nt@$I)~=hwhFhNlXBZURN$0ER9DtL!Qh20+_U-3{ zY7p?OkTBvWJA~27qC4uo@Pqe4qIOWgkv3n&CqL{S-HrJ>tx$W)YGlue z^DbDUc(ALv*0QQ?YQO1G%Nwi@pUnt{+L1ryaa%*>l!NN0r%Zx{7*uJHn)9*=e`KK{ zL~&U=kjZS}-@)_GFIwut^-o@?rk%YhUslsl?-;0joP$bjg09x5^~B`g8W}f?*vL(H zO4Y3W!cs~oJ(@t@uxN$QSzGl-)b6lgFl%drd($#K zl~jV)s+F%a>xh&?wY`^DDYApZlrz@$iL}{1epScA@9eYx(gVT~g*x~EMDo2ElNW@J z`C~x`9$A>ASLwmic1&#CWV-9e4XakW>}Ke@;9z6_Xb1m%3K@|KR~GveI9vf=?vf^~ z2MsGvhwqVJE0E_=R3)?5$Sm(R#jTY6{yH8^rD9}*+=}gS6|I#o0`ldP13|c(43s+&g3VqEq9m#f*ZbNL!d$Q` z`BlSV=E;yTH%b`i!`|&3Hn-LP+fefalmpoqLIYJaILBQzD-A+hazOBWNm=xkxKSfW zuQS$2UZY_Va=O-TFLf?e4n_vKe{U>!pBXlnwuooBlw&%mXfMTJlwQWZ?x;e7QU;; z2P=1=PG4pTF?ND2#(!hqe#zr5MTYo()vv%YuJQtB+5H@_mY14rUCZoSiw&WDZZ{%; ze*@EhLRY5dad*aa;&5zc#oQWPPb$gqvt#EJ6sN8mdL(c*xC-$_Pa@m&x0b?1*!|5+ znQUqFe__EgHd9Q6C#6Y0)%9F?69G!Ez6qnLqCbD!Q$8uAf`4~G%mq+8GW00S!!ZSP zRDiS-fb+>73;|@Dz>g@vJSRK*3J^17nNl+Dx8PGZ8M95Out-+iB{(AO0?a8&DMHnJ zp&Cy}Fc+xQUkfK9OwhOfB$_BsF^Gz`TI&ogbCHgnNY_iG7b@BjC(=(58RUx$d7_>C zEs>E}wClNO_o7H|Na^1*jR7l7*~w{{^@!~>rny)5UR~zixNggoZmaxmYhL%h(rycW zx6SkJ1B>0};_ibmF&QUTqB3pG#fR<0c3xupP_aXt_(+P_F<&1}$ff7xVo#Ut zzEXdPLnTa`$$d(qAnnMZe2TNg{sa802bth|>ptLK1sD3a7C*Eezm%!^wY(UsNWSWsv=*e}Il51J!wYXqad*?gZ zp{;$%cKtsOr*#n#PT0nG0#s~i?kAJ}6n=k}xIg=Of6ik6we|k%HvJ3`X#f8K?@JbP literal 0 HcmV?d00001 From e6ca01ea08a7d7503c6566e7f61c776cad1ae7cb Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 5 Apr 2011 11:38:37 +0000 Subject: [PATCH 292/541] JAMES in lower case git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1088986 13f79535-47bb-0310-9956-ffa450edef68 --- pom.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pom.xml b/pom.xml index c8f8e564f84..c18c86aa8ce 100644 --- a/pom.xml +++ b/pom.xml @@ -26,9 +26,9 @@ org.apache.james james-parent - Apache JAMES Parent POM + Apache James Parent POM 1.7-SNAPSHOT - The Apache JAMES Parent POM + The Apache James Parent POM http://james.apache.org/ 2006 pom From d8068ecff4f1db1bfcde97d4cb6683e399811f51 Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 5 Apr 2011 11:41:19 +0000 Subject: [PATCH 293/541] JAMES in lower case git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1088988 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/pom.xml | 4 ++-- project/pom.xml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/maven-skin/pom.xml b/maven-skin/pom.xml index 6da5d79f883..a021cecd40e 100644 --- a/maven-skin/pom.xml +++ b/maven-skin/pom.xml @@ -26,8 +26,8 @@ org.apache.james maven-skin - JAMES Skin - Apache JAMES Official Maven2/3 Site Skin + Apache James Skin + The Apache James Official Maven2/3 Site Skin http://james.apache.org/maven-skin/ diff --git a/project/pom.xml b/project/pom.xml index 998c0aab784..26675693436 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -26,8 +26,8 @@ org.apache.james james-project - Apache JAMES Project - The Apache JAMES Project + Apache James Project + The Apache James Project http://james.apache.org/ 2006 pom From a0fb96d5c07169adea32a2b44544eadc039f25ca Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 5 Apr 2011 11:54:43 +0000 Subject: [PATCH 294/541] Move UML model from server to project as it also contains information on imap,mailbox git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1088994 13f79535-47bb-0310-9956-ffa450edef68 --- .../resources/model-eclipse-modeler/.project | 11 + .../resources/model-eclipse-modeler/model.di | 23 + .../model-eclipse-modeler/model.notation | 2815 +++++++++++++++++ .../resources/model-eclipse-modeler/model.uml | 176 ++ 4 files changed, 3025 insertions(+) create mode 100644 project/src/site/resources/model-eclipse-modeler/.project create mode 100644 project/src/site/resources/model-eclipse-modeler/model.di create mode 100644 project/src/site/resources/model-eclipse-modeler/model.notation create mode 100644 project/src/site/resources/model-eclipse-modeler/model.uml diff --git a/project/src/site/resources/model-eclipse-modeler/.project b/project/src/site/resources/model-eclipse-modeler/.project new file mode 100644 index 00000000000..6eaa05a7dd9 --- /dev/null +++ b/project/src/site/resources/model-eclipse-modeler/.project @@ -0,0 +1,11 @@ + + + james-server + + + + + + + + diff --git a/project/src/site/resources/model-eclipse-modeler/model.di b/project/src/site/resources/model-eclipse-modeler/model.di new file mode 100644 index 00000000000..98d713b58e6 --- /dev/null +++ b/project/src/site/resources/model-eclipse-modeler/model.di @@ -0,0 +1,23 @@ + + + + + + + + + + + + + + + + + + + + + + + diff --git a/project/src/site/resources/model-eclipse-modeler/model.notation b/project/src/site/resources/model-eclipse-modeler/model.notation new file mode 100644 index 00000000000..a2e1f955213 --- /dev/null +++ b/project/src/site/resources/model-eclipse-modeler/model.notation @@ -0,0 +1,2815 @@ + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + +
    + + +
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/project/src/site/resources/model-eclipse-modeler/model.uml b/project/src/site/resources/model-eclipse-modeler/model.uml new file mode 100644 index 00000000000..34429cd68cb --- /dev/null +++ b/project/src/site/resources/model-eclipse-modeler/model.uml @@ -0,0 +1,176 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + apache-james-domain-xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From bd23ec57f9712ce85e923f4c50b2291eab302f38 Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 5 Apr 2011 16:30:31 +0000 Subject: [PATCH 295/541] Fix some content (naming, feature,...) in the project web site git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1089116 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 2 +- project/src/site/site.xml | 2 +- project/src/site/xdoc/index.xml | 55 +++++++++++++------------- 3 files changed, 30 insertions(+), 29 deletions(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index ef527065d51..5be4702e478 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -260,7 +260,7 @@ Mailing List Experimental - yes + no yes diff --git a/project/src/site/site.xml b/project/src/site/site.xml index dde14383d2b..c791391cdd9 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -17,7 +17,7 @@ specific language governing permissions and limitations under the License. --> - + org.apache.james diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index bb8dd5fe8f2..5c6dbb76f62 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -33,7 +33,8 @@
  • Server Pack
  • Components
  • Call for Logo
    • -
  • Video
    • + +
    @@ -42,7 +43,7 @@

    Hey! - James Server 3.0-M2 is out! Thank you to everyone who contributed code, + Apache James Server 3.0-M2 is out! Thank you to everyone who contributed code, documentation, bug report, feedback...

    @@ -51,14 +52,14 @@

    The Apache James Project delivers a rich set of open source modules and libraries, written in Java, related to Internet mail communication which build into an advanced enterprise mail server.

    -

    All are welcome to the Community! We recommend that Users, Developers, Curious and Fans subscribe to the James +

    All are welcome to the Community! We recommend that Users, Developers, Curious and Fans subscribe to the mailing lists and follow @ApacheJames on Twitter.

    You can also read the wiki (discover who uses James,...)

    -

    Just like other Apache projects, James is developed in an +

    Just like other Apache projects, Apache James is developed in an open and collaborative manner.

    @@ -103,9 +104,9 @@ -

    James Server 3.0 and 2.3.2 are integrated email server with advanced fully functional features.

    +

    Apache James Server 3.0 and 2.3.2 are integrated email server with advanced fully functional features.

    -

    James 3.0 provides a mailet container, delegating to independent processing agents known as mailets. +

    Apache James Server 3.0 provides a mailet container, delegating to independent processing agents known as mailets. It benefits from modular architecture, is built on Spring and is moving towards OSGi. It supports the following protocols:

    @@ -118,14 +119,14 @@ POP3
  • IMAP - (see IMAP sub-project).
    • -
  • Sieve filtering into mailboxes for incoming mail.
    • + (see Apache James IMAP project). +
  • Sieve filtering into mailboxes for incoming mail (see Apache James jSieve project).
  • Fetchmail from POP3 and IMAP accounts.
  • NNTP (better known as news, only with Server V2).
    • -

    You can also try the Hupa WEB-mail solution to give access +

    You can also try the Apache James Hupa WEB-mail solution to give access from any browser to IMAP mailboxes (hosted by James Server or any other IMAP Server).

     @@ -134,52 +135,52 @@
    - +

    Developers looking for a modular mail platform on which to build can look at the modules and libraries used to compose James Server 3.0.

    -

    IMAP provides a flexible codec for IMAP, +

    Apache James IMAP provides a flexible codec for IMAP, command processors and a sample data access layer. In combination with a socket layer, and a mailbox persistence, this library can be used to create an IMAP server.

    -

    The Mailet subproject collects products +

    The Apache James Mailet project collects products related to mailets (mail processing components analogous to servlets). These are independent of the James server and can be reused in any mailet container.

     -

    Protocols project delivers a lightweight, +

    Apache James Protocols project delivers a lightweight, and highly extensible framework for mail protocols implementations.

    -

    Mailbox is a flexible Mailbox storage +

    Apache James Mailbox is a flexible Mailbox storage accessible by mail (imap, pop3, smtp,...) and other protocols..

    -

    Mime4J parses MIME typed documents (including +

    Apache James Mime4J parses MIME typed documents (including - but not limited to - mail). APIs similar to DOM, SAX and pull parsers are exposed.

    -

    jSPF implements +

    Apache James jSPF implements SPF

    -

    jSieve implements the +

    Apache James jSieve implements the Sieve mail filtering language

    -

    jDKIM implements +

    Apache James jDKIM implements DKIM

    -

    MPT is a scripted functional test tool +

    Apache James MPT is a scripted functional test tool suitable for testing mail protocols.

    -

    Postage generates mail traffic suitable +

    Apache James Postage generates mail traffic suitable for stress testing mail servers

    @@ -312,18 +313,18 @@
    +
    From 6149938a4e2db15e98d0c72d4c669335e07bab0b Mon Sep 17 00:00:00 2001 From: eric Date: Thu, 7 Apr 2011 13:52:42 +0000 Subject: [PATCH 296/541] Avoid additional icon from standard maven skin on buttons git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1089884 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/src/main/resources/css/james.css | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/maven-skin/src/main/resources/css/james.css b/maven-skin/src/main/resources/css/james.css index 27c7cb7e58d..055350341df 100644 --- a/maven-skin/src/main/resources/css/james.css +++ b/maven-skin/src/main/resources/css/james.css @@ -21,7 +21,6 @@ Button From http://davidwalsh.name/github-css and adapted to maven site. */ - .minibutton { display:inline-block; height:23px; @@ -38,6 +37,12 @@ text-decoration:none; } +/* Avoid additional icon from standard maven skin on buttons */ +.minibutton a.externalLink { + background:none !important; + padding-right: 0px !important; +} + .minibutton>a>span { display:block; height:23px; From 14bb9b249f2b36c6b62fcb3c05e5061156d3110b Mon Sep 17 00:00:00 2001 From: eric Date: Fri, 8 Apr 2011 12:50:05 +0000 Subject: [PATCH 297/541] Announce Apache James Server on main and news pages (JAMES-1219) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1090222 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 6 +++- project/src/site/xdoc/newsarchive.xml | 43 +++++++++++++++++++++++++++ 2 files changed, 48 insertions(+), 1 deletion(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 5c6dbb76f62..5352609262a 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -43,7 +43,7 @@

    Hey! - Apache James Server 3.0-M2 is out! Thank you to everyone who contributed code, + Apache James Server 3.0-M3 is out! Thank you to everyone who contributed code, documentation, bug report, feedback...

    @@ -371,6 +371,10 @@
    + + +

    2011 - Apache James Server 3.0-M3released

     +

    The Apache James project is happy to announce the release + of version 3.0-M3 (Milestone 3) of its modular mail server.

    +

    We thank all Users for their feedback and tests and we encourage anyone to + download + and discover this Milestone 3 release.

    +

    If you're interested in contributing to the James project, please subscribe to the James + mailing lists.

    + 
    +        * What's new in 3.0-M3 for end users
+          - Numerous IMAP bug fixes (better client support, memory improvement, NIO and IO support...)
+          - Support for IMAP IDLE (RFC 2177, server transmit updates to the client in real time)
+          - Telnet Management has been removed in favor of JMX with client shell
+          - More metrics counters available via JMX
+          - Better debug logging on protocols
+          - JPA validated against more databases (among others Oracle)
+          - Multiple address and port configurations per protocol
+          - POP3 is now operational (was buggy in 3.0-M2)
+          - Mailbox Tooling to copier from a persistence to another persistence
+          - Upgrade tool from James 2.3 is available
+          - Better logging on protocols with adjustable level
+          - Full mailet package must be specified
+          - Composite Matchers
+          - Better debug logging on protocols
+          - Mailing list functionality has been removed
+          - More documentation on web site for configuration,...
+          - ... and much more, see details on https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10411&version=12315512
+        * What's new in 3.0-M3 for developers
+          - Less maven modules
+          - Maven 3.0.2 required to build
+          - Upgrade to latest frameworks versions (netty, activemq, jackrabbit...)
+          - Code reports generation via 'mvn site -P site-reports' maven profile
+          - Corrections further to findbugs,... reports
+          - Code formatting
+          - ... and much more, see details on https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10411&version=12315512
+      
+        * Quick Start  http://james.apache.org/server/3/quick-start.html
+
    + +     +

    Dec/2010 - Apache James Protocols 1.2 released

     From 57f56f4dc085432a22f3f4efd73a7bdc4377ba9a Mon Sep 17 00:00:00 2001 From: eric Date: Fri, 8 Apr 2011 12:51:07 +0000 Subject: [PATCH 298/541] missing space git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1090223 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/newsarchive.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index a205c45f571..e3f9538f4e9 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -18,7 +18,7 @@ -

    2011 - Apache James Server 3.0-M3released

     +

    2011 - Apache James Server 3.0-M3 released

    The Apache James project is happy to announce the release of version 3.0-M3 (Milestone 3) of its modular mail server.

    We thank all Users for their feedback and tests and we encourage anyone to From 1a7551f94740adfa28708483650c8a86fb9e5b2c Mon Sep 17 00:00:00 2001 From: felixk Date: Fri, 8 Apr 2011 13:14:25 +0000 Subject: [PATCH 299/541] Add james logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1090235 13f79535-47bb-0310-9956-ffa450edef68 --- .../main/resources/images/logos/james-logo.jpg | Bin 0 -> 5180 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-logo.jpg diff --git a/maven-skin/src/main/resources/images/logos/james-logo.jpg b/maven-skin/src/main/resources/images/logos/james-logo.jpg new file mode 100644 index 0000000000000000000000000000000000000000..6752e5e8a2072ba67f2ac7533998ce602cf23402 GIT binary patch literal 5180 zcmbW3c|6qL*T6pv#+rT0zJOqN0Ros?~C z*&1WZ5{-Q@W`25>@AG>7{(7G0+9wP5oz{3C-E0rKhE(p`m32gX!p*8JU@x7@3$@&T+7@oMS)7#KgwK#?Hyb&CSis z%FD;Y#mB+L&Gp9#73gda4J`vLEdv(|6ARb>StxA)J3Zh8M1iQp0cv(C5IYs63lISS zD%!JX{{;MBLPdQRBOREYfsyIV0K*1QQ-MI#G@w6GpIJwptphadv>al}`gELDZeZ~s zE|r+Hck~ihE8DrPM+lOt?!mDPj6A%2{O6@ENXy7xR8!Z`)Vi#F?Ye=Xk+F%X%`ICy z``ZqV9(O#wyzlz>hCB!j3x`KU#yyIE{N!mu;)|E*8JStHUS}5+zAq{+`Mb2Ns=5YK zTUY%_!`u5K5-u}TM@#y#u7Zm{dPpp5) z{*8KQAFgSD8ANq!G$%6j8UywuH3ZehEd4@a&-KHacidY@WV~+5AbIlwc6)e-@<0E9mr+! z+TA2|Y^hMm@Y1M8f4n8kz}GiuSke)g5-HM^>7u987*zi3dNbQ~+@&s-By*k!&n55S zw7i0b-@7%%V>T6?q?G+5)x}f4o>n@f`i<<2DJ%w} zy%t}7T99F^kUEf?ma1^Sdwclk5&JH?YXC^PcR|$`^Y^$#PW+KTxWB{0vWc}hh|74! zP=(tcl+RM$zOb87>x0XO9jN&W6C*MstEoo4J^43B5cbFbZoL^J&DAlnle z{~G+@9uh1uobQD;FV1;3clXq47yeBMK^uXuWM9s8$tE{IM%QB#W!^3_$`nNZqp~l) zJr|1*^3WfDHP3j5_vW0!s;7xjnUcibTh_eRd#N!T2x~${MPp%`WrCX0Z^7rOI5is2 zaU(+setLaoCT78f7BiyDi4$>gzU6~Y!Fq5xIgcR)qD}l18!B|2s`l8{Yw+wTmN_4bk zwd%e~d?&LahmqXGfxDe%^%{{i*HqUu@A1G-jel)ywWi3eC=z9|+CG?H#VQJ1FA{B0 z{_Y#YcE63Cc?zOU12sS={UYg?BNWF9>&FxoIn7Lf+DW!5m)n(YxkN9A<_QLr|AU=xmKt z*cke^y4k@{w$@m=lUMIacJSRoCg&^%YIdGF3hzf+ ztrRI9ofsADrt49F=KRvVTXuC;t~0&53RRsKpBULZ?>E%vzJ$m;&QJKoWn}>Tw|c|^&QGrfaP=ie1ac9>#XWK6d-}buz-Gin6hmqi?P{p{!k^yJdfOuu=&-N zX9U^U$Ue%Shi;mGM7W*4)srAW#&lKbUKbPnD|nbN-YS|I_r<#2l0GB0_<8_|l?{h} zt7j(r+JEEMCmyZq`_P6Te*gI(FttT;Skm}+D8EN9^(9+SVU(0ml-@zasX&syMZduAR!*f7%c!Q_reQ&s5cx7;uxuKbc^n9c^0 zrkPMaGh=k{hI%>TM5kgSjDMqsptDniEXItyy89JYll6-Ncq}aC^op>&Gruy+69qG? zkq#Piuv3m@=nQZU89Rp|c=lxcjnJrnacB^YBL<}e?A=~=xKj%(eYvMSFMPv0E`=Ul zTaJL05(C`S_c$H6B$Lg|y_928lEB|`W7f5I2ZC@sy25#?DKIV{MV6j-$-74We6pb_ zW}DVfxav&i@jjMYP%X2Plu{P5QWfZ$N+P8SSPF?eZJ`+j#-NzZnwjvIH(uMiUdgGx z)X3R)rB%u1O`~zI`r^l*ZAhKl{ahpJ#lr4=IaZPo`UA*0NHeX!ueNI;Vb_HMJSyqr zAxEXBuB>az!&HXmisOT7^t91-{Cz_gh7xOBpuI>Alf9|=Oze(CxSLie?4|U@`(2N% zmGt@h(4X)h4RrM`Iz$?_Ef1@!5PrI7wf_MMuePTqJp%zSdLxiVx(1hjdv> zFg0^5Ir)OLaQp(!`DMGS%KN>)$}^U<VE~T zDwlyFP44CAx-6VHz--zUzA1>zUaic8h}5bNxesH;M`WfTwTLw#w$D6E4KGP2A{@xylCS? zFhp#lyBk<)3nBS&ErQc#9GK$x@Dk_s@S8@dX;OFU>x>7Lcgk`fXo*If)Y)WG0IA~) z(_FWB+XxQ-)<`EGtQ_Nu(q%k)TDTLR?#eutb*p*QtZ>X53Ij~j&maX47BC7qI&=)Y~VRt-V)mgGSaa-tOWTkvAjMg+yZ`_`4_q!$eFJ5-$xS|ux5;a6{Uo>kVTH$5Y zT#Pr)>ti>&%XbwfvX!FcRF*aaE(@g?`94`hKM~&!Y)1?FaP&y>W=k!Z(hmxD%orcC z#6r5^LnO|Jj#2gpcEfKYn4efSH(~fMPwTEcXC)=La0hX3*t`A+h}6;88lS`c*x%RM zaFAesyzR_VnaN8Kh)kvU?Lek9#699$K6oQBmS#4!u!jsq*{g=a5H_ z`OX?a0tp-}mpO(>O}2&yySR565R%K+ySyz~<}8EMegQ+70qJE7^ovjX<9Ze@qhCG1 zqWmmp(A_-Y$HgTj#1Q;x?!mE#kEXxBd^p3!t2^?~`s7z^>Vs|B!q6oY0G}g|T7640 zq5vIL8x$b10zPQ#6g1;;@l_h6e|DT9Z7j@O zYk%3E*OIqTc`ws)8?zPSKTw>yUDtm&b%J_E3fi8;lZ#56hwv~aVsGb*IRo0IX~8U> z!?3jKcppburY&2rw2v0>0-%{}o$PO|*4*63D<)5Bv1zs}g1=`5JYpqilVV z%FvyGqb0z#rL5e?RMmMTW28N$(4JM@v{{NlVGePE7`E@gRo0R6Qa5=i0PGNY?6`ku zj<|FpfcmmZ9zpF>fDj5$gm#!9OF?17zrME4DWmYPV{0X-uN(y+nnCB^q397hrEiY) z-W>3|*9E2fIEJUCK&NFn^6zjTv%^G@v(W0+geDs_+-702b0#EeQIVm^;y9SOc~;r% zr{PT$rvz_*sHZzv6tqeKSfT!k@hz%YH-F2nusqhuTQtohy4R$?Z(S-T%TNF~fQ;lG zgwG4csNt$h)%7Y?al8!f1b75~Qsq&^oy>BbADa<}x=shN6d?UMf}H|RB5@s$I-WOQ!_uYPTo>_1Rd1azF-N?b$=#kT4{3Ip+%23){cLXN2>tMN z*L#Nh=!gQ)Y*B!h@x-%-3o}1E!VvpaA%w^YH5}$RjD(QxeIDC;c&a_UzMRDAGNWrE zb8@R!<~A_P2H&qJ`+8VIMx`xyZpxoi*2F@Otqz4Ny-y2^TpiQWbQO6Z;j$tVEwU6K z_9i@`qJq5fqRXv-`K?+h+#3UaX5@-w+MLsyh4$8fp7J! zkvHPt#ib^6;QbXrWBY*fvXY`d^T3f8PcS~MxA?fqJc$iaQB#U9!%6%$2kf8q&YxBy zRf*wN7a*oy&7QcPUGColsm=+SQB>;3(lB1+C<@SZnMWl%8ubpvJBIikV{+vDB54Fo z!eVr5;bT#o+oYtoJT!Db?&1_l;=~;xy>0kXXrTAmN8QUvz$sb8HQnLI%$FY;i8naf zws)3Ah2YCI zoS@+LqFG7p$M2Y&hW^IY;-tzKpVP66+J8#{LPV$OUB*{nOs)QMEIJmo!(_F!EF3e* zllp0KmTmP5Ie`^He(|h;kvt2AwqM`m!tEH=hs3oQ_r+(qr!m;^4@ZF;Go?lc?WYM% z&~23dSd$IjPi7DGRHG8pZ+5ql)7q1NXW6RvRZ#rPxZD8A2b(Cj--*-cZVE7kyE=~f zlDBcY`h|XIA|RYr^q3$;+M{5U28FPdaL zJ>#XhWZK6#;+;TMsfV;T?+1fFt>M5V_99}(@9xYW+}Ofx_1VV`m=NFcU}u8y^H}?6 zZTCjs5&eEso3+Z0ZM8LQhP<}l8wIb;Q75?vt^2s2sY&NMr-)lSVkcLpNP5&-tqa%G zi{2-*_UYa0Yi|i`9xA^-@UifQ6cm%0GAh%SQPZqdFC0_n)$(S%MF?)wWxoUSZQ&ci z=u86Y11tGlSS1j^<0&~GbnC2zSi+gek5bQ}=8JI@;A#1g+R+f1Ll(NaRr8w!e4+pg zXEo^f)%i^|t{4 z*M)(QvR7iniEB~Jer?80nqG-|(SnS_qb;n68#TLnquUka!!V7l;qt6N=RL?-iF;_k IMMatV7ejgbCIA2c literal 0 HcmV?d00001 From 17a18b4e90834f22219549b4159f03f729a9e424 Mon Sep 17 00:00:00 2001 From: felixk Date: Wed, 13 Apr 2011 04:44:45 +0000 Subject: [PATCH 300/541] Have javadocs generated when either running mvn site or mvn site -Psite-reports, but not for the goals install/deploy. Move this to from server to project pom.xml git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1091645 13f79535-47bb-0310-9956-ffa450edef68 --- project/pom.xml | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/project/pom.xml b/project/pom.xml index 26675693436..7b9938c9d91 100644 --- a/project/pom.xml +++ b/project/pom.xml @@ -102,9 +102,54 @@ maven-project-info-reports-plugin 2.3.1 + + org.apache.maven.plugins + maven-javadoc-plugin + 2.7 + + + + org.apache.maven.plugins + maven-javadoc-plugin + + + javadocs-for-site + pre-site + + aggregate + test-aggregate + + + 256m + 1g + true + + + note + a + NOTE + + + todo + a + TODO + + + warning + a + WARNING + + + ${target.jdk} + + + + + + org.apache.maven.plugins maven-site-plugin @@ -157,5 +202,6 @@ ${basedir}/src/site false + 1.5 From 41dd97ef644d7865f41127d4214b6e3a246bab74 Mon Sep 17 00:00:00 2001 From: eric Date: Thu, 14 Apr 2011 04:34:38 +0000 Subject: [PATCH 301/541] Use direct link for button anchor git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1091998 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 5352609262a..93ef0d59884 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -65,14 +65,14 @@

    - + Download Early James Server 3.0-M2

    - + Download Stable James Server 2.3.2 From bd8012b66ed6b78daaf24ad53e12c493cd8246fc Mon Sep 17 00:00:00 2001 From: felixk Date: Fri, 15 Apr 2011 19:24:15 +0000 Subject: [PATCH 302/541] Add postage logo git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1092790 13f79535-47bb-0310-9956-ffa450edef68 --- .../images/logos/james-postage-logo.gif | Bin 0 -> 7583 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 maven-skin/src/main/resources/images/logos/james-postage-logo.gif diff --git a/maven-skin/src/main/resources/images/logos/james-postage-logo.gif b/maven-skin/src/main/resources/images/logos/james-postage-logo.gif new file mode 100644 index 0000000000000000000000000000000000000000..d38961b1f721b444a4be9fb40d3c4988e8021e7c GIT binary patch literal 7583 zcmWkyX*AT08~tr#W|(0H!`R2ZGbCHm&yu|wDqE_lBqT}5S~Fu88v9lnQTB|Yz231T z3QbaJeTNiUM@6FYfB#?Zx!>-&_niBj^IUgNH(R?so4`=u2>{$z9eMU-tfT$nyXvaC z(D1*%{~nD!`uMtYl#()o!AMZ+&E;e&D{A~%n*Oo+_wV2NnVI*?!^3GL*}s36U#oC_ zJZ~J1I`HSaV0m?Q_1E9-+>F0-Gby{{R)75Y^!NAbkNHPhcI#~Hk{R1pKP}94b$=Cq zUj6mcf_!x0@3-aEU-jw4<>g<0Ux^Z|*N$(t??2!8`Ok-@hK2@bmz~ZB_wHi8diCn( z@}Gr;h5EMhrz@+jcXdB|KRYrsDEQ|N0094KYW_n0BLHCXfB3&AKw?#JHpat5`P5)T z>`;{bSz%M0S9@^BL|ejx&&mIY_=!GdH4kUIl1HL%{wuzg8eQunndx0WpO`AS!I~-~ z=S-ER%B5|fChEyisc|KxW#zjQl+lIYBeIY{p;v@>;|`m8jqqW1WPv~^zZN4 zm?5p_?|>G4*wyc@r)|_acxnG-s7*C|m@*{*luRR=oSh8PhgP>MYPQ6AcFk7fjkW&D zYISnYU}Z2DZhC^Q8F)IQa!@c^Ywb3epQomx7g5(>T-v-H{{+mFdAuzr#&^3bG1}Nt zo*NDs_ZQv9bjPqg|OlOaz=2n+75}=_W7u2<)*uwjOL6-?Cp=- zTE%?D><1))u+sp_<`5tqtB$dTP2=|;3DRXOZfkv>?B1|UU9-r>fFw!z(;~*r#Vi>a z<+xeEz)#1aw-37|`EB7`_ZAJ4hXQ>F2aHj+HS(D*XFtEbov!%s1m6-zDvjxriKtWX zHRLi87p(cX!r9dBAR$1IPGsim6#rTO>~Ta3P}(-^J;u?x3fAuv#dpWw}DB)2(3jUg|X`is)fD zBNHwQR2>)WJa9mFjT4qk5{XJmHqJRms|%2k!+mEIW}Em9Bo=5TBtbb%W86NRu#M~N zYSMdCDt^sp9lKHX2pW_EvXo5CQf z)KTTXzXunz>ApwjIjz>!Xx00h0VioEWxy2sBbLSi5A<#Yj$wEr0Dq%bf9JLGB9^aF zduY{{8-&Yyo)Vwm^+s_7p?CUSJCwHzOuhDmg#p*$b)#sB{qB;6YuhY!Big^AMCE>C zj?9{IV@{VtrO+wirxn*Y%DmUZ5~uuQvV&o)U*LB3u45)gLh&RWhBbu;1-GrXwW5blY$cbBZx_HCw-oe>_)CFhQ&1cOV&dp|x0Z(UEmKp$*Nz{_^XLo*-V<*H!XeC5>OV zv=N6;8X!zpuis^pev&K-Q%&5CjTAI=w429GwXh?ABMwfKMqB%3(NF8RblGuH28s4) zo?gn|tICLuT_YguvNEZ_{H522GifUR|$V+X~aASZ$tTdo;c}#L7T=t3%R; zv@^PSiLT1G+TGLIz>T#{bqo<1f(Cmaz5!r7fMVAJB-}`GWmhFHe$Hjzr?&F7|Mbjz z5(G4yiLji4HXNdQWT_kXxNDEGa3ngaq3=9M>^=mo6|w;ZZn`QC#rj8u656ONfE$kL zRttzeLik6}p-4v$*2tIhU`N{M@vct7^U?0pj;_w;72)S)b_F5oGz;K&)A_8WpRns9 zfXy53(Psbhc9*099M_XuzW`TH25s8KuYabzQAqwc;^|nXv>yX$BKs28Xl}|#w;c+~ z0BFA06^8x^Tbw#!90hEJ`w0qy2gx7&Dg$0ku@k^G@$i_|a#pUE6V_vz?P#T}Zi3M^R8O0susz3&psfu*QgvkVpO0ZnY1o54 zywIlsYuE{+$qu)7TibM(O%d0g_GoA#?>g2mYdfFA__W3NTQArC8;ZT*5V8H8-F7#L z%L&gTSkeTM-(9#iH-gn=$hK` z%^m~Nm$9czKAC?V2jpon1@Y-&LHK1Gb=hGIR*XrMuL}x@QNR<>y)pwm+a?nm$ru!o z^b@n)Cj=5CTSKM_zQOWOaZ&!Oy>Jutx>Bk^ZoKxY;HU_9r6}Ss{4%*jXZq1UcB(&d zmwrdddkNFOR7Xfb%3QhX2N}u;4-2vY-+xK0c4qOWw=n*msTKzb(YcQO(Kw(-_(zg z>?F1&20+Cp`$<$$tsAb*_N;24ZYk>PdZCgmM;bDf=SeusI_Na9B&96_QxgnGIKFW7v#{;L!u~HLzgvr%HFa(fwq43h)wjdAHkAOZbR#6%s z0Hx~gc_NqOqUqBlbWCt^;fVBV9?d-b7d4mDZ@x>z1ffqZNH(@ayu+ntDBmi4V3_)h zTy#3aRh2VRArFFDe9mq;9JF`fT*9%W8RK4s%07Z&eS?CHw257{YLn<0TCqtgga$8r z-sQaHzttKS+`|Vt8-GqlZWP|YD=e^qLc!cl{mEf>pLp`D(N}GzeeS114zSBTolM*_ z=16Uqjb-+~EC2q)gWp%=T*M*LL{nNzsL|uz9=m718vHX9_c{IM?4CkhzqAHbmiyQ( zWSJCdKMt$?(n-2DYKhmiy)3JMPU{M{PkLNq8<(-RY1~@DWuyk+ex!-DFRV0q;5~R44Zcefp$o$Orks!KNXh>C=>bVf zglYbE*{39&RS0}eW}63LlxcaD6RESFEY|2LQo44SBYxvgc3)A9>jUGuqMuo|vfrd` z>h{0PDc{_?qJ21iL4!S6dc{)q?5>R6s+>3(K4{8JQKmztF0{=@s1xyi1#z+Q$5OQd z{B&)6R-3;$q}&6HXyMPc24!Vgwz6=~Y&LtvL?ai{+48a@X}kI5b1WqO7S!IKCfw z=Y~u^i~0OMZHq8%;sAnSMfwXl>$y2^8<9^xls#H-ng&@YnWut0StbMq2p4jlT?@1SwT+w`gTZ7bOADO3w<*a^T@3EIBp z`Yg{_*#V)Vo*1OW?n`4481MWtNCYv<-Iz%79sDlEQ0%(A*7A-5kH!=UodHhS? zotcgLb*SbLZ%u2A+KMeC7qs)xR)?9!L=RSs+cCsPVUsT@*@L$Ek2PivhmwR$kZZl< zURsJf@iqK}3zOqWf@Q9iZJ8*eWp13Vm;IKB1yM+c0jRFf#?m192B%gpp!O2UPfQTqCT_ zKZB#e8gxjCRH?-Ux(}qtq7cRtI-*pmDy%g{p=3YJv3KTOOgMoLmc^dY5x@`)QnUe{ zJYl5t$bmE%#|Lt$@G2rWt*F0VKgs&}Y>68!$1SeVSs2e%#C)BBZCQxjvB={H#@i5i zMTIQ*6?F=b?@+ZX{hYc{?zLaAZw2PLIQI_!^hlDf;<-F&9@wo9llj;WPKI#e89KAV zo(U_&H0aPEb0K*38%UyuNGHekSCJfWxw9A)6V1uuwhk)=k5f?RNR zVaSWYGFF4svhlI6 z919|%by`Bb^kT0E)4Z!cK|==A9hpKyi|;q!s=464ncA(Flvzw-`11y3VSAD+xtdOB ziZo4&$^QbtpAF#*`fhDzioF;Jt1B^i03Ujbq*U%E#MChLxgG@`~0ICpLUF`Y;P zvynBC$fp^2Q!DbPrGDNBBjh?f@MJXtGNU*!R1tn%q#uuiS9L_SWC3LZ3h<5K!&3}{ z63vj{6o`oq&Su&PKB(^Zb!@ z1F+BgoR8VAl`Dwvj*C-Xr|2F?O+}Mi=y6YGha0_gHm}+LdD5*c%miPy&VawO#_JWz z)djXG@gW<4XvkBd2x|k3kWk6X_(xzKO9mrqw7RLTMBf=qzI6o)#w-^p32ZcI&=s4r zc>3AzK`Gr>*MG_2Q$yH>*2b;L;<2jp6X20hSIZZO$Ia`TX{S0`5fWOnTz0%KDS724 zvSmlTu@Uk|vgYSOj9Rw__@Fx*r8)D}R+D>(_i{?)b4$Mbf<#xKE5Wsck4f=^w`6(n zO)1HPV<3?PT?qggMa0bX7E2yz2lUaSPAW6{)}CIIEduGn*4Ni5x6wU7t^>#3J8v&w z4|J6W-`Gk!^`i#i&lOH9c4&XN?nV;02(z(1-Tq45K|YuXT8J}WaPCHL#O2mz26S>` zU1H?<9g!(ipIh!PdalOFmp&OVXn@vmW@{BND&+qyGHFYPEUn!Aw-Um@T=glduKb5;LJh<^^1@`#Z z6hKNT5(8Z;Y9fD4D!*-2@fjpB4=VnGJ|*=ivY}~1xGz;VYH?7O)sx61zSKnC&JFDR zm~YNJqr!sJneB%-wskD5X_h08k>h_Sqv~N2i(^3iYb&lxEyY93=KIJ!tto zA(O*uG5gd6SN5sm2gQID|F#OM`D^Jkk1PM|{D1fL6fA7z8$k!g{O9uP+=oWD(Esrc zY4W3YxMjrI*>`M8J+Yjc?iPAF_|<(hXxvX6;^OrH$r#SNy8t4Fv0mu6en6tX#Sj?F zUni?j3`R^mp|nWu+?Qg>K&zW?g}qiNnWLy~9g#(W+b6?W2U8HbY`hw|A1gNV> za#&mowFw-nwOw$h$|MH9^^hBg(N6C0H-5eWD6Kj)zTO@2Sb6P9i1U4LB7lKA(P_W; z(`mDDU|OnmUR&miSbDF)znAVpsjXow~X1uyQth#+^T}AH9u3r~blE+=p=bMEczOApf$7qWfz~|fc zE8hTC0iY8ElnfEySls+Zl)Q4|T4tK|s@kJNa&mYJFz+RloE}7TXo)Ttn2d2n`%2(6*%__vX=a6!MH)1`Qr4aj;A6rgu%U)Jza* z+9zo??i&C;wFCOsgESw&TuJgV=0NAniSv~*XJYm^#%CZG zxp04`*3}}>^-|CqUG;B%q>pzsDjV2RvMT^*X7=42g(d{5|~M zF1ab=h*_)|zcmkgB6P=Lq+R;^m)iPo9&hIFyjip1 zNPc2?@d=gy=bzQwp zWIb5v)oWwIdrf+yAOy*9^w?SyyYL`kLi z3(N%7Cj-5aW&STqF$4(=?5Us^RgROwV^U?)!U-yBYDD>i>M9gD<-@6nf#E^fqec{> z`WlL&E&iyylB&0S+GgJqvaT9QyHY}>g`%E4JAv*FUIAM_ku z(k`C~liJWiz9cqF=bT=Xq#vE%RSW4wFRD(EA?B#0{nT*>Rn-snl4w&&)Fv#!=6EP8 zdy?HL;l-VT=BjuV61@myw1y>8B3*UN-ww?1mwe3i0S?siSZm!qhx&6g{IvXwG zF=Fr%m(J`JQ%ZO}-j)P8tB?}9s1L#J_iI2`$-~Na)^Zu7AWlC?;t0dihtBQ~(Imdz z6*o82<9U^syxhKY3A;O6QO)gEqQzdXJe9pCD!sq4Fc6}9d?@+4L4%2ehHsKrf1j_R z2G6McT*%nHA@?ir0mCFog)D_xp&`KM8uQ`OW` zzga@cB@|e@ch>kiw0B5Sd;BzO%W)zuN^=kYUs-~5^r;CF$2CiFI^f44Bmav;6%TS? zIDaprKR{mPX!0i)tp3K^4wo9volKmHTI;^}arlm_*U@RpuwQGYoU;F1PRU6qyuVR{ zQ#Dd~?oKBgsl$mrvzr;SQ|ZKvyeR|CRgwXetAnc&VY=*R#RhYdd`;*;@RCSkoq9N$ zaYSo^$HuC&X0Y=9RHqDu#FU;&G81JFnT^S9RwYl{J9n;pE4h0Cl47H>UM4H2N>t1^ zLbS>R|ClRl5LGaOHGDK#2CF^yAX`Z_Ya$XcV~i_Mi~R*|r#;Q7SyqLc*Fx~1x&u!1 zL8I%M3(RO$HTyu#GlIlnCfrBRp3J6L&ayleCL-7w`0~@V7I_+thf#=L5_t8wioh(a zqsO9}T(k}|gDf$`9L~L8x-t76b#_lN1>)m{ZjnGi57k7c;boC!!}OM&3iWI(PSSvl ztw9dumOy5`;cJ{%|9ha=sgzO-#8L_ry_Ss>vYmfh`DD59?0M}?^p`QbEbWd?CJPss zgJv5(^3ual_X7{t=`MOq4jkMiqMuQ_dSBq-kLR|Y{92k*SG8pQr4re_b_snTzk9;Y zt-zDE2OtKAPi9K^2t-HM(S#r^i7rPeK)mT%ca32u*4Uzm`UAtS*TaFl&!-RD4wrC#e& ziyYv4L3`qL6I;h?sVqhNYEk-EL7(aT!9a==%-n>6nYtf@rF3FDrh-pBs^G0lf0RH{t0A>tda^|n16Mi$7LwR+V zXEKYE|IHy{V*a)D;6m1e=OuKl_5hIpNO2Zqn8r;??V0TbP#R#6KS|tk%^6q9#M;J9 zN_z{OHKaQw*0lY%g*Wxlv@9}p1GVI;!d+FIEwYVMwa9D(SL$dCo;UYUCZXxBj=gWb zWfxbT3#iMB!f>W&ex*O3g$x%J#&^9{o3C_V|E1_u+K;yyppu7^bTK#6YIRx@PLgFE zk|;`c@WlGiIia+EBs2G6ZaE`cmC7nP^J7}yNy*E%u(b)TYcF9OiiM~%%1x6!4QrO~yIoImR{QCtXH=VHzHa09$nR2w zwNiUV2*D=xc7FO?0w5Fj&n{nzd1nd@{^ku9K+E7sVH7nL6~1*fzP!6Ew2~UL-#eSo+1X` zMb+c2?IKFp#|&5f7htvQNo;&mprdM7`lc6t< zi`bMkOw)&6K_k)Sm(Oeuza7i0QwcF9ANu|&!nY>)i5~=|sNk83+_5L4 Date: Sat, 16 Apr 2011 08:16:47 +0000 Subject: [PATCH 303/541] Use 1.7-SNAPSHOT skin for project web site git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1093945 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/site.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/site.xml b/project/src/site/site.xml index c791391cdd9..5d998a7570e 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -22,7 +22,7 @@ org.apache.james maven-skin - 1.6-SNAPSHOT + 1.7-SNAPSHOT From 69fd8fedc520503aeab312343f0921e2564f5153 Mon Sep 17 00:00:00 2001 From: eric Date: Sat, 16 Apr 2011 08:17:31 +0000 Subject: [PATCH 304/541] We don't use galleria js for now git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1093947 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/resources/js/james/functions.js | 2 +- project/src/site/xdoc/index.xml | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/project/src/site/resources/js/james/functions.js b/project/src/site/resources/js/james/functions.js index de6b020c75f..32f01ec3320 100644 --- a/project/src/site/resources/js/james/functions.js +++ b/project/src/site/resources/js/james/functions.js @@ -1,4 +1,4 @@ $(function(){ - Galleria.loadTheme('./js/galleria/themes/classic/galleria.classic.js'); +// Galleria.loadTheme('./js/galleria/themes/classic/galleria.classic.js'); initIndexPage(); }); diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 93ef0d59884..c3fedc8408b 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -14,9 +14,10 @@ #james-logo-slideshow {height:200px; width:500px;} + + From fc397d767c0ee2b46171fe49b6af4aaa86ecb0be Mon Sep 17 00:00:00 2001 From: eric Date: Sat, 16 Apr 2011 08:32:02 +0000 Subject: [PATCH 305/541] Add fancybox utility for image zooms under MIT licence to Apache James maven web skin. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1093948 13f79535-47bb-0310-9956-ffa450edef68 --- .../src/main/resources/META-INF/maven/site.vm | 2 + .../src/main/resources/js/fancybox/blank.gif | Bin 0 -> 43 bytes .../resources/js/fancybox/fancy_close.png | Bin 0 -> 1517 bytes .../resources/js/fancybox/fancy_loading.png | Bin 0 -> 10195 bytes .../resources/js/fancybox/fancy_nav_left.png | Bin 0 -> 1446 bytes .../resources/js/fancybox/fancy_nav_right.png | Bin 0 -> 1454 bytes .../resources/js/fancybox/fancy_shadow_e.png | Bin 0 -> 107 bytes .../resources/js/fancybox/fancy_shadow_n.png | Bin 0 -> 106 bytes .../resources/js/fancybox/fancy_shadow_ne.png | Bin 0 -> 347 bytes .../resources/js/fancybox/fancy_shadow_nw.png | Bin 0 -> 324 bytes .../resources/js/fancybox/fancy_shadow_s.png | Bin 0 -> 111 bytes .../resources/js/fancybox/fancy_shadow_se.png | Bin 0 -> 352 bytes .../resources/js/fancybox/fancy_shadow_sw.png | Bin 0 -> 340 bytes .../resources/js/fancybox/fancy_shadow_w.png | Bin 0 -> 103 bytes .../js/fancybox/fancy_title_left.png | Bin 0 -> 503 bytes .../js/fancybox/fancy_title_main.png | Bin 0 -> 96 bytes .../js/fancybox/fancy_title_over.png | Bin 0 -> 70 bytes .../js/fancybox/fancy_title_right.png | Bin 0 -> 506 bytes .../main/resources/js/fancybox/fancybox-x.png | Bin 0 -> 203 bytes .../main/resources/js/fancybox/fancybox-y.png | Bin 0 -> 176 bytes .../main/resources/js/fancybox/fancybox.png | Bin 0 -> 15287 bytes .../js/fancybox/jquery.easing-1.3.pack.js | 72 + .../js/fancybox/jquery.fancybox-1.3.4.css | 359 +++++ .../js/fancybox/jquery.fancybox-1.3.4.js | 1156 +++++++++++++++++ .../js/fancybox/jquery.fancybox-1.3.4.pack.js | 46 + .../fancybox/jquery.mousewheel-3.0.4.pack.js | 14 + 26 files changed, 1649 insertions(+) create mode 100644 maven-skin/src/main/resources/js/fancybox/blank.gif create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_close.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_loading.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_nav_left.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_nav_right.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_shadow_e.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_shadow_n.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_shadow_ne.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_shadow_nw.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_shadow_s.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_shadow_se.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_shadow_sw.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_shadow_w.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_title_left.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_title_main.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_title_over.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancy_title_right.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancybox-x.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancybox-y.png create mode 100644 maven-skin/src/main/resources/js/fancybox/fancybox.png create mode 100644 maven-skin/src/main/resources/js/fancybox/jquery.easing-1.3.pack.js create mode 100644 maven-skin/src/main/resources/js/fancybox/jquery.fancybox-1.3.4.css create mode 100644 maven-skin/src/main/resources/js/fancybox/jquery.fancybox-1.3.4.js create mode 100644 maven-skin/src/main/resources/js/fancybox/jquery.fancybox-1.3.4.pack.js create mode 100644 maven-skin/src/main/resources/js/fancybox/jquery.mousewheel-3.0.4.pack.js diff --git a/maven-skin/src/main/resources/META-INF/maven/site.vm b/maven-skin/src/main/resources/META-INF/maven/site.vm index b1d5f9e441b..750a9c57ca6 100644 --- a/maven-skin/src/main/resources/META-INF/maven/site.vm +++ b/maven-skin/src/main/resources/META-INF/maven/site.vm @@ -485,9 +485,11 @@ @import url("$relativePath/css/site.css"); @import url("$relativePath/js/jquery/css/custom-theme/jquery-ui-1.8.5.custom.css"); @import url("$relativePath/js/jquery/css/print.css"); + @import url("$relativePath/js/fancybox/jquery.fancybox-1.3.4.css"); + #foreach( $author in $authors ) diff --git a/maven-skin/src/main/resources/js/fancybox/blank.gif b/maven-skin/src/main/resources/js/fancybox/blank.gif new file mode 100644 index 0000000000000000000000000000000000000000..35d42e808f0a8017b8d52a06be2f8fec0b466a66 GIT binary patch literal 43 scmZ?wbhEHbWMp7uXkcLY|NlP&1B2pE7Dgb&paUX6G7L;iE{qJ;0LZEa`2YX_ literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancy_close.png b/maven-skin/src/main/resources/js/fancybox/fancy_close.png new file mode 100644 index 0000000000000000000000000000000000000000..07035307ad435f8f2f8eedf0bce50f7ec8a858c2 GIT binary patch literal 1517 zcmV1To%f)hA(E>uTT$~N#GA0orBqo9-jKM;POccZrXJjTzge4|Sa0ca~7y<+{ z2m7~>41(Jqf9L`mBM6zAjf4;hkjP@@B~d6Xz385|dB5iCM=Ro&JZZmk-uHdZd2i=@ zK0a@Md;u9DFE7t8BO^nxckf<*yC?SckUFGmX^jwM@NV80+eiP zQ*s##s^a3}Ldwd@cHO*r^T5i=%Fj}=Cr_R@78e&C((#usU;YFS>C)2Dw4tG)YO=*P zWt;6ZfL46;=u!R1$jGM-hhvcpVyCa+S}Q!T2ALHx;BHe#M~BsHHos=s2iW})#C?}q ztqvud-gYjKsG$zHm2XhmYPB(Bn>kzw z=gS!w6cG`jJ$?H00VK+=!cMnBDn?IFkCkj7KmNq~hrkZvU@n=EP}|7Gxw*M}1_lPI zNx@_?IS^|%_ok<(o3gXBH^f+@(X7_g)K~%n0$gMM{{Ab=%gZ*hH99)_Eo>!VJd8_C zE)WMoNsBB#u&}W3BMEnPby>y64F-cra9>kX)4DJoA0KZ5fitNn`NTT4wY3%+fA;Lz zZ+K4ucJi+Mg!m%<>Ug8kSg^LX_JD-5va;NEM#+V_H)8UHgaj8UJ?LiZVx92t@KxlB zb1oz#Bo|{kAO!IDVfOII$VfwRad8C+y?XV^;VEu~g@tQka>%(zhlYl1p7P=0!-vj9 zYiMYw3l0uW##jWq+eZ-;6r@4F%{+PXGcz;xx78|Q_F7Eb+}ynGO@4TI*h!27r4#SzfR=K~ zhtpe&%-o-olT$}R&!0cHdm}}wbdd`2lO~)PlarHXnm>2$+(ng2^$EtJ+=vwl#Xg-* zSA%x<9|=lJ3CXuACMEY46&1O~{LGm%7HKm8lhZ|+Pv?nF1LcJswy+L%zshO4HzpR4skij zxq<8a{QPpl!oq4$R(*n7$-q`gsjcF2;NWZ?##l9wBW)lu_Bpk)RJgGO&Ey+2dDr3J z*x2~aJFl#)G^5U)q~qh`_b^ru6q9Xf%arlfse$W(T#z5f?cqE0>k)x`c6QcMUS4jN z#$B996B84z1O(|{7{3S{Bb#j7?T~OCi+pq$fP9eGqJ%Evk~i}B@#8tcAnk_QAg)9f z!qn81MJO5W0n6>}?Q|$y25QL`+uU$0x?KbSI<(UOBavf=wCW!^J3Ie)^yty-8!yk& z($YLG4fjwT{k&5mHL@*_7Xi1c4?x$HT^y5qc2zyPPCG3CUKl!f@Zj&~&!7K?fD>&z zDk^G(=74sN=`q$#Wm{gaK5myi7K~vRQ8s=CoB+NC8j<}iKpXzI(SMmt*2r@wST=`s zW7t-}X4hPqXy3W00000NkvXXu0mjftFGKG literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancy_loading.png b/maven-skin/src/main/resources/js/fancybox/fancy_loading.png new file mode 100644 index 0000000000000000000000000000000000000000..2503017960b3972499d3aa92f89953935ae40934 GIT binary patch literal 10195 zcmZvCRa6{Z)GRK+A-I#l3GNJT8Egn7KyZS)ySwY)GC**5cXtmOAh^3rfXjE+eY*eu zvb$HWe&}AO&aSFmCtO)c7UKiS2N)O_4A2)TmG>(H3=HfB3ex-CA}8B>rB4S*iGOoj zIbB0`GB%#)yQsNe_Z(XHJVzvTksi>+`6l(%$`7%p5{2L+{tq=VJ?V0JL-5DetdIHF|rZRGiB+~M$cAs!3L4m1WqS5m4Uut{B{sus$nl}9N zp#?4R@YNv8YM{JrwP-Li8Ynr~UO3E8cBsK321T79L4oqq#7><+nH-uo4c3S zzbjdhtN2LE+Wk$ypLztVwTlowGQqng!^I&U`;KFsDxwwAwF4PR(`@g%I}B1@?aN<; z9cJzX7khkNkJG|u_OY88t2=a(9k|tRF|O^~620}B74q3{|Mu}rUKMRU=5i@t4rH}t zWMo)9&m6ObjvNsA;yz~`O>f^l&kjH&j=Aexy0cfmC&I>@QU7`Ql zPU3_q?7Cqi%{r7|wPeZc`_s9mfR2B_K39;>*-yWV=qR41Ls>bqydL@}bse|D>1|L> zSvMFEQ2vnWJKlHRcZAw{ZIfc@+_x^0qqpf`uaLP9OH$Mxyno5YuLvbooxn?EWW9?3 z!YB&gf0xHo{M%6#qA!QwrjFO!Dm~{w(pCL9Z1XeAf)Nj@AQGyB2^*KX+-VJJjiv1` z<4I`VooCdOm?}gf8PD(k+m)s!AE5Z?+0=PkK{!n$OKo*{K2N95Y`L?t*m<`z<@&zR zp~CHRl4dh@$sJ4b-?gm;KP++XcWjfN6N#Qw_o;QATHBKP9&7y-bUDZkt@PRB%5E8d zyIxSjYTf;8+p-~Y-!k=O$;kfFCPu};=7d4N%l)KG@8xK)nb+&}I$Q6pWy;&;g|G86 zI-2s|2J)g^1XG`LO53Wj0gJDEZw-Oyi2)Wft0k{z<}G%H3dQ>?Y(D?CDZ2o#2V1hj zM_=W)_N5IX(aMyXUqh1U_WG#TC%LuB%3bK~)3%|v<)+ah|2DDoR!5Ri1|w~KpZ~C> zj*1KZd%Z~(gdF2RFMx01Wj`AW>Y$yS`Ndy3rPZS*pr6~#`6Q{ z%20=uSgaS;|E%9NE(<&vHm9^dubopg^XZ9&z5b1D ztpelNuc?SSpElb&~gE~4TESBIw z4hXi+ap2YNx8^D{Y~U3Q@Y|(~)|YhqOBukuK1!NNCMG7sGZ6A#)2w8O6Kn zdChi*Bi4O9!Q85-l}W!%4SCss_ceWT5CR9)!>d)k=W(}t8zRG>zPaIpd-bRcl+8}< zyZAFh+)b7i2(xFGQ1NiT*Ss*nf$|V%2{)tO&r?qsL@GB0#g&?RJHuU!w|`-+L=^sL zBkr*m4+?S5Lim?WVQJ4G?3fKVc}Q*JmJmX3?v`M44RD$Chi8S>0a5i2&wbyXSv8dY zyfv7Z{pAwk7MSBUu@ z5G6tLJnE1!1UjyO1R`?s4&aNgugC^{U9o!idxxDc93pcZ7raY)Xn7Pw`)<#e)4& zcN7v?6cRi?#`bl9ECtBz_QVZ0guMA?CDv=_ljYyH*ZV4aa_^g&fXJni?@vAE{G+P77pVW4Tj}s-(;*& z1STX!WHYF!Btlft>2`qz&1ijPaSdm%!UIMua~VRnoET&%1AAf)#vSfWj=q$8;qo|vcK_;z1j(+l2X0@o7C&Rzg8!2h$XZGbenx^q2; zApAgMeMi;{fO?<|f=I--(6#z(IL}cC|D24*dg^rhIE3G^yTJFZF55a-#}tYH=P$~* zb}RzkLIDvK`;ZA4OnYPQQ?;ssg`Ml>vON8NVnk@fl0k&o2W`-r3Bg-8NJYuCo0$rb zAKi(Z+>hRKA>bjOr%LHS@;94B&obY#4yCecQ0pdAnSV&v!vLF&-`Mm?t?}6F z?PaX5mkzFp$i(YKsOTz58Zgc7q)IVxy5hYd;~k@a63_Ja7Z0!ycbH~U&Y;r17f{Z} zwhnd>Xve$Riey{w@OgRi9rKhkQO@>jj2#Py8_PSVvvwxp0HTR7DdE{>K_i9RL= zrPNU6SCAR*HU3BLhMV(aTn;NBJQziUp9-R3QkgnENmN9ZBlJCW?l9$81skWTmD&YK zJ%7bQFP*wlswyu56egGmr!KVx=+KneK+U;f>vSk#hKg0u(yv^fNk=GGdULDg_=itK zp3;*2U!wB8TA$o;k!;o@OA2zx*%c|y0#?BBp?nDDw5rBS_SB_Sbz$6-fYTvnj(ezNfL{$?uz9aa=HGSg$mLTxTf{7e`Oqr?7rp+0`lg6AQpk z9Nsxh5kt+I%$5|50=OZUzms%|OAS{5^$g0~djWjOVxYk^CLD{|njlM2ex}zn9yCa1 zXCSTHoM#Rjq25u6;*Ug2A+S~Y`_kh|<3C=w_~F{9JKTLW^z5D41V2cjL8y+L*0IQ_ z?L+y%E(_`Xj&MzngB*bEt_~znvHKiL&w-ytZ<@L~s{_sdoRaSXOA5{31d;sz#pvvv zgq9-MCupHYRhjX{g`7wlu9(YJkAO)+oP%bGYC{Q>2v4!wD(_QEQe5suxdx(SIXS!9 zV|=hm;s|y$aq8^~zssyzb{|fvQc!Cj#FNH1$?tLP+^0!rIS_gU*h1d?y;X7vm>l>a zwr^N0VzNQ_j$}0!F~;(iG9UmS=QO|XM%w%nK5uQHaLT2-I$_CRCbGr8ymE9J_k{YTcfRFh1nn)R6_X#W#Fg4I=2W=GD|J_UwPwIQsBklSR4`o0$A&X8xn-V`k#d|7nEr9kiD4Dx?q zJBBg6NsFLaJWHtZ+GQr~rb(+STSHpb`9UQ4BbXjmTjDz;@V0H}7=mOf+#fvH-crjF z@uztsU}U)L0`Q{D-mZfkuH|zPNNIKXy+C+QIrQ&23l%VJtwn!M0wNG>wEi_? z``=Fg-bBV*o!jNs*j0n^Sn^x-5T@n{us@koqBnB}HI+tGJ!*iBb=5xNu?gt0oYXmW z8+W9Aca$K535BsvBR3qs~{jn>MoPaD#Aa+9Thdjr^?c!Rm zd+L48(+PM55nZ#`>laDoAVlLUXKyJl;Rm?x@Vv6HMm5<-R6-Z-qq1C{(`EqabpBzG zj;4V!x`7^=;;cYNpRy+iPV>rQAJl)AhcD--7r9MjgEiiV#SR|%E*YZcCryW8uK0m8 zL*X&^7In#HoVp*5gKHN+#O5c>>55A?ba%a_dj$xtqeA|)Js2dMKsh{lLDK@0m9lYa zWh*#0TQ2T27j^N`(t+eEfPUoBbvH_Kxa-u1jcNIe2YA^XT=1{3*Wd)}tKRN&dun&* znJX0Gvn8K!-%j#7%+r_|9qIlzn!o^G{q2MJxsdbiTZx3rG2xVS7HXrp5s;0PD>=hY zBl<_TAVt^N>MxbO(@<=MbHrHR=MZIY*8L>tB_Jja#yQoQZ2U!66gIECXOtndOORap zIR~TG$;oHLIJfQd#!j_3_Qvmx`fn3O*zC1bYC_$3%GfsjXN1z3asw+xTs!lK0I3p~ z7+&tcZUsM&QuO)Rahedf=&&)d1_C6zma`x{C50fHF?zDa=ZblEB;H@x_ z*db{M-tS}6{hx>Au=h4<8bWA8WETt$$|~;BYStwE1pYq48aKuv)4zT2-le|_1FnV@ z&z3AIiy5J{V@~m(2Aps_b7@uMmeTM}Zrs1Cl&)1e*ht|I zj+H9o<}yH3ZLHkB*F?)hWh$+em0HTThaoLx6FA4~msa-#wQzbyJ7ZmQjr#_R2ho^; z^_`?dw}hUR_w8a@8*K8J-lhK2Ot+y`>+{`n0h_lu{26PzN8ov0&f4B@R&y6%I6s2# zaHh%b232N&`aa6F5}eHI$b&SYPEgsOw5r$FS9yGwbRGzrIvbyEgZ9&nFxs0*_O>EKspQWU0tWeX06p%_D|(!O+TmLQ=`cGc+aR*yqXicgOVfS-31*Vth9=M<`>TD z2ecu1@-;8F3cm{pGegNysh5>XjRo{+T&Ak)F?qQ`lGeFVEKm{O*Fh^hd&!`$*H zo5Oc&)hGQS+5HxkD6FQ8nebel#;ty}aAw`K(xh8I_#=)-z$e>p3&-I@Xi7DsewFYp z$O_YrvYr1N$2_XK@wwpD36YvYlkAWY{ImJ=ap?zi$l%xZ*=IqNes{oGZ_d&RUp#M>B0_e>rGRlDA!;QcB^(S{BAOFH9!5r^ucGvwr7zaBu z0nl8=Q**gw{nD9@q{NiDSWk(V7^!=lJ2pWMJjM<6vo&=apq;2<=R}w*8Y1=kz=PCQ z%)%vAD1wFG6WryVg@``Sirh@k%N803_$(=+!8Mvb9?1T!G85NtuNdZnEQyu#A?w`B z)F3b>f5ji+x}KM|Tj2^Y*G*7{b`Tfi5Vo1I10v&)jAXu~zp&^l9_6zJNyTM-8Umo1 z9&95H=Jn67@b=o@EulLxhu9I5NUWA}RT~7aM&6p*w#;#@t_WkoM=N611DP@^AO(5% z_O)wI8+=$Zu|&6GLOI$LM?5!R9z_jmV}oTTbo5w#im;QnduH`c$N zW{BAB52R%1;Rn5cODK_%Sd9)aoctB9zxfjVQ>(H0D(}uy@LHYyAgK3g(>S9( zPtYyFU)v324BQ;?fy(SYzzu)I?S5X)C%oy!_vo35qBl@iLxXeO0=c!$`taf&-nWfH z&;kAR#ny=d^p!J#(|f-;_JYU39P352-lqenf}$VP>n~VNP4fO z7WIbrhM-BLcG@K6C#AME+0)ar)&j3)4d;NqqtG&xvMIB$;{YjyD%@TxXDz(Gn^~Q$ z`{|#$49R1=uT?+cj-swXngY48cUNapbLV7E{z3w$^>d9@EA@w>HM^RNCa!C{AQXMm zpS_ccdl>Gl@TvUqk0?XIXoR{14Qy=kig!<*wYyEI!{IFM!!y{06q1<;ELY*y*mjQT zv-b*OcY}^&CpfUnzo^;VokcN($`aoxgOa2-iM%AbK5g=>;P?fEw9oVMKLygeXnM7D zPtexNCH+(J;~KzQ96%ZTw*j@q*9|u=z0Y-$-X6>%8rAx{yN1?B`D^BfVA-Q>P-Zwe z;|%7ZvMvfrLx6PA)1366l#K`VLUj=^JQGKQr;$;%1P{A3+amuyFpQjUjaj|r5k8@8&dKiV2D0a28K5jva= zscr^-stsDrbQN`~3V1XeM345Wu`L|$V2`1Pl`51 z!sHL}P{WSZ@>@dt0qCwF@)>_sDDUL@v?vgBJUvVtqIV{pdh9z%PiKh$SX?-VD2}@Z6HA6- zt@V4EnoebJo&k^RU@I_2;opR+}*c)nrCI`yn@ErJWz96(SbIVk1>cE!Tka7+3`tF#7q&mOS z`(vja3j^a6Q^nJG3SpdQm0wa<72`6^6xx!7k=(pVAT$qCygHU&2G^*HUT}^RwjJNp zVjsZ-`}x>d3-MAWGZ5r%sw4F*$o{=syLAd8Mu?DV4DF|;2*Jox zqVL%1j1#^%=iX>tz6Qjk3TO);M&rXtl%qgk9grE3>4MXk7Whlg72rmd9g!l$_+3&E z6*h-nCMPb4^T8$kZueK9(P+4T=;!doMXH%k2WDZ$>{4(7lz{?r+!{D2KSt$CV(H_H z09z`;*W-{JA{4V`;ct6^**HAhq-p$yC!Fv{xUAPqWOUMqgwdVO=ShY%=Zt@BDuAe`?$w6~HWQL{`llqWf6s}0s*z#HS;O3a z=ILyMmZ&A@kv(0D+vYjR5o^0XD5avMI0e%)%4(QMuouS5z3U;m`;cPc?0(9-y@U!e z8`cw(kspE<f=vKG@{6#xOuWYLU46A_{#wSGt9nrgw})%Z22yb0fhbwJaqq)%z$PaC_= z3ox7-F_lzT^9!i(CE6 zW<2&Wf2a{(QsxusH!M~2vW)|^uKs)OZ zmI^}fUwIueqDYM}Hp_|Vp>A79nJ8^LR5d1S;Q>w#hmAWb#T`r4AJ~Xv;6gnE-j*Qk zwNw7#)xPg>g$s)62xcF_l*sdm^_NrVX|dvZ&p>qY=srP47z1ewBWITjEe65;a(0E< zsKF5<#?0SAwMHrOG^N5~-08VWNK!`W|E7Jofg`@;V9vxN`V(KMQ7OQ50~f_DqPJi8 z6s(d7BHK|74FG*y=+P~=U{op#TT^k#OBsmpmz7R(n`tLDrm9z&lDKlR$rc{n&Wy_f}H^^xUb{sfU=4ICbJ`(9&;3Z3fCy0rvgB9M zYXJOzI!BVShvjpSRe=NmGVk>cdV`Q015u&=ITQ3#Gp7D;WU9-#Ty@{_tVkMAQNqTD z89X_&nz0hLSxzu+{iZ?fqt!=1tl;^;blU*(sJlZHnmNqp<|A?O8Yqeq>aY}@n1 zBd&ihKHMSw8p9mpUE#S1BM;d0J46}4d<00ZkaWga7oyiz?n2O$_km?HNrL+#l7`D1 zDt>O(bK^#^beJ$Dp;k3Q)+J?E0B-A4flwH2y@}{?;{_nm@P%QMps2J z#`ilc^%ORDrR0HkSAcEzL6MbEuv|s7a0Ar)gMbJT(!}yXkC_|qfJI;E22Fs6`>U2+ zV1&^n-1Dqhq~VvMo!jd|vkg^x@GPMw8SrLWQvGe4@@)xUShf-uDZ8HkE!_>b4{dqT z8096-(q!Ru;Ij<5@|jEX&B4JzS5AqWVG4h+OLc;we*kqEFMhlePe?Xo(mzk0QTAQb zpD2r0t+lznomct39G}wZEMuz0)=dgp3T>?BPsHbx^CB%dqpOboI~ogTn`N9K1hy>{ zDBae4+0e=;4Ed>107Xpg6!O@x>V~|>YdDrp^;g9CF{RNew0I&FVx}{X5%+2=zXe{D z)DMs9SjWl*_A?z_0KcjSCKJ!NP8N(+BX78sW+x%34{ePG(M^UYj%THt zxZ8TL#-|J$Ui@6z9;Yh}Z!tM%V>jJuIJ-?8kmCLBd^|wCgTzGsD_kLyfTJg|Cs%`+8tvvjHT@<@+c88YVruAnGHq;4A%KT z`@dcO=c%}~pTNFPbF|rymrfuW8#gW8GRQQEe8)QF8oAyYmLo%Jv;Y=7EHouB zJQ=5|h)@1}F#B{wX3e#`0jf@ocdnZ;E$5xtwD??6V3z;dPTQBe^HZq-b%{6VCF=FR zL>xf=$+cR=ko_y>!X9j&oZEAcOX#tMNcb;(xuU}kDM|P5mmN<5;map=HhG=w$|}(w z4F*XeZGLzBif3-phMaoKI`4adR)>&}aCKzXy<-RDAU(u_f-$(-Omb^%F>+tQyUWY- z98G`O5ncSRfQ;n3q=LbzbJNk}=XZs1__J63e;DEaOA!A=p#VP2rE}oOH-BMvLgYtc zoAcvckXV;~6fXD|`?DPrCnsupBsl^pc!s>84G60AQrQAUv~pvfJVGH*F3yd1!r-1e zi9&~F;796Dg(Wi1n4+u~#KD>ECTCUiM{t=D!kwPLM7V~k{HGdYq%u(>bX=z9#R zge?YcYjBNZvw0!CXZ)E}yiN$;?-`_vV=weI@%t6E>KQw$qZo?yP7%!-7D}&J;Rd^y z2L}gPL)GDF%_S8P%|t6;LU)8(vhxC{bue%1KQGKL{}`1SxM@5h3BqQW$1UJ=iHVKX z!>q&nVn}oCqRUI42H5o?zjm^4 zhTv#NSZ?tF^7J6}Ds4Id@g55ZMz$AERk7!_lo<;SCuZW33@e=0gl8*tD>!a0k^q_ViXjTmlOQizar{@TPjZ$e(u*)b zl&+l8$FXO3_IyDUh_4-QR3im{;hkU zv{vzd6YBp_9?y3`R?m*xel6XQdQ-D~W%obNJ?_u(^o)Wn2nbCAm5RjF3^UlDjNKOR z{-zm);7^zU^uJ~aeK0&5K7A zk!1|bDtR`F7u}LdQL>XuAiOL)$^!>_q!Rx_qE{et)MEwb@S{@W`+Z4Aw2az8N7*;j z28~WHm*L2qk_1^vZ{qCssnc0&vsCg(7oWohyP@9E!SL}lGkp5Mol&OL@SQWG!*9BR z0qAh(zMth9KCDMQT!@!?YhIMqNDF_IM(>}Gi}a7@vu~0@GO=V5?Pk#Sqt{UE%}PuM{~;(=J78A zSrs-=fTfW`08-7aQ5oi{Ll4And$a}6a7%A+l1f{j62K2!xMxo-1)`o$Id8iOER0N* zxIDeb$xtGU)+USD=qHDg(Y`X~J68tf`TqIO_Tn$%1NaeiYTKadL_2eajT1&)NB+^q2@D9b{MUY_>TNQpZi%SO_bqXjyXHB;Ui$Sf9@s+j;Wb z{id0A9C(t~>E@^vPF(@ScmscJxOc7zNXd^Oh>_aW(3u(xR)buk9$q9y|pmKaV!1QFxCztuHO}!PY}!G@y49mJ z0cZk6!rr+O$%3(;B?-}K84!e8{>9v~L;P_$0eQ4}M1oXBfsT{~ZTR)Ko%2eWMnbKn zb5q1ekkgw_RUy#!uXEEL9eB2&?El4NCZmw3r1hMX#a}lk-dBMCPR4OgqRj$-M;-^< hjOQhwL*8E5RB0mfPrR|R-jC_QfTWeADkby-{tw&r+hqU% literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancy_nav_left.png b/maven-skin/src/main/resources/js/fancybox/fancy_nav_left.png new file mode 100644 index 0000000000000000000000000000000000000000..ebaa6a4fd34e51575a01da366312c20618985cbc GIT binary patch literal 1446 zcmV;X1zGxuP)R`@usIzf?P{x4#0gFqr~|(;IJySuwjr=+Ar78e&sHZ(Lu;P)*wKU%|U#jmpg5~Q6= zNl8{#mZGz>Q!_F$qJ8n=#Z9x>Jn_n|ZEtTsSzllOW_Wn`!@Rt_=!l4jAl`tKb-5%L zv7js_CMF<1KR>Fcr{|nbr~AR4Y-MG|y0EZdwI6@^^5yrikSZ}TQ5hH*C?{R4Q{?KT zKD6U2SFWfB2M0g0TCEGD5GUP%Y0a>J0W!M1fVuVU?d@ix(YV91PjUK7@OzY8E)OJ~ z&Q30n%8njA8kC)#t?uvd&xMXHQZzI)WQmTB-n1vQM_gQ-{_*3-7UA?*_bJ9=m|W(F zT+IHE$H&L3T3T8zSS*%BTHM>)YZi;eI#;9uNVch|X-go#ckf=VQmKq2-ORBYaGo52 zejyg&!SS;_ltMX3~N9_#ORsfn&tMTp}T$j*yAd)6-A(_4O6g z0=-^ug|9bVkxorbSsNQ0x9sPG&EF`laq6qgf=!d ztnQGKnVtDqz_Vx1Y=Kr=TU+Vx?;nS;5H`1m#Lv%9fqI)#T3Y%!3C+yRSpE-E!h;77 zwm7Z1{&Y;%TkkIqz&m9sAKBbnCkzsHry#@vbY{a-wI?zu7 zloV4Q9NtQWLUAT7Ev=G-*4EZ6|HZd^F*!MDB>C#<>PDGN_5sGi_Yq4ZlG7@css!ck z9};wyN`LrygSGPaaLVfqXl2Z+Nkm;ygvo12>(Bf+YwDwC`Hbwy5foiCI>(Z2*F z+nZVe;)K}P*aF#9Y8tUS3{lK|w(!NULrkdP#x17leSb zXU`h&IIwaw4`8eqNV6{>BDOh|vjhZ0E{e&QDDu0Pe|>%Zmb;{dg@s0w$z&rPA0K~+ zu^J$UblaCq5g(ljxEe?Y`8AmFYt-vOfqZ&;+Eh?bV07kp3Z#jN34Zfk3!OW_7k zM!Hz%fopN!Lja&lI}y+lIZjBszTeT&@!Ra|?DQ)q4Us*EN5ey8M=zh0NVTlX;X`2G z(+8kuN)-Dfn@v@Ns?$arfE9ks%*_0?uCDGc0&cYN@bK_KngiO{r&oDx0_$@6^x5~= zW5Gx^5k=$2z;)mYpdQiR47B2ZEBzOVMD;v(on_N_Z6xdRarMj=Ped`)=n zv4Dh?$k=SYcJSdjDa(58`F?t%ZzxBbaRs;9zaA#)un(S!5dZ)H07*qoM6N<$g4RXF AD*ylh literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancy_nav_right.png b/maven-skin/src/main/resources/js/fancybox/fancy_nav_right.png new file mode 100644 index 0000000000000000000000000000000000000000..873294e969db9160f5ddd4e1ab498ff60b080e3f GIT binary patch literal 1454 zcmV;f1yTBmP)Wa6`&Z+!IVkxf`V#(j>y7#5eg z5*PD+C=wGBwT+F9xi*_^fd=>X_FBba@wz8b0c3ma+OG#c&LYnSBp_4S(*6BG8m#QpsI))yBSw}|WBy?ft)>pk?VIMu|0u-xC@UxO$< zHa9o-0~vR8bXeVyB61x;@W6T@vgyO$TgWvPslhu zJ>BGvFeN3$D2UT9wO!c-2M2E;RvddB6cm(&J}nRg`1!DUaA;_#J})n?kc`&W*6f~w z$XoI8@o`6>)z;Ql1O^7iqc4Qr?IQ^Y2vDQmrd_^#`AagIo}RXO6Tw=o)=2K&OZ?8A zJDVKcH{^2p2j~ms)bf#Ff5Y^8{ZZ7~8Zw%koV0nHJ||9`FbS!%u(0sL`TfAafI}Du zN;}#qfQDkqhr?T=R;!O@W@c89(aOq-SHe5pO)Do4INRL6f8R{+tE;Q)Wir`E=nLN^ zERjf#VBjT`yZ^}0T`IW~brs!I17PDwDHNtJpz(@u7&_Ci&*x`nXGh4eva-_hHlhTo z>wKX6jrLg})!Ef*2q(qH#unh5y~V~`*!#E25W2>+0$@y%jAkE;d^% z7KiBQ=;#CV)c|?K?OZZNymTtyIv@+;=i$b0QLhID@u{gPOF=<_+1^cd)FbceJt|Pr3Z2#UW)pC9hbbpr%#_w3xu>9DucKZSqKjwKC}oa!!=;B zxw)ARh3h~maWUsB$KtMw06>R!GGHKatdM5?eS3TRA2TyEQ!m{-s9LkQG(13d^zuqc z)WBRWF9N%+J^)=)qIgeo*i|*CI?Xfzc;V-hCr|!<<;s9veooizpgD1ug<#0dV!Z literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancy_shadow_e.png b/maven-skin/src/main/resources/js/fancybox/fancy_shadow_e.png new file mode 100644 index 0000000000000000000000000000000000000000..2eda0893649371f8d92b92976d8542cdd1b601ed GIT binary patch literal 107 zcmeAS@N?(olHy`uVBq!ia0vp^B0$W@!3HGnP3ltxQbwLGjv*Y^lSRZuwe#}JO|p{EaWGAM`~zK|Yh zF7SQ+m+Ig>B0@o-N8?trihfzZ+Vp1~`{zf0o*#X0$hUAi%N$P)W1wCJ22WQ%mvv4F FO#q)zAp-ya literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancy_shadow_ne.png b/maven-skin/src/main/resources/js/fancybox/fancy_shadow_ne.png new file mode 100644 index 0000000000000000000000000000000000000000..79f6980a3ba5c43de120d963dbba2516b8f27ac7 GIT binary patch literal 347 zcmV-h0i^zkP)dR9Yb&V8f!h)aDezHAsc|y@|hdQ zYJb}?8~~zFbQ)ku!Ey)KSukutuvdZ@MKMX|x|A3tPyx?YVhN^6z!Mi4Mj2f#%<;nh z2{>?YAzu|{u^;Oq!;f7Z4tPBpJEmZ+^GZ#$=9nz(K+UmK7}|u&EPi%aRt_C3qOFB_ zHc`~N>51%{?ijG?xsHt>MwRChgk=x_z0gh3O2xSL)-6?+2LKZL74~Q>MZjWtwukkA tvjRC=&j+0R$&bLyT7MhBcTXDISHC&xXU0&5CWHV0002ovPDHLkV1fX+la~Mh literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancy_shadow_nw.png b/maven-skin/src/main/resources/js/fancybox/fancy_shadow_nw.png new file mode 100644 index 0000000000000000000000000000000000000000..7182cd938ae98e7e28c65a0bc55df576042ff9f5 GIT binary patch literal 324 zcmV-K0lWT*P)2-&4CO{qhKP$XKD&mgeXEM77>~`RA}h@U^Z##eQZVtM>a-K?QT4 z&(8BFf(rD5V61)2I__wHYuRwoaDIqw5Vdr_JSDVr){#J@r;{vbDL|tRyCiirf~4OF zX-l=Ecm>@yR)1nSMt~dy90Zb`^`)TQbhf8jR@fA!l6V$musRyB9Y{p$SCW}!$3==V zk)fW)Xo{s^ez$t+XhmZj;ts)!kTokvmM>z)zt70000 literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancy_shadow_se.png b/maven-skin/src/main/resources/js/fancybox/fancy_shadow_se.png new file mode 100644 index 0000000000000000000000000000000000000000..541e3ffd3e88224b34a4d2097c66a780e6060aeb GIT binary patch literal 352 zcmV-m0iXVfP){pM9=`y8<_IvWD02WY@RZ<9dgjNmAB|sYF}Xw>7Sq@O0000eMf9z;FC21=)67q_`W0*0KnS4AR00W2`RGn3i8UfsEegLO@ zPhds?2e1Tm)FK3=bymIAx?X=YFo3Mdh7W?@I#8s#svp!&PB> zwah@Ngd|l0N4SCfzvjtQnd$dZ0yM)N$X+lqdtN!Pt{Wn*_`0U}m1^#r1 mwpaW{;a?9KKt^WrpTAEd?0j1W(3L*`0000P{ho=rRL|66mGO)=r*Hk83F#~lnc)I$ztaD0e0sy?& B8X5oq literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancy_title_left.png b/maven-skin/src/main/resources/js/fancybox/fancy_title_left.png new file mode 100644 index 0000000000000000000000000000000000000000..6049223d1ec6af46e100499c01f6489c9e2c6240 GIT binary patch literal 503 zcmV+)0005LNklqcp9&~$uJw{{rUub~E?-XJ#Upm4Fe%-Gl z!u%tb0N102a|s5;SPlQvJlFCTBbvYaK@wIW6Gjx@?i20AlVDJcHNfh25WRlbF6CIq zv9_ZnqOH`}ppaUR0@%ZcM9zpDt2uQM>f+Z#wIMmyuui3DeoYXWE|hQ{D$te=Yhgkq zIvyj+$t8T|S1wITzUftNOe(E+Qjn$kDotY;I5}1lRgwi=?K26ke)djLR5W2|!7CVH zJ-`tuAq|`lK978y+CnqGNCkUke_%Gig ukvFM-ftpWh!il7Wg7kz7Y?7xB@G*olNlgoj4E_Yv!rmdKI;Vst0Ha3^zyJUM literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancy_title_right.png b/maven-skin/src/main/resources/js/fancybox/fancy_title_right.png new file mode 100644 index 0000000000000000000000000000000000000000..e36d9db2a7c6e570aec993d3665cbc13620115e2 GIT binary patch literal 506 zcmV+)0005ONklxjQB-g>5=x46nGBwseihc$zfzvTFh(=tCRj6cJ4M&ASrCAq-HbokPnRBAHVa2(-|l wYU(UxfYLN;KDSr z1<%~X^wgl##FWaylc_d9MY*0Xjv*Ddw)7kFH5l+P-xcE$W)3=fYI&uMKVzWNT*W|n zhqlRY)q0r(8Mg&Fu_zpISivgz+b7g)c6G&O{~njE??Y{u-MM!p^=9_W+X-j8mhfK? zj`H2Yy;kp%)!V-M3;EVThyB(Z@o88wpMja-vy^g)SgE!<&|(HpS3j3^P6|6H_V+Po~-c6$N>^IEGZ*^681?Yf#{6Zf~e!I`r4y-J+3m*Ue*gH=cNZ zzpU%p61aCO%jt%FHUKW&bEWLcUAGzK?;SYE)E{9#W9O8@uj{O@89qzNU(dkI YVCW(7-@(*!CeU;SPgg&ebxsLQ07`N|KL7v# literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/fancybox.png b/maven-skin/src/main/resources/js/fancybox/fancybox.png new file mode 100644 index 0000000000000000000000000000000000000000..65e14f68fd83b87f75c22c0c074e7b20bf20a133 GIT binary patch literal 15287 zcmaKTWn3G5&@B{~;%>#=DG;={yF10TIJA^Ni@Q6dxD|J62@u>uaf*A8(n3=TLErSb z_x;^(_f!7a-E4NVIcLtyoQc=dQGJd}gNuTK@?2d_$pHDPf`Wp&gN=z?QPI&3p`b{G zsVm7Fy<0o~g!9hI>FTLkeXUCSdR`&CQ|`OGxubq*0?(JYNfXC5{*R2zWF6(Xx-T>T2>J&K|Eil&n6Lix zEi`275C{!+X!)7CS*e}=H>=RA%jh4XH)T6XDeap>QZ zuCvB3f1j3`!i;@?^<5L}xzP0QOB^9?Eo@W0)j~`y+S=c{by#*Uoo$DiKILjfWNDo7 zGyqd&{!#&d_P|oW`zcaEy@;d2w|y57JdXR@m44ad$Gcyz{_I2&GK4@SU`c&Hd(VQh zn#vD^;#Q75G(~U%V%iDZL@L=Tw9hMZzCDFM9j?16?PmU()egI=v!xGRv3`4gH%jYG z*XB5pVfpH2C-V9c_8xe%8@rGrVEZ`G|9I83-+!6xowV&cMz2~U_i)uGJ@S3*cKE#^ znI+w0?#cY$pob>5_bg~ZYi`wc9G?Q_yI;!^xaByQ6*CF-F7!LoI6}!W%HOm zn)78kmGgzB<<3%Ss~TX_waZ9m05q-1AFMtfR>_#;a^F#k^#p)TMJWuMY$%F z%=%jUAKs6$O@3rjj7b9g9%p$QdV5l>n-#J#o(%rG=J6u=#jCJnOQN^y{2O0)x&Yqprl%*#!!_|zCVEW-yaI3-X52yuJ!c9 zz6iUCoS&ax%2yIfhCSZHUTwP$BhI})gzWuY_kNXgz1*K3Fz$UQmp8oH;@~mz(&g{T z0*5JN@$_j~RW(h1-Lq}xFRb{(q)D{SX3WtO`gObC;WQ9!DO#{`WS)_(*3(jJ3Lmxc)?Yc*Af>4 zXe$gst9FHmyt#7KrhMt(-!b86SnN$#XDi-;E-tXxuPcS#V1!6;)8@e~HvOb#ByQ&M zcK?UuX`Ca?v*Y!yriExsd@4QoJ$zOm`&Ikyszd50kEry*&*@-WOMQL)1w}jVgR0J4 z{o{+}~L{4c-2cW8G<*T_5Qs0y+A@Nh*tb7dX$-KpW;Hf3Q%V!a9Rc-`M0ex{kr z|Il@RukPls=sp>NOZq~@c{)Hzjg^FF1czDSutYx6{UFoI%G9*$Xv+5SH(imbfq_9E z94fW)v+sKAibW+UZyC+*=Fjjeg3ZG`hZG6-&ECL;o_yU8w+oxRXfU4syJ9}5*O&7g zvgp|981c0xY6-ssnoDEoubAhwe~C1Ph{=UKRM=Dc2hC?qWyga7}FOlQ163X0-*oqNwC4Yek|~X5e^P*VcQF zkUhPwZc!iLY%3QJ2{Ho@I z%dr=>z!}k%0N@^JagB=^_|LrNx>w)TvQA5t8{oB96C=sH!(KuDB6Dd zQ~jz>|K~1IPiLg9-A#L4s^n>nME}i*z)>Q=T2~fvkfEN*E;={T9sKDFYe0s$@o-*( zoEh}zmtQ}znV$kaO$S!N?@O$4?1l{p$z5d4tKilfaUnH1{9i^XqJR3|Uyi+nOHf+* z3}Rk8>MrX*)A&fo;0NC5B%=VEvC=)mu&29i0Z0O`ytHlX;cF(qYo*pLff_-FgJM~; z`)Tu;nHg_i7E0>?{jNgCtlz)6Iu&!AhGYMFn3H~ zJ`xR}4KY&CDsFSI%$sALezXs*9+#c^b>%GE&f)276Jgv<&zGpyo3TDQ%pvJt+&`&! z{Shd!jqXoDjbjmZGxVY}3?{YhMhsiwHT=CS0NllEL&%itR?%i52HSB+*%#wyeQC#y zyVd6XT%3pt6!g3rD_gah3DtT()o>Rv4_d#VyNVK(HhUM8cE8n3B|E| zh}3;3MgAV}^Qx*Ui6_lVS8s3c9PNhg`}5c(1ENE!P=VRx+IEQGL91)lZX=qnPZ9q1 zw5yZO!no+NVgMz&qw6SP=(&e&;Z$>q9{zXi2*K8@yh{H9B^0|1%fk897`kfNUA1#u z!{IV-MMi{e(bIe`_|JA-W3M}=w#mV-ajYBW{>-4l+bof*j=QrEjP12y!e;c>Z&;;V zM^8p8Eobfr3B$fYlBk55<1%$+d-RJ$p7W&h#Y+@F{BUtO>E#R`VBQJ{x&;Dkx&$}H zhOSgb-6>zcMD(`*QoD<9_c&DiV!qaNaA$kj=NWEQ*MFBH`?d@mR1eODIlr^8TQ&6! z?Zu%cuPP3^JxSi%Ej-q-8cKc578ijX@M73*YmY660uq2%TywHd$$rc+JHxc=>e{aVhBM(C=M%@zXsoNWf$<@*&Si zfBaE0iEyQmu4#8O^y-Lkv9sT1-MYB#6SxX;Zup)VKSW5h^`mE2w@xP1CKEEQVqieE z-|qCmnZTox4%cD$#KBz8wr>J;jgQ;vP03?pziiiZf^9Ya9A+z3FRHlvj1|4zu(0z) zk!NHd77L4tsP$B}E)KJnWQ(xqc50Cd4qeLyo7NSYC(nUG-q(2o8G`N>r}!nR>VooB zgQ~`?w`)w4s9nI9q&{b&YrC(Q$Ybmtlea49Z8$%cgf)F5FpZ`{>nRg=iw*s=fI|x~ zs(Z3*nj?^gW{3$m)_kYV>2TDRihE(6$#=dJLrPn*^e2K-^tNl$r_6h8P?Ida`U7x3 zS=_602o@XE{9@RMKYg?j(ay&?`SPJK7pZm`;)Ul4eqxd^hX@u12smf1_zTYw*g(E^ zM>kZdJXPfif?ct?IE8t==XZliUxmmBke(C$Z9FIp@<~(>*En>z|3+X31BNaT$SY4M zNkx5vUujEG6+;x6sn725w@+MSoBhFHH>`f}h`>2f5Ojs|e21azA#TBNt+Y$R*0x%yhV(lOeN^%?TxVUzBBxe;St&eUh^Ev#1hE2>Fug5G zX0^DLvfguwUx&H2HtZ~8ygSPI>L&0uAoGh!j%9nnc2Cq}!FhthK>F_tp1{3$4vMKg z&#>U&p2+u9cG&k*{#!$}l9H0kukL=dX8|r7HIXq9h#IinounmdhBFKZqZ(xogX!ubN$md{4_8j{mQ2-|aUw4ZOE9DntRlBlZA$gv;G`P+hM&gLaJ zWH?F#8W%iq1I_poC(54AEv(1nYfRsk*%bleNu;9*L>Ou`FBBpuWk)I=cHcRX%htu> zoP@h!b-onASogDD5C4iX*0tkphDUA3I5@(^@qjz)0#*F^F*g#b`UY#EgjQIY+24A7 z@C0-HO_z0psDI#nETB7|@i%u8+$!cBZ%r)7`}NwOcb-^o2fg$I+KL&PkO&kFw(ilc z$Pd`|O7c#T*p_Qo)bpL6`-gnArJ&|QEv*&j1huMidI%JOS$n?YrAN37{#C`;uDB{; zyWOtHZi9)3tMHEtWzN2Rxhf*2*O&)7-)tCvtW;~KmwmZ%hb;U8DrV3KV zdtfrOdSFhq9-+a9j6eFPV+yUfr|TerITV2O=`OJg#4kzEg62zxF!xS_aG-5XOH~Ph zBsQi&)mfq6xujyijEGi$)3@y_|G@Ghobn{i3^-dSYmG9`2pZe1n%zFSvE`uUrBIaV zzXbKIyw@biKIOz>_^ar2;dpqe(DIya=(rwN`IoT-avuKeZr^=d$8Df(#4 zQx6RhoGc+FO>z+;V|&$8)7p>mH8pBo%xZ)Y?4=7jd&_3?KfbrE*aRPD!;PXec-5VY ztVuS6m%vD` zoFWnCLFAr|)tHdxa5LU%cnR&ZiDzEf^=`|CrdD4p#UQI?7Za&z^nDH^+;r^D3su@r znNEYJ)kW{!!(ADt52^N9LeqKWImiG2VNz=zL0mAJRx* z8p&o_w`Su}@UH6F+V;~J(5X~mftrXhiiHfeuD^`ZY<+loNH*~9wr-rga=%Z3<-y<< zn<#Z^Y$@Kb#19``Q4FH?rhOufTc3YpWm*cXIFeJ@ad^K2e52o)j-K)>zc7pZj~^G` zN}2}Q!aIUl(WZTwfU!nMU4Z;+DCMg%DBw*12}kmh8YrZ|cLN2*+$^atj*cm7sPq|r z!@1S7qXTZF#KqqJ+%T3`7D`^>7QKACwXhb%Il+maJ>}Dw5jUdMmERLj z^lV00V@9;Xs7jY1Ep8Y$fmYG^lDsBvI1vS?m0xgoY-$^Nh5gVju6}uVM$$eus+G0o{WIi^N?T&>ddhjX8|G3%UeA>(3)XB+rK zKDyDnGB0;#|Bf=;icdxo8S7+luH)X&^pZWQ_~Xo*G}_LhgSLh+9`{-v^!kk-(0dUyojhC0T| zD}}kjs(flk{NmN9fRNVyyKHy^dv>f69trQWB1iqI#6jx{`W#g|f`xve>0Chz%LT-6 z16?J6Am3OFW0`njr%oD6(|&DMv~nO5B*63L(=mob?(1$ZRh_Jh@d&H8Y+Ht1G91U- zr)RnFP0uj2WH*g@0|OG`0aJB4W%OnBA2X}U>TL(WFE}iWyCFS6;IA&P?Y_p?-q^5* znWg8?Fyl)FvOC2t(#ph^Z0U-Dwi{nMj3&kU%UHpS!oOswQfMTT2^J-H9ROFw-S;XpY4@f8S!Yi8jepr(*@yLuH$`62eH zs=Fa;YwJ&=?`ddhO&=~(KWKTq`7N`Olzm}kGvsk4^Y`r>!Ni+bg<Lw^6bY>kq~e zK=)vs&g}A91Lh< z+m;C)W8{Ihn^!PSgS>g80px2KK}N9PG)aRaRt|HjarO7-*rCv(TN+ZP<6N#M$$B6A zs*me>n>lpV{^<_^6d~Q6ihtG^Zb5StlnX1~-C{|grsBLSxxVjj0{%+cP)3pdxjVml z8x*(v7GJ6!{f$k7sd#QDuO>} zjCk;mXVWmC>n|fihn*Q_k(|}_nAGxdW!UQDM!>b1V!qV<(I@uw)o7;<*Lc9rFofpP z%S@Qp&tSpMhU_)0W+)Ph?=;TFR)G42h4ctdNEiA9D#dqL@?mF@H@9Ys<>%N#Dxt|g zAut#aXWs{Ga8VXsMoFU|(1^+dIpAX63*ceSA>&~)_(lp6jjmkXWOFvxwEdUX*?NW2 z=ZV{4N9%bQI0o5eZV`+Mn;Z?AP*zqeNNX2ZL7)4_+X;ZcHxz@joH>T)cM=9 z72M&=GuzfZU_9o)u0A0lG`Bm0IOc{Vi@l;6y}h?Yvf;Onxi6SOr*rsFF)5PIkV#9N zrX)vLEt>krTP0iwf<|vVo=;v{FQ42s-D9UQfbD_^r)hEW8ZTXjv{H4&_I>tlpVH9#F&N4Mx5=VwieJV!h6tl`gSKxTOwV`o(`2o(?@Ny=y zWz^8C>;9+Ep2eFt#`@gx77)~_urrdHT1G%!tarRQ!E!)xm`N9P&70;<;B^6}eqbG+z?~l!peI}w^v&MxDP*abNyuhW1CN~d{X#xgc z=F8VWJ!?Jp1<@~jb3YB8lOU|IMn&%YwcWZx8@m-Foy28C;if{OC||M9%}3}| z`oRb6TZ8=@mvzv-(9e9(YKZ? z-vm1-c%4+wWwBce+czuEsU7#ZolNZ~Qvpf*uRo`4-v4MbsahDfF7slbfEYv!G2GaA z?6Wc{QDP`iGbiLw}s_oFyv-?|ms6^HD1|!Dy9#g^T{c}?J5~f7vU(5GC zV17IMWmm@|el+7OV(#hAwdm10&Jc}t%V-J46$q=`^s33gtYB{V%vmKCn5E5>r!d|MS7TPrY{TqUH6$ zGgPk<$Lpg9B@a}pEw6^?p9UZCWkl@+>Jc6vebkQR{ zrI5U>EiY72u%2Z>utv};v4>8~{s+{g8rM0@@{-nnr0@sP8{q^ZM-LI?R^314!%h-j z+xtncjPhC~%0 zNpU>;J@(;LL4>Tr45BwJb^fJ&*1?)RvOp7&Ml3cV3iIGY*R;Y@Zld;5=Z~IHm$B6m z%V}kK^8^0g2W;+bWKOFW+F<c*}T=l;am@$VV6qC1M`w-a#xbePQi{EFHHjQom|`GY|TZRcV@5_-CB-B=5o_+RK=rIjVJpOT8sOyT5UG#uDp;6gl)` z913|no9~ZWf8{*flTYOy`!nVDc`PyTmT9%}GdAq&&GUM(l6@DHpwTo+X zZ#irZY^YSIpIxJ0ov_Ei*^D9tvsx<35zUZbhsHPf+7 zi&0cdDeWsq^18ZyT`hLYV^ByNKln>e^i4Ci}8GT3YQlH?U7Q$Xsu<#qDkoc6=U~ZFHB|&km$6 z-*oTp#N}ZX_Dj)t%s*MnW=N+-K#%4dFDKR zYPf|riI{wT-URu9@w-vh1!R$Y9v9n-Y;|Keheeg1$$9R%92=NyUKlkPEE_iX75#}d zAaHv?Bb08=OXp40KS2>RB6ktL5_hns5Lql(=~k_r|Ehg)Aqu?Rpo*jRr|HE8eWFwu z-H3UhwoxU?tvISr14caeJKk{j!*2guwT)BMLb2}=wA}boC3ITtTtku9?gv84&4&FQ z{(|6_`ZQv!?E%qcU9FvNm21c^L6##)5u5vj#-_c2B!l-2iYX2@ELZJf3Egea@K-|I zDc7u97JVg8+P=&&PWAukavlh#Zp?%e52NTVA>#I5tu{Dh&(OqqshoI3F^l6sb3HB8 zbgo#8f9wl7A0)gZG@-4VLCr8hDYIo^h1gRj3ZbR#>?xyym5z)Myk|UvI4m&*Jr?k1rD{3L+wq<+nC!Mv6&`Ic4+YM*Kz<5y=gZLWqT8)5FN)x0 z#J_fgUq`_^(5c@bvP(@UTRDQ98fzdF>uaD|^+TPb`21K#e1F;o9@!b2>^o@?(D1? zd#K{P?6#n$L(OR`rxK5+uIUb+ADPd%PqRN-ZUJn0e9IsSRNa~-tKgBk9UT*Eu0>Fj z2mDL1C~L0yW_6QlKx;*{Ec?HWZR>pmr)QID@jVbu8IpgSl;5q>ZrLObX9NgUdPd=h z!p`Q5Z{I1QXvhFHQ=|XA7edbsj@yk6|I^JAO{1fg{(3jtP%p#7hZFf}EdA`-B4?<6 z8w{>V1?r?f=$;|f)cyHc%hcd zPpR+0(au7hfvnhn(RkgB7>VJgSGwUMG~2%#9$%FMy$AADY^Zm&)X=& zfoU>Yb+R@=J>w-KE>iX;{UHtlnC6Vl=bF`uol?VtGmt;j4g7d}1{+*N9yak)K8sk1 zA!`~`M6eYe=-SZ+xN>3~>2bE#{*Jz(z=sb?`tisyB}j}zl;%nhjiybm%>Bt%4Imry zEdd>F8Aay30vS_>ilbPPhS^~^hBq2;Zu)?uG=|-2c0cT19`h^2O0juz>1l|%y5H02 zAKP!=ZCzV5e*HZeWXh~!hdXqEcg|?-BnII5Q~7y)>Uwc+xR_{ljArL|cMMAmcz*B9 zzp3Y_AlN8cMes^Hnh*b(kH4SD!mdLzW}1)+T_Z~z^(T9NXzuEjv8lD_uf{Jw719tl zv`RP-1Vt3Qa%#u0W;ub}DQ{YWfXaeYZjSD_&Pq!k+rb~KvjR!|7ApLSIUzHqTu5~k zZlNNS$SR;_M~4^gySor$QF19GPCJE9DfugWpS>qSB`n-=up_e2oV*lIm#PNSaEIz| zN_s5qGqgEFUSVASNv`Ub>VC?U-#HIRFN|^N1xmjLmE!K_$*>TC5_jwtCKUHv8d^_1 zs;1Q{D|ejt{D~+^C1`r{oWan8l<#~BPROc2kK>kbDn=DpRuD$}-tHq_3muSPQzKKs zFh$MNy{*XI)z$0{X;5fNTZn|AiBK%m91t1NJ)ccRWo@;nN^Hh*AT=5_7*?MJoYl7# zsG&Iq-5+G?@_(+awcx@U=FOyw5c4=US|ycM8ob=&k<&+w_5qtc_h9O!R7h`RSs|VF zIsAH?s?Jz>r}oT^kGjJzVdVGe>8WvnDz(5nJD+a38C(|0l@k*==(J-nfnvA%39?yt zd~EiFG(~-#Jv*>qQcZP)a&ksBZe))MP8-yQlOj4rqrrwD*ln zP|O<7jtX+3!JXt^M1rU4hvitgY48W)YMSr7ur+FbY_ZHqK32Ah=X_UsEIwo?x?f`5 z?4Pz2aEVh+&?_0;#=m-@UL%17-O;O-v=#VygX-}a;_ouc|AQa`J5XkOD@@79zCe}p z3=yNAr?&)8?nO4ORY2auh*4&!_#Ti2DvkwVo&KIS(tiHU0h*i4Rl+=3(mnjW7hwC1 zAi_DOVvnXn%EoQ()PtqtWt@3b&U-hqMYkfArT7a$@}~ zO1e%1uyy|n*`t=U!pne0%(E&?U;;R4>_{8Gb7YJrB*8zqn<5xV@ZOICA~tRLBSPtz-WCq`;lH&q;CHLS;k_ z&+tksI(dl8o1;tX^u$Sr(RicInuW6*AqCCMF`h#h`*AG{jfN?|H~eScV3bxjcH^9n z;(iMHcsMdAOk?-_B{#nB<{mIJEUppDRVjc3FC3Fnel3X**H6t`9$?EGSx8Imi&}O=D)3r}Mdq_BADjr22HfLfZ_yKoXDDvr`}xxW)WHPO7jgr`lKmh7b=wjb z@ok_#*2l7T0^GVbAg7TXh#%b)>+Kl!&~@BlHSKp3tm(L#f#j<1W3R>%qT!W1Oh)X` z+@Gonlml&G@O%(>1cKO8qlXeW+RVzRbL@p6Mb{tDhx`2(Q-kKEViU@7p`5M z&0X7p$-HSH$$aLDmM21-5#m&ky7QRcF49O50yET=SsFnVaw!USCMCB@w2z48G{dnT za_kDvMP;FhA~z!M&M(Z-$_&=l);?ox%USH#IFkKmrovOF_<)$Q&2cYswDSj7S+Q=8 z&mipO3k=hCZU_cV#hdBUeysHv<$ORg{Fl5jMgr^fuNs}q5k?;gI!3xBZ2g+@*I)Cs zQuvu{A&rl#d**G<4R+bqHa10!Z4Irher%O3n{Au+mL#mvkg;Y~!4Ls#_{9*RK#`Ec zD2+^9X+~ecKl|VmAhu+cbUrggXw*VW#uhA#v;d}zq_ud11YLU5r5Hm*l9dIL7#KvK zb9gLEn@zXP%6=hx;c&<<5uGw|v_i8x@`d`RigCj)QephA@g8eZtr*jq}#JboQWEKRLqUlV8Y+dy+&S)&E;Q&lgX*Q43-DzVC+kO{V-tg7w$ zfjxnRt=<;X5Nr`NV*GdG@Kx;Mmu?xQpA)1sh!%!~CEx`$EM+^U$R^P!pUy`7jc9Yb zi4Ly@w9BFnNM$uWXc|r?$}M{`J!aAU)xq4vdItgnen!&)S@c3* zA~EK|g1?ziSo!5bOjT|=Q=W1iz@E-2BsS~Rc1m+9>x=&ZpP0Yi*rEtwWL}Je!iJ>!TXxo z3cms%TXPJsy~k&4=OS?}<~_Xv##~Kga)=L3TVTe*t!p^Ye8BMT$be=Id@eN0C{?)wnjYzmbwnCf{uVL^VhXP|IDf8>g`gGQ|ssLZoNNi z_$1i(o=CB>{5p1mfBb}H~(@x%rE-{HE=-%(5ke}w95e>~LKh<_@SN*=x>{?<#X;K4c8PwA% zXPbZcp4xU^R_)cmXr~CFH2)V<+elz3|BFv5pr)(1o#B^A5X~@ZA>UhbJ+SNn4e?iq zVQ2qPMfPvcN~a?49&o`AEc%zrx}_l%-^*B6YwN`&EyPoQhc91xKj4nO>+HSY5e3NbT5>14lW zvH(!3VfDuE0#8)16}$GF<-gtJ@6ax@WShYlb8xyi5rT;sYgKp@(Sk8i5Zl+}R#?vm zarSlP%r0L|VyyVlNG_5sD=WV&OBZ~X)yRj7vKH_uokdmhkNC5>V`i)B!tc^WOd>r{ ze@+r?kXmWreq;iFO=>YJ7OKI^F^OuNZi&O|362sxH|5*CJ)m|>e14nYR3Lprfq@$D zFu+PAg1i?VD5o^^SHVU>@-U9-(1MBK0>Y3QNKS_0We5jM_5n9I6AKWG)sIqH^-D_uGJ>4%qA$!w2vKd&1%uDXv zhCgPE=93vk1-|@f4H7h&k>jF)iifw6IeKz!Y=R{Gmlbr=yOdZ6=SA@qqgEn7@&+xd z!((Z$wgwl+_Z5e0<7o8BN6GI zVsSp&4|T#AsSB3-{{=(c?~dx`5sNShg( zG#1q@Qj%K?q%%xzkL2U+dQc_TFZknbjji%plZ&gd!E$ZGg7ew+ST9&28u`mYTD;2c z^qgP7&fbSYTr_m;-WWY+kbcKKqOu(f`$TR}Ohn?ltdeW<{xb`{EXL)rMTXQ4NO6FK z*#z0$npSroAr=_=bquv4_a|5LiE2rp8M{;kxSs(^_qO0pn&F>%@op}SfPD)3cxm1br@0g4!H;1NpFvk(5T@A*kUm`Tz{x*gq;NnQ(n4u z3dtz2SYp96k0aGsMglyYF;!9xQyLV;blzZbhdY|zcVFl{pkXj|DrL9j&F7)7aX!bQ z9uyUPX|I(Pf=2uOKYSU`5@OHk83eFJp;E?k2?ii-rZY-%ln@JPkiaGuUh@YPY%iML z1P?QOK;7p|)t%?U8!E?%8SukVzP)(~8G5^t`gZIR(p6YUi4uxya-h^~ECu@6 zqqAC%xW;+t()4VM{|wJ6e$Ni7Xl}lj355EB0e141pK#~D=KRAS#y*f9n%n3*h(Xyd z@8`S&tQJN@p0;1yyyMk|xH0kL)DFj+{IgEZ{8L&PJ^rx9!ELjM;COT8jNB}US7ijV z+sA@%1LRXs{P`>F`irv9+orz1Yj@%sK8jfC)-NaI3l15UTe!Jfgqe38|O!;sI2JS^U`6FGzsESspo zJ67>9!9_8nklSSzoDnSp&(1%y>P3qusVclU!9(ebDy1zQ=T7II#d}B4wqMr-?xp9M zb4=*|Uhol>-Mf`D$~TbQCCnc=Rl{Gw+knJg)Y%*Tfb5P1qh7+YmKXa$2g>HNrW9#Q zhE-bm9OOk`nz2RjjzWl?!MMgFy|_vY_MnWl5wQM%iHK851<&M20;Eeik3|yItH%6|oN9Eun6{%d= z=N*eANB|4DmbrRaN=(|bb2)575&|JP3t}M@h=m!1$dRRp%&-+T0AF8=%d*i<2z{Lh z^F3)IGo1%ZbKG$?nNultCSy0di(F%Ybg&(;k z1izF4^>M!(M)W!<><(H=dwPQDr5OZ?ie+6C6uj**G(x37O`rWR5pseAXJt9$EgTvv zx4a84!V;Ov#?xo~Do%gr{GPUXF8H#!%uK!9%Sr-IZP?*+33*8(p3BHHv%9#C06jvGqkfob46X?zh8#~j zPJ7k1&cfrel5#z{5%T=s%-E-Z#5|L?qmmUG0d=2Ak^=?b&vnK`{Xu_3_vk^E?4$xx z*;D$%(M|j94SX0STo#sIR+rpJ*tY&@s71E=mkubfnYXRVwX8VB+&7aaX zDkYYB08*`-r~k?r|BEg|>3>NVQXVe+TgCDnY4`*WEFO2#&}dCIr(efKj#%hFlb5GZw{&Grpn$HOUs!iagffg< zUOr3@Dmwyx;;e{LUpr{gNl~)W zX@2n$J5io08JiWmLC#GBrIG(1`lzs(%$$xv4*B5(677_}0DvK1{DsG-&*K_EoMlrU z1r9}lAnTooE-E#wQ+?v#McpTvQxiAkk)126n3!C*p}Ki}-pxM`r2ez?TgTl*eVEkx*hsQ4AG1Scb@M1?Bo z64>{l#I7SqZM5$0m$gw!#s{=|bGn1d3YpvS_JPXsv{T^2Xvc)HkNba5@(>xrwNvD3 zSJGWRM!%K`GJiBn_W_SS%OI7~BQ#W!$zg(OccJ37cp#jKUfwUV>yVMqNf$*9P>0_X zQ3XzOz@}VP-r7gmFGi5ST<-NsaScbte+`6jy-v##`Q86b z6jG|SjsPcT{TA5e7iAKdP`-O5snH$Fp#~DWi2dP+tDEgGywPnPkgPeJ+9QTdTzE{X z88~L0W4K4`f9Q5Q<}Oh(JfaAvN+0-dgE;%?(P*qXNwpB_)-Zzm*mP zcex|GZO8(LWj!(h`(I@JpSU%%%+bka+4p#^=Li0xSy-m?t6ws8mE^qtzmeB(XQ@wU ZMt7F5hocMxav&E)U0Fw|QQ>vO{{ZOG+C=~W literal 0 HcmV?d00001 diff --git a/maven-skin/src/main/resources/js/fancybox/jquery.easing-1.3.pack.js b/maven-skin/src/main/resources/js/fancybox/jquery.easing-1.3.pack.js new file mode 100644 index 00000000000..9028179e7bd --- /dev/null +++ b/maven-skin/src/main/resources/js/fancybox/jquery.easing-1.3.pack.js @@ -0,0 +1,72 @@ +/* + * jQuery Easing v1.3 - http://gsgd.co.uk/sandbox/jquery/easing/ + * + * Uses the built in easing capabilities added In jQuery 1.1 + * to offer multiple easing options + * + * TERMS OF USE - jQuery Easing + * + * Open source under the BSD License. + * + * Copyright © 2008 George McGinley Smith + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without modification, + * are permitted provided that the following conditions are met: + * + * Redistributions of source code must retain the above copyright notice, this list of + * conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright notice, this list + * of conditions and the following disclaimer in the documentation and/or other materials + * provided with the distribution. + * + * Neither the name of the author nor the names of contributors may be used to endorse + * or promote products derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, + * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE + * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED + * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING + * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED + * OF THE POSSIBILITY OF SUCH DAMAGE. + * +*/ + +// t: current time, b: begInnIng value, c: change In value, d: duration +eval(function(p,a,c,k,e,r){e=function(c){return(c35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('h.i[\'1a\']=h.i[\'z\'];h.O(h.i,{y:\'D\',z:9(x,t,b,c,d){6 h.i[h.i.y](x,t,b,c,d)},17:9(x,t,b,c,d){6 c*(t/=d)*t+b},D:9(x,t,b,c,d){6-c*(t/=d)*(t-2)+b},13:9(x,t,b,c,d){e((t/=d/2)<1)6 c/2*t*t+b;6-c/2*((--t)*(t-2)-1)+b},X:9(x,t,b,c,d){6 c*(t/=d)*t*t+b},U:9(x,t,b,c,d){6 c*((t=t/d-1)*t*t+1)+b},R:9(x,t,b,c,d){e((t/=d/2)<1)6 c/2*t*t*t+b;6 c/2*((t-=2)*t*t+2)+b},N:9(x,t,b,c,d){6 c*(t/=d)*t*t*t+b},M:9(x,t,b,c,d){6-c*((t=t/d-1)*t*t*t-1)+b},L:9(x,t,b,c,d){e((t/=d/2)<1)6 c/2*t*t*t*t+b;6-c/2*((t-=2)*t*t*t-2)+b},K:9(x,t,b,c,d){6 c*(t/=d)*t*t*t*t+b},J:9(x,t,b,c,d){6 c*((t=t/d-1)*t*t*t*t+1)+b},I:9(x,t,b,c,d){e((t/=d/2)<1)6 c/2*t*t*t*t*t+b;6 c/2*((t-=2)*t*t*t*t+2)+b},G:9(x,t,b,c,d){6-c*8.C(t/d*(8.g/2))+c+b},15:9(x,t,b,c,d){6 c*8.n(t/d*(8.g/2))+b},12:9(x,t,b,c,d){6-c/2*(8.C(8.g*t/d)-1)+b},Z:9(x,t,b,c,d){6(t==0)?b:c*8.j(2,10*(t/d-1))+b},Y:9(x,t,b,c,d){6(t==d)?b+c:c*(-8.j(2,-10*t/d)+1)+b},W:9(x,t,b,c,d){e(t==0)6 b;e(t==d)6 b+c;e((t/=d/2)<1)6 c/2*8.j(2,10*(t-1))+b;6 c/2*(-8.j(2,-10*--t)+2)+b},V:9(x,t,b,c,d){6-c*(8.o(1-(t/=d)*t)-1)+b},S:9(x,t,b,c,d){6 c*8.o(1-(t=t/d-1)*t)+b},Q:9(x,t,b,c,d){e((t/=d/2)<1)6-c/2*(8.o(1-t*t)-1)+b;6 c/2*(8.o(1-(t-=2)*t)+1)+b},P:9(x,t,b,c,d){f s=1.l;f p=0;f a=c;e(t==0)6 b;e((t/=d)==1)6 b+c;e(!p)p=d*.3;e(a<8.w(c)){a=c;f s=p/4}m f s=p/(2*8.g)*8.r(c/a);6-(a*8.j(2,10*(t-=1))*8.n((t*d-s)*(2*8.g)/p))+b},H:9(x,t,b,c,d){f s=1.l;f p=0;f a=c;e(t==0)6 b;e((t/=d)==1)6 b+c;e(!p)p=d*.3;e(a<8.w(c)){a=c;f s=p/4}m f s=p/(2*8.g)*8.r(c/a);6 a*8.j(2,-10*t)*8.n((t*d-s)*(2*8.g)/p)+c+b},T:9(x,t,b,c,d){f s=1.l;f p=0;f a=c;e(t==0)6 b;e((t/=d/2)==2)6 b+c;e(!p)p=d*(.3*1.5);e(a<8.w(c)){a=c;f s=p/4}m f s=p/(2*8.g)*8.r(c/a);e(t<1)6-.5*(a*8.j(2,10*(t-=1))*8.n((t*d-s)*(2*8.g)/p))+b;6 a*8.j(2,-10*(t-=1))*8.n((t*d-s)*(2*8.g)/p)*.5+c+b},F:9(x,t,b,c,d,s){e(s==u)s=1.l;6 c*(t/=d)*t*((s+1)*t-s)+b},E:9(x,t,b,c,d,s){e(s==u)s=1.l;6 c*((t=t/d-1)*t*((s+1)*t+s)+1)+b},16:9(x,t,b,c,d,s){e(s==u)s=1.l;e((t/=d/2)<1)6 c/2*(t*t*(((s*=(1.B))+1)*t-s))+b;6 c/2*((t-=2)*t*(((s*=(1.B))+1)*t+s)+2)+b},A:9(x,t,b,c,d){6 c-h.i.v(x,d-t,0,c,d)+b},v:9(x,t,b,c,d){e((t/=d)<(1/2.k)){6 c*(7.q*t*t)+b}m e(t<(2/2.k)){6 c*(7.q*(t-=(1.5/2.k))*t+.k)+b}m e(t<(2.5/2.k)){6 c*(7.q*(t-=(2.14/2.k))*t+.11)+b}m{6 c*(7.q*(t-=(2.18/2.k))*t+.19)+b}},1b:9(x,t,b,c,d){e(t')[0], { prop: 0 }), + + isIE6 = $.browser.msie && $.browser.version < 7 && !window.XMLHttpRequest, + + /* + * Private methods + */ + + _abort = function() { + loading.hide(); + + imgPreloader.onerror = imgPreloader.onload = null; + + if (ajaxLoader) { + ajaxLoader.abort(); + } + + tmp.empty(); + }, + + _error = function() { + if (false === selectedOpts.onError(selectedArray, selectedIndex, selectedOpts)) { + loading.hide(); + busy = false; + return; + } + + selectedOpts.titleShow = false; + + selectedOpts.width = 'auto'; + selectedOpts.height = 'auto'; + + tmp.html( '

    The requested content cannot be loaded.
    Please try again later.

    ' ); + + _process_inline(); + }, + + _start = function() { + var obj = selectedArray[ selectedIndex ], + href, + type, + title, + str, + emb, + ret; + + _abort(); + + selectedOpts = $.extend({}, $.fn.fancybox.defaults, (typeof $(obj).data('fancybox') == 'undefined' ? selectedOpts : $(obj).data('fancybox'))); + + ret = selectedOpts.onStart(selectedArray, selectedIndex, selectedOpts); + + if (ret === false) { + busy = false; + return; + } else if (typeof ret == 'object') { + selectedOpts = $.extend(selectedOpts, ret); + } + + title = selectedOpts.title || (obj.nodeName ? $(obj).attr('title') : obj.title) || ''; + + if (obj.nodeName && !selectedOpts.orig) { + selectedOpts.orig = $(obj).children("img:first").length ? $(obj).children("img:first") : $(obj); + } + + if (title === '' && selectedOpts.orig && selectedOpts.titleFromAlt) { + title = selectedOpts.orig.attr('alt'); + } + + href = selectedOpts.href || (obj.nodeName ? $(obj).attr('href') : obj.href) || null; + + if ((/^(?:javascript)/i).test(href) || href == '#') { + href = null; + } + + if (selectedOpts.type) { + type = selectedOpts.type; + + if (!href) { + href = selectedOpts.content; + } + + } else if (selectedOpts.content) { + type = 'html'; + + } else if (href) { + if (href.match(imgRegExp)) { + type = 'image'; + + } else if (href.match(swfRegExp)) { + type = 'swf'; + + } else if ($(obj).hasClass("iframe")) { + type = 'iframe'; + + } else if (href.indexOf("#") === 0) { + type = 'inline'; + + } else { + type = 'ajax'; + } + } + + if (!type) { + _error(); + return; + } + + if (type == 'inline') { + obj = href.substr(href.indexOf("#")); + type = $(obj).length > 0 ? 'inline' : 'ajax'; + } + + selectedOpts.type = type; + selectedOpts.href = href; + selectedOpts.title = title; + + if (selectedOpts.autoDimensions) { + if (selectedOpts.type == 'html' || selectedOpts.type == 'inline' || selectedOpts.type == 'ajax') { + selectedOpts.width = 'auto'; + selectedOpts.height = 'auto'; + } else { + selectedOpts.autoDimensions = false; + } + } + + if (selectedOpts.modal) { + selectedOpts.overlayShow = true; + selectedOpts.hideOnOverlayClick = false; + selectedOpts.hideOnContentClick = false; + selectedOpts.enableEscapeButton = false; + selectedOpts.showCloseButton = false; + } + + selectedOpts.padding = parseInt(selectedOpts.padding, 10); + selectedOpts.margin = parseInt(selectedOpts.margin, 10); + + tmp.css('padding', (selectedOpts.padding + selectedOpts.margin)); + + $('.fancybox-inline-tmp').unbind('fancybox-cancel').bind('fancybox-change', function() { + $(this).replaceWith(content.children()); + }); + + switch (type) { + case 'html' : + tmp.html( selectedOpts.content ); + _process_inline(); + break; + + case 'inline' : + if ( $(obj).parent().is('#fancybox-content') === true) { + busy = false; + return; + } + + $('
    ') + .hide() + .insertBefore( $(obj) ) + .bind('fancybox-cleanup', function() { + $(this).replaceWith(content.children()); + }).bind('fancybox-cancel', function() { + $(this).replaceWith(tmp.children()); + }); + + $(obj).appendTo(tmp); + + _process_inline(); + break; + + case 'image': + busy = false; + + $.fancybox.showActivity(); + + imgPreloader = new Image(); + + imgPreloader.onerror = function() { + _error(); + }; + + imgPreloader.onload = function() { + busy = true; + + imgPreloader.onerror = imgPreloader.onload = null; + + _process_image(); + }; + + imgPreloader.src = href; + break; + + case 'swf': + selectedOpts.scrolling = 'no'; + + str = ''; + emb = ''; + + $.each(selectedOpts.swf, function(name, val) { + str += ''; + emb += ' ' + name + '="' + val + '"'; + }); + + str += ''; + + tmp.html(str); + + _process_inline(); + break; + + case 'ajax': + busy = false; + + $.fancybox.showActivity(); + + selectedOpts.ajax.win = selectedOpts.ajax.success; + + ajaxLoader = $.ajax($.extend({}, selectedOpts.ajax, { + url : href, + data : selectedOpts.ajax.data || {}, + error : function(XMLHttpRequest, textStatus, errorThrown) { + if ( XMLHttpRequest.status > 0 ) { + _error(); + } + }, + success : function(data, textStatus, XMLHttpRequest) { + var o = typeof XMLHttpRequest == 'object' ? XMLHttpRequest : ajaxLoader; + if (o.status == 200) { + if ( typeof selectedOpts.ajax.win == 'function' ) { + ret = selectedOpts.ajax.win(href, data, textStatus, XMLHttpRequest); + + if (ret === false) { + loading.hide(); + return; + } else if (typeof ret == 'string' || typeof ret == 'object') { + data = ret; + } + } + + tmp.html( data ); + _process_inline(); + } + } + })); + + break; + + case 'iframe': + _show(); + break; + } + }, + + _process_inline = function() { + var + w = selectedOpts.width, + h = selectedOpts.height; + + if (w.toString().indexOf('%') > -1) { + w = parseInt( ($(window).width() - (selectedOpts.margin * 2)) * parseFloat(w) / 100, 10) + 'px'; + + } else { + w = w == 'auto' ? 'auto' : w + 'px'; + } + + if (h.toString().indexOf('%') > -1) { + h = parseInt( ($(window).height() - (selectedOpts.margin * 2)) * parseFloat(h) / 100, 10) + 'px'; + + } else { + h = h == 'auto' ? 'auto' : h + 'px'; + } + + tmp.wrapInner('
    '); + + selectedOpts.width = tmp.width(); + selectedOpts.height = tmp.height(); + + _show(); + }, + + _process_image = function() { + selectedOpts.width = imgPreloader.width; + selectedOpts.height = imgPreloader.height; + + $("").attr({ + 'id' : 'fancybox-img', + 'src' : imgPreloader.src, + 'alt' : selectedOpts.title + }).appendTo( tmp ); + + _show(); + }, + + _show = function() { + var pos, equal; + + loading.hide(); + + if (wrap.is(":visible") && false === currentOpts.onCleanup(currentArray, currentIndex, currentOpts)) { + $.event.trigger('fancybox-cancel'); + + busy = false; + return; + } + + busy = true; + + $(content.add( overlay )).unbind(); + + $(window).unbind("resize.fb scroll.fb"); + $(document).unbind('keydown.fb'); + + if (wrap.is(":visible") && currentOpts.titlePosition !== 'outside') { + wrap.css('height', wrap.height()); + } + + currentArray = selectedArray; + currentIndex = selectedIndex; + currentOpts = selectedOpts; + + if (currentOpts.overlayShow) { + overlay.css({ + 'background-color' : currentOpts.overlayColor, + 'opacity' : currentOpts.overlayOpacity, + 'cursor' : currentOpts.hideOnOverlayClick ? 'pointer' : 'auto', + 'height' : $(document).height() + }); + + if (!overlay.is(':visible')) { + if (isIE6) { + $('select:not(#fancybox-tmp select)').filter(function() { + return this.style.visibility !== 'hidden'; + }).css({'visibility' : 'hidden'}).one('fancybox-cleanup', function() { + this.style.visibility = 'inherit'; + }); + } + + overlay.show(); + } + } else { + overlay.hide(); + } + + final_pos = _get_zoom_to(); + + _process_title(); + + if (wrap.is(":visible")) { + $( close.add( nav_left ).add( nav_right ) ).hide(); + + pos = wrap.position(), + + start_pos = { + top : pos.top, + left : pos.left, + width : wrap.width(), + height : wrap.height() + }; + + equal = (start_pos.width == final_pos.width && start_pos.height == final_pos.height); + + content.fadeTo(currentOpts.changeFade, 0.3, function() { + var finish_resizing = function() { + content.html( tmp.contents() ).fadeTo(currentOpts.changeFade, 1, _finish); + }; + + $.event.trigger('fancybox-change'); + + content + .empty() + .removeAttr('filter') + .css({ + 'border-width' : currentOpts.padding, + 'width' : final_pos.width - currentOpts.padding * 2, + 'height' : selectedOpts.autoDimensions ? 'auto' : final_pos.height - titleHeight - currentOpts.padding * 2 + }); + + if (equal) { + finish_resizing(); + + } else { + fx.prop = 0; + + $(fx).animate({prop: 1}, { + duration : currentOpts.changeSpeed, + easing : currentOpts.easingChange, + step : _draw, + complete : finish_resizing + }); + } + }); + + return; + } + + wrap.removeAttr("style"); + + content.css('border-width', currentOpts.padding); + + if (currentOpts.transitionIn == 'elastic') { + start_pos = _get_zoom_from(); + + content.html( tmp.contents() ); + + wrap.show(); + + if (currentOpts.opacity) { + final_pos.opacity = 0; + } + + fx.prop = 0; + + $(fx).animate({prop: 1}, { + duration : currentOpts.speedIn, + easing : currentOpts.easingIn, + step : _draw, + complete : _finish + }); + + return; + } + + if (currentOpts.titlePosition == 'inside' && titleHeight > 0) { + title.show(); + } + + content + .css({ + 'width' : final_pos.width - currentOpts.padding * 2, + 'height' : selectedOpts.autoDimensions ? 'auto' : final_pos.height - titleHeight - currentOpts.padding * 2 + }) + .html( tmp.contents() ); + + wrap + .css(final_pos) + .fadeIn( currentOpts.transitionIn == 'none' ? 0 : currentOpts.speedIn, _finish ); + }, + + _format_title = function(title) { + if (title && title.length) { + if (currentOpts.titlePosition == 'float') { + return '
    ' + title + '
    '; + } + + return '
    ' + title + '
    '; + } + + return false; + }, + + _process_title = function() { + titleStr = currentOpts.title || ''; + titleHeight = 0; + + title + .empty() + .removeAttr('style') + .removeClass(); + + if (currentOpts.titleShow === false) { + title.hide(); + return; + } + + titleStr = $.isFunction(currentOpts.titleFormat) ? currentOpts.titleFormat(titleStr, currentArray, currentIndex, currentOpts) : _format_title(titleStr); + + if (!titleStr || titleStr === '') { + title.hide(); + return; + } + + title + .addClass('fancybox-title-' + currentOpts.titlePosition) + .html( titleStr ) + .appendTo( 'body' ) + .show(); + + switch (currentOpts.titlePosition) { + case 'inside': + title + .css({ + 'width' : final_pos.width - (currentOpts.padding * 2), + 'marginLeft' : currentOpts.padding, + 'marginRight' : currentOpts.padding + }); + + titleHeight = title.outerHeight(true); + + title.appendTo( outer ); + + final_pos.height += titleHeight; + break; + + case 'over': + title + .css({ + 'marginLeft' : currentOpts.padding, + 'width' : final_pos.width - (currentOpts.padding * 2), + 'bottom' : currentOpts.padding + }) + .appendTo( outer ); + break; + + case 'float': + title + .css('left', parseInt((title.width() - final_pos.width - 40)/ 2, 10) * -1) + .appendTo( wrap ); + break; + + default: + title + .css({ + 'width' : final_pos.width - (currentOpts.padding * 2), + 'paddingLeft' : currentOpts.padding, + 'paddingRight' : currentOpts.padding + }) + .appendTo( wrap ); + break; + } + + title.hide(); + }, + + _set_navigation = function() { + if (currentOpts.enableEscapeButton || currentOpts.enableKeyboardNav) { + $(document).bind('keydown.fb', function(e) { + if (e.keyCode == 27 && currentOpts.enableEscapeButton) { + e.preventDefault(); + $.fancybox.close(); + + } else if ((e.keyCode == 37 || e.keyCode == 39) && currentOpts.enableKeyboardNav && e.target.tagName !== 'INPUT' && e.target.tagName !== 'TEXTAREA' && e.target.tagName !== 'SELECT') { + e.preventDefault(); + $.fancybox[ e.keyCode == 37 ? 'prev' : 'next'](); + } + }); + } + + if (!currentOpts.showNavArrows) { + nav_left.hide(); + nav_right.hide(); + return; + } + + if ((currentOpts.cyclic && currentArray.length > 1) || currentIndex !== 0) { + nav_left.show(); + } + + if ((currentOpts.cyclic && currentArray.length > 1) || currentIndex != (currentArray.length -1)) { + nav_right.show(); + } + }, + + _finish = function () { + if (!$.support.opacity) { + content.get(0).style.removeAttribute('filter'); + wrap.get(0).style.removeAttribute('filter'); + } + + if (selectedOpts.autoDimensions) { + content.css('height', 'auto'); + } + + wrap.css('height', 'auto'); + + if (titleStr && titleStr.length) { + title.show(); + } + + if (currentOpts.showCloseButton) { + close.show(); + } + + _set_navigation(); + + if (currentOpts.hideOnContentClick) { + content.bind('click', $.fancybox.close); + } + + if (currentOpts.hideOnOverlayClick) { + overlay.bind('click', $.fancybox.close); + } + + $(window).bind("resize.fb", $.fancybox.resize); + + if (currentOpts.centerOnScroll) { + $(window).bind("scroll.fb", $.fancybox.center); + } + + if (currentOpts.type == 'iframe') { + $('').appendTo(content); + } + + wrap.show(); + + busy = false; + + $.fancybox.center(); + + currentOpts.onComplete(currentArray, currentIndex, currentOpts); + + _preload_images(); + }, + + _preload_images = function() { + var href, + objNext; + + if ((currentArray.length -1) > currentIndex) { + href = currentArray[ currentIndex + 1 ].href; + + if (typeof href !== 'undefined' && href.match(imgRegExp)) { + objNext = new Image(); + objNext.src = href; + } + } + + if (currentIndex > 0) { + href = currentArray[ currentIndex - 1 ].href; + + if (typeof href !== 'undefined' && href.match(imgRegExp)) { + objNext = new Image(); + objNext.src = href; + } + } + }, + + _draw = function(pos) { + var dim = { + width : parseInt(start_pos.width + (final_pos.width - start_pos.width) * pos, 10), + height : parseInt(start_pos.height + (final_pos.height - start_pos.height) * pos, 10), + + top : parseInt(start_pos.top + (final_pos.top - start_pos.top) * pos, 10), + left : parseInt(start_pos.left + (final_pos.left - start_pos.left) * pos, 10) + }; + + if (typeof final_pos.opacity !== 'undefined') { + dim.opacity = pos < 0.5 ? 0.5 : pos; + } + + wrap.css(dim); + + content.css({ + 'width' : dim.width - currentOpts.padding * 2, + 'height' : dim.height - (titleHeight * pos) - currentOpts.padding * 2 + }); + }, + + _get_viewport = function() { + return [ + $(window).width() - (currentOpts.margin * 2), + $(window).height() - (currentOpts.margin * 2), + $(document).scrollLeft() + currentOpts.margin, + $(document).scrollTop() + currentOpts.margin + ]; + }, + + _get_zoom_to = function () { + var view = _get_viewport(), + to = {}, + resize = currentOpts.autoScale, + double_padding = currentOpts.padding * 2, + ratio; + + if (currentOpts.width.toString().indexOf('%') > -1) { + to.width = parseInt((view[0] * parseFloat(currentOpts.width)) / 100, 10); + } else { + to.width = currentOpts.width + double_padding; + } + + if (currentOpts.height.toString().indexOf('%') > -1) { + to.height = parseInt((view[1] * parseFloat(currentOpts.height)) / 100, 10); + } else { + to.height = currentOpts.height + double_padding; + } + + if (resize && (to.width > view[0] || to.height > view[1])) { + if (selectedOpts.type == 'image' || selectedOpts.type == 'swf') { + ratio = (currentOpts.width ) / (currentOpts.height ); + + if ((to.width ) > view[0]) { + to.width = view[0]; + to.height = parseInt(((to.width - double_padding) / ratio) + double_padding, 10); + } + + if ((to.height) > view[1]) { + to.height = view[1]; + to.width = parseInt(((to.height - double_padding) * ratio) + double_padding, 10); + } + + } else { + to.width = Math.min(to.width, view[0]); + to.height = Math.min(to.height, view[1]); + } + } + + to.top = parseInt(Math.max(view[3] - 20, view[3] + ((view[1] - to.height - 40) * 0.5)), 10); + to.left = parseInt(Math.max(view[2] - 20, view[2] + ((view[0] - to.width - 40) * 0.5)), 10); + + return to; + }, + + _get_obj_pos = function(obj) { + var pos = obj.offset(); + + pos.top += parseInt( obj.css('paddingTop'), 10 ) || 0; + pos.left += parseInt( obj.css('paddingLeft'), 10 ) || 0; + + pos.top += parseInt( obj.css('border-top-width'), 10 ) || 0; + pos.left += parseInt( obj.css('border-left-width'), 10 ) || 0; + + pos.width = obj.width(); + pos.height = obj.height(); + + return pos; + }, + + _get_zoom_from = function() { + var orig = selectedOpts.orig ? $(selectedOpts.orig) : false, + from = {}, + pos, + view; + + if (orig && orig.length) { + pos = _get_obj_pos(orig); + + from = { + width : pos.width + (currentOpts.padding * 2), + height : pos.height + (currentOpts.padding * 2), + top : pos.top - currentOpts.padding - 20, + left : pos.left - currentOpts.padding - 20 + }; + + } else { + view = _get_viewport(); + + from = { + width : currentOpts.padding * 2, + height : currentOpts.padding * 2, + top : parseInt(view[3] + view[1] * 0.5, 10), + left : parseInt(view[2] + view[0] * 0.5, 10) + }; + } + + return from; + }, + + _animate_loading = function() { + if (!loading.is(':visible')){ + clearInterval(loadingTimer); + return; + } + + $('div', loading).css('top', (loadingFrame * -40) + 'px'); + + loadingFrame = (loadingFrame + 1) % 12; + }; + + /* + * Public methods + */ + + $.fn.fancybox = function(options) { + if (!$(this).length) { + return this; + } + + $(this) + .data('fancybox', $.extend({}, options, ($.metadata ? $(this).metadata() : {}))) + .unbind('click.fb') + .bind('click.fb', function(e) { + e.preventDefault(); + + if (busy) { + return; + } + + busy = true; + + $(this).blur(); + + selectedArray = []; + selectedIndex = 0; + + var rel = $(this).attr('rel') || ''; + + if (!rel || rel == '' || rel === 'nofollow') { + selectedArray.push(this); + + } else { + selectedArray = $("a[rel=" + rel + "], area[rel=" + rel + "]"); + selectedIndex = selectedArray.index( this ); + } + + _start(); + + return; + }); + + return this; + }; + + $.fancybox = function(obj) { + var opts; + + if (busy) { + return; + } + + busy = true; + opts = typeof arguments[1] !== 'undefined' ? arguments[1] : {}; + + selectedArray = []; + selectedIndex = parseInt(opts.index, 10) || 0; + + if ($.isArray(obj)) { + for (var i = 0, j = obj.length; i < j; i++) { + if (typeof obj[i] == 'object') { + $(obj[i]).data('fancybox', $.extend({}, opts, obj[i])); + } else { + obj[i] = $({}).data('fancybox', $.extend({content : obj[i]}, opts)); + } + } + + selectedArray = jQuery.merge(selectedArray, obj); + + } else { + if (typeof obj == 'object') { + $(obj).data('fancybox', $.extend({}, opts, obj)); + } else { + obj = $({}).data('fancybox', $.extend({content : obj}, opts)); + } + + selectedArray.push(obj); + } + + if (selectedIndex > selectedArray.length || selectedIndex < 0) { + selectedIndex = 0; + } + + _start(); + }; + + $.fancybox.showActivity = function() { + clearInterval(loadingTimer); + + loading.show(); + loadingTimer = setInterval(_animate_loading, 66); + }; + + $.fancybox.hideActivity = function() { + loading.hide(); + }; + + $.fancybox.next = function() { + return $.fancybox.pos( currentIndex + 1); + }; + + $.fancybox.prev = function() { + return $.fancybox.pos( currentIndex - 1); + }; + + $.fancybox.pos = function(pos) { + if (busy) { + return; + } + + pos = parseInt(pos); + + selectedArray = currentArray; + + if (pos > -1 && pos < currentArray.length) { + selectedIndex = pos; + _start(); + + } else if (currentOpts.cyclic && currentArray.length > 1) { + selectedIndex = pos >= currentArray.length ? 0 : currentArray.length - 1; + _start(); + } + + return; + }; + + $.fancybox.cancel = function() { + if (busy) { + return; + } + + busy = true; + + $.event.trigger('fancybox-cancel'); + + _abort(); + + selectedOpts.onCancel(selectedArray, selectedIndex, selectedOpts); + + busy = false; + }; + + // Note: within an iframe use - parent.$.fancybox.close(); + $.fancybox.close = function() { + if (busy || wrap.is(':hidden')) { + return; + } + + busy = true; + + if (currentOpts && false === currentOpts.onCleanup(currentArray, currentIndex, currentOpts)) { + busy = false; + return; + } + + _abort(); + + $(close.add( nav_left ).add( nav_right )).hide(); + + $(content.add( overlay )).unbind(); + + $(window).unbind("resize.fb scroll.fb"); + $(document).unbind('keydown.fb'); + + content.find('iframe').attr('src', isIE6 && /^https/i.test(window.location.href || '') ? 'javascript:void(false)' : 'about:blank'); + + if (currentOpts.titlePosition !== 'inside') { + title.empty(); + } + + wrap.stop(); + + function _cleanup() { + overlay.fadeOut('fast'); + + title.empty().hide(); + wrap.hide(); + + $.event.trigger('fancybox-cleanup'); + + content.empty(); + + currentOpts.onClosed(currentArray, currentIndex, currentOpts); + + currentArray = selectedOpts = []; + currentIndex = selectedIndex = 0; + currentOpts = selectedOpts = {}; + + busy = false; + } + + if (currentOpts.transitionOut == 'elastic') { + start_pos = _get_zoom_from(); + + var pos = wrap.position(); + + final_pos = { + top : pos.top , + left : pos.left, + width : wrap.width(), + height : wrap.height() + }; + + if (currentOpts.opacity) { + final_pos.opacity = 1; + } + + title.empty().hide(); + + fx.prop = 1; + + $(fx).animate({ prop: 0 }, { + duration : currentOpts.speedOut, + easing : currentOpts.easingOut, + step : _draw, + complete : _cleanup + }); + + } else { + wrap.fadeOut( currentOpts.transitionOut == 'none' ? 0 : currentOpts.speedOut, _cleanup); + } + }; + + $.fancybox.resize = function() { + if (overlay.is(':visible')) { + overlay.css('height', $(document).height()); + } + + $.fancybox.center(true); + }; + + $.fancybox.center = function() { + var view, align; + + if (busy) { + return; + } + + align = arguments[0] === true ? 1 : 0; + view = _get_viewport(); + + if (!align && (wrap.width() > view[0] || wrap.height() > view[1])) { + return; + } + + wrap + .stop() + .animate({ + 'top' : parseInt(Math.max(view[3] - 20, view[3] + ((view[1] - content.height() - 40) * 0.5) - currentOpts.padding)), + 'left' : parseInt(Math.max(view[2] - 20, view[2] + ((view[0] - content.width() - 40) * 0.5) - currentOpts.padding)) + }, typeof arguments[0] == 'number' ? arguments[0] : 200); + }; + + $.fancybox.init = function() { + if ($("#fancybox-wrap").length) { + return; + } + + $('body').append( + tmp = $('
    '), + loading = $('
    '), + overlay = $('
    '), + wrap = $('
    ') + ); + + outer = $('
    ') + .append('
    ') + .appendTo( wrap ); + + outer.append( + content = $('
    '), + close = $(''), + title = $('
    '), + + nav_left = $(''), + nav_right = $('') + ); + + close.click($.fancybox.close); + loading.click($.fancybox.cancel); + + nav_left.click(function(e) { + e.preventDefault(); + $.fancybox.prev(); + }); + + nav_right.click(function(e) { + e.preventDefault(); + $.fancybox.next(); + }); + + if ($.fn.mousewheel) { + wrap.bind('mousewheel.fb', function(e, delta) { + if (busy) { + e.preventDefault(); + + } else if ($(e.target).get(0).clientHeight == 0 || $(e.target).get(0).scrollHeight === $(e.target).get(0).clientHeight) { + e.preventDefault(); + $.fancybox[ delta > 0 ? 'prev' : 'next'](); + } + }); + } + + if (!$.support.opacity) { + wrap.addClass('fancybox-ie'); + } + + if (isIE6) { + loading.addClass('fancybox-ie6'); + wrap.addClass('fancybox-ie6'); + + $('').prependTo(outer); + } + }; + + $.fn.fancybox.defaults = { + padding : 10, + margin : 40, + opacity : false, + modal : false, + cyclic : false, + scrolling : 'auto', // 'auto', 'yes' or 'no' + + width : 560, + height : 340, + + autoScale : true, + autoDimensions : true, + centerOnScroll : false, + + ajax : {}, + swf : { wmode: 'transparent' }, + + hideOnOverlayClick : true, + hideOnContentClick : false, + + overlayShow : true, + overlayOpacity : 0.7, + overlayColor : '#777', + + titleShow : true, + titlePosition : 'float', // 'float', 'outside', 'inside' or 'over' + titleFormat : null, + titleFromAlt : false, + + transitionIn : 'fade', // 'elastic', 'fade' or 'none' + transitionOut : 'fade', // 'elastic', 'fade' or 'none' + + speedIn : 300, + speedOut : 300, + + changeSpeed : 300, + changeFade : 'fast', + + easingIn : 'swing', + easingOut : 'swing', + + showCloseButton : true, + showNavArrows : true, + enableEscapeButton : true, + enableKeyboardNav : true, + + onStart : function(){}, + onCancel : function(){}, + onComplete : function(){}, + onCleanup : function(){}, + onClosed : function(){}, + onError : function(){} + }; + + $(document).ready(function() { + $.fancybox.init(); + }); + +})(jQuery); \ No newline at end of file diff --git a/maven-skin/src/main/resources/js/fancybox/jquery.fancybox-1.3.4.pack.js b/maven-skin/src/main/resources/js/fancybox/jquery.fancybox-1.3.4.pack.js new file mode 100644 index 00000000000..1373ed0838b --- /dev/null +++ b/maven-skin/src/main/resources/js/fancybox/jquery.fancybox-1.3.4.pack.js @@ -0,0 +1,46 @@ +/* + * FancyBox - jQuery Plugin + * Simple and fancy lightbox alternative + * + * Examples and documentation at: http://fancybox.net + * + * Copyright (c) 2008 - 2010 Janis Skarnelis + * That said, it is hardly a one-person project. Many people have submitted bugs, code, and offered their advice freely. Their support is greatly appreciated. + * + * Version: 1.3.4 (11/11/2010) + * Requires: jQuery v1.3+ + * + * Dual licensed under the MIT and GPL licenses: + * http://www.opensource.org/licenses/mit-license.php + * http://www.gnu.org/licenses/gpl.html + */ + +;(function(b){var m,t,u,f,D,j,E,n,z,A,q=0,e={},o=[],p=0,d={},l=[],G=null,v=new Image,J=/\.(jpg|gif|png|bmp|jpeg)(.*)?$/i,W=/[^\.]\.(swf)\s*$/i,K,L=1,y=0,s="",r,i,h=false,B=b.extend(b("
    ")[0],{prop:0}),M=b.browser.msie&&b.browser.version<7&&!window.XMLHttpRequest,N=function(){t.hide();v.onerror=v.onload=null;G&&G.abort();m.empty()},O=function(){if(false===e.onError(o,q,e)){t.hide();h=false}else{e.titleShow=false;e.width="auto";e.height="auto";m.html('

    The requested content cannot be loaded.
    Please try again later.

    '); +F()}},I=function(){var a=o[q],c,g,k,C,P,w;N();e=b.extend({},b.fn.fancybox.defaults,typeof b(a).data("fancybox")=="undefined"?e:b(a).data("fancybox"));w=e.onStart(o,q,e);if(w===false)h=false;else{if(typeof w=="object")e=b.extend(e,w);k=e.title||(a.nodeName?b(a).attr("title"):a.title)||"";if(a.nodeName&&!e.orig)e.orig=b(a).children("img:first").length?b(a).children("img:first"):b(a);if(k===""&&e.orig&&e.titleFromAlt)k=e.orig.attr("alt");c=e.href||(a.nodeName?b(a).attr("href"):a.href)||null;if(/^(?:javascript)/i.test(c)|| +c=="#")c=null;if(e.type){g=e.type;if(!c)c=e.content}else if(e.content)g="html";else if(c)g=c.match(J)?"image":c.match(W)?"swf":b(a).hasClass("iframe")?"iframe":c.indexOf("#")===0?"inline":"ajax";if(g){if(g=="inline"){a=c.substr(c.indexOf("#"));g=b(a).length>0?"inline":"ajax"}e.type=g;e.href=c;e.title=k;if(e.autoDimensions)if(e.type=="html"||e.type=="inline"||e.type=="ajax"){e.width="auto";e.height="auto"}else e.autoDimensions=false;if(e.modal){e.overlayShow=true;e.hideOnOverlayClick=false;e.hideOnContentClick= +false;e.enableEscapeButton=false;e.showCloseButton=false}e.padding=parseInt(e.padding,10);e.margin=parseInt(e.margin,10);m.css("padding",e.padding+e.margin);b(".fancybox-inline-tmp").unbind("fancybox-cancel").bind("fancybox-change",function(){b(this).replaceWith(j.children())});switch(g){case "html":m.html(e.content);F();break;case "inline":if(b(a).parent().is("#fancybox-content")===true){h=false;break}b('
    ').hide().insertBefore(b(a)).bind("fancybox-cleanup",function(){b(this).replaceWith(j.children())}).bind("fancybox-cancel", +function(){b(this).replaceWith(m.children())});b(a).appendTo(m);F();break;case "image":h=false;b.fancybox.showActivity();v=new Image;v.onerror=function(){O()};v.onload=function(){h=true;v.onerror=v.onload=null;e.width=v.width;e.height=v.height;b("").attr({id:"fancybox-img",src:v.src,alt:e.title}).appendTo(m);Q()};v.src=c;break;case "swf":e.scrolling="no";C='';P="";b.each(e.swf,function(x,H){C+='';P+=" "+x+'="'+H+'"'});C+='";m.html(C);F();break;case "ajax":h=false;b.fancybox.showActivity();e.ajax.win=e.ajax.success;G=b.ajax(b.extend({},e.ajax,{url:c,data:e.ajax.data||{},error:function(x){x.status>0&&O()},success:function(x,H,R){if((typeof R=="object"?R:G).status==200){if(typeof e.ajax.win== +"function"){w=e.ajax.win(c,x,H,R);if(w===false){t.hide();return}else if(typeof w=="string"||typeof w=="object")x=w}m.html(x);F()}}}));break;case "iframe":Q()}}else O()}},F=function(){var a=e.width,c=e.height;a=a.toString().indexOf("%")>-1?parseInt((b(window).width()-e.margin*2)*parseFloat(a)/100,10)+"px":a=="auto"?"auto":a+"px";c=c.toString().indexOf("%")>-1?parseInt((b(window).height()-e.margin*2)*parseFloat(c)/100,10)+"px":c=="auto"?"auto":c+"px";m.wrapInner('
    ');e.width=m.width();e.height=m.height();Q()},Q=function(){var a,c;t.hide();if(f.is(":visible")&&false===d.onCleanup(l,p,d)){b.event.trigger("fancybox-cancel");h=false}else{h=true;b(j.add(u)).unbind();b(window).unbind("resize.fb scroll.fb");b(document).unbind("keydown.fb");f.is(":visible")&&d.titlePosition!=="outside"&&f.css("height",f.height());l=o;p=q;d=e;if(d.overlayShow){u.css({"background-color":d.overlayColor, +opacity:d.overlayOpacity,cursor:d.hideOnOverlayClick?"pointer":"auto",height:b(document).height()});if(!u.is(":visible")){M&&b("select:not(#fancybox-tmp select)").filter(function(){return this.style.visibility!=="hidden"}).css({visibility:"hidden"}).one("fancybox-cleanup",function(){this.style.visibility="inherit"});u.show()}}else u.hide();i=X();s=d.title||"";y=0;n.empty().removeAttr("style").removeClass();if(d.titleShow!==false){if(b.isFunction(d.titleFormat))a=d.titleFormat(s,l,p,d);else a=s&&s.length? +d.titlePosition=="float"?'
    '+s+'
    ':'
    '+s+"
    ":false;s=a;if(!(!s||s==="")){n.addClass("fancybox-title-"+d.titlePosition).html(s).appendTo("body").show();switch(d.titlePosition){case "inside":n.css({width:i.width-d.padding*2,marginLeft:d.padding,marginRight:d.padding}); +y=n.outerHeight(true);n.appendTo(D);i.height+=y;break;case "over":n.css({marginLeft:d.padding,width:i.width-d.padding*2,bottom:d.padding}).appendTo(D);break;case "float":n.css("left",parseInt((n.width()-i.width-40)/2,10)*-1).appendTo(f);break;default:n.css({width:i.width-d.padding*2,paddingLeft:d.padding,paddingRight:d.padding}).appendTo(f)}}}n.hide();if(f.is(":visible")){b(E.add(z).add(A)).hide();a=f.position();r={top:a.top,left:a.left,width:f.width(),height:f.height()};c=r.width==i.width&&r.height== +i.height;j.fadeTo(d.changeFade,0.3,function(){var g=function(){j.html(m.contents()).fadeTo(d.changeFade,1,S)};b.event.trigger("fancybox-change");j.empty().removeAttr("filter").css({"border-width":d.padding,width:i.width-d.padding*2,height:e.autoDimensions?"auto":i.height-y-d.padding*2});if(c)g();else{B.prop=0;b(B).animate({prop:1},{duration:d.changeSpeed,easing:d.easingChange,step:T,complete:g})}})}else{f.removeAttr("style");j.css("border-width",d.padding);if(d.transitionIn=="elastic"){r=V();j.html(m.contents()); +f.show();if(d.opacity)i.opacity=0;B.prop=0;b(B).animate({prop:1},{duration:d.speedIn,easing:d.easingIn,step:T,complete:S})}else{d.titlePosition=="inside"&&y>0&&n.show();j.css({width:i.width-d.padding*2,height:e.autoDimensions?"auto":i.height-y-d.padding*2}).html(m.contents());f.css(i).fadeIn(d.transitionIn=="none"?0:d.speedIn,S)}}}},Y=function(){if(d.enableEscapeButton||d.enableKeyboardNav)b(document).bind("keydown.fb",function(a){if(a.keyCode==27&&d.enableEscapeButton){a.preventDefault();b.fancybox.close()}else if((a.keyCode== +37||a.keyCode==39)&&d.enableKeyboardNav&&a.target.tagName!=="INPUT"&&a.target.tagName!=="TEXTAREA"&&a.target.tagName!=="SELECT"){a.preventDefault();b.fancybox[a.keyCode==37?"prev":"next"]()}});if(d.showNavArrows){if(d.cyclic&&l.length>1||p!==0)z.show();if(d.cyclic&&l.length>1||p!=l.length-1)A.show()}else{z.hide();A.hide()}},S=function(){if(!b.support.opacity){j.get(0).style.removeAttribute("filter");f.get(0).style.removeAttribute("filter")}e.autoDimensions&&j.css("height","auto");f.css("height","auto"); +s&&s.length&&n.show();d.showCloseButton&&E.show();Y();d.hideOnContentClick&&j.bind("click",b.fancybox.close);d.hideOnOverlayClick&&u.bind("click",b.fancybox.close);b(window).bind("resize.fb",b.fancybox.resize);d.centerOnScroll&&b(window).bind("scroll.fb",b.fancybox.center);if(d.type=="iframe")b('').appendTo(j); +f.show();h=false;b.fancybox.center();d.onComplete(l,p,d);var a,c;if(l.length-1>p){a=l[p+1].href;if(typeof a!=="undefined"&&a.match(J)){c=new Image;c.src=a}}if(p>0){a=l[p-1].href;if(typeof a!=="undefined"&&a.match(J)){c=new Image;c.src=a}}},T=function(a){var c={width:parseInt(r.width+(i.width-r.width)*a,10),height:parseInt(r.height+(i.height-r.height)*a,10),top:parseInt(r.top+(i.top-r.top)*a,10),left:parseInt(r.left+(i.left-r.left)*a,10)};if(typeof i.opacity!=="undefined")c.opacity=a<0.5?0.5:a;f.css(c); +j.css({width:c.width-d.padding*2,height:c.height-y*a-d.padding*2})},U=function(){return[b(window).width()-d.margin*2,b(window).height()-d.margin*2,b(document).scrollLeft()+d.margin,b(document).scrollTop()+d.margin]},X=function(){var a=U(),c={},g=d.autoScale,k=d.padding*2;c.width=d.width.toString().indexOf("%")>-1?parseInt(a[0]*parseFloat(d.width)/100,10):d.width+k;c.height=d.height.toString().indexOf("%")>-1?parseInt(a[1]*parseFloat(d.height)/100,10):d.height+k;if(g&&(c.width>a[0]||c.height>a[1]))if(e.type== +"image"||e.type=="swf"){g=d.width/d.height;if(c.width>a[0]){c.width=a[0];c.height=parseInt((c.width-k)/g+k,10)}if(c.height>a[1]){c.height=a[1];c.width=parseInt((c.height-k)*g+k,10)}}else{c.width=Math.min(c.width,a[0]);c.height=Math.min(c.height,a[1])}c.top=parseInt(Math.max(a[3]-20,a[3]+(a[1]-c.height-40)*0.5),10);c.left=parseInt(Math.max(a[2]-20,a[2]+(a[0]-c.width-40)*0.5),10);return c},V=function(){var a=e.orig?b(e.orig):false,c={};if(a&&a.length){c=a.offset();c.top+=parseInt(a.css("paddingTop"), +10)||0;c.left+=parseInt(a.css("paddingLeft"),10)||0;c.top+=parseInt(a.css("border-top-width"),10)||0;c.left+=parseInt(a.css("border-left-width"),10)||0;c.width=a.width();c.height=a.height();c={width:c.width+d.padding*2,height:c.height+d.padding*2,top:c.top-d.padding-20,left:c.left-d.padding-20}}else{a=U();c={width:d.padding*2,height:d.padding*2,top:parseInt(a[3]+a[1]*0.5,10),left:parseInt(a[2]+a[0]*0.5,10)}}return c},Z=function(){if(t.is(":visible")){b("div",t).css("top",L*-40+"px");L=(L+1)%12}else clearInterval(K)}; +b.fn.fancybox=function(a){if(!b(this).length)return this;b(this).data("fancybox",b.extend({},a,b.metadata?b(this).metadata():{})).unbind("click.fb").bind("click.fb",function(c){c.preventDefault();if(!h){h=true;b(this).blur();o=[];q=0;c=b(this).attr("rel")||"";if(!c||c==""||c==="nofollow")o.push(this);else{o=b("a[rel="+c+"], area[rel="+c+"]");q=o.index(this)}I()}});return this};b.fancybox=function(a,c){var g;if(!h){h=true;g=typeof c!=="undefined"?c:{};o=[];q=parseInt(g.index,10)||0;if(b.isArray(a)){for(var k= +0,C=a.length;ko.length||q<0)q=0;I()}};b.fancybox.showActivity=function(){clearInterval(K);t.show();K=setInterval(Z,66)};b.fancybox.hideActivity=function(){t.hide()};b.fancybox.next=function(){return b.fancybox.pos(p+ +1)};b.fancybox.prev=function(){return b.fancybox.pos(p-1)};b.fancybox.pos=function(a){if(!h){a=parseInt(a);o=l;if(a>-1&&a1){q=a>=l.length?0:l.length-1;I()}}};b.fancybox.cancel=function(){if(!h){h=true;b.event.trigger("fancybox-cancel");N();e.onCancel(o,q,e);h=false}};b.fancybox.close=function(){function a(){u.fadeOut("fast");n.empty().hide();f.hide();b.event.trigger("fancybox-cleanup");j.empty();d.onClosed(l,p,d);l=e=[];p=q=0;d=e={};h=false}if(!(h||f.is(":hidden"))){h= +true;if(d&&false===d.onCleanup(l,p,d))h=false;else{N();b(E.add(z).add(A)).hide();b(j.add(u)).unbind();b(window).unbind("resize.fb scroll.fb");b(document).unbind("keydown.fb");j.find("iframe").attr("src",M&&/^https/i.test(window.location.href||"")?"javascript:void(false)":"about:blank");d.titlePosition!=="inside"&&n.empty();f.stop();if(d.transitionOut=="elastic"){r=V();var c=f.position();i={top:c.top,left:c.left,width:f.width(),height:f.height()};if(d.opacity)i.opacity=1;n.empty().hide();B.prop=1; +b(B).animate({prop:0},{duration:d.speedOut,easing:d.easingOut,step:T,complete:a})}else f.fadeOut(d.transitionOut=="none"?0:d.speedOut,a)}}};b.fancybox.resize=function(){u.is(":visible")&&u.css("height",b(document).height());b.fancybox.center(true)};b.fancybox.center=function(a){var c,g;if(!h){g=a===true?1:0;c=U();!g&&(f.width()>c[0]||f.height()>c[1])||f.stop().animate({top:parseInt(Math.max(c[3]-20,c[3]+(c[1]-j.height()-40)*0.5-d.padding)),left:parseInt(Math.max(c[2]-20,c[2]+(c[0]-j.width()-40)*0.5- +d.padding))},typeof a=="number"?a:200)}};b.fancybox.init=function(){if(!b("#fancybox-wrap").length){b("body").append(m=b('
    '),t=b('
    '),u=b('
    '),f=b('
    '));D=b('
    ').append('
    ').appendTo(f); +D.append(j=b('
    '),E=b(''),n=b('
    '),z=b(''),A=b(''));E.click(b.fancybox.close);t.click(b.fancybox.cancel);z.click(function(a){a.preventDefault();b.fancybox.prev()});A.click(function(a){a.preventDefault();b.fancybox.next()}); +b.fn.mousewheel&&f.bind("mousewheel.fb",function(a,c){if(h)a.preventDefault();else if(b(a.target).get(0).clientHeight==0||b(a.target).get(0).scrollHeight===b(a.target).get(0).clientHeight){a.preventDefault();b.fancybox[c>0?"prev":"next"]()}});b.support.opacity||f.addClass("fancybox-ie");if(M){t.addClass("fancybox-ie6");f.addClass("fancybox-ie6");b('').prependTo(D)}}}; +b.fn.fancybox.defaults={padding:10,margin:40,opacity:false,modal:false,cyclic:false,scrolling:"auto",width:560,height:340,autoScale:true,autoDimensions:true,centerOnScroll:false,ajax:{},swf:{wmode:"transparent"},hideOnOverlayClick:true,hideOnContentClick:false,overlayShow:true,overlayOpacity:0.7,overlayColor:"#777",titleShow:true,titlePosition:"float",titleFormat:null,titleFromAlt:false,transitionIn:"fade",transitionOut:"fade",speedIn:300,speedOut:300,changeSpeed:300,changeFade:"fast",easingIn:"swing", +easingOut:"swing",showCloseButton:true,showNavArrows:true,enableEscapeButton:true,enableKeyboardNav:true,onStart:function(){},onCancel:function(){},onComplete:function(){},onCleanup:function(){},onClosed:function(){},onError:function(){}};b(document).ready(function(){b.fancybox.init()})})(jQuery); \ No newline at end of file diff --git a/maven-skin/src/main/resources/js/fancybox/jquery.mousewheel-3.0.4.pack.js b/maven-skin/src/main/resources/js/fancybox/jquery.mousewheel-3.0.4.pack.js new file mode 100644 index 00000000000..cb66588e29c --- /dev/null +++ b/maven-skin/src/main/resources/js/fancybox/jquery.mousewheel-3.0.4.pack.js @@ -0,0 +1,14 @@ +/*! Copyright (c) 2010 Brandon Aaron (http://brandonaaron.net) +* Licensed under the MIT License (LICENSE.txt). +* +* Thanks to: http://adomas.org/javascript-mouse-wheel/ for some pointers. +* Thanks to: Mathias Bank(http://www.mathias-bank.de) for a scope bug fix. +* Thanks to: Seamus Leahy for adding deltaX and deltaY +* +* Version: 3.0.4 +* +* Requires: 1.2.2+ +*/ + +(function(d){function g(a){var b=a||window.event,i=[].slice.call(arguments,1),c=0,h=0,e=0;a=d.event.fix(b);a.type="mousewheel";if(a.wheelDelta)c=a.wheelDelta/120;if(a.detail)c=-a.detail/3;e=c;if(b.axis!==undefined&&b.axis===b.HORIZONTAL_AXIS){e=0;h=-1*c}if(b.wheelDeltaY!==undefined)e=b.wheelDeltaY/120;if(b.wheelDeltaX!==undefined)h=-1*b.wheelDeltaX/120;i.unshift(a,c,h,e);return d.event.handle.apply(this,i)}var f=["DOMMouseScroll","mousewheel"];d.event.special.mousewheel={setup:function(){if(this.addEventListener)for(var a= +f.length;a;)this.addEventListener(f[--a],g,false);else this.onmousewheel=g},teardown:function(){if(this.removeEventListener)for(var a=f.length;a;)this.removeEventListener(f[--a],g,false);else this.onmousewheel=null}};d.fn.extend({mousewheel:function(a){return a?this.bind("mousewheel",a):this.trigger("mousewheel")},unmousewheel:function(a){return this.unbind("mousewheel",a)}})})(jQuery); \ No newline at end of file From f7ec17ad4408f81c1b63f72d207d6a2946b4ab6f Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 2 May 2011 04:32:10 +0000 Subject: [PATCH 306/541] Mention User Flag as new feature (MAILBOX-63) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1098472 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/newsarchive.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index e3f9538f4e9..833e62b4406 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -30,6 +30,7 @@ * What's new in 3.0-M3 for end users - Numerous IMAP bug fixes (better client support, memory improvement, NIO and IO support...) - Support for IMAP IDLE (RFC 2177, server transmit updates to the client in real time) + - Support for IMAP User Flags - Telnet Management has been removed in favor of JMX with client shell - More metrics counters available via JMX - Better debug logging on protocols From 6cb07ed7fede6231be297eb9103e86192d5ab781 Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 17 May 2011 09:42:26 +0000 Subject: [PATCH 307/541] Document java 1.6 as requirement for server. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1104083 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/index.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/server/src/site/xdoc/index.xml b/project/server/src/site/xdoc/index.xml index 5be4702e478..ca0e71c82c1 100644 --- a/project/server/src/site/xdoc/index.xml +++ b/project/server/src/site/xdoc/index.xml @@ -450,7 +450,7 @@ - Java 1.5 + Java 1.6 Requirement yes no From 0bd8e08ce6964384631627cffc5bf87b01b7fe14 Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 17 May 2011 09:43:33 +0000 Subject: [PATCH 308/541] Document WITHIN extension support and java 1.6 for next release. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1104084 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/newsarchive.xml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 833e62b4406..90667c5fb91 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -31,6 +31,7 @@ - Numerous IMAP bug fixes (better client support, memory improvement, NIO and IO support...) - Support for IMAP IDLE (RFC 2177, server transmit updates to the client in real time) - Support for IMAP User Flags + - Support for IMAP WITHIN Extensions (RFC 5032) - Telnet Management has been removed in favor of JMX with client shell - More metrics counters available via JMX - Better debug logging on protocols @@ -45,6 +46,7 @@ - Better debug logging on protocols - Mailing list functionality has been removed - More documentation on web site for configuration,... + - Java 1.6 mandatory - ... and much more, see details on https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10411&version=12315512 * What's new in 3.0-M3 for developers - Less maven modules From bda69167ca38ebd24ac2e41c5a8642126e16d7ba Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 24 May 2011 20:16:54 +0000 Subject: [PATCH 309/541] Format model for server documentation (JAMES-1219) git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1127262 13f79535-47bb-0310-9956-ffa450edef68 --- .../model-eclipse-modeler/model.notation | 202 +++++++----------- .../resources/model-eclipse-modeler/model.uml | 6 +- 2 files changed, 82 insertions(+), 126 deletions(-) diff --git a/project/src/site/resources/model-eclipse-modeler/model.notation b/project/src/site/resources/model-eclipse-modeler/model.notation index a2e1f955213..c56efd44b3a 100644 --- a/project/src/site/resources/model-eclipse-modeler/model.notation +++ b/project/src/site/resources/model-eclipse-modeler/model.notation @@ -40,12 +40,12 @@ - + - + @@ -468,7 +468,7 @@ - + @@ -705,7 +705,7 @@ - + @@ -734,7 +734,7 @@ - + @@ -763,7 +763,7 @@ - + @@ -792,7 +792,7 @@ - + @@ -821,7 +821,7 @@ - + @@ -850,7 +850,7 @@ - + @@ -925,7 +925,7 @@ - + @@ -983,7 +983,7 @@ - + @@ -1116,7 +1116,7 @@ - + @@ -1145,7 +1145,7 @@ - + @@ -1174,7 +1174,7 @@ - + @@ -1203,7 +1203,7 @@ - + @@ -1232,87 +1232,12 @@ - + - - - - -
    - - -
    - - -
    - - - - - -
    - - -
    - - -
    - - - - - - - - - - - - - - - - - - - - - - -
    - - -
    - - -
    - - - - - - - - - - - - - - - - - - - - - - - - + @@ -1491,7 +1416,7 @@ - + @@ -1532,7 +1457,7 @@ - + @@ -1561,7 +1486,7 @@ - + @@ -1590,7 +1515,7 @@ - + @@ -1619,7 +1544,7 @@ - + @@ -1648,7 +1573,7 @@ - + @@ -1716,7 +1641,7 @@ - + @@ -1757,7 +1682,7 @@ - + @@ -1822,6 +1747,18 @@ + + + + + + + + + + + + @@ -1833,7 +1770,7 @@ - + @@ -2095,7 +2032,7 @@ - + @@ -2383,8 +2320,9 @@ - - + + + @@ -2398,6 +2336,19 @@ + + + + + + + + + + + + + @@ -2604,23 +2555,6 @@ - - -
    - - -
    - - -
    - - - - - - - -
    @@ -2646,7 +2580,7 @@ - + @@ -2665,6 +2599,18 @@ + + + + + + + + + + + + @@ -2811,5 +2757,17 @@ + + + + + + + + + + + + diff --git a/project/src/site/resources/model-eclipse-modeler/model.uml b/project/src/site/resources/model-eclipse-modeler/model.uml index 34429cd68cb..2551f2c66a0 100644 --- a/project/src/site/resources/model-eclipse-modeler/model.uml +++ b/project/src/site/resources/model-eclipse-modeler/model.uml @@ -118,10 +118,6 @@ - - - - @@ -158,6 +154,8 @@ + + From b08276676a99b66746c0875e4c4bec9fbf3b3f32 Mon Sep 17 00:00:00 2001 From: eric Date: Tue, 31 May 2011 10:43:40 +0000 Subject: [PATCH 310/541] Announce IMAP and Mailbox 0.2 release on web site home page git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1129606 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 6 ++++++ project/src/site/xdoc/newsarchive.xml | 17 +++++++++++++++-- 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index c3fedc8408b..7f1c93d1685 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -372,10 +372,16 @@
      + +
    • May/2011 - +
    • Dec/2010 - diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 90667c5fb91..ac724a446bd 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -18,7 +18,19 @@ -

      2011 - Apache James Server 3.0-M3 released

       +

      Apache James IMAP 0.2 and Mailbox 0.2

       +

      The Apache James Project is happy to announce + the release of version 0.2 of the Apache James IMAP and Mailbox components with following features:

      +

      - Numerous IMAP bug fixes (better client support, memory improvement, NIO and IO support...).

      +

      - Support for IMAP IDLE (RFC 2177, server transmit updates to the client in real time).

      +

      - Support for IMAP User Flags.

      +

      - Support for IMAP WITHIN Extensions (RFC 5032).

      +

      - Mailbox Tooling to copy from a persistence implementation to another implementation.

      +

      - ... See also the complete release notes for IMAP 0.2 + and Mailbox 0.2.

      + +       From d7f50f222e5e7e87e06336897a2813ac253cf101 Mon Sep 17 00:00:00 2001 From: eric Date: Fri, 3 Jun 2011 06:32:37 +0000 Subject: [PATCH 311/541] Mention documention on sendmail is out-dated git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1130910 13f79535-47bb-0310-9956-ffa450edef68 --- project/server/src/site/xdoc/james_and_sendmail.xml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/project/server/src/site/xdoc/james_and_sendmail.xml b/project/server/src/site/xdoc/james_and_sendmail.xml index 067a7f4d755..52d5282111d 100644 --- a/project/server/src/site/xdoc/james_and_sendmail.xml +++ b/project/server/src/site/xdoc/james_and_sendmail.xml @@ -26,8 +26,14 @@ -
      +
      +

      This information contained in this document is outdated.

      +

      It describes how to configure a version of sendmail that is no more the current one.

      +

      Moreover, some distributions are now replacing sendmail with Postfix.

      +

      For up-to-date information, please refer to the sendmail and/or postfix documentation.

      +
      +

      This document explains how to configure sendmail to route all mail generated by /usr/sbin/sendmail or local mail on a host through James on the same host, including mail to local addresses without @host.
      All sendmail configuration file locations are for Redhat Linux 7.2, other installations may have different locations.
      From 72ab74845def4ddd44193ab7687431719d6ab724 Mon Sep 17 00:00:00 2001 From: rdonkin Date: Mon, 13 Jun 2011 19:13:33 +0000 Subject: [PATCH 312/541] JAMES-1263 http://www.apache.org/dev/crypto.html asks that a notice about crypto is added to download pages. James distributes several products designed to work with third party cryptographic library. So, added section at the top and then specific bits for each effected product. If anyone knows of any I've missed, please jump in and patch. Please feel free to tweak the visuals in the site.css. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1135230 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/resources/css/site.css | 9 ++++ project/src/site/xdoc/download.xml | 70 ++++++++++++++++++++++++- 2 files changed, 77 insertions(+), 2 deletions(-) diff --git a/project/src/site/resources/css/site.css b/project/src/site/resources/css/site.css index dce4fafbb20..91932109611 100644 --- a/project/src/site/resources/css/site.css +++ b/project/src/site/resources/css/site.css @@ -38,3 +38,12 @@ margin: 0px 0px 10px 10px; background-color: white; } + +/* Box containing cryptography export control notice */ +.apache-james-crypto-notice { + padding: 0.7em; + margin: 0.5em 0 0.5em 0; + border-style:solid; + border-width:medium; + background-color: #cdd3d8; +} \ No newline at end of file diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 9db4f9741c5..def8138f68e 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -25,7 +25,28 @@ - +

      + +
      +
      +

      +Some distributions include cryptographic software. The country in which you currently reside may have restrictions on the import, possession, use, +and/or re-export to another country, of encryption software. BEFORE using any encryption software, please check your country's laws, +regulations and policies concerning the import, possession, or use, and re-export of encryption software, to see if this is permitted. +See http://www.wassenaar.org for more information. +

      +The U.S. Government Department of Commerce, Bureau of Industry and Security (BIS), +has classified this software as Export Commodity Control Number (ECCN) 5D002.C.1, which includes information security software using or performing cryptographic +functions with asymmetric algorithms. The form and manner of this Apache Software Foundation distribution makes it eligible for export +under the License Exception ENC Technology Software Unrestricted (TSU) exception (see the BIS Export Administration Regulations, Section 740.13) +for both object code and source code. +

      +More specific details are included below. Export control information for the +is found here. +

      +
      +
      +

      Use the links below to download the product from one of @@ -153,6 +174,22 @@

    + +
    +
    +

    + + Apache James Server 3 uses third party cryptography software + including +

    + +
    +
      @@ -180,7 +217,22 @@ for a detailed list of changes. Some of the earlier defects could turn a James mail server into an Open Relay. All users of James Server are urged to upgrade to version v2.3.1 as soon as possible.

      - + +
      +
      +

      + + Apache James Server 2 uses third party cryptography software + including +

      + +
      +
      +
      • Binary (Unix TAR):

        Apache Crypto Mailets 1.0 is the latest stable version:

        + +
        +
        +

        + + Apache Crypto Mailets 1 uses third party cryptography software + including +

        +         +
        +
        • --> +
      • June/2011 - +
      • May/2011 - diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index ac724a446bd..eaa617a429e 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -18,6 +18,11 @@ +

        Apache James Protocols 1.5

         +

        The Apache James Project is happy to announce + the release of version 1.5 of the Apache James Protocols

        +

        Read the release notes.

        +

        Apache James IMAP 0.2 and Mailbox 0.2

        The Apache James Project is happy to announce the release of version 0.2 of the Apache James IMAP and Mailbox components with following features:

        From 379037de02b8b49e6cf0156a6f19876eef5ba402 Mon Sep 17 00:00:00 2001 From: eric Date: Wed, 29 Jun 2011 08:42:10 +0000 Subject: [PATCH 315/541] mvn site is not happy with jira url. shorten it git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1141003 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/newsarchive.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index eaa617a429e..6473cfe8cd9 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -21,7 +21,7 @@

        Apache James Protocols 1.5

        The Apache James Project is happy to announce the release of version 1.5 of the Apache James Protocols

        -

        Read the release notes.

        +

        Read the release notes.

        Apache James IMAP 0.2 and Mailbox 0.2

        The Apache James Project is happy to announce From ca1637b5d03a0841727d007c0737f52ac389a454 Mon Sep 17 00:00:00 2001 From: eric Date: Wed, 29 Jun 2011 09:29:21 +0000 Subject: [PATCH 316/541] Use & in full link rather than shortened url git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1141023 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/newsarchive.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 6473cfe8cd9..b87a2076d42 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -21,7 +21,7 @@

        Apache James Protocols 1.5

        The Apache James Project is happy to announce the release of version 1.5 of the Apache James Protocols

        -

        Read the release notes.

        +

        Read the release notes.

        Apache James IMAP 0.2 and Mailbox 0.2

        The Apache James Project is happy to announce From 9331e0ad38141ef1de932d3410b54b667dbb4123 Mon Sep 17 00:00:00 2001 From: felixk Date: Wed, 29 Jun 2011 17:13:24 +0000 Subject: [PATCH 317/541] Access javascript arrays via array.item(nr) instead of array[nr] because the cgi script doesn't likes words in square brackets. See JAMES-1260 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1141169 13f79535-47bb-0310-9956-ffa450edef68 --- .../src/main/resources/META-INF/maven/site.vm | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/maven-skin/src/main/resources/META-INF/maven/site.vm b/maven-skin/src/main/resources/META-INF/maven/site.vm index 750a9c57ca6..88338b2fd04 100644 --- a/maven-skin/src/main/resources/META-INF/maven/site.vm +++ b/maven-skin/src/main/resources/META-INF/maven/site.vm @@ -467,7 +467,7 @@ (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; - var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); + var s = document.getElementsByTagName('script').item(0); s.parentNode.insertBefore(ga, s); })(); @@ -524,17 +524,15 @@ var hrefs = document.getElementsByTagName('a'); var extensions = ["gz","bz2","zip","jar","asc","sar"]; for (var l = 0; l < hrefs.length; l++) { - // 0+ is a workaround for download.cgi script by ASF that - // is not happy with simple words in square brackets - if (hrefs[0+l] != "") { - var path = hrefs[0+l].pathname; - var external = hrefs[0+l].hostname != location.host; + if (hrefs.item(l) != "") { + var path = hrefs.item(l).pathname; + var external = hrefs.item(l).hostname != location.host; if (external) { var splitted = path.split('.'); - var ext = splitted[0+splitted.length-1]; + var ext = splitted.item(splitted.length-1); for (var e = 0; e < extensions.length; e++) { - if (extensions[0+e] == ext) { - startListening(hrefs[0+l],"click",trackDownloads); + if (extensions.item(e) == ext) { + startListening(hrefs.item(l),"click",trackDownloads); } } } From 347fcf64efafc086ff7727a88fd9c6b423e3ca52 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 10 Jul 2011 07:12:29 +0000 Subject: [PATCH 318/541] Update project site for jSPF 0.9.9 release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1144787 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 28 +++++++++++++-------------- project/src/site/xdoc/index.xml | 18 +++++------------ project/src/site/xdoc/newsarchive.xml | 7 ++++++- 3 files changed, 25 insertions(+), 28 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index a34d7b114ff..df680a65dfd 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -170,7 +170,7 @@ is found here.

        POP3 is broken in 3.0-M2 - Please use IMAP4 to read your Mails! - POP3 is repaired in M3 snapshot and you can download it from here. + POP3 is repaired in beta2 snapshot and you can download it from here.

    @@ -302,32 +302,32 @@ is found here.
    -

    Apache James jSPF 0.9.8 is the latest jSPF stable version:

    +

    Apache James jSPF 0.9.9 is the latest jSPF stable version:

    • Binary Resolver (JAR): apache-jspf-resolver-0.9.8.jar [PGP]
      • + href="[preferred]/james/jspf/binaries/apache-jspf-resolver-0.9.9.jar">apache-jspf-resolver-0.9.9.jar [PGP]
    • Binary Tester (JAR): apache-jspf-tester-0.9.8.jar [PGP]
      • + href="[preferred]/james/jspf/binaries/apache-jspf-tester-0.9.9.jar">apache-jspf-tester-0.9.9.jar [PGP]
    • Binary (ZIP Format): apache-jspf-0.9.8-bin.zip [PGP]
      • + href="[preferred]/james/jspf/binaries/apache-jspf-0.9.9-bin.zip">apache-jspf-0.9.9-bin.zip [PGP]
    • Binary (Unix TAR.GZ): apache-jspf-0.9.8-bin.tar.gz [PGP]
      • + href="[preferred]/james/jspf/binaries/apache-jspf-0.9.9-bin.tar.gz">apache-jspf-0.9.9-bin.tar.gz [PGP]
    • Source (Unix TAR.GZ): apache-jspf-0.9.8-src.tar.gz [PGP]
      • + href="[preferred]/james/jspf/source/apache-jspf-0.9.9-src.tar.gz">apache-jspf-0.9.9-src.tar.gz [PGP]
    • Source (ZIP Format): apache-jspf-0.9.8-src.zip [PGP]
      • + href="[preferred]/james/jspf/source/apache-jspf-0.9.9-src.zip">apache-jspf-0.9.9-src.zip [PGP]
    • Other Binaries
      • diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 5d4aaf183f1..cd1902ff717 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -44,7 +44,7 @@

      Hey! - Apache James Server 3.0-M3 is out! Thank you to everyone who contributed code, + Apache James Server 3.0-M2 is out! Thank you to everyone who contributed code, documentation, bug report, feedback...

      @@ -378,6 +378,10 @@
    --> +
  • July/2011 - +
  • June/2011 - @@ -413,18 +417,6 @@
  • Apache Mailet Standard 1.0 released
    • -
  • Oct/2009 - -
    • -
  • Sep/2009 - -
    • -
  • Aug/2009 - -
    • Read all the news in full in the News Archive
    diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index b87a2076d42..bf9773bb36e 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -18,9 +18,14 @@ +

    Apache James jSPF 0.9.9

     +

    The Apache James Project is happy to announce + the release of version 0.9.9 of the Apache James jSPF which includes fixes related to OSGI.

    +

    Read the release notes.

    +

    Apache James Protocols 1.5

    The Apache James Project is happy to announce - the release of version 1.5 of the Apache James Protocols

    + the release of version 1.5 of the Apache James Protocols.

    Read the release notes.

    Apache James IMAP 0.2 and Mailbox 0.2

     From b8f1b42b1611c43dabcecae2d2352f317da8e6df Mon Sep 17 00:00:00 2001 From: felixk Date: Mon, 18 Jul 2011 05:32:56 +0000 Subject: [PATCH 319/541] Implement Apache Branding Requirements 3. Website Navigation Links: navbar links included, link to www.apache.org included -> need to update the left menu, putting the link to www.apache.org in bold. See JAMES-1289 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1147748 13f79535-47bb-0310-9956-ffa450edef68 --- .../src/main/resources/META-INF/maven/site.vm | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/maven-skin/src/main/resources/META-INF/maven/site.vm b/maven-skin/src/main/resources/META-INF/maven/site.vm index 88338b2fd04..0d9e1ca324e 100644 --- a/maven-skin/src/main/resources/META-INF/maven/site.vm +++ b/maven-skin/src/main/resources/META-INF/maven/site.vm @@ -273,6 +273,32 @@ #end #end +
    Apache Software Foundation
    + #end ## #macro ( copyright ) From 0db9214a404637900df9f46c5af1387ab0b9c84b Mon Sep 17 00:00:00 2001 From: felixk Date: Mon, 18 Jul 2011 06:33:21 +0000 Subject: [PATCH 320/541] Cleanup / Use skin for Apache Branding in Navigation. See JAMES-1289 git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1147757 13f79535-47bb-0310-9956-ffa450edef68 --- maven-skin/src/site/site.xml | 2 +- project/server/src/site/site.xml | 2 +- project/src/site/site.xml | 12 ------------ 3 files changed, 2 insertions(+), 14 deletions(-) diff --git a/maven-skin/src/site/site.xml b/maven-skin/src/site/site.xml index 24dfed3851a..d0c1f20c123 100644 --- a/maven-skin/src/site/site.xml +++ b/maven-skin/src/site/site.xml @@ -22,7 +22,7 @@ org.apache.james maven-skin - 1.6-SNAPSHOT + 1.7-SNAPSHOT diff --git a/project/server/src/site/site.xml b/project/server/src/site/site.xml index 7948adf094b..f5fb52ed03b 100644 --- a/project/server/src/site/site.xml +++ b/project/server/src/site/site.xml @@ -22,7 +22,7 @@ org.apache.james maven-skin - 1.6-SNAPSHOT + 1.7-SNAPSHOT diff --git a/project/src/site/site.xml b/project/src/site/site.xml index 5d998a7570e..d0e3397b7c8 100644 --- a/project/src/site/site.xml +++ b/project/src/site/site.xml @@ -85,18 +85,6 @@ --> - - - - - - - - - - From 8e59abdffb6accc9cd3972d86542995aef8bdbc5 Mon Sep 17 00:00:00 2001 From: eric Date: Mon, 25 Jul 2011 14:02:05 +0000 Subject: [PATCH 321/541] Add news for mime4j 0.7 in project web site. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1150705 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 30 +++++++++++++-------------- project/src/site/xdoc/index.xml | 4 ++++ project/src/site/xdoc/newsarchive.xml | 23 ++++++++++++++++++++ 3 files changed, 42 insertions(+), 15 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index df680a65dfd..1f3584ef0a8 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -265,33 +265,33 @@ is found here.
    -

    Apache Mime4J 0.6.1 is the latest stable version:

    +

    Apache Mime4J 0.7 is the latest stable version:

    • Binary (Unix TAR): apache-mime4j-0.6.1-bin.tar.gz [PGP][MD5]
      • + href="[preferred]/james/mime4j/apache-mime4j-0.7-bin.tar.gz">apache-mime4j-0.7-bin.tar.gz [PGP][MD5]
    • Binary (ZIP Format): apache-mime4j-0.6.1-bin.zip [PGP][MD5]
      • + href="[preferred]/james/mime4j/apache-mime4j-0.7-bin.zip">apache-mime4j-0.7-bin.zip [PGP][MD5]
    • Source (Unix TAR): apache-mime4j-0.6.1-src.tar.gz [PGP][MD5]
      • + href="[preferred]/james/mime4j/apache-mime4j-0.7-src.tar.gz">apache-mime4j-0.7-src.tar.gz [PGP][MD5]
    • Source (ZIP Format): apache-mime4j-0.6.1-src.zip [PGP][MD5]
      • + href="[preferred]/james/mime4j/apache-mime4j-0.7-src.zip">apache-mime4j-0.7-src.zip [PGP][MD5]
    • Binary (JAR library only): apache-mime4j-0.6.jar [PGP][MD5]
      • + href="http://www.apache.org/dist/james/mime4j/apache-mime4j-0.7.jar.asc">PGP][MD5]
    • Other Files (javadoc.jar, sha1 checksums...)
      • diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index cd1902ff717..8501535e814 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -378,6 +378,10 @@
    --> +
  • July/2011 - +
  • July/2011 - diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index bf9773bb36e..1eaf981ea81 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -18,6 +18,29 @@ +

    Apache James Mime4J 0.7

     +

    The Apache James Project is happy to announce + the release of version 0.7 of the Apache James Mime4J.

    +

    Mime4J is a flexible MIME parsing library written in Java. SAX, DOM and pull parsing styles are + supported.

    +

    The 0.7 release brings another round of API enhancements, bug fixes and performance optimizations. + A major effort has been put in code reorganization, separating parsing code from DOM manipulation + code. Mime4J has been restructured into three separate modules: 'core', 'dom' and 'storage'. + The 'core' package provides an event-driven SAX style parser that relies on a callback mechanism + to report parsing events such as the start of an entity header the start of a body, etc. + The 'dom' package contains base/abstract classes and interfaces for MIME-DOM manipulation aiming + to provide the base for a full featured traversable DOM. Per default the Mime4J DOM builder stores + content of individual body parts in memory. The 'storage' package provides support for more + complex storage backends such on-disk storage systems, overflow on max limit, or encrypted storage + through JSSE API.

    +

    Mime4J 0.7 improves support for headless messages, malformed separation between headers and body + and adds support for "obsolete" rfc822 syntax (e.g: "Header<somespace>: " style). Parsing + performance for quoted printable streams have been considerably improved. A "DecodeMonitor" object + has been introduced in most code to define how to deal with malformed input (Lenient vs Strict + behaviours). Mime4J 0.7 also provides LenientFieldParser as an alternative to DefaultFieldParser + when a higher degree of tolerance to non-severe MIME field format violations is desired.

    +

    Read the release notes.

    +

    Apache James jSPF 0.9.9

    The Apache James Project is happy to announce the release of version 0.9.9 of the Apache James jSPF which includes fixes related to OSGI.

    From 46a48b43c40ebaeb62637dabc5dc25bdb25b8005 Mon Sep 17 00:00:00 2001 From: norman Date: Mon, 25 Jul 2011 17:56:54 +0000 Subject: [PATCH 322/541] Correct mime4j release download url git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1150811 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 1f3584ef0a8..be3a4275806 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -278,20 +278,10 @@ is found here. href="http://www.apache.org/dist/james/mime4j/apache-mime4j-0.7-bin.zip.asc">PGP][MD5]
    • -
  • Source (Unix TAR): apache-mime4j-0.7-src.tar.gz [PGP][MD5]
    • -
  • Source (ZIP Format): apache-mime4j-0.7-src.zip [PGP][MD5]
    • - -
  • Binary (JAR library only): apache-mime4j-0.6.jar [PGP][MD5]
    • + href="[preferred]/james/mime4j/apache-mime4j-project-0.7-source-release.zip">apache-mime4j-0.7-src.zip [PGP][MD5]
  • Other Files (javadoc.jar, sha1 checksums...)
    • From 4c1b430cf8939b1a4252071bd6c0d91599064b6e Mon Sep 17 00:00:00 2001 From: bago Date: Fri, 29 Jul 2011 22:08:47 +0000 Subject: [PATCH 323/541] Update main James site to reflect jDKIM 0.2 release git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1152386 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 36 +++++++++++++++++++++++++++ project/src/site/xdoc/index.xml | 4 +++ project/src/site/xdoc/newsarchive.xml | 9 +++++++ 3 files changed, 49 insertions(+) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index be3a4275806..5bac0af144c 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -63,6 +63,7 @@ is found here.
  • Apache James Server
  • Apache James Mime4j
  • Apache James jSPF
    • +
  • Apache James jDKIM
  • Apache James JSieve
  • Apache James Mailet
  • Apache James Mailet Base
    • @@ -325,6 +326,41 @@ is found here.
    +
    + +

    Apache James jDKIM 0.2 is the latest jDKIM stable version:

    + + +
    +

    Apache JSieve 0.4 is the latest stable version:

    diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index 8501535e814..cd8f68dac78 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -378,6 +378,10 @@ --> +
  • July/2011 - +
  • July/2011 - diff --git a/project/src/site/xdoc/newsarchive.xml b/project/src/site/xdoc/newsarchive.xml index 1eaf981ea81..7b7ad1d860b 100644 --- a/project/src/site/xdoc/newsarchive.xml +++ b/project/src/site/xdoc/newsarchive.xml @@ -17,6 +17,15 @@ +

    Apache James jDKIM 0.2

     +

    The Apache James Project is happy to announce + the release of version 0.2 of the Apache James jDKIM library.

    +

    jDKIM is a DKIM implementation library written in Java. It provides + both verification and signing and also provides Mailets for the + Apache JAMES project.

    +

    This is the first official release of the library, but the code has + been in production almost unchanged since two years.

    +

    Read the release notes.

    Apache James Mime4J 0.7

    The Apache James Project is happy to announce From baedd75952a05df584e911346f5b385deb2b5f4c Mon Sep 17 00:00:00 2001 From: bago Date: Sat, 30 Jul 2011 13:24:45 +0000 Subject: [PATCH 324/541] fix jdkim download urls. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1152460 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/download.xml | 26 ++++++-------------------- 1 file changed, 6 insertions(+), 20 deletions(-) diff --git a/project/src/site/xdoc/download.xml b/project/src/site/xdoc/download.xml index 5bac0af144c..9f4ef78e61c 100644 --- a/project/src/site/xdoc/download.xml +++ b/project/src/site/xdoc/download.xml @@ -331,31 +331,17 @@ is found here.

    Apache James jDKIM 0.2 is the latest jDKIM stable version:

    From f970462f013a0bc6e0823ca54064264e424cdd13 Mon Sep 17 00:00:00 2001 From: eric Date: Sun, 7 Aug 2011 09:25:39 +0000 Subject: [PATCH 325/541] Update project web site for upcoming beta3 release. git-svn-id: https://svn.apache.org/repos/asf/james/project/trunk@1154679 13f79535-47bb-0310-9956-ffa450edef68 --- project/src/site/xdoc/index.xml | 2 +- project/src/site/xdoc/newsarchive.xml | 88 +++++++++++++-------------- 2 files changed, 45 insertions(+), 45 deletions(-) diff --git a/project/src/site/xdoc/index.xml b/project/src/site/xdoc/index.xml index cd8f68dac78..fdbb8461c77 100644 --- a/project/src/site/xdoc/index.xml +++ b/project/src/site/xdoc/index.xml @@ -374,7 +374,7 @@