 Is it work? Yes. Thank you for the introduction. Welcome. My name is Joost van Baal and I will talk about the work I did on integrating mailman with PGP and S-MIME so that you can have a secure list server. You can reach me and you can reach the project. The style of the presentation is somewhat different than the one you saw before. I choose that there are various list servers, of course. I choose to work on mailman and I can show you why. Yes, it works. This is an overview of the various main list servers that are in the open source world and this graph depicts the popularity within WN as WN packages so how many people are using this specific main list server software. As you can see, they all have about the same popularity and this one looks a little bit different. Where's the point up there? This is mailman and this is the rest. So everybody is using mailman. Well, okay, what is the server? Okay, you have someone who wants to post a message to the main list server and the subscribers who want to receive the post. What I did was make it possible that the list itself has a key pair, either PGP or S-MIME and for people wanting to post, they can submit their public keys, either PGP or S-MIME, to the list server. So when a poster encrypts to the list key, then this traffic is encrypted and when a subscriber has submitted this public key to the list, then this traffic can be encrypted too and at both points there also can be authentication because the list server can say, hey, you are a poster but you didn't sign your mail with a submitted key so I'm not allowing your message to get in. At the other side also, the server can sign the outgoing posts with its own key so that people can say, okay, this post really got accepted by the list server and it's not from some other instance. Is that clear or am I wrong? If people want to interrupt me with questions, that's fine with me so please do if you have any questions. Okay. So this is the, for those of you who are familiar with mailman, this is the membership configuration web interface and what I added was here a box to submit your public keys. So these are additions on the mailman code itself and then we have some more configuration interfaces for privacy options. As you can, in the previous slide with the scheme, there are these two points where encryption and authentication can take place. There are various knobs you can tweak to say what you want, what restrictions you want on these two parts in the communication. And these are, here are some knobs for GPG and similar knobs exist for RASMIME. And here you can upload keys if you're a list administrator for your list. So here's another one of these interface where you can tweak the knobs for your specific list. Okay. So both for PGP and for RASMIME, these four knobs exist. For the poster, so this is the first part of whether the mail gets accepted by the list server. You can say should the post be encrypted to the list key, should the post be signed by some register member and once it's accepted, should it be distributed encrypted to the member keys and should the server sign it with its own key. So you can have various options and how strong you want authentication and message integrity. Let's see. Well, this is about the overview I wanted to give of the main list server. Of course, the code is in Python, it's mailman and service in Python. It's submitted at the NAB Bazaar branch. So you can contribute patches, of course. What else? I've got a question, yes, please. Now, currently it's only distributed as a patch, so you have to get the mailman to have it all itself, apply the patch and do configure make, make us all. I'm currently working on binary packages for WN and RPMs, but these are not yet there. Well, actually I started working on the project, the patch exists for quite a long time and I started working on it a couple years ago. At some point in time there were binary packages, but the work continued and the focus is elsewhere. I should mention one other thing, the Ananas Foundation funds the work, so I got a friend to work with. I want to distribute the handouts, I'll come back to you. I have some more complete stories about it, and please pass them, thank you. Should I repeat the question for the audio? Okay. The question was, did I write spam assassin rules to reject or accept the post? No, I did not. The validation of the whether the message is probably signed is done by mailman itself because all the PGP and SMIME handling is in the patch itself, so it's not external. So no spam assassin or whatever. Okay. I want to reject it. Okay. So the spam assassin rules are supposed to be used by someone who subscribes to the list to decide whether the list is probably signed by the list key. Now I did not write these rules, but indeed that's a valuable thing to add. One other thing I should mention, of course you can have encryption and signing. You can use PGP while operating on main lists. You don't need any support on the list server actually, but what the patch adds is it delegates the key management from the subscribers of the user participating in the list to the key server. Is that clear? Traditionally, you'd have to encrypt your message to all the members of the list, and of course that's a hassle if you have big lists. So this key management is delegated and handled by the list itself. I saw another question. The question is what the list server does? That's what you want to know. Okay. Are the list server encrypts to each member separately or grips to all? It encrypts to each member separately. It does not make one message and sends it to all, but they all got specific messages specifically for them. That's an interesting question. The mailman development is interesting. There are about two persons working on the upstream now, which is very few given the installed base on the side of the code. There's a stable branch and unstable branch. Of course upstream doesn't want big changes on the stable branch. And the unstable branch, while some weeks ago there was a first battery release, it's not distributed within any popular distribution, so nobody's using it except for people interested in the mailman development. So that's why I choose to patch the stable base so that I had the opportunity of making with relatively little effort dubbing packages so that people could easily use it. The next version which is going to be used is probably a version of the stable branch. Yes? No, archives are not encrypted. The idea is that if you want to use this functionality, you just should not archive your lists. The archiving is, there's Piper mail, which is a default archive for mailman, which everybody hates. So yeah, I don't think it would be useful to work on that code. Sorry? Oh, okay. You have lots of knobs. And one interesting thing is you could say message, you could allow encrypted messages. And if you have the Chinese dissident case, that someone wants to send out a message to the world, wants to be anonymous and doesn't want the message to get wire tapped in his own network, then he can encrypt it to the list server key. And once it's there, it gets distributed. So that would be a nice case. Of course, it's a very effective, it can be used as a very effective anti-spam measurement because I don't think spam engines are going to use encryption to get send spam to lists. They do? Sign or encrypted? Signed. Jesus Christ. Yeah. Yeah. Yeah. Okay. Yeah, the spam fight, it's a mutual fight. So I think it's just the next step. I don't know. I think it could be helpful. But yeah, well, if you have some secret stuff to discuss that, of course, that's the main use case. You want to discuss privately. You want to be sure about whom you're discussing with. And you don't want to have this big hassle of key management. And that's the main use case, of course. Yes. Yes. No, well, it's always right off. The alternative is that you do key management by all individuals themselves. And that would require lots of clue at each participant in the discussion. So, any more questions? Yes? No, you can submit your public key using the web interface. But there are other scenarios possible. So there's the answer I can choose. No, I don't want this. I want to do the key management in a different way. Oh yeah, you can submit your key only once. Because otherwise, there would be some interesting security issues. Any more questions? We have two more minutes. Okay. Well, I don't know if anybody got the paper. I guess, yeah. Okay. I heard about papers. Well, they're all gone now, but okay. Thank you.