mail protocols
==============
imap4, pop3 ... are implemented as a simple unix-like applications which
parses a simple shell-like input and convert them into protocol-specific
queries.

The network layer is abstracted by pipes, so you can use any application
to provide a transport layer to the protocol. This is 'netcat' for plain
TCP connections and 'openssl s_client' for SSL ones.

From this point you need a fifo input to feed the program with commands
and a fifo to get the result of the command.

The mail handler pipeline can be described as follows:


                           protocol input
                      .----------------------------------.
                      V                                  |
 +-------+        +-------+          +---------+         |
 | input | stdin  | pop3  | stdout   | netcat  | stdout  |
 | fifo  |------->| imap4 |--------->| openssl |---------'
 +-------+        +-------+          +---------+
                    |  |
                    |  | stderr    +--------+  +--------+
                    |  `---------->| status |  | parsed |
                    |              +--------+  | output |
                    | secondary output         | result |
                    `------------------------->| of cmd |
                                               +--------+

The understanding of this pipe graph reveals that the protocol application
requires two input channels and three output ones.

Three of them are just the basic stdin, stdout, stderr filedescriptors,
and the other two are used to get feedback from the communication channel
and dump the result of the command to a file.

In a posix shell you can implement the pipeline in this way:

  $ rm -f input fifo-in fifo-out output
  $ mkfifo input fifo-in fifo-out
  $ :> output
  $ (while : ; do cat input ; done ) | \
    dmc-pop3 fifo-in output 2> fifo-out | nc host port > fifo-in

In this way the fifo-in fifo file is used to push commands to the daemon.

The fifo-out is used for the parent application to get notifications
when the command has been completely executed. Timeouts are suposed to
be handled by the protocol handler and the manager application should
understand that all those protocols are not going to give you results
inmediately.

An implementation of a manager tool for the previous daemon is:

  $ echo login user pass > fifo-in
  $ cat fifo-out # lock until command is executed
  $ cat output   # retrieve result of command
  ...

The simplest way to test if a protocol handler is working properly is:

  $ dmc-pop3 fifo-in /dev/stderr | nc host port > fifo-in

The pipe graph can be hardly simplified if we embed the transport
layer inside the program.

               _________________
              / ssl, host, port \
              \______,  ________/
                      \|
 +-------+        +-------+ stdout      +--------+
 | input | stdin  | pop3  |------------>| status | fifo lock
 | fifo  |------->| imap4 |--------.    +--------+
 +-------+        +-------+ stderr  \   +--------+
                                     `->| output | truncated file
                                        +--------+

In this way the *nix pipeline becomes:

  $ dmc-pop3 tcp host port

And the daemon pipeline will look like:

  $ mkfifo input outlock
  $ :> output
  $ (while : ; do cat input ; done ) | dmc-pop3 host port 2> outlock > output

PROs:
 - the pipeline is simpler
 - the transport can change from plain to ssl

CONs:
 - ssl cert checks needs to be done inside the application
