Re: [Mailman-Developers] URGENT: Google Summer of Code status report and code due

Alexander Sulfrian writes: > If the list_name would be also reversed, it could lead to some > surprising subtree clashing. For example web2.0 would be in the same > subtree like something1.0 (people sometimes use strange list > names...). I agree that list_name should *not* be reversed; it is

Re: [Mailman-Developers] Login / User Identification Issues in MM3

Richard Wackerbarth writes: > There seems to be two fundamental design strategies being discussed. > One of them has a monolithic data store and the other has a > distributed store. > Barry has expressed some reservations about overloading a > monolithic data store with data extraneous to the

Re: [Mailman-Developers] Login / User Identification Issues in MM3

Barry Warsaw writes: > I don't see any reason why it couldn't be mapped to a REST API; it's just a > lack of need, and nobody's written it yet. The question is whether > IUserManager is actually the right API for a REST interface - in general I > don't think you need a 1-to-1 mapping of inter

Re: [Mailman-Developers] Login / User Identification Issues in MM3

Barry Warsaw writes: > The question is whether we want to support running the core without > having this user service available, i.e. in standalone mode. Are > we going to require that this service be running in order to run > the core? I think we shouldn't be so strict. But *some* user ser

Re: [Mailman-Developers] Login / User Identification Issues in MM3

Richard Wackerbarth writes: > I think that you have missed a level of abstraction. Why do we need it? AFAICS, at this point we have a bunch of services that need to be specified somehow. We *need* a RESTful interface for some functions because they make the most sense if accessed remotely, and

Re: [Mailman-Developers] Login / User Identification Issues in MM3

Richard Wackerbarth writes: > We should not be required to repeat this in the future. Therefore, > we need to have a service level interface for ALL inter-service > interactions, even if we do not require the RESTful implementation > of those interactions at this time. I guess I think of "com

Re: [Mailman-Developers] Exposing not advertised lists via nntp archiver

Joshua Cranmer writes: > > How to solve that? The only possibility I could think of uses the > > filter mechanism of the available newsgroups. The clients could supply > > a regexp like filter. I would implement a mechanism, that shows > > unadvertized lists with an archive only if the supplie

Re: [Mailman-Developers] Login / User Identification Issues in MM3

Richard Wackerbarth writes: > I think that you are finally beginning to understand the > perspective that I am trying to provide. I don't have any trouble understanding the perspective you're trying to provide in the abstract; it's just Software Systems Design 301. What I have trouble seeing i

Re: [Mailman-Developers] Bug 971013 - schema migrations BLOCKED

Barry Warsaw writes: > >This bug is about providing orderly schema migrations. I now admit that I'm > >blocked and I'm looking for suggestions. > > I actually think I've finally cracked this nut. I have it working > for SQLite, and am now testing for Postgres. When I get that > working a

Re: [Mailman-Developers] mailing list to work with ADSP and DMARC

Patrick Ben Koetter writes: > My bet is you will receive more feedback if you start implementing DMARC > relevant features into MM3 code. If you get Murray Kucherawy, I don't know if > he's still on the list, to contribute/share ideas on DMARC you will very > likely get a bulletproof implement

Re: [Mailman-Developers] translation of mail templates

Patrick Ben Koetter writes: > They have free accounts for open source projects. It might be a > nice way to organize a translation community. It's likely that we don't have to organize one, we already have one. Barry, why don't you try to get in touch with that Vietnamese lady and see what she

Re: [Mailman-Developers] translation of mail templates

Mark Sapiro writes: > If mailman generates web pages with non-ascii, say utf-8 encoded > characters and the installation's web server assigns a default character > set other than utf-8, all the utf-8 encoded characters will be garbled. > This will not happen if the characters are encoded as HT

Re: [Mailman-Developers] Getting to Mailman 3.0 final

Patrick Ben Koetter writes: > I think if we release MM3 without 'a frontend' we will miss > people's expectation to get a feature complete MLM - which includes > a frontend in most peoples opinion I guess. I agree on the basis of introspection (which is obviously a statistically biased sample)

