Modified: james/server/trunk/src/site/xdoc/installation_instructions.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/xdoc/installation_instructions.xml?rev=1001446&r1=1001445&r2=1001446&view=diff ============================================================================== --- james/server/trunk/src/site/xdoc/installation_instructions.xml (original) +++ james/server/trunk/src/site/xdoc/installation_instructions.xml Sun Sep 26 15:13:45 2010 @@ -23,6 +23,95 @@ <title>James 3.0 - Installation</title> </properties> <body> + +<section name="Step 0: Building. (only necessary for daily snapshots)"> +<p> If you have downloaded a binary distribution, you do not need to build James. + Proceed directory to Step 1. </p> +<p> To compile James from the source code you need <a href="http://ant.apache.org/";>Ant</a>. + 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.</p> +<p> 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.</p> +<p>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.</p> +<p>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. </p> +<p> <strong>Warning!</strong> 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. </p> +</section> <section name="Step 1: Installation."> +<p> Download distibution. Extract or copy all the files in the archive or dist + directory intto your installation directory. </p> +</section> + +<section name="Step 2: Configuration."> + <p> + Read the short and snappy documentation at docs/index.html for a proper + overview of configuring the system. + </p> + <p> + <b>Summary</b> (for impatient people) + </p> + +<p> 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/</p> +<p> Running [run* --help] will provide a simple command line help. </p> + <p> + 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.) + </p> + +<p> 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. </p> +</section> + +<section name="Step 4: Kickstart."> + <p> + 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. + </p> + <p> + 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. + </p> + <p> + Good luck :) + </p> +</section> + + <section name="Requirements"> <p>James requires a Java Runtime Environment of Java version 1.4 or higher installed to run the James application. The exact JREs available depend on the platform. A JRE must be downloaded and @@ -102,4 +191,5 @@ will be fully operational. Instructions </section> </body> + </document>
Modified: james/server/trunk/src/site/xdoc/james_architecture.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/xdoc/james_architecture.xml?rev=1001446&r1=1001445&r2=1001446&view=diff ============================================================================== --- james/server/trunk/src/site/xdoc/james_architecture.xml (original) +++ james/server/trunk/src/site/xdoc/james_architecture.xml Sun Sep 26 15:13:45 2010 @@ -18,33 +18,48 @@ under the License. --> <document> + <properties> <title>Design Objectives</title> <author email="[email protected]">James Project Web Team</author> </properties> - <body> - <section name="Design Objectives"> + +<body> + + <section name="Architecture"> + + <p>James is a multi-protocol message processing and storage engine. James + currently consists of: + <ul> + <li>Two mail prototcol servers (SMTP and POP3),</li> + <li>a remote administration server,</li> + <!-- <li>an NNTP server,</li>--> + <li>a mail processing engine that supports the Mailet API</li> + <li>file-system message storage and a message storage interface to RDBMS's</li> + <li>file-system user record storage and an experimental interface to LDAP directories</li> + <li>support for TLS (SSL) for POP3 and remote administration</li> + <li>support for SMTP auth</li> + </ul> + </p> + + <p>James is deployed on top of Spring.</p> + + + </section> + + <section name="Design Objectives"> + + <subsection name="Features"> - <subsection name="features"> <p>These are some of the currently implemented features:</p> - <p> - <i> - <b>Complete portability</b> - </i> Apache James is be a 100% pure Java application - based on the Java 2 platform and the JavaMail 1.4 API. - </p> - <p> - <i> - <b>Protocol abstraction</b> - </i> Unlike other mail engines, protocols are seen only + <p><i><b>Complete portability</b></i> Apache James is be a 100% pure Java application + based on the Java 2 platform and the JavaMail 1.4 API.</p> + <p><i><b>Protocol abstraction</b></i> 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)</p> - <p> - <i> - <b>Complete solution</b> - </i> the mail system is able to handle both mail + <p><i><b>Complete solution</b></i> 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.</p> <p> @@ -74,49 +89,44 @@ scalability and mission-critical use.</p> <p>Anything else you may want if you help us write it :-)</p> </subsection> - <subsection name="standards compliance"> + <subsection name="Standards compliance"> <p>It is the existence of published "open" standards which -allows independant teams to develop interoperable software. -<br/>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. -<br/>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. -<br/>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. - </p> - <p>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. - </p> - <p> -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. -</p> - <p> -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. -</p> - <p> -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 <i>internet draft</i> RFC but not yet subject of a <i>standards track</i> RFC) it is -acceptable to implement the behaviour so long as it is adequately -documented (for instance by refrence to an <i>internet draft</i> or -other public document) and users can be clear about what to expect from James. -</p> + allows independant teams to develop interoperable software. + <br/>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. + <br/>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. + <br/>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.</p> + <p>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.</p> + <p>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.</p> + <p>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.</p> + <p>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 <i>internet draft</i> RFC but not yet subject of a <i>standards track</i> RFC) it is + acceptable to implement the behaviour so long as it is adequately + documented (for instance by refrence to an <i>internet draft</i> or + other public document) and users can be clear about what to expect from James.</p> </subsection> - </section> - </body> + + </section> + +</body> + </document> Added: james/server/trunk/src/site/xdoc/mailstores_configuration.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/xdoc/mailstores_configuration.xml?rev=1001446&view=auto ============================================================================== --- james/server/trunk/src/site/xdoc/mailstores_configuration.xml (added) +++ james/server/trunk/src/site/xdoc/mailstores_configuration.xml Sun Sep 26 15:13:45 2010 @@ -0,0 +1,31 @@ +<?xml version="1.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. +--> +<document> + + <properties> + <title>Mail Store Configuration</title> + </properties> + +<body> +<section name="Mail Store Configuration"> + +</section> +</body> +</document> Added: james/server/trunk/src/site/xdoc/protocols.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/xdoc/protocols.xml?rev=1001446&view=auto ============================================================================== --- james/server/trunk/src/site/xdoc/protocols.xml (added) +++ james/server/trunk/src/site/xdoc/protocols.xml Sun Sep 26 15:13:45 2010 @@ -0,0 +1,31 @@ +<?xml version="1.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. +--> +<document> + + <properties> + <title>Protocols</title> + </properties> + +<body> +<section name="Protocols"> + +</section> +</body> +</document> Modified: james/server/trunk/src/site/xdoc/stylesheet.css URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/xdoc/stylesheet.css?rev=1001446&r1=1001445&r2=1001446&view=diff ============================================================================== --- james/server/trunk/src/site/xdoc/stylesheet.css (original) +++ james/server/trunk/src/site/xdoc/stylesheet.css Sun Sep 26 15:13:45 2010 @@ -3,122 +3,122 @@ td { font-family: Verdana, Arial, Helve strong { font-weight: bold;} p { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 90% } a { - font-family: Verdana, Arial, Helvetica, sans-serif; - font-size: 90%; + font-family: Verdana, Arial, Helvetica, sans-serif; + font-size: 90%; } h3 { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 100% } li { - font-family: Verdana, Arial, Helvetica, sans-serif; - font-size: 90%; + font-family: Verdana, Arial, Helvetica, sans-serif; + font-size: 90%; } table { border-style: none} td { border-style: none} .section-header { - border: thin solid #525D76; - background-color: #525D76; - color: #FFFFFF; + border: thin solid #525D76; + background-color: #525D76; + color: #FFFFFF; } .subsection-header { - border: thin solid #828DA6; - color: #FFFFFF; - background-color: #828DA6; + border: thin solid #828DA6; + color: #FFFFFF; + background-color: #828DA6; } .source { - left: 4em; - border: 1px solid #000066; - white-space: pre; - font-family: "Courier New", Courier, mono; - padding: 0ex 2ex 2ex 2ex; - margin: 0ex; + left: 4em; + border: 1px solid #000066; + white-space: pre; + font-family: "Courier New", Courier, mono; + padding: 0ex 2ex 2ex 2ex; + margin: 0ex; } .left-navbar { - padding-right: 1ex; - padding-left: 1ex; - border-top: 1px none #CCCCCC; - border-right: 1px none #CCCCCC; - border-bottom: 1px none #CCCCCC; - border-left: 1px none #CCCCCC; + padding-right: 1ex; + padding-left: 1ex; + border-top: 1px none #CCCCCC; + border-right: 1px none #CCCCCC; + border-bottom: 1px none #CCCCCC; + border-left: 1px none #CCCCCC; } li a { - font-family: Verdana, Arial, Helvetica, sans-serif; - font-size: 90%; + font-family: Verdana, Arial, Helvetica, sans-serif; + font-size: 90%; color: #333333; } p a { - font-family: Verdana, Arial, Helvetica, sans-serif; - font-size: 90%; + font-family: Verdana, Arial, Helvetica, sans-serif; + font-size: 90%; color: #333333; } .right-navbar { - padding-left: 1ex; - padding-right: 1ex; - border-top: 1px none #CCCCCC; - border-right: 1px none #CCCCCC; - border-bottom: 1px none #CCCCCC; - border-left: 1px none #CCCCCC; + padding-left: 1ex; + padding-right: 1ex; + border-top: 1px none #CCCCCC; + border-right: 1px none #CCCCCC; + border-bottom: 1px none #CCCCCC; + border-left: 1px none #CCCCCC; } ul { - list-style-position: inside; - margin: 0em 0em 0em 0px; - padding: 0em 0em 0em 0px; - list-style-type: square; + list-style-position: inside; + margin: 0em 0em 0em 0px; + padding: 0em 0em 0em 0px; + list-style-type: square; } .section-body { - padding-left: 1em; - margin-bottom: 1em; - border-top-width: 1px; - border-right-width: 1px; - border-bottom-width: 1px; - border-left-width: 1px; - border-top-style: none; - border-right-style: solid; - border-bottom-style: none; - border-left-style: solid; - border-top-color: #CCCCCC; - border-right-color: #CCCCCC; - border-bottom-color: #CCCCCC; - border-left-color: #CCCCCC; - padding-right: 1ex; - text-align: justify; + padding-left: 1em; + margin-bottom: 1em; + border-top-width: 1px; + border-right-width: 1px; + border-bottom-width: 1px; + border-left-width: 1px; + border-top-style: none; + border-right-style: solid; + border-bottom-style: none; + border-left-style: solid; + border-top-color: #CCCCCC; + border-right-color: #CCCCCC; + border-bottom-color: #CCCCCC; + border-left-color: #CCCCCC; + padding-right: 1ex; + text-align: justify; } .subsection-body { - padding-left: 1em; - margin-bottom: 1em; - border-top-width: 1px; - border-right-width: 1px; - border-bottom-width: 1px; - border-left-width: 1px; - border-top-style: none; - border-right-style: none; - border-bottom-style: none; - border-left-style: none; - border-top-color: #CCCCCC; - border-right-color: #CCCCCC; - border-bottom-color: #CCCCCC; - border-left-color: #CCCCCC; - text-align: justify; + padding-left: 1em; + margin-bottom: 1em; + border-top-width: 1px; + border-right-width: 1px; + border-bottom-width: 1px; + border-left-width: 1px; + border-top-style: none; + border-right-style: none; + border-bottom-style: none; + border-left-style: none; + border-top-color: #CCCCCC; + border-right-color: #CCCCCC; + border-bottom-color: #CCCCCC; + border-left-color: #CCCCCC; + text-align: justify; @@ -126,26 +126,26 @@ ul { pre { - left: 4em; - border: 1px solid #000066; - white-space: pre; - font-family: "Courier New", Courier, mono; - padding: 0ex 2ex 2ex 2ex; - margin: 0ex; + left: 4em; + border: 1px solid #000066; + white-space: pre; + font-family: "Courier New", Courier, mono; + padding: 0ex 2ex 2ex 2ex; + margin: 0ex; } .detail-table-header { - font-weight: bold; - color: #FFFFFF; - background-color: #666666; - vertical-align: text-bottom; - text-align: center; + font-weight: bold; + color: #FFFFFF; + background-color: #666666; + vertical-align: text-bottom; + text-align: center; } .detail-table-content { - border: 1px solid #CCCCCC; - font-family: Verdana; - font-size: 90%; - margin: 2px; - padding: 0px 4px; + border: 1px solid #CCCCCC; + font-family: Verdana; + font-size: 90%; + margin: 2px; + padding: 0px 4px; Modified: james/server/trunk/src/site/xdoc/summary.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/xdoc/summary.xml?rev=1001446&r1=1001445&r2=1001446&view=diff ============================================================================== --- james/server/trunk/src/site/xdoc/summary.xml (original) +++ james/server/trunk/src/site/xdoc/summary.xml Sun Sep 26 15:13:45 2010 @@ -25,92 +25,91 @@ <body> -<section name="The James Server"> - -<p>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.</p> - -<p>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.</p> - -<p>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.</p> - -</section> -<section name="POP3 Service"> - -<p>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.</p> - -<p>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.</p> - -<p>More information on configuring the POP3 service can be found <a href="pop3_configuration.html">here</a>.</p> - -</section> -<section name="SMTP Service"> - -<p>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.</p> - -<p>More information on configuring the SMTP service can be found <a href="smtp_configuration.html">here</a>.</p> - -</section> -<section name="NNTP Service"> - -<p>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.</p> - -<p>More information on configuring the NNTP service can be found <a href="nntp_configuration.html">here</a>.</p> - -</section> -<section name="FetchMail"> - -<p>FetchMail, 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.</p> - -<p>More information on configuring FetchMail can be found <a href="fetchmail_configuration.html">here</a>.</p> -</section> -<section name="The SpoolManager, Matchers, and Mailets"> - -<p>James separates the services that deliver mail to James (i.e. SMTP, FetchMail) -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.</p> - -<p>More on the structure of the SpoolManager and the Mailet API can be found <a href="spoolmanager.html">here</a>.</p> - -</section> -<section name="Repositories"> - -<p>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.</p> - -</section> -<section name="RemoteManager"> - -<p>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.</p> - -<p>More on the configuring the RemoteManager can be found <a href="remotemanager_configuration.html">here</a>.</p> - -</section> + <section name="The James Server"> + + <p>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.</p> + + <p>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.</p> + + <p>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.</p> + + <subsection name="POP3 Service"> + + <p>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.</p> + + <p>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.</p> + + <p>More information on configuring the POP3 service can be found <a href="pop3_configuration.html">here</a>.</p> + + </subsection> + + <subsection name="SMTP Service"> + + <p>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.</p> + + <p>More information on configuring the SMTP service can be found <a href="smtp_configuration.html">here</a>.</p> + + </subsection> + + <subsection name="FetchMail"> + + <p>FetchMail, 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.</p> + + <p>More information on configuring FetchMail can be found <a href="fetchmail_configuration.html">here</a>.</p> + + </subsection> + + <subsection name="The SpoolManager, Matchers, and Mailets"> + + <p>James separates the services that deliver mail to James (i.e. SMTP, FetchMail) + 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.</p> + + <p>More on the structure of the SpoolManager and the Mailet API can be found <a href="spoolmanager.html">here</a>.</p> + + </subsection> + + <subsection name="Repositories"> + + <p>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.</p> + + </subsection> + + <subsection name="RemoteManager"> + + <p>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.</p> + + <p>More on the configuring the RemoteManager can be found <a href="remotemanager_configuration.html">here</a>.</p> + + </subsection> + + </section> + </body> + </document> Modified: james/server/trunk/src/site/xdoc/upgrade_instructions.xml URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/xdoc/upgrade_instructions.xml?rev=1001446&r1=1001445&r2=1001446&view=diff ============================================================================== --- james/server/trunk/src/site/xdoc/upgrade_instructions.xml (original) +++ james/server/trunk/src/site/xdoc/upgrade_instructions.xml Sun Sep 26 15:13:45 2010 @@ -22,92 +22,51 @@ <properties> <title>James 3.0 - Upgrading</title> </properties> + <body> -<section name="Upgrading Comments"> -<p>James upgrading 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.</p> -<p>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.</p> -<p>So the Upgrading sequence is: <b>1) Start, 2) Stop, 3) Move 4) Edit, 5) Restart</b>.</p> -</section> -<section name="Copy mailboxes and users"> -<subsection name="Copy mailboxes and users"> -<p>Remove the apps/james/var directory and copy the apps/james/var directory of the old james -installation in this place.</p> -</subsection> -</section> -<section name="Copy and modify config.xml"> -<subsection name="Remove the fetchpop block"> -<p>It's necessary to remove the fetchpop block in config.xml because fetchpop was removed in 3.0.</p> -</subsection> -<subsection name="Move mailet and matcher packages config"> -<p>Move <mailetpackages> and <matcherpackages> outside of the <spoolmanager> block.</p> -</subsection> -<subsection name="Add necessary mailets"> -<p>Add the following line as the first mailet of the "root" processor:</p> -<source> -<mailet match="All" class="PostmasterAlias"/> -</source> -<p>This was hardcoded in 2.2.0 and previous. Now we made it configurable.</p> -</subsection> -<subsection name="Move the spoolrepository config"> -<p>Move the spoolrepository out of the mailstore. Its also necessary to change the config syntax. For example:</p> -<source> -<spoolRepository> - <repository destinationURL="db://maildb/spool/spool" type="SPOOL"/> -</spoolRepository> -</source> -Must converted to -<source> -<spoolrepository destinationURL="db://maildb/spool/spool" type="SPOOL"/> -</source> -</subsection> -<subsection name="Move the objectstore"> -<p>Move the objectstore config into the mailstore config.</p> -</subsection> -<subsection name="Add SSL to server-sockets"> -<p> To be able to use SSL you need to add this SSL config to the server-sockets block:</p> -<source> -<!-- -<factory name="ssl" class="org.apache.avalon.cornerstone.blocks.sockets.TLSServerSocketFactory"> - <ssl-factory> - <keystore> - <file>conf/keystore/</file> - <password>secret</password> - <key-password>keysecret</key-password> - <type>JKS</type> - <protocol>TLS</protocol> - <algorithm>SunX509</algorithm> - <authenticate-client>false</authenticate-client> - </keystore> - </ssl-factory> -</factory> ---> -</source> -</subsection> -</section> -<section name="Modify costum mailets if necessary"> -<p> Please note the following things that were changed. So maybe it's necessary for you to change some stuff in your mailets. </p> -<subsection name="Avalon updates"> -<ul> -<li>avalon Component has been replaced by avalon Service</li> -<li>avalon Composable has been replaced by avalon Serviceable</li> -<li>avalon ComponentManager has been replaced by avalon ServiceManager</li> -</ul> -</subsection> -<subsection name="Cornerstone updates"> -<ul> -<li>MailStore interface has been removed: mailets looking up the MailStore should now lookup -a Store (org.apache.avalon.cornerstone.services.store.Store)</li> -</ul> -</subsection> -</section> -<section name="Start James"> -<p> Now you should be able to start james without problems.</p> -</section> + <section name="Upgrading Comments"> + <p>James upgrading 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.</p> + <p>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.</p> + <p>So the Upgrading sequence is: <b>1) Start, 2) Stop, 3) Move 4) Edit, 5) Restart</b>.</p> + </section> + + <section name="Copy mailboxes and users"> + <subsection name="Copy mailboxes and users"> + </subsection> + </section> + + <section name="Copy and modify config.xml"> + <subsection name="Remove the fetchpop block"> + </subsection> + <subsection name="Move mailet and matcher packages config"> + </subsection> + <subsection name="Add necessary mailets"> + </subsection> + <subsection name="Move the spoolrepository config"> + </subsection> + <subsection name="Move the objectstore"> + </subsection> + <subsection name="Add SSL to server-sockets"> + </subsection> + </section> + + <section name="Modify costum mailets if necessary"> + <p>Please note the following things that were changed. So maybe it's necessary for you to change some stuff in your mailets. </p> + <subsection name="Avalon updates"> + </subsection> + <subsection name="Cornerstone updates"> + </subsection> + </section> + <section name="Start James"> + <p> Now you should be able to start james without problems.</p> + </section> + </body> + </document> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
