remail/Documentation/introduction.rst

.. SPDX-License-Identifier: GPL-2.0

.. _remail_introduction:

Introduction
============

remail is a very simplistic mailing list tool which provides encryption.

Why yet another mailing list tool?
----------------------------------

The handling of the embargoed hardware security issues made it necessary
to have a encrypted mailing list. Managing Cc lists manually and dealing
with the odd GPG integrations in the mail clients is just not a workable
solution.

There are only a few Open Source implementations of encrypted mailing lists
available. Some of them are abandoned projects. The alive ones have their
own set of shortcomings. One of them supports only S/MIME. The other
supports only PGP, but did not survive testing in a real world
deployment. Repairing ruby code and dis-tangling the thing from its weird
daemons and other over-engineered features was certainly not a project for
the weekend.

After thinking about it for a while, I recognized that for the purpose at
hand the tool can be very simplistic. Using existing tools like getmail and
SMTP servers plus the knowledge about the gory details of emails which I
gained by writing mail handling scripts in python for my daily work, made
it possible to implement it in a rather short time.


What it does
------------

remail reads mail from a maildir, decrypts it with the mailing list private
key and re-encrypts it for every enabled subscriber. The resulting mails are
delivered to the localhost's SMTP server.

remail supports S/MIME and PGP on both ends.

No MUA functionality and no complicated SMTP delivery mechanisms are
required. They all exist in well maintained tools already.

The list configuration is a simple yaml file and is maintained manually
with your favorite text editor. Building tools around that is not part of
this project and there are many existing ways to handle that conveniently.

The proven in use mechanism is to have the configuration files in git and
let the mailing list system either check for updates regularly or get some
external notification that a new configuration is available.


What it does not
----------------

It does not care about mail transport on the receiving side, no POP or IMAP
support as this can be handled by tools like getmail.

It does not care about complex mail transport on the sending side as this
can be handled by SMTP servers like postfix or exim.

It has no integration into SMTP server transports or filters because it
makes no sense to deploy such a sensitive mechanism on a public facing
machine.

It does not come with GUI and managenent tools. A crypto mailing list is
subscribers only for obvious reasons and not meant to handle a large amount
of subscribers. It's meant for secure communications of a small group of
people without having the hassle of keeping Cc lists up to date and
encrypting for every recipient.


How it works
------------

.. image:: remail.svg

The mailing list has the usual post, bounce and owner email addresses on a
public mail server. These addresses are aliased to a user account. The
mails are stored in the users inbox or forwarded to a protected machine.

The mailing list software runs on a protected and separated machine behind
firewalls and access barriers like any other sensitive application.

The mail is retrieved from the public facing machine by any of the existing
mechanisms, e.g. getmail, fetchmail or any MTA which can deliver mail to a
maildir. remail does not implement any transport on the incoming side as
there are good tools available which can handle the requirements of a
particular setup.

The list daemon retrieves the mails from the maildir and selects the
appropriate list via the 'To' header. It then decrypts the incoming mail,
re-encrypts it for each subscriber and delivers it to the local SMTP server
which takes care of relaying it to the public facing SMTP server.