Re: [Mailman-Developers] "newlist" command and Mailman 3

Barry Warsaw writes: > Currently, JSON is the only supported output format. I'd be open to patches > that provide other output formats. Please, no. "Filters are one honking great idea. Let's do more of those!" I think most of the interesting programming languages people might write Mailman

Re: [Mailman-Developers] Getting to Mailman 3.0 final

Bob Puff@NLE writes: > I don't want more servers (processes). I need secure, > low-footprint, low cpu-utilization processes. You're not going to get more processes unless you want them. The processes currently planned are just called "runners" now, and will be less coupled than currently. Whe

Re: [Mailman-Developers] Getting to Mailman 3.0 final

Terri Oda writes: > That said, I'm tentatively planning a personal postorious hackathon all > day Saturday the 22nd. If anyone wants to join me, I'll be on #mailman > on freenode! I don't think I can join but maybe Could you be a bit more specific than "all day" (especially time zone)

[Mailman-Developers] Unforeseen difficulties with the Mailman logo

Terri Oda writes: > I don't suppose anyone here has some hidden graphics-fu and could help > me out? the buttons have a 1.375in printable area, I'm no graphics expert, but at that size, I'd avoid gradients unless you've got at least 1200dpi, preferably 2400dpi resolution. You could try offse

[Mailman-Developers] GHC 12 Open Source Day was amazing!

Terri Oda writes: > I think people had a lot of fun seeing their code go live on our test > server and watching their bugs get fixed, and I think we've got a few > contributors who'll be interested in doing more (and maybe, once I > wrangle the travel funds, coming to pycon!). I'm so very

Re: [Mailman-Developers] add_members and nomail

Mark Sapiro writes: > Scot Hacker wrote: > > > >Long story short, if I were to submit a patch, would it likely be > >accepted? Or is there a good reason why it's not included? > > Probably yes. The reason it was never include upstream is that Apple > has *never* shared any of its Mailman ch

[Mailman-Developers] Mailman 3: dlist integration

Terri Oda writes: > In a dlist-enabled list, every message is part of a thread, as > determined by the posting address used > (mailinglist+threadn...@example.com or +new for a new thread whereupon > we create a new name). How is the new name determined? What happens if you just post to ma

Re: [Mailman-Developers] Mailman 3: dlist integration

Terri Oda writes: > > Is it possible to split or merge threads? > Posters can split off a thread at any time by just replying to +new > instead of the existing thread. So if somebody is subscribed to the old thread, and their default is not to automatically subscribe to new threads, they los

[Mailman-Developers] Using bracketed prefixes in subject as filters

Gordon P. Hemsley writes: > Thus, a subject line that begins "[css3-fonts]" will be assumed to > be about only the css3-fonts spec, [...] and not, say, the > css3-flexbox spec (subject lines prefixed with "[css3-flexbox]"). > > To handle this, the Mailman archive interface would provide an o

[Mailman-Developers] New to mailman

Sandesh Agrawal writes: > But i have no idea about how to proceed , can somebody help me please. Well, first you need to tell us where you're stuck! The basic procedure is 1. Get a Launchpad account (sooner or later). 2. Check out the most recent commit to the sources you're interested i

[Mailman-Developers] Wiki woes

Terri Oda writes: > I know we've been under some pressure from the FSF to switch to a > more free wiki, and they'd offered to find us some help in doing > the migration. The pressure is real and will intermittently reappear. In my experience, *specific* help on infrastructure from the *FSF* n

Re: [Mailman-Developers] Wiki woes

Paul Boddie writes: > I was just reading the discussion about Wiki migration from > Confluence to MoinMoin on this list (mailman-developers). When this > topic was first raised, a mailing list was set up IMO, this list is the appropriate place, and one shouldn't hesitate to post here about it

Re: [Mailman-Developers] Wiki woes

