Schleuder/ documentation/ v2.2/


Frequently answered questions.

General Questions

What about a webinterface?

Have a look at Webschleuder.

Why yet another encrypted mailinglist?

For two reasons:

  • We didn't (and don't) see a dedicated, stable and usable software doing encrypted mailinglists. We needed one so we wrote one.
  • No other software features remailing emails to non-subscribers (see concept).

Please have a look at other projects doing similar things to compare yourself:

How good/mature is the code?

Please judge yourself or make others do it. We do we best we can but as any software contains bugs Schleuder also does. Some have been found (and closed, see bugs), but not so many. Which means there's still bugs in there.

We'd love to have you tear our code apart. Please don't hesitate to hack and pen-test and tell us about the results — whatever you found out, also no findings is a result!

On the other hand Schleuder is being used by some people with very different mail user agents (aka mail programs), GnuPG-setups, OS-situations and partly strange ideas of inputting content without severe problems since quite a while.

How many people use Schleuder?

We don't know. We do know from some projects that employ or provide Schleuder, which counts up to some dozen lists, but we don't know how many users that makes. And even less we know about the rest of the world, especially since Schleuder is included into the Debian and Ubuntu repositories.

Does it scale?

In general: Yes. We haven't heard of real problems so far. We're expecting a limit, though. Please see the corresponding paragraph in concept.

What does the name mean?

"Schleuder" is a german word for a catapult or slingshot. We don't know exactly anymore who chose the name for what reason but we somehow like it. A slingshot is a simple and low-tech, yet powerful little tool to annoy people coming too close unsolicitedly. If our software suits for similar purposes we're happy.

Where's the public key of the list?

You can receive it by email, see paragraph Sendkey in sending emails.

Technical/Usage Questions

How are list-members identified?

List-members are identified via their GnuPG-key in two possible ways: * The member has a key assigned (key_fingerprint in members.conf), which matches the signing key of an incoming signature. * The member has no key assigned and an UID of the signing key matches the email-address the member is subscribed with.

If the signature cannot be verified the sender is not seen as a member and the email is treated as an external e-mail to the list.

Who can invoke special commands (e.g. ADD-KEY) on the list?

By default only members can invoke special commands on the list. Special commands are processed by plugins which are only invoked for emails that are validated and authorized. This means: An email invoking a special command must be sent by a member, which is cryptographically verified (see above).

It is possible to restrict invocation of specific special commands only to admins of the list, by adding the keyword in question to the keywords_admin_only configuration option.

By default the keywords ADD-MEMBER, DELETE-MEMBER, and DELETE-KEY are listed as admin-only.

How does Schleuder select the right key?

Each Schleuder list has its own keyring containing its own public and private key, as well as all the keys of members and the outgoing peers.

Schleuder selects the key for each member either by the fingerprint given in the members.conf (we strongly recommended to set these!) or (if no fingerprint is assigned) by looking for a key with a UID that matches the members email-address.

To encrypt for non-members Schleuder looks for keys matching the email-addresses in its public keyring. If more than one usable key matches the criteria schleuder skips the recipient and produces an error-notification.

Why doesn't Schleuder fetch keys from keyservers?

Automatic fetching of keys from keyservers would introduce possible Man-in-the-Middle-attacks.

It is vital for gpg-enabled communication to verify your opposite peer. Therefore, it is important to verify the key which will be used to encrypt outgoing e-mails to members or other peers via the resend feature.

Automatic fetching from keyservers would by-pass this verification and you would have no control over which keys Schleuder would use.

Besides the possibility for an undetected MITM-attack this could also be used to pollute the list's keyring with already existing uids. Due to Schleuders key selection mechanism (see above) it would be possible to sabotage communication over the list, as well as break remote administration of the list.

To use keyservers with schleuder safely assign a key to any subscribed member and don't use the resend-feature. Then there's little to fear.

But expiring keys are annoying!

Run contrib/check-expired-keys.rb $listname from cron once a week and be warned in advance.