* [License](COPYING): GNU GPL v2
* [Guidelines](GUIDELINES)
+*NOTE:* Firma development is currently on hold, but patches and pull requests are still
+accepted. Please check [schleuder](http://schleuder2.nadir.org) for an alternative.
+
Getting the code
----------------
so no messages -- encrypted or not -- rest on your system in all steps of the
process.
-Everyone has the private key X The server has the private key
--------------------------------------------------------------
+Architecture
+------------
When using a encrypted mailing list software, one must choose between keeping
the private key in the server or send it to each of the subscribers. We'll not
public. Designing Firma, we decided for the centralized model, for three main
reasons:
-1 - A server can be safer than any user's ordinary computer.
+1. A server can be safer than any user's ordinary computer.
-2 - Automation: when some user is removed from the list, we just remove their
-key from the list keyring; in the decentralized approach, the list admin needs
-to regenerate a new list keypair, otherwise the unsubscribed user can still
-decrypt list messages if he can sniff the mail server traffic.
+2. Automation: when some user is removed from the list, we just remove their
+ key from the list keyring; in the decentralized approach, the list admin needs
+ to regenerate a new list keypair, otherwise the unsubscribed user can still
+ decrypt list messages if he can sniff the mail server traffic.
-3 - Use a public-key and all info stored onto it as the subscriber info.
+3. Use a public-key and all info stored onto it as the subscriber info.
Why Bash
--------