Paul Boddie writes: > > (I love that you'll be able to author pages in reST. :) > > You lose some of the more interesting features doing that, though, > I think. Like what? And of course if you don't need those features you can use ReST, right? That is, there's some way to specify markup l

Re: [Mailman-Developers] Mailman 3 and New Lists (Templates for Defining?)

Barry Warsaw writes: > Note that styles are only applied when a list is created, so it is > better to think of them as the default set of attributes for a > list. I'm unhappy with the name, then. "Style defaults" would be pedantically correct. > IOW, if you changed a style after a list is c

Re: [Mailman-Developers] Mailman 3 and New Lists (Templates for Defining?)

Terri Oda writes: > > On 13-03-05 8:28 PM, Stephen J. Turnbull wrote: > > OTOH, would it really be that burdensome to keep styles in the > > database and allow styles to be updated with appropriate effects on > > the lists? A style *change* that could be applied doma

[Mailman-Developers] GSoC 2013 ideas page updates

Terri Oda writes: > I don't know that it'll result in us attracting more students just yet > (again, org applications don't open 'till March 18th) but if it seems > like there's a small surge after this weekend, you can blame me. s/blame/thank/ Speaking-for-myself-wink-wink-nudge-ly y'rs, _

Re: [Mailman-Developers] Like to participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the list (Django, Python)

Terri Oda writes: > Hi Surya! > > On 04/01/2013 09:00 AM, Surya Kasturi wrote: > > I have gone through the proposed ideas > > http://wiki.list.org/display/DEV/Google+Summer+of+Code+2013 and found some > > of them to be interesting.. > > > > 1. RSS and NNTP access to mailman services > > 2

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

Abhilash Raj writes: > Well what i want to make it is that whenever a user sends a mail to the > list it should be singed with his private key so that it can be verified > against his public that he uploads if he wants permissions to post in the > list. You mean that the user should sign it h

Re: [Mailman-Developers] Like to participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the list (Django, Python)

Surya Kasturi writes: > Actually, I am on Windows. setting up Mailman is a problem for me.. need > time for that. Ouch. Do you have access to a VM hypervisor so you can run Linux inside of Windows? If so, the shortest path home is likely to be installing Ubuntu there. Otherwise, we'll help a

Re: [Mailman-Developers] Like to participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the list (Django, Python)

Here's a brain bubble for you: Stephen J. Turnbull writes: > I don't want to discourage you. But please be realistic about your > choice of environment. Ooh, tasty! How about a Mailman Raspberry Pi? Seriously, Barry, ya think it's possible? This would solve the en

Re: [Mailman-Developers] Like to participate in GSOC 2013 (GNU Mailman) - Like some ideas proposed in the list (Django, Python)

Surya Kasturi writes: > Since no one had so far configured mailman on windows, I guess, I > can try it (not now but.. later on). Why not we build an executable > for windows (.exe) for users to install? This could take sometime > to port and solve conflicts.. but at the end, it would be superb

Re: [Mailman-Developers] GSOC 2013 - Introduction and Project Discussion

Pierre-Yves Chibon writes: > On Sat, 2013-04-06 at 15:03 +0530, Udit Saxena wrote: > > 2. Web Posting Interface. > > Isn't this similar/overlapping to what HyperKitty already does? No. There's no reason why a web posting interface needs to interact with the archives; it can talk directly to

Re: [Mailman-Developers] GSOC 2013 - Introduction and Project Discussion

Pierre-Yves Chibon writes: > How do you reply to a thread if you don't have access to the > archives? The archives provide a URL to the web interface instead of a mailto URL. > If it is thought as a different system then I understand. I was more > confused if that was thought as part of Hype

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

Abhilash Raj writes: > Can you please point me in some direction to learn about the various > possible ways to sign a mail and/or encrypt it. Basically that's going to be MUA-dependent. There are standards for this (prominently S/MIME aka RFC 5751), but whether MUAs implement it is MUA-specifi

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] 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 effec

