Schleuder/ documentation/ v2.2/

concept

Schleuder is a group's gateway: subscribers can communicate encrypted (and pseudonymously) among themselves, receive emails from non-subscribers and send emails to non-subscribers via the list. Schleuder takes care of all de- and encryption, stripping of headers, formatting conversions, etc. Further Schleuder can send out its own public key upon request and receive administrative commands by email.

A servile man in the middle

Basically Schleuder is a "perfect" MITM (man in the middle).

Each list has its own keypair. Schleuder decrypts every incoming email and verifies its signature with the keys from the list's keyring. Then Schleuder loops over the list of subscribers, creates for each a stripped down copy of the message, encrypts it with the subscriber's key and signs it with its own key, and sends it out.

Into to the body of these emails sent to subscribers Schleuder inserts some lines of metadata into the top of the body, containing a (configurable) copy of some of the original headers and the result of the decryption and verification of the incoming email. Here's an example:

    From: Bob <bob@example.net>
    To: schleuder2@nadir.org
    Date: Tue, 6 Apr 2010 17:28:46 +0200
    Enc: encrypted
    Sig: Good signature from 01234567DEADBEEF Bob <bob@example.net>

This MITM-approach contrasts other encrypted mailing list's concepts but it has certain advantages:

  • The software and the users do not face the difficulties of preserving and crafting and verifying relayed signatures: To enable end-users to verify a relayed signature the mailing list software may not change a single bit of the whole message. This becomes quite complicated if you want the software to de- and re-encrypt the messages, though. There's only one possiblity at all: clearsign the message, then encrypt the signed message without signing it again. Any message, that is not crafted exactly like this could not be handled by the software and could not pass the list.
  • No subscriber needs to have access to the private key of the list. This helps if somebody's key is compromised or leaves the list: there's only need to remove one key from the list's keyring, nothing to be done about all the other keys including the list's key. Furthermore the whole management of subscriber's keys becomes a lot easier: each subscriber does only need to know the lists key, not those of all subscribers.

However there is also a disadvantage:

  • The lists private key and its passphrase have to reside on the mailserver. You do have to trust this server ultimately. Absolutely. Fully. Completely. (We have some ideas how to reduce this need for trust you have to give away, but that's nothing concrete yet.)

Here's a schema of how Schleuder works (click to enlarge):

schema of schleuder message flow

Anonymizing

Schleuder has anonymizing features: from the incoming email only little information is copied to the outgoing message. No details on who sent a message from which IP- or email-address is visible publicly (if the outgoing email is encrypted).

Of course this stil does not prevent the analysis of social networks completeley, as agencies can collect data about messages leaving a specific mail system in a certain time frame all with the same subject. But there's no way to tell who sent that message without decrypting the body, unless they also collected data about messages going into the system.

Special Commands

Schleuder can do even more. We implemented a simple plugin-system that enables us (and you) to specifiy so-called keywords and tie some actions to it. Distributed with Schleuder we provide plugins that let subscribers manipulate the list of members, the public keyring, receive specific public keys from the keyring and more (see a list). One of the most used of those is the resend-keyword: it enables subscribers to send emails also to some outside person (see section about Remailing).

Keywords are all upper case, begin with 'X-' and stand in the beginning of the mail body with only blank lines above them (otherwise they are not regconized). If they require an argument, this must be separated by a colon. Arguments spread over more than one line are expected to begin in the line following the keyword. See examples.

Keywords are looked for in every email that's validly signed by a list member. The list's config may limit the use of a keyword to the list admins. If a keyword is forbidden it is still removed from the email but not saved in the list of keywords. Else Schleuder lets every plugin decide if there's something to do, and if yes let's the plugin take action. If the plugin did not end the whole process (which it might by replying directly), Schleuder then continues its work with individualizing the email and sending it.

If you want to write a new plugin please read plugins/README in the source code.

Remailing

Concerning Schleuder we use the term "remailing" to refer to the possibility to send out messsages to non-subscribers. Any member (which by the way is the same as a subscriber) can instruct Schleuder to not only send the current message to all subscribers, but also to send it to other email addresses specified in the message itself. This way Schleuder can also proxy communication to and from people that are not subscribed and maybe don't even know they're communicating with/through a mailing list software.

Please beware: This is not the same meaning the word "remailing" has in the mixmaster-context. With Schleuder only verified members can re-mail a message.

Here's an extended version of the working schema of schleuder including the remailing feature (click to enlarge):

schema of schleuder message flow, with resend

A group's gateway

As mentioned before Schleuder is designed as a tool for group communication. Any number of people can receive emails from the outside and also send emails back out while still staying opaque behind the one email-address driven by Schleuder.

A common use for Schleuder are contact-addresses for collective projects (think of info@...). Incoming emails are (re)encrypted and forwarded to each subscriber, which can communicate internally as well as answer to the original sender via Schleuder. To the outside person all this is only an email address with a public key. He/she does not know who or even how many people wrote the answer (unless there's information about that in the body of course), how many people did read his/her email in the first place, or where geographically the author(s) of the answer might be located.

The outside person does know, however, that he/she is communicating with a single, consistent entity as Schleuder signs all outgoing emails.

Scalability

Schleuder probably has a scalability problem. We know lists running with 75+ subscribes flawlessly. But if you run Schleuder on old hardware with some hundreds of subscribers we prognose problems. On one hand this is due to the repeated de- and encryption processes, which need quite some CPU-cycles and a nice load of randomness. On the other hand Schleuder presently holds the delivery-connection from the MTA open until the whole list is processed, during which it sequentially opens one smtp-connection back to the MTA for each outgoing email. That can take some time and definitely takes some ressources.

A solution for this would be to fork at an earlier time. We're thinking about this, but before we actually do such change we'd like to see or hear about some experiences with these considerations. If you have some, please share it with us!