Export more lyx -> tex master
authorMatthew Mondor <mmondor@pulsar-zone.net>
Mon, 2 Dec 2019 08:05:37 +0000 (08:05 +0000)
committerMatthew Mondor <mmondor@pulsar-zone.net>
Mon, 2 Dec 2019 08:05:37 +0000 (08:05 +0000)
mmsoftware/js/js-appserv/doc/js-appserv-protocol.tex [new file with mode: 0644]
mmsoftware/mmmail2/notes/mmmail-design.tex [new file with mode: 0644]

diff --git a/mmsoftware/js/js-appserv/doc/js-appserv-protocol.tex b/mmsoftware/js/js-appserv/doc/js-appserv-protocol.tex
new file mode 100644 (file)
index 0000000..f9e204c
--- /dev/null
@@ -0,0 +1,477 @@
+%% LyX 2.1.2.2 created this file.  For more info, see http://www.lyx.org/.
+%% Do not edit unless you really know what you are doing.
+\documentclass[letterpaper,english]{article}
+\usepackage[latin9]{inputenc}
+
+\makeatletter
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
+\special{papersize=\the\paperwidth,\the\paperheight}
+
+\newcommand{\noun}[1]{\textsc{#1}}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
+\newenvironment{lyxcode}
+{\par\begin{list}{}{
+\setlength{\rightmargin}{\leftmargin}
+\setlength{\listparindent}{0pt}% needed for AMS classes
+\raggedright
+\setlength{\itemsep}{0pt}
+\setlength{\parsep}{0pt}
+\normalfont\ttfamily}%
+ \item[]}
+{\end{list}}
+
+\makeatother
+
+\usepackage{babel}
+\begin{document}
+
+\title{The JS-AppServ Protocol (JSASP)}
+
+
+\author{By Matthew Mondor}
+\maketitle
+\begin{abstract}
+The FastCGI protocol, although bearing significant advantages over
+plain old CGI, and even often over HTTP-specific APIs, was considered
+an overly complex protocol after an in-depth study. Using binary format
+headers would not have been a problem by itself, but representing
+multiple-octets words as separate octet fields instead of using a
+big-endian representation, as well as using multiple header structure
+types depending on the size of the data to be processed, instead of
+a fixed sized word of the maximum needed size, seemed bad design.
+
+Moreover, although this could be for the sake of flexibility, the
+numerous ways to design server-side applications with FastCGI also
+can lead to problems. Ultimately, the use of FastCGI appears most
+efficient with a heavily threaded language such as Java, which language
+and threaded methodology have their own set of problems. Having the
+HTTPd launch application-server-side processes was also considered
+unadequate.
+
+This protocol is specifically designed to work on unix systems using
+an independent, persistent process per user session, along with long-lasting
+bidirectional socket connections between those persistent processes
+and the HTTP daemon which initiates the requests. This document describes
+the very details of the system. For convenience, the \noun{JSON} (\noun{JavaScript
+Object Notation}) is used to transmit requests and responses.
+
+Disdadventages exist; For instance this system is not compatible with
+the existing CGI or FastCGI protocols. Moreover, although parts could
+be re-implemented to support other languages, the system was specifically
+made for use with the SpiderMonkey JavaScript engine. However, a provided
+compatible HTTPd is included as part of the system, which is especially
+tailored to this model.
+\end{abstract}
+\newpage{}
+\begin{abstract}
+\tableofcontents{}
+\end{abstract}
+\newpage{}
+
+
+\section{HTTPd specification}
+
+
+\subsection{Model}
+
+Within this system, the HTTP server model is simple and only requires
+a single process. Non-blocking I/O is used and the server merely serves
+as a proxy between the js-appserv servers and the remote HTTP clients.
+
+This service should be as efficient as possible, since it must avoid
+becoming a main bottleneck. It should ideally be written in C and
+care should be taken to ensure that no memory leaks or security problems
+are found. Nevertheless, a re-spawner process could restart this service
+whenever it dies or locks, if this situation ever was to occur. If
+it is stable enough, the active session IDs and associated information
+can be kept in RAM instead of having to be stored into a database.
+It then remains up to the dynamic application to, as necessary, save
+database information associated with this state if needed and to retreive
+it, etc.
+
+Optionally, the HTTPd can remember the client IP address associated
+with the create SIDs to only keep accepting requests for that SID
+from that very address, depending on the nature of the application.
+
+
+\subsection{Operations}
+
+Here are the steps performed by the HTTP server when it obtains a
+request from a user:
+\begin{itemize}
+\item Verification weither the vhost/path combination was defined by the
+administrator as being handled by a particular js-appserv application.
+If not, serve static pages as requested if they exist and are accessible.
+\item If path corresponds to an application and that the user did not provide
+a unique session ID cookie which is still considered valid, generate
+a new session ID for the user and send along an HTTP cookie to the
+client, redirecting it to the same URL it requested with a few seconds
+of delay.
+\item If path corresponds to an application and that the client provides
+us a unique session ID which still is valid, verify if there already
+was an established socket connection for this particular client/application
+pair. If so, direct request to that application. Otherwise, attempt
+to establish a socket connection to an application, and then forward
+the request there. The connection to the application remains open
+to serve further requests.
+\item In the event where the session ID expires, or that the application
+initiates a command to discard the session ID, the corresponding socket
+connection to the application is closed and the entry for the session
+data is deleted.
+\item In the event where the connection to an application is lost unexpectedly
+or as the result of an inactivity timeout and that the session did
+not expire, the session is marked as no longer having a connection,
+so that it can be re-established on the next session. It becomes the
+responsibility of the application to gracefully retrieve the persistent
+session associated data as needed so that a session may still resume
+normally.
+\end{itemize}
+
+\subsection{Current implementation}
+
+\emph{XXX}
+
+
+\section{Application (JS-AppServ) specification}
+
+
+\subsection{Model}
+
+The server uses a multi-processes model, along with a pool of pre-forked
+processes for performance (Apache 1.3.x style). Basically, there is
+a master controller process, along with a number of children processes
+listening on the specified bound interface(s) and port(s), serialization
+being used among them.
+
+These processes expect lenghty persistent connections originating
+from the HTTP server, and generally survive after disconnection so
+that multiple connections may be served without needing a process
+to be restarted everytime. However, they can be configured to recycle
+after a number of connections were served, in order to avoid long
+term resources leaks. It is also possible for the process to exit
+as the result of an \emph{execve(2)} call being completed in the same
+process, in which case it immediately gets replaced by a new process.
+
+This model simplifies application design, avoiding the requirement
+of reentrant, thread-safe, non-blocking and leakless code to be used,
+which can require a considerable time to properly write and debug.
+Moreover, it provides more security than using a single process, avoiding
+a crash or exploit from propagating to the whole application. Using
+a multi-processes model also allows additional tricks such as privilege
+separation if the application requires this.
+
+js-appserv applications can run remotely from the HTTPd, or locally.
+Moreover, it may run under other user credentials. It can also run
+into a \emph{chroot(2)} environment, sandboxed using \emph{systrace(1)},
+etc. Simple authentication is performed between the HTTPd and the
+js-appserv daemons when the connections are initiated, in order to
+prevent unwanted local or remote users from accessing the service.
+\emph{Under local unix domain sockets, it is possible to authenticate
+using AF\_LOCAL ancillary data to determine that only the allowed
+user(s) can connect (XXX to be implemented).}
+
+Just like with FastCGI or other proxying distribution methods, it
+is still important for the administrator to ensure that as few as
+possible entry points are allowed. This can be done by making the
+applications listen to an interface/port combination to which only
+the HTTP server can connect, through a route on which sniffing is
+considered impractical.
+
+\emph{Optional data stream compression and encryption between the
+server and the application will be provided, using a proprietary private
+key cryptography method which is simpler although more efficient than
+SSL (XXX to be implemented).} Care is taken to not disclose the password
+over the connection and to not reuse existing encryption session keys.
+There however is no guarentee whatsoever as to the security of the
+system.
+
+
+\subsection{Operations}
+
+A typical js-appserv application child process behaves as follows:
+\begin{itemize}
+\item Setup the JS context, loading the application scripts, preprocessing
+them (can be done by the parent process and inherited by the children,
+telling children to recycle upon reloading when signalled with \emph{SIGHUP}).
+Note that in-progress connections can either be interrupted upon reception
+of \emph{SIGHUP} by the parent, or notified to exit whenever closing
+normally, depending on the application requirements. This is configurable
+via a configuration file.
+\item Listen for a connection until one can be obtained.
+\item Authenticate client/HTTPd, and drop it with an error immediately if
+it should not be allowed, returning to connection waiting again.
+\item Connection was accepted. Retrieve SID and previously saved session
+persistent data if resuming, or create a new SID depending on the
+context. If loading, persistent session saved data is retrieved as
+well for unexpired, valid SIDs.
+\item The JS application now waits for requests and serves them. These are
+expected to all be requests to serve the same user (under the same
+SID). Therefore it is possible to cache a lot of data for efficiency.
+\item The application can send a response to discard the session ID and
+then exit, causing the connection to be dropped and process to wait
+again for connections. It can also drop the connection for inactivity
+timeout. When closing connection for a still valid SID, persistent
+data is saved to allow resuming under another connection (which generally
+will be served by another process which will need to reload this data).
+\emph{It is also possible for the application to use application-global
+shared memory to cache some SID specific data (XXX to be implemented).}
+\item From time to time, the process will exit after serving a certain number
+of persistent connections, to release dangling resources that it may
+be leaking, if any.
+\item The application manages the session-specific unique IDs, which the
+HTTP translates to a cookie, \emph{GET} or \emph{POST} variable. In
+this protocol, these IDs (Session ID or SID) consist of 64 character
+strings which each character consists of one of a list of 64 characters.
+As such, these can be efficiently generated using a reliable random
+source of 32-bit or 64-bit input values, to generate batches of 4
+to 8 characters at a time of the SID. \emph{A noonce is also used
+so that it is unlikely for two identical SIDs to ever be used (XXX
+to be implemented).}
+\end{itemize}
+
+\subsection{Current implementation}
+
+
+\subsubsection{JS-AppServ core}
+
+The core of the server is writtein in C and uses the \emph{mmserver2(3)}
+library, which easily allows support for IPv4, IPv6, \emph{AF\_LOCAL}
+and a pool of processes. This library calls application-specific callbacks,
+which in turn, delegate to JavaScript functions, allowing the application
+to be written into JS. The tasks which were considered to be best
+written in C for efficiency were exported as JS objects for use by
+the js-appserv application's scripts.
+
+The parent process initializes a JS runtime and context, loads in
+the main application script (\emph{main.js}) and executes it to create
+the JS functions. This context is inherited (\emph{MAP\_COPY}) to
+the children processes. This means that multiple connections within
+a process can be served under the same context, although because of
+the nature of SpiderMonkey, which includes a good Garbage Collector,
+and the fact that between connections we clear \emph{SID} and \emph{DATA},
+this should generally not be a problem, and it increases efficiency.
+\emph{However, hooks are provided to the scripts so that they may
+load and cache scripts and then execute them under different contexts
+as needed (XXX to be implemented).}
+
+
+\subsubsection{JS-AppServ Web applications}
+
+Once in the \emph{Request Server State} (\ref{sub:The-request-server}),
+the non-system requests are forwarded to JS functions provided by
+the custom user Web application. \emph{This system may dispatch operations
+under various contexts as necessary.}
+
+XXX
+
+
+\section{The JS-AppServ protocol (JSASP)}
+
+Here we define the JSASP.
+
+
+\subsection{Overview}
+
+The use of the \noun{JSON} (\noun{JavaScript Object Notation}) format
+was chosen for its simplicity and efficiency, using a simple custom
+protocol, over other approaches often using XML and HTTP, or complex
+proprietary binary formats. A custom JSON parser was implemented in
+order to avoid needing to use the insecure \emph{eval()} function.
+
+The JSASP allows the applications to run independently from the HTTP
+daemon and to be distributed as necessary among various servers as
+application load requirements increase. It permits the HTTPd to create
+and maintain sessions and perform requests on behalf of a session
+to serve a user.
+
+These session-specific requests, similarily as with FastCGI, can be
+classified under three roles, \emph{Responder} (serving \emph{GET},
+\emph{POST}, \emph{PUT}), \emph{Authorizer} (allowing or not access
+to a particular resource), and \emph{Filter} (allowing to transparently
+filter/process files).
+
+
+\subsection{Stateless commands}
+
+These commands are always available independently of the current connection
+state.
+
+
+\subsubsection{ping}
+\begin{itemize}
+\item Request:\end{itemize}
+\begin{lyxcode}
+(\{cmd:''ping''\})\end{lyxcode}
+\begin{itemize}
+\item Response:\end{itemize}
+\begin{lyxcode}
+(\{result:true,~msg:''pong''\})
+\end{lyxcode}
+The main purpose of this command is to either verify if the connection
+still works properly, and/or to prevent the connection from being
+closed by js-appserv for inactivity timeout. Oftentimes the HTTPd
+will simply let the connection timeout automatically, which allows
+to free processes serving very idle sessions to serve more busy sessions.
+
+
+\subsubsection{\label{sub:quit}quit}
+\begin{itemize}
+\item Request:\end{itemize}
+\begin{lyxcode}
+(\{cmd:''quit''\})\end{lyxcode}
+\begin{itemize}
+\item Response:\end{itemize}
+\begin{lyxcode}
+(\{result:true,~msg:''\textless{}message\textgreater{}''\})
+\end{lyxcode}
+This command may be issued to immediately interrupt the connection
+at any time. If currently serving a SID, the session-specific data
+will be saved so that the session may be resumed.
+
+
+\subsection{The authentication state}
+
+Every httpd-\textgreater{}js-appserv connection starts in the greeting
+state.
+
+\emph{XXX}
+
+
+\subsection{The SID management state}
+
+After successful authentication, the HTTPd can request to resume a
+previous valid SID, or request that a new SID be created. It is also
+possible to verify for validity of a SID and then request a new one
+if the requested one did not exist, in which case the newly created
+SID should be sent again as session cookie to the user by the HTTPd.
+
+Care is made so that once activated on a connection, no other connection
+can activate the same SID, among other processes of the same js-appserv
+or between multiple local or remote ones. For this reason, SIDs are
+often stored into a common database (postgresql in the case of the
+reference implementation).
+
+However, if it is known that no conflict can occur (only a single
+js-appserv being run for instance, and that shared memory allows the
+various connections to share an in-memory hash table), an implementation
+could potentially use an in-memory system instead of depending on
+an RDBMS. 
+
+This state begins with the message:
+\begin{lyxcode}
+(\{result:true,~msg:\char`\"{}Ready\char`\"{}\})
+\end{lyxcode}
+
+\subsubsection{sid\_load}
+\begin{itemize}
+\item Request:\end{itemize}
+\begin{lyxcode}
+(\{cmd:''sid\_load'',~sid:''\textless{}sid\textgreater{}''\})\end{lyxcode}
+\begin{itemize}
+\item Response:\end{itemize}
+\begin{lyxcode}
+(\{result:\textless{}boolean\textgreater{},~msg:''\textless{}string\textgreater{}''\})
+\end{lyxcode}
+Request to resume serving a specific session. This occurs after unexpected
+connection loss between the HTTPd and the js-appserv application,
+or after disconnection due to request inactivity timeout for the SID,
+where the closing phase saved persistent state information for it.
+
+If successful, this request causes the persistent data to be loaded
+back and the specified SID to become the active one for this connection.
+This request can only succeed if not currently serving a SID.
+
+On error, \emph{result} will be \emph{false} in the response, but
+the connection is left open for the HTTPd to optionally request creation
+of a new SID with the \emph{sid\_create} (\ref{sub:sid_create}) command,
+although it may also issue the \emph{quit} (\ref{sub:quit}) command.
+
+
+\subsubsection{\label{sub:sid_create}sid\_create}
+\begin{itemize}
+\item Request:\end{itemize}
+\begin{lyxcode}
+(\{cmd:''sid\_create''\})\end{lyxcode}
+\begin{itemize}
+\item Response:\end{itemize}
+\begin{lyxcode}
+\{\{result:\textless{}boolean\textgreater{},~msg:''\textless{}string\textgreater{}''{[},~sid:''\textless{}sid\textgreater{}''{]}\})
+\end{lyxcode}
+Requests that a new session be created. This is only possible if not
+currently serving a SID. When successful, the SID is returned and
+becomes the currently active SID being served by this connection.
+
+On error, \emph{result} is \emph{false} but the connection is left
+open. Failure here consists of an abnormal application error.
+
+
+\subsubsection{sid\_destroy}
+\begin{itemize}
+\item Request:\end{itemize}
+\begin{lyxcode}
+(\{cmd:''sid\_destroy'',~sid:''\textless{}sid\textgreater{}''\})\end{lyxcode}
+\begin{itemize}
+\item Response:\end{itemize}
+\begin{lyxcode}
+(\{result:\textless{}boolean\textgreater{},~msg:''\textless{}string\textgreater{}''\})
+\end{lyxcode}
+Requests that the currently being served session be destroyed. This
+is only possible if currently serving that particular SID. In general,
+SID expiration or the application will decide when to destroy the
+SID. This however is provided for convenience where the request could
+be initiated via the HTTPd. The connection is immediately closed after
+the SID is destroyed.
+
+
+\subsection{\label{sub:The-request-server}The request server state}
+
+In this state the application can serve various requests for a specific
+SID until it expires or a request inactivity timeout occurs, causing
+a switch to \emph{The Closing State} (\ref{sub:The-closing-state}).
+These requests are only possible if currently serving a valid, unexpired
+SID. Multiple such requests are processed over the same persistent
+connection.
+
+
+\subsubsection{responder\_get}
+
+\emph{XXX}
+
+
+\subsubsection{responder\_post}
+
+\emph{XXX}
+
+
+\subsubsection{responder\_put}
+
+\emph{XXX}
+
+
+\subsubsection{authorizer\_{*}}
+
+\emph{XXX}
+
+
+\subsubsection{filter\_{*}}
+
+\emph{XXX Might not need SID?}
+
+
+\subsection{\label{sub:The-closing-state}The closing state}
+
+If the SID is not yet to be discarded, the application saves any persistent
+data for the SID before closing, so that resuming requests for it
+under a future connection be possible. The connection is then closed.
+This state information includes the \emph{DATA} object which is automatically
+hanled, as well as optional application specific data which might
+need saving (the application can provide a function to be called at
+this effect).
+
+
+\section{The Web Application Framework}
+
+\emph{XXX}
+\end{document}
diff --git a/mmsoftware/mmmail2/notes/mmmail-design.tex b/mmsoftware/mmmail2/notes/mmmail-design.tex
new file mode 100644 (file)
index 0000000..85f945d
--- /dev/null
@@ -0,0 +1,325 @@
+%% LyX 2.1.2.2 created this file.  For more info, see http://www.lyx.org/.
+%% Do not edit unless you really know what you are doing.
+\documentclass[english]{article}
+\usepackage[latin9]{inputenc}
+\usepackage[letterpaper]{geometry}
+\geometry{verbose,tmargin=0.5in,bmargin=0.5in,lmargin=1in,rmargin=1in}
+\usepackage{graphicx}
+
+\makeatletter
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
+\newenvironment{lyxlist}[1]
+{\begin{list}{}
+{\settowidth{\labelwidth}{#1}
+ \setlength{\leftmargin}{\labelwidth}
+ \addtolength{\leftmargin}{\labelsep}
+ \renewcommand{\makelabel}[1]{##1\hfil}}}
+{\end{list}}
+
+\makeatother
+
+\usepackage{babel}
+\begin{document}
+
+\title{mmmail v2 project design (draft 3)}
+
+
+\author{By Matthew Mondor}
+\maketitle
+\begin{abstract}
+\textbf{mmmail} is currently being redesigned from scratch to support
+new features which the current design could not be easily adapted
+to provide. This design is intended for a new branch, \textbf{mmmail}
+version 2.
+
+\textbf{mmmail}, along with this document, are Copyright (c) 2001-2002,
+Matthew Mondor, All rights reserved.
+
+The status of \textbf{mmmail} version 2, and it's design is currently
+under development. If you can provide any bug report or suggestions
+about the design, please contact Matthew Mondor, via email at \textbf{mmondor@gobot.ca}
+\end{abstract}
+
+\section{Targetted features}
+
+\textbf{mmmail} version 2 should support the following features.
+\begin{lyxlist}{00.00.0000}
+\item [{Domain~administration~delegation:}] It should be possible for
+the system manager to delegate administration tasks to administrators
+of particular domains. In the new design administrators can be specified
+domains they can manage, and various access permissions can be customized
+per administrator.
+\item [{Mail~filtering:}] Mail should be able to optionally be filtered
+when getting in through SMTP before being routed into mailboxes or
+relayed out.
+\item [{SMTP~relaying:}] The current released \textbf{mmmail} implementation
+does not allow relaying messages at all. The new design should allow
+it. It appears to be the most requested feature which alot of users
+need. It should relay using smarthosts or MX routing.
+
+\begin{itemize}
+\item \emph{Design for the smarthosts part not yet complete.}
+\end{itemize}
+\item [{Bandwidth~shaping:}] \textbf{mmmail} should continue to support
+per-connection and global read and write bandwidth speed limits.
+\item [{POP3:}] \textbf{mmmail} already supports POP3 since the start,
+and should continue supporting it. The APOP extension could be supported,
+however this unfortunately requires passwords to be stored in clean
+text into the user database rather than as hashes.
+\item [{IMAP:}] The second most requested feature consists of IMAP support.
+I intend to design the new system in a way to allow making this possible.
+\item [{IMAP-SMTP~and~POP3-SMTP:}] Several times when request was made
+about relaying, mention was done about this technique; Relaying from
+a host would be accepted during a customizable delay (possibly also
+for a customizable maximum number of messages), after a user has successfully
+authenticated via POP3 or IMAP.
+\item [{Per-mailbox~auto-forwarding:}] This feature will allow users to
+auto-forward all incomming mail for a mailbox to another email address,
+if relaying is allowed for that domain, of course.
+
+\begin{itemize}
+\item \emph{Design for this not yet complete, should use permissions.}
+\end{itemize}
+\item [{Mailing~list~management:}] It should be possible for \textbf{mmmail}
+to have mailboxes in fact consisting of mailing lists, for which a
+list of subscribed addreses would be kept. Only mail originating from
+one of those addresses would be accepted and would be copied locally,
+or relayed, to each subscribed address. It also should be possible
+to provide read-only mailing lists, where only specified mail accounts
+can post into.
+
+\begin{itemize}
+\item \emph{Design for this feature not yet complete.}
+\end{itemize}
+\item [{Abstract~authentication~and~storage~modules:}] When the data
+layout design is complete, I intend to write a C library of various
+functions which will be required by all \textbf{mmmail} daemons to
+manage mail. An underlaying lower level library should also be implemented,
+and would internally be used by the former library, via a structure
+of function pointers or other method. This will allow to abstract
+storage and authentication code to use for instance (MySQL, pgsql,
+file, db4, etc).
+\end{lyxlist}
+\newpage{}
+
+
+\section{Database tables design}
+
+\includegraphics[width=8.5in,keepaspectratio,angle=90,bb = 0 0 200 100, draft, type=eps]{/home/mmondor/mmmail/mmmail-tables.eps}
+
+
+\author{Figure 1 - Database tables design}
+
+\newpage{}
+\begin{lyxlist}{00.00.0000}
+\item [{\emph{admin}}] The description of all allowed remote administrators,
+with their permissions. These permissions are described as follows:
+
+\begin{lyxlist}{00.00.0000}
+\item [{\emph{modify\_admin}}] Administrator is allowed to create, delete
+and manage list of administrators for assigned domains.
+\item [{\emph{modify\_domain}}] Permission to create, delete and manage
+domains.
+\item [{\emph{modify\_alias}}] Right to add and delete aliases for assigned
+domains.
+\item [{\emph{modify\_nofrom}}] Permission to add and delete entries of
+allowed addresses/hosts which may use empty \textbf{FROM} commands
+via SMTP.
+\item [{\emph{modify\_relayfrom}}] Privilege to add and delete permanent
+patterns of hosts and address masks to accept relaying from via SMTP.
+\item [{\emph{modify\_user}}] Access to create and delete users within
+the assigned domains, which of course may each have mailboxes.
+\item [{\emph{modify\_box}}] Adminisrator may create, delete and manage
+mailboxes of users within the allowed domains.
+\item [{\emph{modify\_list}}] Administrator can create and delete addresses
+subscribed to mailing lists within assigned domains.
+\end{lyxlist}
+
+It is important that the code makes sure that the login handle be
+unique when inserting a new entry in this table. Of course, an administrator
+who can create administrators can only lower levels of their own administrators;
+They thus cannot change a disabled permission on themselves or on
+their administrators.
+
+\item [{\emph{domain}}] This table contains one entry per known domain.
+Most delegated administration tasks will be performed on objects,
+all tied to specific domains. Tied to domains are the \emph{domain\_admin},
+\emph{alias}, \emph{nofrom}, \emph{relayfrom}, \emph{user}, \emph{box}
+and \emph{list} tables. The domain name is important, and will not
+be found anywhere else within the tables. It is important that the
+code makes sure that the domain name does not already exist when inserting
+a new domain. The \emph{lists} boolean field disables checking for
+mailing lists for this domain if FALSE, thus disabling all mailing
+lists temporarily for it, if any, and making \emph{mmmail-smtpd} faster.
+
+\begin{itemize}
+\item \emph{Add other domain-specific permissions and limits for boxes,
+users, lists, admins, relaying.}
+\end{itemize}
+\item [{\emph{domain\_admin}}] This table specifies which domains are linked
+to which administrators. Several administrators may be assigned to
+a domain, and several domains can be handled by an administrator.
+Of course the administrator permissions should be taken into account.
+\item [{\emph{alias}}] This holds entries for patterns matching a mailbox
+name which should be remapped to specific mailboxes. These only operate
+on the username part of email addresses, as they are domain-specific.
+\item [{\emph{nofrom}}] Each domain can also be assigned a list of hostname
+patterns or address masks which are allowed to use empty \textbf{SMTP
+FROM} commands such as \textbf{FROM:\textless{}\textgreater{}}. This
+table is global rather than tied to specific domains, and only special
+administrators should have access to modify it.
+\item [{\emph{relayfrom}}] Each domain are now assigned a list of client
+hostnames or addresses which should be automatically accepted to relay
+mail for. The expires field allows to implement the \emph{POP3-SMTP}
+and \emph{IMAP-SMTP} methods which could automatically setup an entry
+to allow relaying for a length of time for hosts which successfully
+authenticated through POP3 or IMAP protocols first. Therefore, this
+table holds both permanent relay pattern matching entries, and temporary
+ones, matching specific addresses, which can expire. expires should
+be 0 for permanent entries.
+
+
+Like for \emph{nofrom}, only special administrators are allowed to
+modify the permanent entries of this table. They are global rather
+than on per-domain basis. The temporary expiring entries are automatically
+managed internally, while the permanent ones can be modified by an
+administrator with necessary permissions.
+\begin{itemize}
+\item \emph{It would be trivial to have the temporary expiring entries into
+a memory cache only, rather than in a table. For performance considerations
+this could be done. At least the design shows how it is possible to
+achieve by future} \textbf{\emph{mmmail}} \emph{version 2.}
+\end{itemize}
+\item [{\emph{box}}] Describes each mailbox, tied to their user and domain.
+Each box comports the quota limits with their current counters. It
+is important to make sure that the address field remain unique for
+the current domain when adding new boxes.
+\item [{\emph{list}}] Similarly to \emph{box}, specifies each mailing list
+for a domain. If mailing lists are enabled for a domain (\emph{lists}
+field is TRUE in \emph{domain} table) this table is verified for a
+match by \emph{mmmail-smtpd} when receiving a message, before the
+box table be verified for potential matching. The \emph{from} field
+specifies which \textbf{FROM} address should be used when relaying
+the message to the subscribers. It is important that the code makes
+sure that it does not already exist when inserting a new list address
+for a domain.
+
+\begin{itemize}
+\item \emph{Several other list configuration fields may need to be added
+here. Possibly also a list of users which should not be allowed to
+subscribe, or rather a list of patterns which should match to choose
+which subscriber hosts to accept, etc. Also think of a control system
+on who is allowed to post.}
+\end{itemize}
+\item [{\emph{subscriber}}] This table specifies all subscribed addresses
+for a mailing list. These are verified by mmmail-listd before accepting
+the message for the list, to make sure that only subscribers can post.
+The accepted message is then dispatched to each subscriber, relayed
+if necessary (if relaying is allowed of course).
+\item [{\emph{header}}] A header entry represents a message. As the message
+body can be shared accross multiple instances of the same messages
+in the various mailboxes, only the header is actually copied (See
+\emph{body} table for more information). To this header are either
+linking, with mutual exclusion, an entry from the \emph{filterqueue},
+\emph{boxqueue}, \emph{listqueue} or \emph{relayqueue}.
+
+
+When a header is deleted, it is important to decrease and verify the
+\emph{refcount} field of the corresponding \emph{body} table entry
+it links to, and to delete that body message entry when the counter
+reaches zero.
+
+\item [{\emph{body}}] This table contains all message bodies, to which
+are linking one or more \emph{header} table entries. We maintain a
+\emph{refcount} field which permits to know when this entry is no
+longer referenced and may be deleted. This design permits to reduce
+the frequency of database operations on very large elements, and also
+to greatly optimize the operations and storage space requirements
+on mailing lists where subscribers consist of mailboxes we are providing.
+\item [{\emph{filterqueue}}] This table is only used if \emph{mmmail-filterd}
+runs and mail filtering options have been enabled. It allows to process
+all incomming mail which \emph{mmmail-smtpd} receives through sanity
+checking scripts before it gets dispatched into any other queues.
+The \emph{destination} field permits to know in which queue the message
+should be moved after passing the filter successfully, if it does.
+It also allows application-specific filters to be set by the system
+administrator; A different filtering operation may be wanted for mail
+which has to be relayed than for mail which should be processed for
+a mailing list, etc.
+
+
+If mail filtering is disabled, \emph{mmmail-smtpd} moves the message
+immediately in the queue it belongs to, rather than letting \emph{mmmail-filterd}
+do it asynchroneously.
+
+\item [{\emph{boxqueue}}] All ready messages into all local mailboxes have
+an entry in this table. These are ready to be accessed via \emph{mmmail-pop3d}
+and \emph{mmmail-imapd} services.
+\item [{\emph{listqueue}}] Mail which has been received for an address
+corresponding to a mailing list replicator is stored into this queue
+for processing by the \emph{mmmail-listd} service.
+\item [{\emph{relayqueue}}] All mail which should be relayed out (for both
+mailing list messages to non-local mailboxes and normal relaying)
+is stored in this queue, for processing by the \emph{mmmail-relayd}
+service.
+\end{lyxlist}
+
+\section{Server processes}
+
+Here now consists of a list of the planned server processes, and their
+intended behavior.
+\begin{lyxlist}{00.00.0000}
+\item [{\emph{mmmail-smtpd}}] The standard SMTP server, now called \emph{mmsmtpd},
+which accepts mail from SMTP clients, performing flood protection
+and various sanity checking, and dispatching new mail into the \emph{filterqueue},
+\emph{listqueue}, \emph{boxqueue} or \emph{relayqueue}.
+\item [{\emph{mmmail-filterd}}] Processes the \emph{filterqueue} entries,
+performs wanted sanity checking on mail, and then either drop, or
+move those to the \emph{boxqueue}, \emph{listqueue} or \emph{relayqueue}.
+This process is optional as \emph{mmmail-smtpd} can direct messages
+in their respected queues immediately if filtering is disabled.
+
+\begin{itemize}
+\item \emph{It is still under investigation as to how known third-party
+filters designed for sendmail should be used by} mmmail-filterd\emph{.}
+\end{itemize}
+\item [{\emph{mmmail-listd}}] This process handles the \emph{listqueue}
+and makes sure that the originator address matches a subscribed address,
+to then fill the \emph{boxqueue} to deliver local mailoxes, or the
+\emph{relayqueue} to relay mail out to the subscribers.
+
+
+This server could also support and handle subscription and unsubscription
+requests, sending a confirmation email back with a code which it would
+expect back within a period of time to subscribe the new address.
+\begin{itemize}
+\item \emph{A new table should be created for the expected responses with
+expiration. Also should be taken into account limits for maximum number
+of subscribers, number of failed relayed mail to automatically unsubscribe
+an address, etc.}
+\end{itemize}
+\item [{\emph{mmmail-relayd}}] This server processes the \emph{relayqueue}
+and attempts to act as an SMTP client to send mail out to the SMTP
+servers pointed out by the MX record for the destination domain. An
+entry is deleted from the \emph{relayqueue} when it expires (too many
+retries or expired retry period), in which case reply mail could be
+bounced to the mail originator, or when mail has successfully been
+relayed out.
+
+\begin{itemize}
+\item \emph{Some investigation should be done about how to effectively send
+mail out using more than an RCPT when possible (with decent limit)
+and to send to more than a single server at a time without slowing
+too much database access because of transactions. Moreover, perhaps
+that some MX address cacheing is desirable.}
+\end{itemize}
+\item [{\emph{mmmail-pop3d}}] The standard POP3 protocol client frontend,
+internally processing the \emph{boxqueue}.
+
+\begin{itemize}
+\item \emph{Support for APOP should be envisaged.}
+\end{itemize}
+\item [{\emph{mmmail-imapd}}] The standard IMAP protocol client frontend,
+internally working on the \emph{boxqueue}.\end{lyxlist}
+
+\end{document}