[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:

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 yo

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 b

[Mailman-Developers] Boilerplate and content filtering [was: Introduction and Project Discussion]

Sreyanth writes: > Also, I would like to hear more about : Boilerplate stripper AND Better > content-filtering / handling error messages. > ​Boilerplate stripping is trivial to understand. But, can anyone elaborate > on Better content-filtering / handling error messages? But boilerplate strip

[Mailman-Developers] anti-spam filter

Pratik Sarkar writes: > Is the anti-spam/abuse filter still being seriously considered as a > gsoc project this year? I would say so, yes. Personally, I am fundamentally opposed to it; I think it's wrong in principle (filtering of this kind should be done by the incoming MTA) and inappropriate

Re: [Mailman-Developers] anti-spam filter

Paul Wise writes: > One really useful thing to have would be removal of spam from > archives. Here are some examples of how it has been done before: That's a great idea (and a great example of why I don't think spam-filtering technology should be embedded in a Mailman handler! :-)

Re: [Mailman-Developers] Boilerplate and content filtering [was: Introduction and Project Discussion]

Sreyanth writes: > I have implemented a binary Bayesian classifier which classifies an email > either spam or not spam. Is it better than (or at least different from) SpamBayes (available on PyPI), which some third parties already use in Mailman installations? Let's not reinvent wheels, here!

Re: [Mailman-Developers] Boilerplate and content filtering [was: Introduction and Project Discussion]

Sreyanth writes: > Just hide the boilerplate in the email, giving a link to > click. When clicked, use js to unhide the boilerplate. This would > not anyhow require separate storage. Suggest me something if this > is bad! The main point of sharing links is not storage compression; it's that t

Re: [Mailman-Developers] anti-spam filter

Patrick Ben Koetter writes: > Perhaps the integration could create an interface itself that makes > it easy to add other filters in the future. I am thinking Postfix > 'content filter', which uses SMTP/LMTP to send messages to an > external filter and they send it back then using SMTP. > >

Re: [Mailman-Developers] anti-spam filter

Paul Wise writes: > A generic mailing-list-hoster hosting all 3 of those will want to > allow most mail and add per-list filters. Of course. SpamAssassin at least can already do that (it allows mailbox-specific rules). A properly set up Bayesian filter will notice that certain criteria are as

Re: [Mailman-Developers] Boilerplate and content filtering [was: Introduction and Project Discussion]

Sreyanth writes: > I I understood it before too. I proposed this JS approach, as I wondered > why people would anyhow look at the boilerplate! (That's the main point of > the project right!)​ Depends on your definition of "boilerplate". I consider quoted mailing lists' footers and those stupi

[Mailman-Developers] Interested in - Better User Settings Management

Sneha Priscilla writes: > The one I am most interested in is 'Better User Settings Management'. > I'd like to know if it's a feasible idea for this summer and how > important is it on the list of project ideas for Mailman this year? As far as I'm concerned, definitely yes (since "better" invol

Re: [Mailman-Developers] A feature I'd like to emphasize for GSoC ...

Florian Fuchs writes: > 2013/4/12 Stephen J. Turnbull : > > ... is *convenient access to logs via the admin interface*. > > This could be something for a HTML(5)/JS/CSS savvy person (to make it > *really* convenient). I'm thinking scrollable log views, that > in

Re: [Mailman-Developers] A feature I'd like to emphasize for GSoC ...

Paul Wise writes: > On Tue, Apr 16, 2013 at 4:08 AM, Florian Fuchs wrote: > > > This could be something for a HTML(5)/JS/CSS savvy person (to make it > > *really* convenient). I'm thinking scrollable log views, that > > interactively append/prepend entries to the view, depending on your > >

Re: [Mailman-Developers] anti-spam filter

Pratik Sarkar writes: > Can someone please give me a link of the existing mailman spam filter > techniques.? Besides the links Mark sent, Mailman 2 site admin pages under "Privacy" will explain how to use the already integrated regexp-based filtering. __

Re: [Mailman-Developers] anti-spam filter

I'm copying to Mailman-Developers to ensure the other mentors are aware of your plans. Pratik Sarkar writes: > Actually my college semester exams are starting from next week thats why I > couldn't spend much time on this proposal.Since you gave a positive > feedback,I will start working on it.

Re: [Mailman-Developers] Boilerplate and content filtering [was: Introduction and Project Discussion]

CC-ing Mailman Developers to keep all mentors up to date on what you're thinking. Sreyanth writes: > On Mon, Apr 15, 2013 at 4:13 PM, Stephen J. Turnbull > wrote: > > Worse, quoted footers are often actively harmful, because they contain > > "unsubscribe"

Re: [Mailman-Developers] anti-spam filter

Pratik Sarkar writes: > I am working on the proposal.And how many slots are there for the filter > project? There are no slots for the filter project as such. The whole Mailman project has slots, and they are somewhat fluid, since we operate under the umbrella of the Python Software Foundation

Re: [Mailman-Developers] Boilerplate and content filtering [was: Introduction and Project Discussion]

Terri Oda writes: > Or, if it's less trouble, feel free to stick it on the Python wiki > (which is moin) under SummerOfCode; I was hoping to link to it anyhow as > advice to help students, so it is actually going to be relevant to > python students in general. I think that's the way to go,

Re: [Mailman-Developers] GSOC 2013 project discussion

Avik Pal writes: > Meanwhile It would be much appreciated if someone can direct me to > an labeled dataset available on line. By "labelled" you mean pre-classified into spam vs ham? I see you already found one, but you could also check the SpamBayes and SpamAssassin distributions. > Here I h

Re: [Mailman-Developers] Architecture for extra profile info

Main comment: Sounds like LDAP to me. Florian Fuchs writes: > 5) It should implement an oAuth provider. I don't see this. Mailman is an auth consumer. The only people Mailman can provide auth for are the site admins. Everybody else is more or less untrustworthy. I can see that there are app

