S/MIME is a cryptographic method for Mime messages based on X509 certificate. Before to install Sympa S/Mime features, you must be persuaded that ``S/MIME'' mean ``Secure MIME'' and has nothing to do with ``Simple''.
This chapter just describes what security level is provided by Sympa while using S/MIME messages and to configure Sympa to use it. It is not intended to teach anyone what S/Mime is and why it is so complex ! RFCs number 2311, 2312, 2632, 2633 and 2634 and a lot of literature about S/MIME, PKCS#7 and PKI is available on the Internet. Sympa 2.7 is the first version of Sympa including S/MIME features, this is beta-testing features.
Nothing to do. As Sympa provides nice MIME compatibility, You don't need to do
anything in order to allow subscribers to verify signed messages distributed
through a list. This is not a performence at all, any processus that
distributes messages are compatible with end user
signing processus. Sympa just skips message footer attachement (ref 8.10, page ) to prevent any
body corruption which would break the signature.
Sympa is able to verify S/MIME signatures in order to apply S/MIME authentication method for the message handling. Currently, this feature is limited to the distribution process and to commands when sympa find them in the message body. The reasons of this limitation is related to current S/MIME usage :
S/MIME signature structure is based on a encryption of a digest of the message. Most S/MIME agent does not include any part of the message headers in the message digest so anyone can modify the message header without signature corruption ! This is easy to do, for example, anyone can edit a signed message with his prefered message agent, modify whatever header he want (for example the Subject: , the Date: and thoe To: and redistribute the message in a list or to the robot without breaking the signature.
So we can not apply S/MIME authentication method to command parsed in the Subject: field of a message or via the -subscribe or -unsubscribe email adresse.
In order to be able to send encrypted message to a list, the sender need to use the public key of the list. Sympa will send a crypted message to each subscriber using its personal certificate. To provide this feature, Sympa needs to manage one certificate for each list and one for each subscriber. This will be done in a future version.
All you need is to install openssl (http://www.openssl.org), the minimum requirement is the OpenSSL 0.9.5a. OpenSSL is used by Sympa as an external plugin (like sendmail or postfix), so it must be installed with the apropriate access (x for sympa.sympa).
As the current version is really limited, the configuration is very simple. You just need to teach Sympa where is the binary file for openssl program and where are the certificates of the trusted certificate authority. This is done using the optional parameters openssl and trusted_ca_options.
Once openssl installed and sympa.conf configured,
you sympa is ready for S/MIME. You just need to set the list parameter
depending on the operation you want to secure using S/Mime. Currently,
only the send and subscribe parameter are ready to use S/mime. This one must
refers a scenario written for s/mime usage
(see 7.6, page ).
When receiving a message to distribute, Sympa apply the send scenario with the apropriate authentication method parameter. In most case, the authentication method is ``smtp'', in case the message is signed and the signature as been checked and match the sender email, Sympa apply ``smime'' authentication method.
Take care that if the scenario ignores this authentication method, the message will be rejected. Subsequently, scenario from version previous to 2.7 are not compatible with the OpenSSL configuration of Sympa. All standard scenario (thoses who are distributed with sympa) now includes smime method. The following example is named send.private_smime limit send to subscribers using S/mime signature :
title.us restricted to subscribers check smime signature title.fr limité aux abonnés, vérif de la signature smime is_subscriber([listname],[sender]) smime -> do_it is_editor([listname],[sender]) smime -> do_it is_owner([listname],[sender]) smime -> do_it
It as also possible to mixe various authentication method in a single scenario ; this one send.private_key require either md5 return key or S/Mime signature :
title.us restricted to subscribers with previous md5 authentication title.fr réservé aux abonnés avec authentification MD5 préalable is_subscriber([listname],[sender]) smtp -> request_auth true() md5,smime -> do_it