Re: [Mailman-Developers] Hi from a student interested in a GSoC project
Richard Wackerbarth writes: > Therefore, I would suggest that a migration be broken into some components, > 1) Migrate individual list parameters > 2) Aggregate groups of lists > 3) Migrate individual subscriptions > 4) Aggregate subscriptions by "person". +1, and perhaps some of these are big/error-prone enough to constitute whole GSoC projects themselves. (I don't say that they are, but we should think about it during design of an intern's project.) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion
Terri Oda writes: > Writing individual pipelines may be trivial, but making a user interface > for managing said pipelines is non-trivial. Right now, our pipeline > management interface is "there's a text box in postorius that lets you > choose a pipeline. It's not even a dropdown, and you may be screwed if > you make a typo" which is obviously not how I want it when we > release. ;) That's a more general issue (oh, I see you noticed that! :-), and I have no problem with doing something about it -- indeed, I'd be more than happy to (co-)mentor it because I just *love* custom Handlers. Here's what I would do: 1. Get the list of handlers active to the list. 2. Append the list of inactive handlers from Mailman/Handlers (the site's list, not the distributed handlers). 3. The UI is table with rows containing a checkbox for "active handler" (the row should be greyed out if it's inactive), an ordinal (numerical), and the handler name (gold star for popping up a tooltip with a detailed description/docstring on mouseover). 4. Users can either change the numbers (error checked for uniqueness), with a partial order on standard handlers -- if the partial order is violated (including a missing handler like "ToOutgoing") the user is warned; or (platinum star) drag the handlers into the order they like (with same checks on the partial order). > I see a potential project timeline going something like this: > > A. make a set of custom Mailman 3 Handlers for some well-known existing > anti-spam/anti-malware software. (Maybe 2-3 weeks of work here, finding > 2-4 reasonable pieces of software, setting them up, writing the > handlers, and testing them) One week for that work, it's all in the FAQ already I suspect. > B. make an interface in Postorius so list admins can > enable/disable/reorder these and any whitelisting happening within > mailman. This should involve making an interface in Postorius that > gives admins the ability to change the Pipeline being used, and will > likely involve a small amount of user testing to make sure said > interface doesn't have risk of disastrous results if the administrator > does the wrong thing. (Another 3-4 weeks of work including user > testing, unit tests, and documentation) You think the design above will take more than two days (one to learn how to do D&D to reorder a list) to code, and 4 to document and test? (I'm assuming Mailman2 kinds of pipeline APIs are already available. If new REST API is needed, OK, 3 weeks total.) > C. Figure out how to set up some sort of packager that can install > handlers + antispam software so that the site admin has an easy way to > set these up if requested. (Another 3-4 weeks of work, including testing > any scripts on a few different OSes and extensive documentation) OK, yes, getting PyPI down for the Handlers themselves (while these *could* be delivered with Mailman, I think it would be more valuable to have a standard PyPI delivery protocol for 3rd party Handlers) will likely take that much time, and indeed one needs to deal with OS PMS. > Do feel free to disagree with me, of course, Stephen. I am indeed a curmudgeon about the antispam stuff. I don't think the first release of Mailman 3 should contain an attractive nuisance like serious antispam in Mailman (vs antispam in the MTA). I'll try to keep such negative thinking to one paragraph per post, though. :-) > Or complain that I'm using the lure of antispam to get someone > solve my user interface for pipelines problem, which I totally > am. ;) While I do think that an initial implementation is probably a total of about 2 weeks worth of work, I suspect that one could riff on the theme (hi, Barry, like that metaphor?) for a couple more weeks, and robust disaster recovery (saving off the old pipeline and restoring looks simple enough, but Mr. Murphy is lurking, I'm sure -- in particular, if we're going to allow through-the-web pipelines, we need to guarantee that received mail will not get lost if the pipeline is horked) could account for a couple more weeks. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion
* Stephen J. Turnbull : > Sreyanth writes: > > > 3. Anti-spam / anti-abuse in Mailman. > > A couple of people have mentioned anti-spam, and it's a frequently > requested feature. Nevertheless, I don't think we should spend Google > money and mentor time on it. I concur. > 1. Mailman is the wrong place to do filtering. It's equally > effective, normally covers more messages, and is somewhat more > efficient in resource usage to do it at the MTA. Spam-filtering is expensive. It should be done only once - at sender level and not for each recipient of a mailing list. We could let Mailman do it when the mail enters, but what would be the gain? There's plenty of software out there that already knows how to battle spam. Even worse! In some countries - take Germany for example - you either reject spam at SMTP session level while the sending client is still there and will take notice or you MUST deliver it - else you break the law because you took reponsibility for transport, but supressed the message. Mailman is part of a mail system, but it I don't expect it will ever become the component that will communicate directly with a remote (spam sending) client. All the work to add an anti-spam feature in Mailman would be 'useless' to countries with laws as I described above. BUT ... I think it would be real nice to have a MILTER interface at LMTP server level to allow mail modification as required. Mailman runs in large environments and all the 'large organizations' I have worked asked my team and me to customize how mail is processed. MILTER is a great interface to modify mail. > 2. Any new algorithms *should* be made available at the MTA level > where they can be best put to use by more people. This implies > something that either plugs into existing filters (such as > spamassassin) or MTAs (ie, milters) rather than a Handler. > 3. Adapting existing filters is generally pretty trivial: you write a > 10-line custom Handler that pipes it to an external process. This > isn't big enough for a GSoC project. > 4. To the extent that new algorithms are involved, I have doubts that > Mailman mentors have the kind of expertise needed to really help > with such a project (I could be wrong, but I certainly don't know > much about that kind of text processing, and I don't know that > anybody else in Mailman has expertise in it). > > On the other hand, I don't know which project in GSoC would be a > better place for it. It's possible to argue that Mailman is a > reasonable place for it, but IMHO we probably shouldn't. I hate to stand in the way of someone, who wants to contribute to OSS, but IMHO we shouldn't either. > Regarding anti-abuse, we would like to do something about problems > like backscatter. However, I have to wonder how much *code* (vs > *specification* and *design*) is needed for those problems. If the > project is really spec-heavy, it's probably not really what Google has > in mind (based on comments on the mentors' list, not on any official > Google pronouncements, though). Has anyone ever mentioned SNMP as a feature for Mailman? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] A feature I'd like to emphasize for GSoC ...
... is *convenient access to logs via the admin interface*. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Hi from a student interested in a GSoC project
On Apr 11, 2013, at 07:02 PM, Richard Wackerbarth wrote: >I encourage any GSoC candidates to actively discuss design issues on this >list. Many aspects of MM3 remain only partially defined and still require >design in addition to the coding that will follow. Although some might expect >the mentors might "spoon feed" coding tasks, as a mentor, I would prefer to >work with someone who is actively involved in the design as well as the >implementation. Totally agree. >First, there are some parameters that do not relate to any particular mailing >list. IMHO, these aspects need not even be addressed in a conversion. If I >wish to set up a MM3 installation, I should first, manually, set up a sample >list. After I do so, the configuration of any "real" lists needs to be >COMPLETELY configurable using the REST interface. If that interface is not >presently adequate, it needs to be revised rather than "working around" any >deficiency. The REST API is pretty easy to extend. By far the most time consuming bit (assuming you know where you want your resources to live) is writing docs and tests. For many of the GSoC tasks, extending the REST API should be considered part of the work. This of course includes both in the core and in the mailman-client wrapper. >Therefore, I should be able to set up my "sample list" and, thereafter, >add/edit all of the real lists utilizing the same interface (using >mailman.cliient, etc.) that is available to the Postorius interface for list >creation/editing. A migration tool would, therefore, need only "simulate" >those manual steps that the installer would execute on a web-based interface >to create a new list and adjust its settings. Perhaps. I think migrations could be done this way, but it's probably more efficient to do it against the internal API. >Similarly, handling the subscriptions must be something that can be done >using just the access exposed via the REST interface. > >The big distinction between MM2 and MM3 lies in the conceptual model of >entities. In MM2, each subscription is a separate entity. In MM3, >subscriptions belong to "persons" and management functions are made available >for the person to affect multiple subscriptions at the same time. > >In translating from MM2 to MM3, the aggregation of subscriptions under a >common "person" becomes a non-trivial task. However the mechanisms required >to handle reassignment are needed within MM3 implementations because there is >an alternate access mechanism (admin by email) which cannot directly identify >these "persons". Absolutely right. It's an open question as to how to merge user records. Because the user "databases" in a multi-list MM2 site are silos, there's no connection between my settings in listA and my settings in listB. How would you combine those into a single user record for MM3? Additionally, in MM2 you don't now that m...@example.com and m...@example.com are both owned by me. While it's probably impossible to merge these two records when migrating them to MM3, we would like to have *some* way to merge the two records once they're migrated to MM3. We'd need to work out the workflow for that, including any security guarantees, so that a user could merge those records after a migration. >Therefore, I would suggest that a migration be broken into some components, >1) Migrate individual list parameters >2) Aggregate groups of lists >3) Migrate individual subscriptions >4) Aggregate subscriptions by "person". -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Hi from a student interested in a GSoC project
I encourage any GSoC candidates to actively discuss design issues on this list. Many aspects of MM3 remain only partially defined and still require design in addition to the coding that will follow. Although some might expect the mentors might "spoon feed" coding tasks, as a mentor, I would prefer to work with someone who is actively involved in the design as well as the implementation. Having looked at MM2->MM3 migration in the past (and deferred implementation because critical infrastructure was not available at that time) let me present a different perspective. First, there are some parameters that do not relate to any particular mailing list. IMHO, these aspects need not even be addressed in a conversion. If I wish to set up a MM3 installation, I should first, manually, set up a sample list. After I do so, the configuration of any "real" lists needs to be COMPLETELY configurable using the REST interface. If that interface is not presently adequate, it needs to be revised rather than "working around" any deficiency. Therefore, I should be able to set up my "sample list" and, thereafter, add/edit all of the real lists utilizing the same interface (using mailman.cliient, etc.) that is available to the Postorius interface for list creation/editing. A migration tool would, therefore, need only "simulate" those manual steps that the installer would execute on a web-based interface to create a new list and adjust its settings. Similarly, handling the subscriptions must be something that can be done using just the access exposed via the REST interface. The big distinction between MM2 and MM3 lies in the conceptual model of entities. In MM2, each subscription is a separate entity. In MM3, subscriptions belong to "persons" and management functions are made available for the person to affect multiple subscriptions at the same time. In translating from MM2 to MM3, the aggregation of subscriptions under a common "person" becomes a non-trivial task. However the mechanisms required to handle reassignment are needed within MM3 implementations because there is an alternate access mechanism (admin by email) which cannot directly identify these "persons". Therefore, I would suggest that a migration be broken into some components, 1) Migrate individual list parameters 2) Aggregate groups of lists 3) Migrate individual subscriptions 4) Aggregate subscriptions by "person". Note that the aggregation functions for both lists and persons require similar mechanisms and that having the ability to edit those configurations within Postorius will be beneficial to both migration and routine system operation. Richard On Apr 11, 2013, at 3:11 PM, Barry Warsaw wrote: > On Apr 11, 2013, at 02:22 PM, Elias Assarsson wrote: > >>> * MM2's configuration file is a Python file which really must be imported >>> in order to get a valid set of values. MM3's configuration file is a stack >>> of .ini-style files. > >> I am trying to find and understand the configuration files so that I know >> what that that needs to be migrated and to what form. Is the MM2 >> configuration you refer to mainly Mailman/mm_cfg.py and MM3 configuration >> files src/mailman/config/* and /src/mailman//*? > > Yes, in a deployed Mailman 2, mm_cfg.py will contain the system configuration > settings. These override the settings from Defaults.py so a good way to > explore is to use `bin/withlist` and `import mm_cfg` at the Python prompt. > > In MM3, we use lazr.config, which is essentially a configparser type package > that allows for stacks of configurations, with pushing and popping values on > this stack. > > http://pythonhosted.org/lazr.config/ > > The src/mailman/config/schema.cfg file is at the bottom of the stack and > defines the schema, obviously :). From there, src/mailman/config/mailman.cfg > essentially instantiates this schema, providing all the defaults. In the > testing environment, src/mailman/testing/testing.cfg gets pushed on top of > that (and many tests push and pop micro-overrides). In a deployed system, the > site's mailman.cfg is on the top of the stack and so can override anything. > There are various places this mailman.cfg file is searched; see > src/mailman/core/initialize.py for all the gory details. > > List-specific configurations live in the various config.db files for MM2. > These are pickles. In MM3, everything's in the database. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Hi from a student interested in a GSoC project
On Apr 11, 2013, at 02:22 PM, Elias Assarsson wrote: >> * MM2's configuration file is a Python file which really must be imported >> in order to get a valid set of values. MM3's configuration file is a stack >> of .ini-style files. >I am trying to find and understand the configuration files so that I know >what that that needs to be migrated and to what form. Is the MM2 >configuration you refer to mainly Mailman/mm_cfg.py and MM3 configuration >files src/mailman/config/* and /src/mailman//*? Yes, in a deployed Mailman 2, mm_cfg.py will contain the system configuration settings. These override the settings from Defaults.py so a good way to explore is to use `bin/withlist` and `import mm_cfg` at the Python prompt. In MM3, we use lazr.config, which is essentially a configparser type package that allows for stacks of configurations, with pushing and popping values on this stack. http://pythonhosted.org/lazr.config/ The src/mailman/config/schema.cfg file is at the bottom of the stack and defines the schema, obviously :). From there, src/mailman/config/mailman.cfg essentially instantiates this schema, providing all the defaults. In the testing environment, src/mailman/testing/testing.cfg gets pushed on top of that (and many tests push and pop micro-overrides). In a deployed system, the site's mailman.cfg is on the top of the stack and so can override anything. There are various places this mailman.cfg file is searched; see src/mailman/core/initialize.py for all the gory details. List-specific configurations live in the various config.db files for MM2. These are pickles. In MM3, everything's in the database. >Given the two points above it seems that handling the migration from within >Python is the best choice (rather than using Augeas which is C based or >Config::Model which is Perl based). I think so. Pickles in particular are Python-specific. You could generate an intermediate format, but I'm not sure it's worth it. >Obviously one wants to use whatever feature of Python that can ease the >process. You seem to be using configparser in MM3. I dunno if there are any >other Python tool one should look at in helping migration. Maybe one should >investigate this further. >> * What about importing archives? >I have tried to find information on how archives are stored in MM2 and MM3 >but failed to find any. What is a good source to learn about this? Importing archives will either be trivial or impossible :). At the lowest level, parsing the MM2 .mbox file and generating maildirs would work, but there are existing tools to do that, so probably little for GSoC to worry about. Much more interesting would be to parse the Pipermail database files and try to build a reverse mapping from URL to Message-ID so that these could be preserved when the archive is regenerated for HyperKitty or whatever. >> There is some moderate beginnings in the 3.0 tree, but none of it is >> functional in all likelihood. Take a look at src/mailman/bin/export.py >> and src/mailman/commands/cli_import.py. >So those are the files that are supposed to handle migration for which the >project is to make them handle a complete migration from MM2 to MM3? Well, I'd say they were more some unfinished work in that direction. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion
On 13-04-11 10:44 AM, Stephen J. Turnbull wrote: 1. Mailman is the wrong place to do filtering. It's equally effective, normally covers more messages, and is somewhat more efficient in resource usage to do it at the MTA. 2. Any new algorithms*should* be made available at the MTA level where they can be best put to use by more people. This implies something that either plugs into existing filters (such as spamassassin) or MTAs (ie, milters) rather than a Handler. 3. Adapting existing filters is generally pretty trivial: you write a 10-line custom Handler that pipes it to an external process. This isn't big enough for a GSoC project. 4. To the extent that new algorithms are involved, I have doubts that Mailman mentors have the kind of expertise needed to really help with such a project (I could be wrong, but I certainly don't know much about that kind of text processing, and I don't know that anybody else in Mailman has expertise in it). Writing individual pipelines may be trivial, but making a user interface for managing said pipelines is non-trivial. Right now, our pipeline management interface is "there's a text box in postorius that lets you choose a pipeline. It's not even a dropdown, and you may be screwed if you make a typo" which is obviously not how I want it when we release. ;) I see a potential project timeline going something like this: A. make a set of custom Mailman 3 Handlers for some well-known existing anti-spam/anti-malware software. (Maybe 2-3 weeks of work here, finding 2-4 reasonable pieces of software, setting them up, writing the handlers, and testing them) B. make an interface in Postorius so list admins can enable/disable/reorder these and any whitelisting happening within mailman. This should involve making an interface in Postorius that gives admins the ability to change the Pipeline being used, and will likely involve a small amount of user testing to make sure said interface doesn't have risk of disastrous results if the administrator does the wrong thing. (Another 3-4 weeks of work including user testing, unit tests, and documentation) C. Figure out how to set up some sort of packager that can install handlers + antispam software so that the site admin has an easy way to set these up if requested. (Another 3-4 weeks of work, including testing any scripts on a few different OSes and extensive documentation) D. If there's any time leftover, implement some clever new filter (and appropriate Handler) that makes use of the list information itself (e.g. subscriber list, archives, etc.) to make better spam decisions. (at this point, you've got maybe 2 weeks left in the GSoC timeline) I think that constitutes enough useful-to-mailman work to justify the google funds, gets us some customizable spam filtering (which as you say, is a frequently requested feature), but doesn't turn us into something we're not. That's why anti-spam made this year's gsoc list even though we've always said "do it in the MTA" and I'm not about to change that policy in general. Do feel free to disagree with me, of course, Stephen. Or complain that I'm using the lure of antispam to get someone solve my user interface for pipelines problem, which I totally am. ;) Terri ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] GSoC 2013 - GNU Mailman - Introduction and Project Discussion
Sreyanth writes: > 3. Anti-spam / anti-abuse in Mailman. A couple of people have mentioned anti-spam, and it's a frequently requested feature. Nevertheless, I don't think we should spend Google money and mentor time on it. 1. Mailman is the wrong place to do filtering. It's equally effective, normally covers more messages, and is somewhat more efficient in resource usage to do it at the MTA. 2. Any new algorithms *should* be made available at the MTA level where they can be best put to use by more people. This implies something that either plugs into existing filters (such as spamassassin) or MTAs (ie, milters) rather than a Handler. 3. Adapting existing filters is generally pretty trivial: you write a 10-line custom Handler that pipes it to an external process. This isn't big enough for a GSoC project. 4. To the extent that new algorithms are involved, I have doubts that Mailman mentors have the kind of expertise needed to really help with such a project (I could be wrong, but I certainly don't know much about that kind of text processing, and I don't know that anybody else in Mailman has expertise in it). On the other hand, I don't know which project in GSoC would be a better place for it. It's possible to argue that Mailman is a reasonable place for it, but IMHO we probably shouldn't. Regarding anti-abuse, we would like to do something about problems like backscatter. However, I have to wonder how much *code* (vs *specification* and *design*) is needed for those problems. If the project is really spec-heavy, it's probably not really what Google has in mind (based on comments on the mentors' list, not on any official Google pronouncements, though). ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Hi from a student interested in a GSoC project
Elias Assarsson writes: > On another note I have been able to setup a web UI although it took far > longer than 5 minutes as I struggled with problems due to having both > Python 2.7 and 3.2 on my system. Did you try a virtualenv? That usually helps with such problems. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] OpenPGP Integration on GSoC
On 11.04.2013 14:35, Richard Damon wrote: >> Next problem: Mailman will have to decrypt the message and re-encrypt it >> for each recipient. This also strips the signature of the original >> sender. How do you show to the recipients that the original message was >> signed (in a way which cannot be forged by any other sender)? > Decrypting and re-encrypting shouldn't break signatures as the sender > should First sign the unencrypted message, and then encrypt it. The > signature can then be passed on in the re-encrypted message, and people > can do their verification of the signature. True, the PGP file structure encapsulates the signature within the encryption (in contrast to S/MIME, which does it vice versa). But the standard PGP binary will strip both in one step, so keeping the signature won't work out of the box (at least I didn't manage to do that, I'd be really interested how to do that - would be useful for searchable mail archives). Stefan. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] OpenPGP Integration on GSoC
On 4/11/13 3:23 AM, Stefan Schlott wrote: > On 11.04.2013 06:19, Joost van Baal-Ilić wrote: > >> I am Joost van Baal-Ilić. I create a PGP keypair with ID Barry Warsaw. I >> sent >> the public key to the list server. I sent a mail, signed with the Barry-key, >> encrtypted to the listkey, with From: Barry's email address, to the list. >> The listserver now distributes it to the lists subscribers, yes? The list >> subscribers will believe the message is from Barry. > You would have to do some key confirmation, just like you have to click > a mail confirmation link upon subscription. > > Next problem: Mailman will have to decrypt the message and re-encrypt it > for each recipient. This also strips the signature of the original > sender. How do you show to the recipients that the original message was > signed (in a way which cannot be forged by any other sender)? > > > Generally speaking PGP support would be great, the efforts Joost and I > made about 10 years ago never made it beyond alpha (or beta at best) > stadium... > > > Stefan. > Decrypting and re-encrypting shouldn't break signatures as the sender should First sign the unencrypted message, and then encrypt it. The signature can then be passed on in the re-encrypted message, and people can do their verification of the signature. It is up to each recipient to decide how well they trust the identity of the sender. Digital keys do NOT naturally verify the identity of the sender, the verify that the sender is a possessor of the signing key, and it is the web of trust on the key management side that connects that with an individual identity. Also, re-encrypting to each recipient isn't as big of a job as it might seem, as actually what happens is a session key is made, and this is used to encrypt the message, the the session key is encrypted with the recipients public-key, so only this last piece needs to be done per recipient. You probably need to send copies individually, or every message will have information about who is subscribed to the list. -- Richard Damon ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Hi from a student interested in a GSoC project
Thanks for an informative answer! 2013-04-10 20:14, Barry Warsaw skrev: Definitely investigate these tools, although my suspicion is that they won't help, or at least won't help enough to make accepting a new dependency worth it. There are a few problems to consider: * MM2's configuration file is a Python file which really must be imported in order to get a valid set of values. MM3's configuration file is a stack of .ini-style files. I am trying to find and understand the configuration files so that I know what that that needs to be migrated and to what form. Is the MM2 configuration you refer to mainly Mailman/mm_cfg.py and MM3 configuration files src/mailman/config/* and /src/mailman//*? * There is not always a 1-to-1 correspondence between MM2 values and MM3 values. Some configurations have been merged, some removed, etc. You will pretty much have to go through each set of MM2 variables and decide if and how to transform them into something meaningful for MM3. * The configuration files are only for system-wide settings. We really also want to be able to upgrade MM2 lists to MM3 lists, and that involves unpickling the config.db state and again, mapping the MM2 variables to MM3 variables, which are stored in a database. Given the two points above it seems that handling the migration from within Python is the best choice (rather than using Augeas which is C based or Config::Model which is Perl based). Obviously one wants to use whatever feature of Python that can ease the process. You seem to be using configparser in MM3. I dunno if there are any other Python tool one should look at in helping migration. Maybe one should investigate this further. * What about importing archives? I have tried to find information on how archives are stored in MM2 and MM3 but failed to find any. What is a good source to learn about this? There is some moderate beginnings in the 3.0 tree, but none of it is functional in all likelihood. Take a look at src/mailman/bin/export.py and src/mailman/commands/cli_import.py. So those are the files that are supposed to handle migration for which the project is to make them handle a complete migration from MM2 to MM3? On another note I have been able to setup a web UI although it took far longer than 5 minutes as I struggled with problems due to having both Python 2.7 and 3.2 on my system. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Setting up a VM.
Hello again community. Two days ago I made a sort introduction of my self and stated that I'm interested in implementing the "Web Posting Interface" project(through this e-mail - http://www.mail-archive.com/mailman-developers%40python.org/msg13451.html). In order to getting started with Mailman development I went through the equivalent quote(here - http://wiki.list.org/display/DEV/Google+Summer+of+Code+2013). Since I'm able to consume the services described here : https://okeanos.grnet.gr/services/cyclades/ , I would like to setup a VM and also make it available for future developers. If you're interested in this, poke me to arrange a meeting in IRC and discuss any further details. Best regards, Peter Markou. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] OpenPGP Integration on GSoC
Hi (and hi Stefan!), On Thu, Apr 11, 2013 at 09:23:35AM +0200, Stefan Schlott wrote: > On 11.04.2013 06:19, Joost van Baal-Ilić wrote: > > > I am Joost van Baal-Ilić. I create a PGP keypair with ID Barry Warsaw. I > > sent > > the public key to the list server. I sent a mail, signed with the > > Barry-key, > > encrtypted to the listkey, with From: Barry's email address, to the list. > > The listserver now distributes it to the lists subscribers, yes? The list > > subscribers will believe the message is from Barry. > > You would have to do some key confirmation, just like you have to click > a mail confirmation link upon subscription. > > Next problem: Mailman will have to decrypt the message and re-encrypt it > for each recipient. This also strips the signature of the original > sender. Not necessarily, iirc. > How do you show to the recipients that the original message was > signed (in a way which cannot be forged by any other sender)? > > Generally speaking PGP support would be great, the efforts Joost and I > made about 10 years ago never made it beyond alpha (or beta at best) > stadium... ACK. Bye, Joost ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] OpenPGP Integration on GSoC
On 11.04.2013 06:19, Joost van Baal-Ilić wrote: > I am Joost van Baal-Ilić. I create a PGP keypair with ID Barry Warsaw. I > sent > the public key to the list server. I sent a mail, signed with the Barry-key, > encrtypted to the listkey, with From: Barry's email address, to the list. > The listserver now distributes it to the lists subscribers, yes? The list > subscribers will believe the message is from Barry. You would have to do some key confirmation, just like you have to click a mail confirmation link upon subscription. Next problem: Mailman will have to decrypt the message and re-encrypt it for each recipient. This also strips the signature of the original sender. How do you show to the recipients that the original message was signed (in a way which cannot be forged by any other sender)? Generally speaking PGP support would be great, the efforts Joost and I made about 10 years ago never made it beyond alpha (or beta at best) stadium... Stefan. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