Re: [Mailman-Developers] Architecture for extra profile info

Florian Fuchs writes: > But maybe we can take a moment to think about the usefulness of such a > feature and the possibilities this might open up, rather than > dismissing the use of a certain technology right off the bat. I'm not dismissing the use; I'm saying an authentication provider is ou

Re: [Mailman-Developers] anti-spam filter

Pratik Sarkar writes: > Coming back to the project,do we need to write patches for the > SpamAssassin or SpamBayes(which are integrated in Mailman) No. You write a Handler which delegates to those external packages. A Handler is a sort of plug-in. > or do we need to start over and make a who

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and > persona, kerberos, etc.) were protocols whereby one system (the > provider) furnishes credentials for a second system (the client) to > some third system (the consumer). That's correct. > If we

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull" > wrote: > > > Richard Wackerbarth writes: > > >> There is no reason why alternate channels [to a connection from > >> localhost authorized by the OS] can

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > Perhaps I didn't understand you. I thought that you were > advocating the omission of any channels other than "shell" and > "localhost". I'm saying that we should make appropriate Mailman components be OAuth clients (subject to site policy, per component), but tr

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > I have no problem with, and actually encourage, that we act as a > consumer of oAuth credentials. +1 > However, the issue here is whether we should be provider of oAuth > credentials (which might then be presented to some outside, totally > unrelated, entity.

Re: [Mailman-Developers] Architecture for extra profile info

Florian Fuchs writes: > If the instance of the user store does not act as provider, we would either: > > 1) effectively require every api user to have an account with some > other oauth provider. Most people do. Sites that care can bring up their own provider. AFAIK that's not terribly har

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > Since we consider the user manager to be a part of the MM complex, > what have we gained by hiding the underlying credential from the > web interface? Security. See the OAuth 2.0 spec (RFC 6749) which recommends (at SHOULD level) this practice. _

Re: [Mailman-Developers] anti-spam filter

Barry Warsaw writes: > I still think this wouldn't be a handler, but a rule. Is this distinction implemented and enforced by the API? If not, it's going to be hard to persuade myself to make the distinction in discussion. Ie, I'll probably just go on calling everything a Handler unless somebod

Re: [Mailman-Developers] Architecture for extra profile info

