summaryrefslogtreecommitdiff
path: root/Architecture_and_Design
diff options
context:
space:
mode:
authorJeroen van Meeuwen (Kolab Systems) <vanmeeuwen@kolabsys.com>2011-06-28 11:14:47 (GMT)
committerJeroen van Meeuwen (Kolab Systems) <vanmeeuwen@kolabsys.com>2011-06-28 11:14:47 (GMT)
commitc4ab9b08eb8fb8786db961749eb56533a59867ef (patch)
tree178a75de3d931a0927d71746c21d88d6dd9bc52c /Architecture_and_Design
parentd6458a079273f523a66eb46f7c72333c421f574f (diff)
downloadkolab-docs-c4ab9b08eb8fb8786db961749eb56533a59867ef.tar.gz
Add the Architecture and Design document
Diffstat (limited to 'Architecture_and_Design')
-rw-r--r--Architecture_and_Design/Makefile24
-rw-r--r--Architecture_and_Design/en-US/.Terminology.xml.kate-swpbin0 -> 223 bytes
-rw-r--r--Architecture_and_Design/en-US/Administration_Panel.xml128
-rw-r--r--Architecture_and_Design/en-US/Architecture_and_Design.ent4
-rw-r--r--Architecture_and_Design/en-US/Architecture_and_Design.xml26
-rw-r--r--Architecture_and_Design/en-US/Archiving_amp_Discovery.xml79
-rw-r--r--Architecture_and_Design/en-US/Authentication_amp_Authorization.xml333
-rw-r--r--Architecture_and_Design/en-US/Book_Info.xml30
-rw-r--r--Architecture_and_Design/en-US/Calendaring.xml12
-rw-r--r--Architecture_and_Design/en-US/Configuration_Management.xml36
-rw-r--r--Architecture_and_Design/en-US/Email.xml337
-rw-r--r--Architecture_and_Design/en-US/Groupware_Overview.xml285
-rw-r--r--Architecture_and_Design/en-US/Integration_amp_Interoperability.xml93
-rw-r--r--Architecture_and_Design/en-US/Kolab_Daemon.xml12
-rw-r--r--Architecture_and_Design/en-US/Kolab_Objects.xml342
-rw-r--r--Architecture_and_Design/en-US/Kolab_Server_Overview.xml273
-rw-r--r--Architecture_and_Design/en-US/Migration.xml12
-rw-r--r--Architecture_and_Design/en-US/Mobile_Device_Synchronization.xml29
-rw-r--r--Architecture_and_Design/en-US/Preface.xml11
-rw-r--r--Architecture_and_Design/en-US/Revision_History.xml33
-rw-r--r--Architecture_and_Design/en-US/Smart_Clients.xml219
-rw-r--r--Architecture_and_Design/en-US/Terminology.xml294
-rw-r--r--Architecture_and_Design/publican.cfg8
23 files changed, 2620 insertions, 0 deletions
diff --git a/Architecture_and_Design/Makefile b/Architecture_and_Design/Makefile
new file mode 100644
index 0000000..b71dc53
--- /dev/null
+++ b/Architecture_and_Design/Makefile
@@ -0,0 +1,24 @@
+PACKAGE = "Architecture_and_Design"
+
+all: clean clean_ids
+ @publican build --langs=en-US --formats=pdf,html,html-single
+
+upload: all
+ @rsync -aHvz tmp/en-US/{html,html-single,pdf} hosted.kolabsys.com:./public_html/kolab-2.3-docs/$(PACKAGE)/
+
+clean:
+ @publican clean
+
+clean_ids:
+ @cp -a ../Common_Content/en-US/*.xml en-US/.
+ @cp -a ../Common_Content/en-US/images/*.png en-US/images/.
+ @publican clean_ids
+ @sed -i -r \
+ -e 's/\t/ /g' \
+ -e 's/((\s{4})+)\s*/\1/g' \
+ -e 's/\s*$$//g' \
+ `find en-US/ -type f -name "*.xml"`
+
+# Additional quick build targets
+pdf:
+ @publican build --langs=en-US --formats=pdf
diff --git a/Architecture_and_Design/en-US/.Terminology.xml.kate-swp b/Architecture_and_Design/en-US/.Terminology.xml.kate-swp
new file mode 100644
index 0000000..1e4e988
--- /dev/null
+++ b/Architecture_and_Design/en-US/.Terminology.xml.kate-swp
Binary files differ
diff --git a/Architecture_and_Design/en-US/Administration_Panel.xml b/Architecture_and_Design/en-US/Administration_Panel.xml
new file mode 100644
index 0000000..8570ae1
--- /dev/null
+++ b/Architecture_and_Design/en-US/Administration_Panel.xml
@@ -0,0 +1,128 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Administration_Panel">
+ <title>Administration Panel</title>
+ <para>
+ TODO
+ </para>
+ <para>
+ The Kolab Groupware administration panel, a web interface to Kolab Groupware available for administrative purposes, will provide the functionality listed in this chapter.
+ </para>
+ <section id="sect-Architecture_and_Design-Administration_Panel-Configuration">
+ <title>Configuration</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Configuration of the <xref linkend="form-Architecture_and_Design-Terminology-Kolab_Groupware_Primary_Domain" />
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Configuration of the Kolab Groupware Administration Security Group
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Configuration of Kolab Groupware Delegation Security Groups
+ </para>
+ <para>
+ Including the assignment of privileges delegated to delegation security groups, including;
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Reset Password
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Create User, if applicable
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Disable User, if applicable
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ (Re-)enable User, if applicable
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Alter user attributes (common name, display name, surname), if applicable
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Create, modify and/or delete distribution lists and/or security groups, if applicable
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Create, modify and/or delete contact lists, if applicable
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Create, modify and/or delete contacts, if applicable
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Review logfiles, if applicable.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Create, modify and/or delete domain aliases and/or domains
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Manage domain administrator groups
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Administration_Panel-Deployment">
+ <title>Deployment</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Architecture_and_Design.ent b/Architecture_and_Design/en-US/Architecture_and_Design.ent
new file mode 100644
index 0000000..3691c08
--- /dev/null
+++ b/Architecture_and_Design/en-US/Architecture_and_Design.ent
@@ -0,0 +1,4 @@
+<!ENTITY PRODUCT "Kolab">
+<!ENTITY BOOKID "Architecture_and_Design">
+<!ENTITY YEAR "2011">
+<!ENTITY HOLDER "Kolab Systems AG">
diff --git a/Architecture_and_Design/en-US/Architecture_and_Design.xml b/Architecture_and_Design/en-US/Architecture_and_Design.xml
new file mode 100644
index 0000000..72696f3
--- /dev/null
+++ b/Architecture_and_Design/en-US/Architecture_and_Design.xml
@@ -0,0 +1,26 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<book status="draft">
+ <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Groupware_Overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Kolab_Server_Overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Email.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Calendaring.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Kolab_Daemon.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Kolab_Objects.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Authentication_amp_Authorization.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Integration_amp_Interoperability.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Configuration_Management.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Archiving_amp_Discovery.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Smart_Clients.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Mobile_Device_Synchronization.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Administration_Panel.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Migration.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Terminology.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <index />
+</book>
+
diff --git a/Architecture_and_Design/en-US/Archiving_amp_Discovery.xml b/Architecture_and_Design/en-US/Archiving_amp_Discovery.xml
new file mode 100644
index 0000000..17dee85
--- /dev/null
+++ b/Architecture_and_Design/en-US/Archiving_amp_Discovery.xml
@@ -0,0 +1,79 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Archiving_amp_Discovery">
+ <title>Archiving &amp; Discovery</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-Archiving_amp_Discovery-Methodologies_for_Archiving">
+ <title>Methodologies for Archiving</title>
+ <section id="sect-Architecture_and_Design-Methodologies_for_Archiving-Blind_Carbon_Copy">
+ <title>Blind Carbon Copy</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-Blind_Carbon_Copy-Deduplication_with_Suppress_Duplicate_Delivery">
+ <title>Deduplication with Suppress Duplicate Delivery</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Methodologies_for_Archiving-Save_to_Archive">
+ <title>Save to Archive</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Methodologies_for_Archiving-IMAP_Server_Replica_Client">
+ <title>IMAP Server Replica Client</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Methodologies_for_Archiving-Backup_with_Delayed_Delete_and_Expunge">
+ <title>Backup with Delayed Delete and Expunge</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Archiving_amp_Discovery-Methodologies_for_Discovery">
+ <title>Methodologies for Discovery</title>
+ <section id="sect-Architecture_and_Design-Methodologies_for_Discovery-Analysis_of_the_Telemetry_Log">
+ <title>Analysis of the Telemetry Log</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Methodologies_for_Discovery-IMAP_Server_Replica_Client">
+ <title>IMAP Server Replica Client</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+ </section>
+
+
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Authentication_amp_Authorization.xml b/Architecture_and_Design/en-US/Authentication_amp_Authorization.xml
new file mode 100644
index 0000000..c36164e
--- /dev/null
+++ b/Architecture_and_Design/en-US/Authentication_amp_Authorization.xml
@@ -0,0 +1,333 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Authentication_amp_Authorization">
+ <title>Authentication &amp; Authorization</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-Authentication_amp_Authorization-LDAP">
+ <title>LDAP</title>
+ <para>
+ LDAP technologies typically contain a one-way hashed password in the <literal>userPassword</literal> attribute of the corresponding LDAP object. Authentication MAY be performed using any attribute that is globally unique, such as;
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ the <literal>uid</literal> attribute,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ the <xref linkend="form-Architecture_and_Design-Terminology-Naming_Attribute" /> if enforced to be globally unique or used with search scope ONE,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ any other attribute that is <emphasis>assumed</emphasis> and/or <emphasis>enforced</emphasis> to be globally unique and/or unique within the search scope.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <section id="sect-Architecture_and_Design-LDAP-Username_amp_Password_Authentication">
+ <title>Username &amp; Password Authentication</title>
+ <para>
+ The authentication routine against LDAP, when using a username and password, typically is;
+ </para>
+ <procedure id="proc-Architecture_and_Design-Username_amp_Password_Authentication-LDAP_Authentication_with_Username_amp_Password">
+ <title>LDAP Authentication with Username &amp; Password</title>
+ <step>
+ <para>
+ The client supplies its <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Credentials" /> in the form of an <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Username" /> and an <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Password" />.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Dependent on the server-side settings, as well as the content of the <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Credentials" /> supplied, the server could be configured to, amongst other things;
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ include a configured <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Realm" />,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ derive the <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Domain" /> and/or <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Realm" /> from the <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Username" /> included,
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </step>
+ <step>
+ <para>
+ The server issues an <xref linkend="form-Architecture_and_Design-Terminology-Mailfolder" /> LDAP for the LDAP object using the configured <xref linkend="form-Architecture_and_Design-Terminology-Base_DN" />, <xref linkend="form-Architecture_and_Design-Terminology-Search_Scope" /> and <xref linkend="form-Architecture_and_Design-Terminology-Search_Filter" />, and using the <xref linkend="form-Architecture_and_Design-Terminology-Distinguished_Name" /> of the LDAP object found, attempts to either <code>bind()</code> or <code>fast_bind()</code> using the distinguished name and the supplied <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Password" />.
+ </para>
+
+ </step>
+
+ </procedure>
+
+ <warning>
+ <title>TODO</title>
+ <para>
+ Address fully qualified vs. unqualified, uid/mail, domain/realm. Also refer to auth mechanisms and ldap server side requirements.
+ </para>
+
+ </warning>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-LDAP-Kerberos_Authentication">
+ <title>Kerberos Authentication</title>
+ <para>
+ TODO - since kerberos is an identity exchange protocol, and not a hmmm list of users and groups for kolab to consume, ...
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-LDAP-SSL_Certificate_Authentication">
+ <title>SSL Certificate Authentication</title>
+ <para>
+ TODO - since ssl infrastructure does not provide lists nor group authorization capabilities, kolab must have
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-LDAP-Kolab_amp_LDAP">
+ <title>Kolab &amp; LDAP</title>
+ <para>
+ TODO: for more information please see the integration part of this document.
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Authentication_amp_Authorization-PAM">
+ <title>PAM</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-PAM-Username_amp_Password_Authentication">
+ <title>Username &amp; Password Authentication</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-PAM-One_Time_Passwords">
+ <title>One-Time Passwords</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-PAM-Kerberos_Authentication">
+ <title>Kerberos Authentication</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-PAM-SSL_Certificate_Authentication">
+ <title>SSL Certificate Authentication</title>
+ <para>
+ TODO - don't forget revocation lists - don't do this one
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-PAM-Kolab_amp_PAM">
+ <title>Kolab &amp; PAM</title>
+ <para>
+ TODO - getent gives listings
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Authentication_amp_Authorization-SASL_Database">
+ <title>SASL Database</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-SASL_Database-Username_amp_Password_Authentication">
+ <title>Username &amp; Password Authentication</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-SASL_Database-Kerberos_Authentication">
+ <title>Kerberos Authentication</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-SASL_Database-SSL_Certificate_Authentication">
+ <title>SSL Certificate Authentication</title>
+ <para>
+ TODO - don't forget revocation lists
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-SASL_Database-Kolab_amp_SASL_Database">
+ <title>Kolab &amp; SASL Database</title>
+ <para>
+ TODO: for more information please see the integration part of this document.
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Authentication_amp_Authorization-SQL">
+ <title>SQL</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-SQL-SQL_Technologies">
+ <title>SQL Technologies</title>
+ <para>
+ sqlite, mysql, postgres, ...
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-SQL-Username_amp_Password_Authentication">
+ <title>Username &amp; Password Authentication</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-SQL-Kerberos_Authentication">
+ <title>Kerberos Authentication</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-SQL-SSL_Certificate_Authentication">
+ <title>SSL Certificate Authentication</title>
+ <para>
+ TODO - don't forget revocation lists
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-SQL-Kolab_amp_SQL">
+ <title>Kolab &amp; SQL</title>
+ <para>
+ TODO: for more information please see the integration part of this document.
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Authentication_amp_Authorization-Password_Supplements_amp_Security">
+ <title>Password Supplements &amp; Security</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-Password_Supplements_amp_Security-Simple_Authentication_Security_Layer">
+ <title>Simple Authentication Security Layer</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-Simple_Authentication_Security_Layer-PLAIN_LOGIN_SASL_Mechanism">
+ <title>PLAIN / LOGIN SASL Mechanism</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Simple_Authentication_Security_Layer-CRAM_MD5_SASL_Mechanism">
+ <title>CRAM-MD5 SASL Mechanism</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Simple_Authentication_Security_Layer-DIGEST_MD5_SASL_Mechanism">
+ <title>DIGEST-MD5 SASL Mechanism</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Simple_Authentication_Security_Layer-GSSAPI_SASL_Mechanism">
+ <title>GSSAPI SASL Mechanism</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Simple_Authentication_Security_Layer-HOTP_SASL_Mechanism">
+ <title>(H)OTP SASL Mechanism</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Password_Supplements_amp_Security-No_plain_text_over_the_wire">
+ <title>"No plain text over the wire"</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Authentication_amp_Authorization-Authorization_Through_Groups">
+ <title>Authorization Through Groups</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Book_Info.xml b/Architecture_and_Design/en-US/Book_Info.xml
new file mode 100644
index 0000000..4cea8da
--- /dev/null
+++ b/Architecture_and_Design/en-US/Book_Info.xml
@@ -0,0 +1,30 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE bookinfo PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<bookinfo id="book-Architecture_and_Design-Architecture_and_Design">
+ <title>Architecture and Design</title>
+ <productname>Kolab</productname>
+ <productnumber>3.0</productnumber>
+ <edition>0</edition>
+ <pubsnumber>0</pubsnumber>
+ <abstract>
+ <para>
+ This document is the reference to version 3.0 of the Kolab Groupware Solution architecture and design considerations, specifications and implementation details.
+ </para>
+
+ </abstract>
+ <corpauthor>
+ <inlinemediaobject>
+ <imageobject>
+ <imagedata fileref="images/title_logo.png" format="PNG" />
+ </imageobject>
+
+ </inlinemediaobject>
+
+ </corpauthor>
+ <xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+</bookinfo>
+
diff --git a/Architecture_and_Design/en-US/Calendaring.xml b/Architecture_and_Design/en-US/Calendaring.xml
new file mode 100644
index 0000000..cab6e37
--- /dev/null
+++ b/Architecture_and_Design/en-US/Calendaring.xml
@@ -0,0 +1,12 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Calendaring">
+ <title>Calendaring</title>
+ <para>
+ This chapter addresses the calendaring aspects of the Kolab Groupware Solution.
+ </para>
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Configuration_Management.xml b/Architecture_and_Design/en-US/Configuration_Management.xml
new file mode 100644
index 0000000..4ad714c
--- /dev/null
+++ b/Architecture_and_Design/en-US/Configuration_Management.xml
@@ -0,0 +1,36 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Configuration_Management">
+ <title>Configuration Management</title>
+ <para>
+ TODO - also refer to integration
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Puppet
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Chef
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ CFEngine
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Email.xml b/Architecture_and_Design/en-US/Email.xml
new file mode 100644
index 0000000..a333b83
--- /dev/null
+++ b/Architecture_and_Design/en-US/Email.xml
@@ -0,0 +1,337 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Email">
+ <title>Email</title>
+ <para>
+ This chapter addresses the email aspects of the Kolab Groupware Solution.
+ </para>
+ <section id="sect-Architecture_and_Design-Email-Content_filtering">
+ <title>Content-filtering</title>
+ <para>
+ Content-filtering is usually performed as close to the outer edge of the corporate network as possible. In reality, content-filtering is typically implemented on any or all of the following mail exchanger types, in order of likelihood;
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Receiving <xref linkend="form-Architecture_and_Design-Terminology-External_Mail_Exchanger" />,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Sending <xref linkend="form-Architecture_and_Design-Terminology-External_Mail_Exchanger" />,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <xref linkend="form-Architecture_and_Design-Terminology-Internal_Mail_Exchanger" />,
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <para>
+ Address content-filtering (where, when, what, enhance, control, audit, report, account).
+ </para>
+ <para>
+ <itemizedlist id="item-Architecture_and_Design-Content_filtering-Available_Technologies">
+ <title>Available Technologies</title>
+ <listitem>
+ <para>
+ Amavisd
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ ClamAV
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ ClamAV Milter
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Greylisting
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Postfix' postscreen (version 2.8 and later)
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Spamassassin
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Spamassassin Milter
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ 3rd party appliances
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <section id="sect-Architecture_and_Design-Content_filtering-Recipient_Checking">
+ <title>Recipient Checking</title>
+ <para>
+ As far as content-filtering is concerned, recipient address checking &ndash;verifying whether or not the recipient address exists in any of the groupware environments&ndash; is typically triggered as one of the first content-filtering defense mechanisms on an <xref linkend="form-Architecture_and_Design-Terminology-External_Mail_Exchanger" /> &mdash;usually only those external mail exchangers of type <xref linkend="form-Architecture_and_Design-External_Mail_Exchanger_Types-Receiving" />.
+ </para>
+ <para>
+ By implementing recipient address checking as a defense mechanism too early, however, an organization exposes itself to recognaisance attacks; an attacker could, relatively quickly, discover which recipient addresses do and which do not exist.
+ </para>
+ <para>
+ There is a significant trade-off to implementing recipient address checking too late, however. All email could have to go through (and pass) the relatively processing intensive anti-spam and anti-virus content filters, offering an attacker opportunity to successfully execute Denial-of-Service attacks.
+ </para>
+ <para>
+ It is therefor strongly recommended to implement other defense mechanisms before recipient address checking is performed, such as blacklisting, greylisting, real-time DNS blacklisting and sender address and domain name space verification, and to implement recipient address checking before anti-spam and anti-virus content filtering.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Content_filtering-Anti_Spam">
+ <title>Anti-Spam</title>
+ <para>
+ When Kolab Groupware is configured to be responsible for anti-spam content filtering measures &ndash;the default&ndash; it will choose to use Apache's SpamAssassin software to do so.
+ </para>
+ <para>
+ Integration with SpamAssassin comes in different shapes and forms, depending on the technology used and the options chosen.
+ </para>
+ <para>
+ For example, anti-spam content filtering can be implemented inline, providing opportunity to not accept the email for delivery, inherently holding the sender MTA responsible for the non-delivery report.
+ </para>
+ <para>
+ Whether or not to use deployment-wide or per-user anti-spam content filtering preferences is another one of such options. This one, however, greatly impacts where exactly anti-spam content filtering may take place.
+ </para>
+ <para>
+ For a more complete reference to email anti-spam techniques, please see <ulink url="http://en.wikipedia.org/wiki/Anti-spam_techniques_(e-mail)">Wikipedia's article on Anti-Spam Techniques</ulink>.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Content_filtering-Anti_Virus">
+ <title>Anti-Virus</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Content_filtering-White_and_Blacklisting">
+ <title>White- and Blacklisting</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Content_filtering-Greylisting">
+ <title>Greylisting</title>
+ <para>
+ When implementing greylisting, recipient addresses are first rejected, before being accepted at a later time. To track which email has been greylisted before, and should thus be accepted when retried, a mail exchanger typically maintains an internal database recording three key pieces of information &ndash;a so-called <emphasis>triplet</emphasis>:
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ The IP address of the sending mail exchanger,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ The envelope sender address,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ The envelope recipient address(es).
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+ <para>
+ Naturally, for greylisting policies to work the internal database must also keep record of the timestamp for the delivery attempt rejected.
+ </para>
+ <para>
+ Greylisting requires the sender to retry delivery, which is not a RFC requirement until <ulink url="http://tools.ietf.org/search/rfc5321">RFC 5321: "Simple Mail Transfer Protocol"</ulink>, which obsoleted <ulink url="http://tools.ietf.org/search/rfc821">RFC 821: "Simple Mail Transfer Protocol"</ulink>. RFC 821 had recommended (not required) retrying delivery. Older mailservers may not be in compliance with the new specifications in RFC 5321.
+ </para>
+ <para>
+ Greylisting introduces a delay in delivery for those "triplets" that do not have established use patterns. This may be contrary to what users expect, as most email delivery is virtually instantaneous. For greylisting to work effectively, whitelisting should be used extensively.
+ </para>
+ <para>
+ The former notwithstanding, trusted 3rd parties can be annotated as such by, for example, listing the 3rd party server IP addresses or DNS PTR entry record(s) (by CIDR or regex notation).
+ </para>
+ <section id="sect-Architecture_and_Design-Greylisting-Additional_Reading">
+ <title>Additional Reading</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://en.wikipedia.org/wiki/Greylisting" />
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://www.greylisting.org/whitelisting.shtml">Known servers not compliant with greylisting</ulink>
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Content_filtering-Real_time_DNS_Blacklisting">
+ <title>Real-time DNS Blacklisting</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Content_filtering-Sender_Address_Verification">
+ <title>Sender Address Verification</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Content_filtering-SPF_Record_Enforcement">
+ <title>SPF Record Enforcement</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-SPF_Record_Enforcement-DNSSEC">
+ <title>DNSSEC</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Email-Recipient_Checking">
+ <title>Recipient Checking</title>
+ <para>
+ recipient address checking
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Email-Integration_amp_Interoperability">
+ <title>Integration &amp; Interoperability</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-Pretty_Good_Privacy_amp_SMIME">
+ <title>Pretty Good Privacy &amp; S/MIME</title>
+ <para>
+ Example, GPG signing without Exchange clients enabled to decrypt / verify signatures - same for S/MIME.
+ </para>
+ <section id="sect-Architecture_and_Design-Pretty_Good_Privacy_amp_SMIME-See_Also">
+ <title>See Also</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <xref linkend="sect-Architecture_and_Design-Integration_amp_Interoperability-SSL_Certificate_Infrastructure" />
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-Email_Routing">
+ <title>Email Routing</title>
+ <para>
+ TODO - routing mtas as internal mtas. link with archiving and discovery. link with content-filtering. link with accounting.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-Shared_Folders">
+ <title>Shared Folders</title>
+ <para>
+ TODO - on shared folders on one groupware environment for clients configured against another groupware environment
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-Distribution_Groups">
+ <title>Distribution Groups</title>
+ <para>
+ TODO - distribution groups between multiple groupware environments, access control.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-See_Also">
+ <title>See Also</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <xref linkend="chap-Architecture_and_Design-Integration_amp_Interoperability" />
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </section>
+
+
+ </section>
+
+
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Groupware_Overview.xml b/Architecture_and_Design/en-US/Groupware_Overview.xml
new file mode 100644
index 0000000..590636e
--- /dev/null
+++ b/Architecture_and_Design/en-US/Groupware_Overview.xml
@@ -0,0 +1,285 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Groupware_Overview">
+ <title>Groupware Overview</title>
+ <para>
+ The following is a list of items that somehow, to some extent, relate to a groupware environment;
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ content-filtering
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ recipient checking
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ real-time dns blacklisting
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ whitelisting
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ blacklisting
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ greylisting
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ relaying
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ archiving
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ discovery
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ authentication
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ authorization
+ </para>
+ <para>
+ including;
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ access control
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ auditing
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ accounting
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ per-user / per-organization / global content-filtering enhancements
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ integration
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ interoperability
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ calendaring
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ journaling
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ support subscription entitlement enforcing
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ multi-domain handling
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ multi-realm handling
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ recipient policy
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ default folders
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ quota
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ monitoring
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ profiling
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ trending
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ performance analysis
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ performance optimization
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ firewalling
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ DNS settings
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ configuration management
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ high-availability
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ storage technology and protocol (e.g. IMAP4rev1)
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ storage technology options (e.g. Cyrus, Dovecot, UW-imap, Courier, ...)
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ storage volume
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ storage performance
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ provisioning
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ backup &amp; recovery
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ disaster recovery
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ SSL certificate infrastructure
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ webmail
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Integration_amp_Interoperability.xml b/Architecture_and_Design/en-US/Integration_amp_Interoperability.xml
new file mode 100644
index 0000000..234d3ef
--- /dev/null
+++ b/Architecture_and_Design/en-US/Integration_amp_Interoperability.xml
@@ -0,0 +1,93 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Integration_amp_Interoperability">
+ <title>Integration &amp; Interoperability</title>
+ <para>
+ The following is a list of items that somehow, to some extent, relate to a groupware environment;
+ </para>
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-Authentication_amp_Authorization">
+ <title>Authentication &amp; Authorization</title>
+ <para>
+ Integration and interoperability as it relates to authentication and authorization
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ technology agnosticity
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ multi-domain, multi-realm
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-Auditing">
+ <title>Auditing</title>
+ <para>
+ Integration and interoperability as it relates to auditing
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-Calendaring">
+ <title>Calendaring</title>
+ <para>
+ Integration and interoperability as it relates to calendaring functionality, e.g. multiple (groupware) environments with different invitation, event definition and free/busy exchange methodologies and interfaces.
+ </para>
+ <para>
+ Include capabilities to integrate external calendars, e.g. Google Calendar, ...
+ </para>
+ <para>
+ Include capabilities to publish public and private urls to Kolab calendars, e.g. not unlike Google Calendar, ...
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-Email">
+ <title>Email</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-Email-Content_filtering_and_3rd_Party_Appliances">
+ <title>Content-filtering and 3rd Party Appliances</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-Recipient_Checking">
+ <title>Recipient Checking</title>
+ <para>
+ Integration and interoperability as it relates to recipient checking, e.g. multiple source trees for available recipients throughout the environment.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Integration_amp_Interoperability-SSL_Certificate_Infrastructure">
+ <title>SSL Certificate Infrastructure</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Kolab_Daemon.xml b/Architecture_and_Design/en-US/Kolab_Daemon.xml
new file mode 100644
index 0000000..c428886
--- /dev/null
+++ b/Architecture_and_Design/en-US/Kolab_Daemon.xml
@@ -0,0 +1,12 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Kolab_Daemon">
+ <title>Kolab Daemon</title>
+ <para>
+ TODO
+ </para>
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Kolab_Objects.xml b/Architecture_and_Design/en-US/Kolab_Objects.xml
new file mode 100644
index 0000000..c2d719e
--- /dev/null
+++ b/Architecture_and_Design/en-US/Kolab_Objects.xml
@@ -0,0 +1,342 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Kolab_Objects">
+ <title>Kolab Objects</title>
+ <para>
+ This chapter outlines the definition, specification and processing of objects relevant to the Kolab Groupware Solution.
+ </para>
+ <section id="sect-Architecture_and_Design-Kolab_Objects-Object_Types">
+ <title>Object Types</title>
+ <para>
+ Object types are defined to distinguish objects with different, generic characteristics. In general, objects of the same type are processed similarly. Each of these object types requires a unique query definition resulting in a unique result set &ndash;or one object type will accidentally be treated as another object type.
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Accounts">
+ <title>Accounts</title>
+ <para>
+ Accounts include all accounts that are assigned to people, resources or services. The generic characteristic is that <xref linkend="form-Architecture_and_Design-Object_Types-Accounts" /> include authentication credentials.
+ </para>
+
+ </formalpara>
+ <para>
+ For example, <xref linkend="form-Architecture_and_Design-Object_Types-Accounts" /> would typically include all accounts for all people whom are to log in to a variety of services, but not <xref linkend="form-Architecture_and_Design-Object_Types-Contacts" />.
+ </para>
+ <note>
+ <title>Not All Accounts are Kolab Accounts or Recipients</title>
+ <para>
+ Not all accounts are necessarily also Kolab accounts. For example, an account may simply hold the bind credentials for a service such as Postfix or Apache's HTTPd, in order for these services to be able to search for the bind distinguished name upon user login, verify authentication, and check authorization. These accounts would typically not be Kolab accounts.
+ </para>
+
+ </note>
+ <para>
+ Minimal information to be included:
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-givenName">
+ <title><code>givenName</code></title>
+ <para>
+ The account's <emphasis>given name</emphasis>, such as <emphasis>John</emphasis>, <emphasis>Joe</emphasis> or <emphasis>Apache</emphasis>.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-sn">
+ <title><code>sn</code></title>
+ <para>
+ The account's <emphasis>surname</emphasis>, such as <emphasis>Doe</emphasis>, <emphasis>Sixpack</emphasis> or <emphasis>Webserver</emphasis>.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-cn">
+ <title><code>cn</code></title>
+ <para>
+ The account's <emphasis>common name</emphasis>, such as <emphasis>John Doe</emphasis>, <emphasis>Joe Sixpack</emphasis> or <emphasis>Apache Webserver Service Account</emphasis>.
+ </para>
+
+ </formalpara>
+ <para>
+ Given a policy, can be composed of <xref linkend="form-Architecture_and_Design-Object_Types-givenName" /> and <xref linkend="form-Architecture_and_Design-Object_Types-sn" /> automatically.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-uid">
+ <title><code>uid</code></title>
+ <para>
+ The account's <emphasis>user identifier</emphasis>, such as <emphasis>jdoe</emphasis>, <emphasis>jsixpack</emphasis> or <emphasis>apache</emphasis>.
+ </para>
+
+ </formalpara>
+ <para>
+ Given a policy, can be composed of <xref linkend="form-Architecture_and_Design-Object_Types-givenName" /> and <xref linkend="form-Architecture_and_Design-Object_Types-sn" /> automatically.
+ </para>
+ <note>
+ <title><code>uid</code> MUST be unique</title>
+ <para>
+ Note the <code>uid</code> attribute MUST be globally unique on at least the most common authentication database implementations, when it is used in authentication.
+ </para>
+
+ </note>
+ <note>
+ <title>The Use of <code>uid</code> in Systems Not Sealed</title>
+ <para>
+ Also note that the <code>uid</code> is used as the <emphasis>username</emphasis> on systems that are not sealed, which has implications on the exact <code>uid</code> that can be used, as well as on the objectClasses required as well.
+ </para>
+
+ </note>
+ <example id="exam-Architecture_and_Design-Object_Types-Example_User_Account_using_LDAP">
+ <title>Example User Account using LDAP</title>
+ <para>
+ Suppose the following is the input:
+ </para>
+ <para>
+ <simplelist>
+ <member> Given Name: <userinput>John</userinput> </member>
+ <member> Surname: <userinput>Doe</userinput> </member>
+
+ </simplelist>
+
+ </para>
+ <para>
+ The output could be, in LDIF, and implementing policies for the composition of the attributes for which no particular value has been specified:
+ </para>
+ <para>
+
+<screen>dn: uid=jdoe,dc=example,dc=org
+objectClass: top
+objectClass: inetOrgPerson
+objectClass: person
+objectClass: mailrecipient
+cn: Doe, John
+givenName: John
+sn: Doe
+mail: john.doe@example.org
+mailAlternateAddress: jdoe@example.org</screen>
+
+ </para>
+
+ </example>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-userPassword">
+ <title><code>userPassword</code></title>
+ <para>
+ The account password.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Base_DN">
+ <title>Base DN</title>
+ <para>
+ The base dn for the LDAP object, such as <emphasis>ou=People,dc=example,dc=org</emphasis> or <emphasis>ou=Employees,ou=Accounts,dc=example,dc=org</emphasis>.
+ </para>
+
+ </formalpara>
+ <para>
+ Given a configuration setting for the base dn, the location for this LDAP object is already known. If no such configuration setting is available, a location should be chosen by the administrator, or a default should be used.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Naming_Attribute">
+ <title>Naming Attribute</title>
+ <para>
+ Together with the base dn for the LDAP object, the naming attribute determines the full Distinguished Name for the LDAP object, such as <emphasis>uid=jdoe,ou=People,dc=example,dc=org</emphasis> or <emphasis>uid=jsixpack,ou=Employees,ou=Accounts,dc=example,dc=org</emphasis>.
+ </para>
+
+ </formalpara>
+ <para>
+ As he naming attribute is used to build the location for the LDAP object, it is commonly an attribute that is enforced to be globally unique by technology or by policy anyways.
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+ <para>
+ Optional information to be included:
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-mail">
+ <title><code>mail</code></title>
+ <para>
+ The email address associated with the account.
+ </para>
+
+ </formalpara>
+ <para>
+ Email Address, could be composed using recipient policy
+ </para>
+ <note>
+ <title><code>mail</code> SHOULD be unique</title>
+ <para>
+ Certain very specific use-case exceptions notwithstanding, note the <code>mail</code> attribute SHOULD be globally unique.
+ </para>
+
+ </note>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Kolab_Users">
+ <title>Kolab Users</title>
+ <para>
+ Kolab users, with possibly a different base dn, search scope or filter to be used as opposed to <xref linkend="form-Architecture_and_Design-Object_Types-Accounts" />. If not set however, should default to the same settings as <xref linkend="form-Architecture_and_Design-Object_Types-Accounts" />.
+ </para>
+
+ </formalpara>
+ <para>
+ For example, while <xref linkend="form-Architecture_and_Design-Object_Types-Accounts" /> may be searched under <emphasis>ou=Accounts,dc=example,dc=org</emphasis>, perhaps <xref linkend="form-Architecture_and_Design-Object_Types-Kolab_Users" /> are to be found under <emphasis>ou=Employees,ou=Accounts,dc=example,dc=org</emphasis>.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Contacts">
+ <title>Contacts</title>
+ <para>
+ Contacts are mail-enabled users outside those on Kolab. Or; "<emphasis>A person who may be communicated with for information or assistance, esp. with regard to one's job</emphasis>".
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Contact_Lists">
+ <title>Contact Lists</title>
+ <para>
+ Contact lists are different from <xref linkend="form-Architecture_and_Design-Object_Types-Distribution_List" />, in that they are considered <emphasis>persistent searches</emphasis> resulting in lists of contacts with one or more attributes in common. For example, a contact list could be composed of all people in a certain branch office. Such list then could be searched separately.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Domains">
+ <title>Domains</title>
+ <para>
+ As any single domain, stand-alone deployment is easily turned into a multi-domain deployment if not by simply adding a second domain name to the environment (domain alias), TODO FIXME.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Hosts">
+ <title>Hosts</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <para>
+ Include definition of roles in the environment, e.g. ext-mx-recv, ext-mx-send, ext-mx-trust, ext-mx-msa, ...
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Networks">
+ <title>Networks</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Resources">
+ <title>Resources</title>
+ <para>
+ Resources include such as conference rooms, beamers, etc. They usually only include a calendar folder, and may or may not be administered by one or more users.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Service_Accounts">
+ <title>Service Accounts</title>
+ <para>
+ Service accounts are required for environments in which anonymous binds and searches are not allowed, and privileges are to be properly and restrictively delegated.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Groups">
+ <title>Groups</title>
+ <para>
+ Groups in general have a variety of purposes. Perhaps the members of the groups are to be expanded to when the group is selected in the To, CC or Bcc fields, or the group is to be used in access control in a third party, external application.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Distribution_Groups">
+ <title>Distribution Groups</title>
+ <para>
+ Distribution groups are to be included in address books and to expand in the user's composer to its members.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Security_Groups">
+ <title>Security Groups</title>
+ <para>
+ Security groups are to be used in access control within Kolab, and only as such, though naturally they may also be distribution groups.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Object_Types-Distribution_List">
+ <title>Distribution List</title>
+ <para>
+ A distribution list is a named list, with a single recipient address, to which messages are sent and forwarded to list subscribers.
+ </para>
+
+ </formalpara>
+ <para>
+ Distribution list software includes, for example, mailman or majordomo.
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </section>
+
+
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Kolab_Server_Overview.xml b/Architecture_and_Design/en-US/Kolab_Server_Overview.xml
new file mode 100644
index 0000000..46f6a72
--- /dev/null
+++ b/Architecture_and_Design/en-US/Kolab_Server_Overview.xml
@@ -0,0 +1,273 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Kolab_Server_Overview">
+ <title>Kolab Server Overview</title>
+ <para>
+ This chapter provides an overview of the architecture of the Kolab Groupware server. <xref linkend="figu-Architecture_and_Design-Kolab_Server_Overview-Primary_Components_of_the_Kolab_Server" /> illustrates the following primary functional components that make up a Kolab Groupware server deployment:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Kolab_Server_Overview-Authentication_and_Authorization_Database">
+ <title>Authentication and Authorization Database</title>
+ <para>
+ The authentication database is the canonical source for information about users and groups, and is used to authenticate and authorize users &ndash;amongst other things. Traditionally, Kolab Groupware has been designed based on LDAP specific capabilities &ndash;more specifically, in fact, it has been based on OpenLDAP specific capabilities&ndash; but virtually any authentication and authorization method and/or technology is eligible to work for Kolab, including, but not limited to;
+ </para>
+
+ </formalpara>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Kerberos (v5)
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ LDAP
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ MySQL
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ PAM
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ PostgreSQL
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Shadow
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ SQLite(3)
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Kolab_Server_Overview-Web_Administration">
+ <title>(Web) Administration</title>
+ <para>
+ The optional web administration panel allows users and administrators to control certain aspects relevant to Kolab Groupware. For example, this includes folder subscriptions, authorization on folders, password management, mobile device management, and more.
+ </para>
+
+ </formalpara>
+ <para>
+ Most of the components in the web administration panel are subject to the user's authorization.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Kolab_Server_Overview-Mail_Exchanger">
+ <title>Mail Exchanger</title>
+ <para>
+ Mail exchangers are responsible for the exchange of email messages between nodes, as well as the exchange of email messages between services.
+ </para>
+
+ </formalpara>
+ <para>
+ Functionally, mail exchangers can be categorized using the following environment specific implementation characteristics;
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Kolab_Server_Overview-Backend_Mail_Exchanger">
+ <title>Backend Mail Exchanger</title>
+ <para>
+ A backend mail exchanger typically installed on an IMAP backend server and is used for two primary purposes; to enable, having received a message for one or more recipients on the backend IMAP server in question, one-shot delivery through LMTP, and to generate the backscatter (non-delivery reports, LMTP related errors).
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Kolab_Server_Overview-External_Mail_Exchanger">
+ <title>External Mail Exchanger</title>
+ <para>
+ An external mail exchanger is tasked with the exchange of email messages with external, 3rd parties. Typically, both email messages received from as well as sent to external sources passes through external mail exchangers.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Kolab_Server_Overview-Internal_Mail_Exchanger">
+ <title>Internal Mail Exchanger</title>
+ <para>
+ Internal mail exchangers are the core of an environment with multiple authentication- and/or authorization databases, and/or with multiple IMAP backend servers. Typically, internal mail exchangers relay email messages to the correct backend server, regardless of whether the backend server is a Microsoft Exchange SMTP bridgehead server, a Kolab IMAP backend server, or a external mail exchanger.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <para>
+ The level in which each of the aforementioned types of mail exchangers are relevant functional components in a certain deployment scenario depends on the desired functionality of the architecture, as well as the available resources in order to implement such functionality.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Kolab_Server_Overview-IMAP_Server">
+ <title>IMAP Server</title>
+ <para>
+ The IMAP server is primarily responsible for mailbox storage, distribution and access control.
+ </para>
+
+ </formalpara>
+ <para>
+ To assist in the creation, modification and deletion of mailboxes, Kolab includes a daemon.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-Kolab_Server_Overview-Web_Client">
+ <title>(Web) Client</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <note>
+ <title>(Web) Client does not include Smart Clients</title>
+ <para>
+ Although the (web) client software will need to have capabilities similar to those of a Smart Client, the distinction between (web) client software and smart clients like Kontact or Outlook is the latter two are not considered server components. There may be other server applications that act as a Kolab Groupware client.
+ </para>
+
+ </note>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <figure id="figu-Architecture_and_Design-Kolab_Server_Overview-Primary_Components_of_the_Kolab_Server">
+ <title>Primary Components of the Kolab Server</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/kolab_server-primary_components-overview.png" format="PNG" width="383" />
+ </imageobject>
+
+ </mediaobject>
+
+ </figure>
+ <section id="sect-Architecture_and_Design-Kolab_Server_Overview-Functional_Requirements_of_the_Authentication_amp_Authorization_Database">
+ <title>Functional Requirements of the Authentication &amp; Authorization Database</title>
+ <para>
+ There is a certain minimal amount of information that Kolab requires to be available in any authentication database, such as the credentials that need to be supplied by a client in order to verify the identity of the user. Which details of those credentials are stored in the authentication database very much depends on the authentication technology used. For a Kerberos (v5) deployment for example, the username and realm would suffice (the ticket is verified with the KDC, and no password exchange is required). For an LDAP deployment however, any unique attribute value, or part thereof, within the search scope may be used in combination with the password needed for a fast-bind operation.
+ </para>
+ <para>
+ Authorization for a user can be separate from the authentication. For example, user <literal>john@doe.org</literal> can be authorized as <literal>john.doe@example.org</literal>, or even <literal>max.imum@example.org</literal> if necessary. Additionally, groups of users are often used as a simple way of authorizing larger numbers of users.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Kolab_Server_Overview-Functional_Requirements_of_the_Web_Administration">
+ <title>Functional Requirements of the (Web) Administration</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Kolab_Server_Overview-Functional_Requirements_of_the_Mail_Exchanger">
+ <title>Functional Requirements of the Mail Exchanger</title>
+ <para>
+ TODO
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Positioning
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Role definition
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ High Availability
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Load Balancing
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Efficient and cost-effective
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Free Software
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ Content Filtering
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Kolab_Server_Overview-Functional_Requirements_of_the_IMAP_Server">
+ <title>Functional Requirements of the IMAP Server</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Kolab_Server_Overview-Functional_Requirements_for_the_Web_Client">
+ <title>Functional Requirements for the (Web) Client</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Migration.xml b/Architecture_and_Design/en-US/Migration.xml
new file mode 100644
index 0000000..40f6ade
--- /dev/null
+++ b/Architecture_and_Design/en-US/Migration.xml
@@ -0,0 +1,12 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Migration">
+ <title>Migration</title>
+ <para>
+ TODO
+ </para>
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Mobile_Device_Synchronization.xml b/Architecture_and_Design/en-US/Mobile_Device_Synchronization.xml
new file mode 100644
index 0000000..dc3a2d8
--- /dev/null
+++ b/Architecture_and_Design/en-US/Mobile_Device_Synchronization.xml
@@ -0,0 +1,29 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Mobile_Device_Synchronization">
+ <title>Mobile Device Synchronization</title>
+ <para>
+ TODO
+ </para>
+ <section id="sect-Architecture_and_Design-Mobile_Device_Synchronization-SyncML">
+ <title>SyncML</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Mobile_Device_Synchronization-ActiveSync">
+ <title>ActiveSync</title>
+ <para>
+ TODO
+ </para>
+
+ </section>
+
+
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Preface.xml b/Architecture_and_Design/en-US/Preface.xml
new file mode 100644
index 0000000..5ef6bf8
--- /dev/null
+++ b/Architecture_and_Design/en-US/Preface.xml
@@ -0,0 +1,11 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<preface id="pref-Architecture_and_Design-Preface">
+ <title>Preface</title>
+ <xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+ <xi:include href="sect-Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+</preface>
+
diff --git a/Architecture_and_Design/en-US/Revision_History.xml b/Architecture_and_Design/en-US/Revision_History.xml
new file mode 100644
index 0000000..a48bcd1
--- /dev/null
+++ b/Architecture_and_Design/en-US/Revision_History.xml
@@ -0,0 +1,33 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<appendix id="appe-Architecture_and_Design-Revision_History">
+ <title>Revision History</title>
+ <simpara>
+ <revhistory>
+ <revision>
+ <revnumber>0-0</revnumber>
+ <date>Wed Feb 9 2011</date>
+ <author>
+ <firstname>Dude</firstname>
+ <surname>McPants</surname>
+ <email>Dude.McPants@example.com</email>
+
+ </author>
+ <revdescription>
+ <simplelist>
+ <member>Initial creation of book by publican</member>
+
+ </simplelist>
+
+ </revdescription>
+
+ </revision>
+
+ </revhistory>
+
+ </simpara>
+</appendix>
+
diff --git a/Architecture_and_Design/en-US/Smart_Clients.xml b/Architecture_and_Design/en-US/Smart_Clients.xml
new file mode 100644
index 0000000..b361d3f
--- /dev/null
+++ b/Architecture_and_Design/en-US/Smart_Clients.xml
@@ -0,0 +1,219 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<chapter id="chap-Architecture_and_Design-Smart_Clients">
+ <title>Smart Clients</title>
+ <para>
+ Kolab Smart Clients speak standard protocols, conform to a variety of RFC specifications and implement the Kolab Groupware Information XML Storage Format as specified.
+ </para>
+ <section id="sect-Architecture_and_Design-Smart_Clients-First_time_Login">
+ <title>First-time Login</title>
+ <para>
+ For smart clients that have a new Kolab account configured, and log in to the Kolab account for the first time, the following conditions may exist;
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ The account has been used before, and contains groupware folders, in which case;
+ </para>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ The folder names may have been created using the localized name as opposed to a name suitable for the application of localization on the smart client side.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ The folders may have been created using a smart client that had more then one (Kolab) account configured, resulting in some groupware folder types not having a <code>default</code> folder for that type of groupware items.
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ The account has been used before but does not contain all relevant groupware folders.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ The account has not been used before, and does not contain any folders.
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+ <para>
+ The following Standard Operating Procedure has been defined.
+ </para>
+ <procedure id="proc-Architecture_and_Design-First_time_Login-Smart_Client_First_time_Login_SOP">
+ <title>Smart Client First-time Login SOP</title>
+ <step>
+ <para>
+ Obtain the list of folders available within the user-specific namespace for the account (e.g. no shared folders from other users, nor shared folders from the <code>shared/</code> namespace), along with their annotations.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ Determine if a default <code>contact</code> folder type exists. This folder would be marked with annotation <code>/vendor/kolab/folder-type</code> set to <code>contact.default</code>.
+ </para>
+ <substeps>
+ <step>
+ <para>
+ If no default folder for contacts exists, and multiple folders have been marked as containing contacts, prompt the user to select the default folder for contacts.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ If no default folder for contacts exists, and no more then one folder has been marked as containing contacts, mark this folder as the default folder for contacts.
+ </para>
+
+ </step>
+ <step>
+ <para>
+ If no default folder for contacts exists, and no folder has been marked as containing contacts, create a folder named '<literal>Contacts</literal>' and mark this folder as the default folder for contacts.
+ </para>
+
+ </step>
+
+ </substeps>
+
+ </step>
+ <step>
+ <para>
+ Lather, rinse and repeat for folder types <code>event</code>, <code>journal</code>, <code>note</code> and <code>task</code>.
+ </para>
+
+ </step>
+
+ </procedure>
+
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Smart_Clients-Consecutive_Operations">
+ <title>Consecutive Operations</title>
+ <para>
+ For the annotated folders in a Kolab account, the smart client will attempt to apply localization as if the original folder name were supplied using the <literal>en-US</literal> locale, using the target locale the smart client is supposed to operate in. Should this fail, the original folder name is to be displayed. Should this succeed, the localized folder name is to be displayed.
+ </para>
+ <para>
+ Should the user choose to delete the folder annotated as containing events, whether displayed as "Calendar" (en_US) or the localized "Agenda" (nl_NL), or "Kalender" (de_DE), to then create the folder "Agenda" (nl_NL) or "Kalender" (de_DE), no further localization is necessary as this has been the explicit wish of the user.
+ </para>
+ <para>
+ However, should a localized client be entitled to create folder names using the localized name, users may end up &ndash;by using different client configurations&ndash; with multiple groupware folders for the same type, in different localizations.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Smart_Clients-Default_Groupware_Folders">
+ <title>Default Groupware Folders</title>
+ <para>
+ Groupware folders marked as default for a certain type should be treated as the default for the configured account and associated identities only, unless no other equivalent groupware folders exist on the smart client, and/or no other accounts have been configured on the smart client.
+ </para>
+
+ </section>
+
+ <section id="sect-Architecture_and_Design-Smart_Clients-Access_Control_Shared_Folders_and_User_Interaction">
+ <title>Access Control, Shared Folders and User Interaction</title>
+ <para>
+ The smart clients will display the user friendly name configured as opposed to the value of the <emphasis>SASL Result Attribute</emphasis> or INBOX name. Additionally, smart clients will strip off qualifiers, or in other words, not display:
+ </para>
+ <para>
+
+<screen>Other Users
+ `- john
+ `- Calendar@doe.org</screen>
+
+ </para>
+ <para>
+ Instead, smart clients should display:
+ </para>
+ <para>
+
+<screen>&lt;Localized "Other Users"&gt;
+ `- &lt;Display Name&gt;
+ `- &lt;Localized Folder Name&gt;</screen>
+
+ </para>
+ <para>
+ E.g., for example, should the Display Name for John be set to "Doe, John", and the user have his locale set to nl_NL;
+ </para>
+ <para>
+
+<screen>Andere Gebruikers
+ `- Doe, John
+ `- Agenda</screen>
+
+ </para>
+ <para>
+ or, should the Display Name for John be set to "John Doe", and the user have his locale set to de_DE;
+ </para>
+ <para>
+
+<screen>Andere Nutzer
+ `- John Doe
+ `- Kalender</screen>
+
+ </para>
+ <section id="sect-Architecture_and_Design-Access_Control_Shared_Folders_and_User_Interaction-More_Advanced_Display">
+ <title>More Advanced Display</title>
+ <para>
+ Consider the following folder tree, sorting and displaying folders and shared folders by category:
+ </para>
+ <para>
+
+<screen>Inbox
+Calendar
+ `- John Doe
+Journal
+ `- Max Imum</screen>
+
+ </para>
+ <para>
+ or, in locale nl_NL:
+ </para>
+ <para>
+
+<screen>Inbox
+Agenda
+ `- John Doe
+Dagboek
+ `- Max Imum</screen>
+
+ </para>
+ <para>
+ For multiple shared folders from the same account:
+ </para>
+ <para>
+
+<screen>Inbox
+Agenda
+ `- John Doe
+ `- &lt;Topic or Title&gt;
+Dagboek
+ `- Max Imum</screen>
+
+ </para>
+
+ </section>
+
+
+ </section>
+
+
+</chapter>
+
diff --git a/Architecture_and_Design/en-US/Terminology.xml b/Architecture_and_Design/en-US/Terminology.xml
new file mode 100644
index 0000000..3f15447
--- /dev/null
+++ b/Architecture_and_Design/en-US/Terminology.xml
@@ -0,0 +1,294 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "Architecture_and_Design.ent">
+%BOOK_ENTITIES;
+]>
+<appendix id="appe-Architecture_and_Design-Terminology">
+ <title>Terminology</title>
+ <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Credentials">
+ <title>Authentication Credentials</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Domain">
+ <title>Authentication Domain</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Password">
+ <title>Authentication Password</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Realm">
+ <title>Authentication Realm</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Service_Name">
+ <title>Authentication Service Name</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Authentication_Username">
+ <title>Authentication Username</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Base_DN">
+ <title>Base DN</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Distinguished_Name">
+ <title>Distinguished Name</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-External_Mail_Exchanger">
+ <title>External Mail Exchanger</title>
+ <para>
+ <emphasis>External Mail Exchangers</emphasis> are <emphasis>Internet facing</emphasis> mail exchangers. In other words, they send and/or receive mail to and/or from the Internet. Four sub-types (<emphasis>roles</emphasis>) exist for external mail exchangers: <xref linkend="form-Architecture_and_Design-External_Mail_Exchanger_Types-Receiving" />, <xref linkend="form-Architecture_and_Design-External_Mail_Exchanger_Types-Sending" />, <xref linkend="form-Architecture_and_Design-External_Mail_Exchanger_Types-Submission" /> and <xref linkend="form-Architecture_and_Design-External_Mail_Exchanger_Types-Trusted" />.
+ </para>
+
+ </formalpara>
+ <note>
+ <title>Combined Roles</title>
+ <para>
+ While an external mail exchanger is assigned at least one <emphasis>role</emphasis>, no one role is mutually exclusive with any other role. As such, all roles may be combined in to one or more external mail exchangers.
+ </para>
+ <para>
+ Additionally, the <emphasis>External Mail Exchanger</emphasis> role can be combined with the <xref linkend="form-Architecture_and_Design-Terminology-Internal_Mail_Exchanger" /> role.
+ </para>
+
+ </note>
+ <important>
+ <title>FIXME</title>
+ <para>
+ The list below should be an ordered list, but Publican &ndash;at the time of this writing&ndash; does not align the formalpara title correctly.
+ </para>
+
+ </important>
+ <para>
+ <itemizedlist id="item-Architecture_and_Design-Terminology-External_Mail_Exchanger_Types">
+ <title>External Mail Exchanger Types</title>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-External_Mail_Exchanger_Types-Receiving">
+ <title>Receiving</title>
+ <para>
+ External mail exchangers of type <emphasis>receiving</emphasis> receive email from the Internet, possibly including &ndash;not limited to&ndash; specific configuration reflecting;
+ </para>
+
+ </formalpara>
+ <para>
+ <orderedlist>
+ <listitem>
+ <para>
+ the corporate content-filtering policies,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ firewall configuration,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ archiving and discovery policies,
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ ...
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-External_Mail_Exchanger_Types-Sending">
+ <title>Sending</title>
+ <para>
+ External mail exchangers of type <emphasis>sending</emphasis> send email to the Internet, typically from <emphasis>known senders</emphasis> only, employing different policies including those for content-filtering.
+ </para>
+
+ </formalpara>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-External_Mail_Exchanger_Types-Submission">
+ <title>Submission</title>
+ <para>
+ External mail exchangers of type <emphasis>submission</emphasis> are used by smart clients to submit email through the corporate infrastructure, to enable recipient mail exchangers to verify the canonical source of the sender email address and mail exchanger IP address and/or hostname against blacklists, whitelists, real-time DNS blacklists, greylists, SPF records and other content-filtering technologies employed at the receiving end.
+ </para>
+
+ </formalpara>
+ <para>
+ External mail exchangers of type <emphasis>submission</emphasis> include a Mail Submission Agent process listening on port <literal>587/tcp</literal> (msa), enabling users with smart clients to circumvent the all too common restrictions on the usage of port <literal>25/tcp</literal> (smtp) by many ISPs. These external mail exchangers have the Mail Submission Agent listener exposed to the Internet, and to prevent abuse require authentication before accepting the submission of email. Additionally, these MSA listener processes often require the use of <xref linkend="form-Architecture_and_Design-Terminology-Transport_Layer_Security_TLS" />.
+ </para>
+
+ </listitem>
+ <listitem>
+ <formalpara id="form-Architecture_and_Design-External_Mail_Exchanger_Types-Trusted">
+ <title>Trusted</title>
+ <para>
+ External mail exchangers of type <emphasis>trusted</emphasis> have been configured to relay certain email to specific hosts, that may or may not be referred to as a mail exchangers for the given domain name space by traditional DNS. A scenario implementing this type of mail exchanger would typically have a two-way trust relationship with a third party.
+ </para>
+
+ </formalpara>
+ <example id="exam-Architecture_and_Design-External_Mail_Exchanger_Types-Two_way_Organizational_Trust_Relationship_Example">
+ <title>Two-way Organizational Trust Relationship Example</title>
+ <para>
+ A dedicated procurement provider may send and receive confidential information transported from one end to the other using email, and to that end be connected to the corporate (IP-)VPN through an external, dedicated (IP-)VPN cloud. The provider's receiving mail exchangers may, as such, not be listed as mail exchangers in any existing, available DNS zone, and require an explicit relay host entry in the configured transport for the consumer's external mail exchanger MTA(s).
+ </para>
+
+ </example>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <formalpara id="form-Architecture_and_Design-Terminology-Fully_Qualified_User_Identifier">
+ <title>Fully Qualified User Identifier</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <para>
+ See also:
+ </para>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Username" />
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Credentials" />
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <xref linkend="form-Architecture_and_Design-Terminology-Authentication_Realm" />
+ </para>
+
+ </listitem>
+
+ </itemizedlist>
+
+ </para>
+ <formalpara id="form-Architecture_and_Design-Terminology-Internal_Mail_Exchanger">
+ <title>Internal Mail Exchanger</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Kolab_Groupware_Primary_Domain">
+ <title>Kolab Groupware Primary Domain</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-LDAP_Search">
+ <title>LDAP Search</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Mailbox">
+ <title>Mailbox</title>
+ <para>
+ A mailbox is essentially a special type of mailfolder, as it is a top-level mail folder. The only level higher then the mailbox name is the prefix (user, shared, DELETED or news). For users, the mailbox corresponds with the user's INBOX. The first level of shared folders however does not truly correspond with a type of special folder like the user's INBOX does.
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Mailfolder">
+ <title>Mailfolder</title>
+ <para>
+ TODO / Contrary to a mailbox, a mailfolder can be anywhere
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Naming_Attribute">
+ <title>Naming Attribute</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Relative_Distinguished_Name">
+ <title>Relative Distinguished Name</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Root_DN">
+ <title>Root DN</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Search_Filter">
+ <title>Search Filter</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Search_Scope">
+ <title>Search Scope</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Transport_Layer_Security_TLS">
+ <title>Transport Layer Security (TLS)</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+ <formalpara id="form-Architecture_and_Design-Terminology-Unqualified_User_Identifier">
+ <title>Unqualified User Identifier</title>
+ <para>
+ TODO
+ </para>
+
+ </formalpara>
+</appendix>
+
diff --git a/Architecture_and_Design/publican.cfg b/Architecture_and_Design/publican.cfg
new file mode 100644
index 0000000..005ff98
--- /dev/null
+++ b/Architecture_and_Design/publican.cfg
@@ -0,0 +1,8 @@
+# Config::Simple 4.59
+# Wed Feb 9 12:46:34 2011
+
+xml_lang: en-US
+type: Book
+brand: common
+
+show_remarks: 1