Barry Warsaw writes: > What's interesting to me about it is that this acknowledges that > administrative control of this extra user information may fall to > folks not at all directly involved in mailing list administration. I think this is crucial to World Domination^W^WMailman 3 uptake. >

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull wrote: > > Richard Wackerbarth writes: > >> Since we consider the user manager to be a part of the MM complex, > >> what have we gained by hiding the underlying credential f

Re: [Mailman-Developers] anti-spam filter

Barry Warsaw writes: > There are several ways to think about it, but I guess the easiest > one is "does this chunk of processing change the message or make a > non-destructive moderation decision?" Or more simply, "is it > moderation or modification?" At least for me, the concept is not a pr

Re: [Mailman-Developers] anti-spam filter

Barry Warsaw writes: > I would love to have contributions to support at least Exim and > Sendmail out of the box. If you're an expert willing to contribute > that code, please get in touch. I'm not an Exim expert, but my production[1] system uses Exim. I'm working (slowly) on Mailman 3 integ

Re: [Mailman-Developers] Architecture for extra profile info

Barry Warsaw writes: > It's also probably true that few people actually use the email command > interface - heck even I rarely use it. Emacs and (some) Debian folks do, though. It's not random, there are whole constituencies (small) out there for this feature.

Re: [Mailman-Developers] Architecture for extra profile info

Barry Warsaw writes: > but also remember how much pain we had at the sprint trying to get Postorius > and HyperKitty deployed together (how's that coming by the way?). I got mail from Yarko, does that help? :-) I hope to get back to that this week, now that I've initialized my classes. Dunno

Re: [Mailman-Developers] anti-spam filter

Pratik Sarkar writes: > Okay so what should a gsoc student concentrate on for the project? Writing the proposal! > 1.a standardized interface (e.g. MILTER, SMTP/LMTP transport) Very important. In the case of a filter proposal, which one is up to you (both are important to Mailman because mil

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

Abhilash Raj writes: > Can you tell about who is going to mentor this(OpenPGP integration with > mailman) I would guess the official mentors are likely to be myself and Wacky (Richard Wackerbarth). Joost isn't official (why not? -- you get a T-shirt! :-) but he has expressed interest and offer

Re: [Mailman-Developers] Setting up a VM.

Chris Cargile writes: > test_not_enough_parameters > (mailman.rest.tests.test_users.TestLogin) Either the test or the code is borked. Last I heard (at the sprint), we didn't know why. Comment out that test so that the rest of the test suite can run. __

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

Abhilash Raj writes: > I made a small list[1] > [1]: https://gist.github.com/maxking/5455462 I strongly recommend that you put this in your proposal on Melange. The mentors will all see it on the mentors' list that way, and you won't get caught short at deadline when Melange crashes.[1] If yo

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

Stefan Schlott writes: > 2. Your list has elevated security requirements. In this case, you can > use gpg-agent to manage the secret key (and its passphrase). I don't understand what threat you propose to address in this way. It's true that you can prevent the attacker from getting access to th

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

Barry Warsaw writes: > OTOH, maybe that's all security theater. If the Mailman system's > private key is available to an attacker, then having the encrypted > message on disk temporarily is probably not going to stop them from > decrypting it. It's worse than that. The attacker doesn't need

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > subscription - the binding of an email address to a list. Also preferences are bound here. (This is not the only kind of thing that preferences can be bound to, but experience shows that we need per-subscription preferences.) > First, rather than having multiple

Re: [Mailman-Developers] Architecture for extra profile info

Abhilash Raj writes: > Hi all, > I wrote a brief summary[1] of this thread. You've misinterpreted or mistyped a couple things I wrote: I'm not against OAuth in general, just against Mailman being an OAuth *provider*, or bundling one, because we can't support it properly. Users should get auth

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > https://server.example.com/mailman/list/ABCDEFG/attribute/join_address > returns the email address to which subscription requests should be > sent. "ABCDEFG" is what? The list? I think the short prefix /mailman/ should be reserved for traditional and anonymous r

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

Daniel Kahn Gillmor writes: > If mailman is storing messages on-disk in an encrypted form, Stefan's > proposal mitigates the threat of an adversary with offline access to the > disk (e.g. in the event of server theft or seizure) OK, it does that. But in the event of that kind of threat, I thi

Re: [Mailman-Developers] Architecture for extra profile info

Xu Wang writes: > For OAuth , you need to > implement token based auth in API, as well as a provider service > because there is no open OAuth provider service for third party API > out there :-( No, we don't *need* to implement *anything*. We implement wha

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > > Ah so you don't mean what I wrote above, you want to represent > > preferences as a table with > > > >row = preference-owning-entity att_name att_key > Correct. But isn't it > > row = preference-owning-entity att_name att_value Yes. __

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > > "ABCDEFG" is what? The list? > > Yes. But note that it is some pk provided by the list store. "pk" ? > >> https://server.example.com/mailman/attribute/posting_address/test_l...@example.com > >> would return the URI representing the list > > > > Why have

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > It is not necessary to have more than a flat collection of lists. I don't know how it will be represented, but we *do* need to support virtual hosting, where the mailman administrator delegates site administration to the owner of the virtual host. > In fact, that

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > Primary Key == An identifier of the server's choice that identifies > a unique instance of the specified resource. It is important to > note that the client CANNOT rely on any particular scheme for > mapping other keys to this identifier. That's true for resourc

Re: [Mailman-Developers] Architecture for extra profile info

Xu Wang writes: > The problem is how do you "confirm ownership of the subscribed address" > when a request coming with an access token. You don't. That was done when the OAuth ID was linked to the address, using the usual 3-step handshake (submit the association, receive an email containing a

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > Groupings of lists simply provides a "shorthand" for the > description of characteristics which are common to the group. You don't need to teach Grandma how to suck intensional vs. extensional Python eggs. > > Such flexibility has benefits and costs. How many of

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > Being able to "write URIs by hand" is a violation of the HAL design > because it locks the interface into a particular implementation. Sorry, that's an un-Pythonic way to think. If HAL really requires URIs that only a machine can deal with, let's junk it. "If the

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > Yes, initially generating a more generic structure than the ad hoc > one in place (which doesn't even attempt to address delegation) Aha! Something that looks like a concrete use case! But what is "delegation"? I mean, "who delegates what to whom? And why does

Re: [Mailman-Developers] Architecture for extra profile info

Xu Wang writes: > No OpenID does not uses OAuth protocol. My mistake. Let's talk about what Mailman needs, then. OpenID (or an equivalent based on a more general system) is all that Mailman needs as far as I can see. AIUI, the resources that can be accessed or mutated, in order of frequency o

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > The "root" of the tree covers all of the lists. Under that top > node, we might create nodes for "Customer Plans", for example, > "Bronze", "Silver", "Gold" and "Platinum". Each of these nodes > would specify some limits that applies to the level of service. Bu

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > > On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull wrote: > > The rest of your post is just a reiteration of your religious > > belief that generic is good. > > Call it "religion" if you wish. It is based on DECADES of &g

Re: [Mailman-Developers] Architecture for extra profile info

Xu Wang writes: > As oauth supported google's userinfo API, one need to present a valid > google's oauth access token to get access. > s/google/mailman/g on above statement, it will be true too. I disagree, in the sense that Google (as an OAuth provider) is in the business of *providing* ente

Re: [Mailman-Developers] Architecture for extra profile info

Richard Wackerbarth writes: > You seem to be missing the point that "one size fits all", or in > this case, one hierarchy, is not a flexible strategy. Sorry, that's false, and there's plenty of evidence in the archives that I've acknowledged that point. But "flexible" is not an absolute, not e

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

Ian Eiloart writes: > Also, what kind of secure list would have automated processing of > message content as a requirement? Precisely, a list that wants to avoid this requirement: > If a message is gpg encrypted, then every sender would require the > public keys of every recipient, would the

  1   2   3   4   5   6   7   8   9   10   >