Re: [Mailman-Developers] Documentation status?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5-Mar-08, at 5:26 PM, Barry Warsaw wrote: I like having docs in the wiki because it lets more people contribute. The downside is that you can't reach it when you're offline and it's harder to publish in alternative media. Have you thought at all about how to handle that? I've actually thought about it a fair bit! I also like the wiki 'cause it's easier for other people to contribute (because I like to believe that I'm not the only person in the world who wants to write extensive Mailman documentation ;) ), and I'm particularly fond of the wiki we're using on wiki.list.org because of the way it outputs. PDF: One of the things I really like about the Confluence wiki software is that it does a pdf export. I was *shocked* by how many people want to print mailman documentation but apparently that pdf appeals to a lot of people (I used to get more mail about that format than any other). I noticed today that the pdf export isn't available if you're not logged in, though. Can we change that? I didn't see it offhand in the settings, but I admit I haven't looked very hard yet. I really think people will use it if they know it's there. HTML: What *is* available even if you're not logged in, though, is a nice printable version of the HTML. We could probably make a plain text version from this, although I'm unconvinced anyone would care except in a theoretical way. ;) Are there other formats that would be useful? When people emailed me and mentioned format, they were almost all using PDF or HTML, so I assume those are the most important ones. Printed hard copies: I've been putting the manuals into big wiki documents rather than splitting them up -- easier for those who want a printout to get it in a go. (The appendices are separate 'cause I didn't think most people would want them, and those who did would probably want them separate.) They can print as pdf or as html, as per their preferences, or import the HTML into something and repaginate however they like. I haven't actually tried this, but it really is nice html output. :) Including the docs with releases?: The HTML output is nice enough that I think we could consider snapshotting the documentation and putting it with each release as HTML. I think the Members Manual is worth including particularly because so many people have it on their sites for their users already. Plus, with a couple of search and replaces, you can customize the whole thing for your site, or even for a specific list, which can be very handy for certain types of users. I'm hoping the List Administrators Manual will be worth including when it's done, too, as well as the as of yet unwritten Site Administrators Manual but maybe I'm getting ahead of myself. Still, I think we'd do well to include some of this with the release. I will even volunteer to proofread the wiki output for each release. (I edited a magazine for years, I can probably handle this.) Doc licensing: I periodically get emails asking about the license on the documentation. I kinda assume it's all GPL (I can sign another copyright form for them if you need me to, Barry.), and that makes most sense if we want to include them. If everyone's okay with that, we should maybe put a note to that effect so I don't have to keep telling people Please, take it and do anything you want with it! I like people using mailman, and if my docs help you do that, use them any way you need to! Or, hrm, maybe I'll just put that in the docs and it'll get the point across. :) Other docs I want to see in the wiki: In my perfect world, I'd like to see us port all of our FAQ items to the documentation part of the wiki, so all of these things could be found in one place and thus easily searchable in one go. Any volunteers? Easy job, just a bit time-consuming, and a bit of thought needs to be put into how best to organize things. My guess is make them all children of an FAQ page so they're automatically indexed, but keep things one-question-per-page since it's unlikely that anyone'll ever want to print the entire FAQ. Similarly, installation docs, things like the backscatter information... all should be in one place. I was trying to explain to one of my department sysadmins where to find mailman help, and it was *embarrassing* when I started listing off the docs I wrote, the FAQ Wizard, the mailing lists, the help files included with the installation, the FAQ on list.org... really, I'd like to see a one- stop shop for documentation, and I think the wiki is the best choice (because more people can contribute!), with us exporting the bits that are useful to go with each release. I periodically try to coerce my little sister to import everything into the wiki for me, but she is strangely resistant to my offer of cookies in exchange for
[Mailman-Developers] 1-click unsubscribe
On Wed, Mar 05, 2008 at 08:25:49PM -0800, Mark Sapiro wrote: Any objections to changing the URL in the RFC 2369 List-Unsubscribe: header to the above - for 2.1.10? I could probably also suppress the Error: No address given message unless you came from options login page itself. I like this. +1 Cheers, -- Cristóbal Palmer ibiblio.org systems administrator ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] before next release: disable backscatter indefault installation
--On 5 March 2008 18:08:39 -0500 Barry Warsaw [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 5, 2008, at 5:33 AM, Ian Eiloart wrote: The one reason that I'm looking for an alternative to Mailman is the lack of adequate integration with MTAs, which means that there is no sensible thing that I can do with suspected spam. What I need to be able to do is reject it at SMTP time, based on list post permissions and other configuations - I need to be able to query the configuration from my MTA (Exim). Ian, I think that alternative is going to be Mailman 3 :). How do you see Exim asking that question? I can see several ways of doing it in Mailman 3. 1) you could call into a Python library that can answer that question; That's doable, with a perl wrapper around a python script. The question I'd want to ask is is email address a allowed to post to list b. 2) you could use some kind of RPC such as the REST api that Andrew's been talking about; I'm not sure whether I could use that from Exim. 3) you could make the appropriate queries directly to the Mailman database, which is based on SQLite currently but can be anything that Storm can talk to. That's probably the most desirable option from the point of view of efficiency, but I'd need to be querying a database remotely. Preferably one with several replicas. Would LDAP be an option? That's what we currently use for our user authentication. Hmm, doesn't look like it. I guess I could knock up a postgres cluster. The disadvantage of this over (1) is that I'd need to replicate Mailman's logic in the SQL query. Is that the kind of thing you want to do? The ideal thing would be if Mailman had an LMTP interface to accept postings, and could make decisions about accepting mail after RCTP TO. That way, Exim could make LMTP callouts to Mailman (effectively, the HELO, MAIL FROM and RCPT TO sections of the L/SMTP protocol). If Mailman says, yes I'll accept this message for delivery, then Exim can continue. Mailman might later reject a message based on other information, like attachment size, but at that point I don't mind bouncing the message. In fact, for list members bouncing is better than rejection because I can determine what I'm going to say. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfPJ/gACgkQ2YZpQepbvXEQNgCfQqZlZIt6kFyb+2MrQcteth1j q/8AnRqG8QjGqwBR0y/IQpFZMxBeiupW =eR4z -END PGP SIGNATURE- -- Ian Eiloart IT Services, University of Sussex x3148 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Web UI redux
--On 4 March 2008 17:57:42 -0500 Ethan Fremen [EMAIL PROTECTED] wrote: Hiya! After an embarrassingly long absence, I am going to try again to make some progress on the web ui front. Barry said in an earlier message that there's no web UI for mm3: my first impulse is to start on something there. I was humbled enough by my first experience trying to make progress on this that I will happily start with anything that y'all think is low hanging fruit just so I can get something committed that can actually be used. a) There was mention that an archive browser is required. b) An easy way for list members to unsubscribe is a legal requirement here in the UK, so that should should also be a priority. The current mechanism is *way* too complicated (even though it probably looks fairly simple to most of us). It needs (a) a simple form where I can enter my email address, and click unsubscribe so that I'm then emailed a verification link, and (b) a confirmation page as the target of that link, which (a) tells me that I'm unsubscribed, (b) allows me to optionally suspend mailings instead, (c) gives me some way to see what other lists I'm subscribed to, perhaps with the option to apply settings to all of them. It should also be very simple to apply site specific page headers, footers and styles. c) List subscription, with captchas, would be useful. Simple option management would also be good: daily digests, d) Simple list management: perhaps with styles announcement only, closed discussion, open discussion. Subscribe (by invitation, with notification, no notification), and unsubscribe). Thanks, ~ethan fremen ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a c.uk Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp -- Ian Eiloart IT Services, University of Sussex x3148 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 1-click unsubscribe
--On 5 March 2008 18:16:53 -0500 Barry Warsaw [EMAIL PROTECTED] wrote: I generally don't like 1-click unsubs but I recognize that this is an important use case in the real world, and it's probably better to have the risk of people getting unsub'd against their will than to have the entire site get blacklisted from AOL because of a cluser. So, a 1-click unsub is a link in the message footer which takes you to a page that says something like You've unsubscribed from our list, sorry to see you go? Well, if the subscriber accidentally clicked that link, then an oops button on the page might get them back in. If someone else clicked the link after the email was forwarded to them, then a farewell email to the subscriber, with a one-click resubscribe might help. A note on unsubscription: I manage a few lists for small voluntary organisations, and for us it is REALLY important to be able to avoid re-subscribing someone who has unsubscribed themselves. Therefore, it would be better to set their preferences to no-mail, rather than simply delete their records. Also useful to record the date and the fact that it was the subscriber who opted out. A note on small organisations: we have members that don't have email. It would be great to be able to record their postal addresses in some form that could easily be printed to envelope labels. Or, their phone numbers. So that they can also be notified of important events. This would be incredibly useful to small community organisations. -- Ian Eiloart IT Services, University of Sussex x3148 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] before next release: disable backscatter indefault installation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 6, 2008, at 12:30 PM, Ian Eiloart wrote: That's probably the most desirable option from the point of view of efficiency, but I'd need to be querying a database remotely. Preferably one with several replicas. Would LDAP be an option? That's what we currently use for our user authentication. Hmm, doesn't look like it. I guess I could knock up a postgres cluster. Theoretically, you would be able to implement different backends for the appropriate interfaces so that some of the data comes out of LDAP, but I haven't gotten that far yet. The ideal thing would be if Mailman had an LMTP interface to accept postings, and could make decisions about accepting mail after RCTP TO. MM3 will have LMTP, perhaps as the preferred way to get messages into the incoming queue. I hadn't thought about doing acceptance testing right there, but it's an interesting idea to think about. Thanks! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfQMZoACgkQ2YZpQepbvXFQNgCgkdfp1UUwsbIDaOis+CHqGpSB 2qUAoJ54l5pVMlclzAPgX/D0WGOydfK8 =38Lj -END PGP SIGNATURE- ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 1-click unsubscribe
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Eiloart Sent: Thursday, March 06, 2008 12:51 PM To: Barry Warsaw; Dan MacNeil Cc: Mailman Developers; Stephen J. Turnbull Subject: Re: [Mailman-Developers] 1-click unsubscribe snip A note on unsubscription: I manage a few lists for small voluntary organisations, and for us it is REALLY important to be able to avoid re-subscribing someone who has unsubscribed themselves. Therefore, it would be better to set their preferences to no-mail, rather than simply delete their records. Also useful to record the date and the fact that it was the subscriber who opted out. A note on small organisations: we have members that don't have email. It would be great to be able to record their postal addresses in some form that could easily be printed to envelope labels. Or, their phone numbers. So that they can also be notified of important events. This would be incredibly useful to small community organisations. /snip Sounds like what you're describing is a more complete CRM. Personally, I don't think Mailman should head in that direction, there are perfectly good CRM's for NPO's out there (like CiviCRM). I'd like to see Mailman improve support for newsletter style setups, which is sounds like is gaining momentum, but getting into full address information should be left to proper CRM solutions. It would be a long time until Mailman could do the other functions of a CRM well-enough for them to be a good idea for anyone to use. Aaron ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 2008 Pizzigati Prize
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: | | I have been awarded the 2008 Pizzigati Prize for Public Interest | Computing for GNU Mailman. | | http://www.pizzigatiprize.org/ That's Awesome! I'm extremely happy to be associated with this project. - -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH0DfRVVuXXpU7hpMRAqXfAJ9Acp63irwuxjheLuvTfQWZD+tqWACdGXs6 fDzTCJL3rFvE1LfvvbhT1KI= =umQE -END PGP SIGNATURE- ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 1-click unsubscribe
Aaron Crosman writes: Sounds like what you're describing is a more complete CRM. Personally, I don't think Mailman should head in that direction, there are perfectly good CRM's for NPO's out there (like CiviCRM). He is talking about a more complete CRM, but we need that anyway because of one-stop subscription management for multiple-list subscribers. The specific attributes Ian requests leave me cold, too, but I have my own idiosyncratic attributes I'd like to be able to query from the subscriber database. Fortunately, what Barry has proposed is an architecture that makes it easy to do these things. (If Barry chooses to work on Ian's requests in the spirit of a Pizzigati Laureate -- congratulations, Barry! -- that's fine by me; I'm happy to contribute by taking care of my own needs.) It would be a long time until Mailman could do the other functions of a CRM well-enough for them to be a good idea for anyone to use. That's not the direction Barry's going AIUI. What would be nice is a way for CRM solutions to take care of the subscriber db and contact scheduling while Mailman lives up to its name by taking care of delivery. Then Mailman would provide a default CRM solution plug-in which handles *only* the customer attributes relevant to subscriptions, ie, name, email, notmetoo, nodupes, nomail, etc. This would provide the same functions that are currently integrated in the Mailman core. See also the posts regarding RESTful interfaces. In other words, from the CRM point of view there would be a message injection API into Mailman, an optional bidirectional API for Mailman to request and update subscriber information from the CRM, and an optional API for the CRM to handle db updates on behalf of Mailman. I think this is what Barry has in mind, although he probably can explain it better. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
[Mailman-Developers] SEC wiki space (was: before next release: disable backscatter indefault installation)
On Wednesday, March 05, 2008 5:54 PM -0500 Barry Warsaw [EMAIL PROTECTED] wrote: Mark's the release manager for 2.1, but FWIW I completely agree with Stephen about this. What I would suggest though is that this information be put in a prominent place on the wiki. We have a security space with nothing substantial in it, so I suggest we put it here. http://wiki.list.org/display/SEC/Home This appears to be a read-only space. The add page link on the dashboard is grey and there's no Edit tab on the main page. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] before next release: disable backscatter in default installation
On Tuesday, March 04, 2008 12:30 PM -0800 Jo Rhett [EMAIL PROTECTED] wrote: 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. How, exactly, does one do these? In particular, how do you remove the aliases when using mm-handler to process mail from sendmail? (I'd be happy to start the wiki page once I have the information to put there.) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] SEC wiki space (was: before next release:disable backscatter indefault installation)
Kenneth Porter wrote: On Wednesday, March 05, 2008 5:54 PM -0500 Barry Warsaw [EMAIL PROTECTED] wrote: [...] We have a security space with nothing substantial in it, so I suggest we put it here. http://wiki.list.org/display/SEC/Home This appears to be a read-only space. The add page link on the dashboard is grey and there's no Edit tab on the main page. Did you 'Sign Up' and/or 'Log In'? -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] 1-click unsubscribe
On 6 Mar 2008, at 17:51, Ian Eiloart wrote: So, a 1-click unsub is a link in the message footer which takes you to a page that says something like You've unsubscribed from our list, sorry to see you go? So its an HTTP GET - which is supposed to be idempotent. I know a while back there was discussion of SpamAssassin modules which evaluated linked webpages for spamminess - presumably that action would clear someone off the list too! Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
[Mailman-Developers] Per-user subject prefix setting
A frequent request on mailing lists without a subject prefix is to add one. This often leads to long debate threads about the utility of the prefix. There seems to be two different styles of processing mail that leads to this conflict. One style (which I use) is to filter mail into many folders, one per list. No tag is needed in this case. The other style is to dump all mail into one or a small number of folders, and in this style one needs to tag to know which list a message belongs to. This has been captured in this feature request: https://sourceforge.net/tracker/?func=detailatid=350103aid=1104433group_id=103 There seems to be limited code for customizing messages per-user, but this setting may want to be treated as some kind of user class setting so that messages can still be batched for the no-prefix class and the add-prefix class. Perhaps this could be implemented as two distinct queues, similar to the way digests are treated as a distinct queue. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] SEC wiki space (was: before next release:disable backscatter indefault installation)
On Thursday, March 06, 2008 12:47 PM -0800 Mark Sapiro [EMAIL PROTECTED] wrote: http://wiki.list.org/display/SEC/Home This appears to be a read-only space. The add page link on the dashboard is grey and there's no Edit tab on the main page. Did you 'Sign Up' and/or 'Log In'? Yep, I created a login and see the Log Out link at top. The COM, DEV, and DOC sections are editable. SEC is not. I expected that the other 3 spaces are only editable when one has a login and thought perhaps SEC had been created with some kind of special group requirement, to keep crackers from seeing exploitable issues before a fix was available. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] SEC wiki space (was: before nextrelease:disable backscatter indefault installation)
Kenneth Porter wrote: Yep, I created a login and see the Log Out link at top. The COM, DEV, and DOC sections are editable. SEC is not. I expected that the other 3 spaces are only editable when one has a login and thought perhaps SEC had been created with some kind of special group requirement, to keep crackers from seeing exploitable issues before a fix was available. You are correct. My bad. since I am a member of a special group (not special enough to change Space Permissions though), I created a non-special user to see if it could add/edit pages. Foolishly, I then just went to a few pages to see if I had an edit tab, but I didn't actually go to the SEC page. -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] before next release: disable backscatter in default installation
1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. How, exactly, does one do these? In particular, how do you remove the aliases when using mm-handler to process mail from sendmail? (I'd be happy to start the wiki page once I have the information to put there.) This cannot be done simply with the current version of mm-handler in contrib -- it requires several code changes and would affect all actions for [EMAIL PROTECTED]. That would have bad effects on VERP bounce handling, for example. Here is an update to mm-handler which might address this adequately. I no longer use mm-handler myself (despite having written it), so I can't test this short of installing a new Mailman instance. Can someone on the list test it? http://home.uchicago.edu/~dgc/sw/mailman/mm-handler/mm-handler-2.10 Since it's contrib and not supported, maybe it would be reasonable to put the update into the 2.1.10 release -- provided someone can declare that it works. :) Otherwise feel free to post it on the wiki. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] before next release: disable backscatter in default installation
On Thursday, March 06, 2008 4:02 PM -0600 David Champion [EMAIL PROTECTED] wrote: Here is an update to mm-handler which might address this adequately. I no longer use mm-handler myself (despite having written it), so I can't test this short of installing a new Mailman instance. Can someone on the list test it? http://home.uchicago.edu/~dgc/sw/mailman/mm-handler/mm-handler-2.10 Since it's contrib and not supported, maybe it would be reasonable to put the update into the 2.1.10 release -- provided someone can declare that it works. :) Otherwise feel free to post it on the wiki. I'll give it a shot. Question about the backscatter settings: # Prevent backscatter for unapproved actions? $BounceUnapproved = 0; # Prevent backscatter for undefined lists? $BounceNonlist = 1; The comment seems to be logically backwards from the variable name. Should it really read allow, not prevent? Does 0 or 1 mean backscatter? ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] before next release: disable backscatter in default installation
# Prevent backscatter for unapproved actions? $BounceUnapproved = 0; # Prevent backscatter for undefined lists? $BounceNonlist = 1; The comment seems to be logically backwards from the variable name. Should it really read allow, not prevent? Does 0 or 1 mean backscatter? Good point. 1 means to bou^H^H^Hbackscatter. The comments should be adjusted. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] SEC wiki space (was: before next release: disable backscatter indefault installation)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 6, 2008, at 2:34 PM, Kenneth Porter wrote: On Wednesday, March 05, 2008 5:54 PM -0500 Barry Warsaw [EMAIL PROTECTED] wrote: Mark's the release manager for 2.1, but FWIW I completely agree with Stephen about this. What I would suggest though is that this information be put in a prominent place on the wiki. We have a security space with nothing substantial in it, so I suggest we put it here. http://wiki.list.org/display/SEC/Home This appears to be a read-only space. The add page link on the dashboard is grey and there's no Edit tab on the main page. Try it now. At one point I thought the entire space should be write restricted to just the core developers, but I think that's misguided. I've opened up the permissions and we can lock specific pages if/when we find that necessary. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkfQooIACgkQ2YZpQepbvXEqKACeN1ZIpkSt3wmRBHwc5AMXbMY8 qnIAoIiUvQl8BbYyq0hxE4j4fbNOs75a =etSR -END PGP SIGNATURE- ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Documentation status?
On Mar 6, 2008, at 3:20 AM, Terri Oda wrote: Other docs I want to see in the wiki: In my perfect world, I'd like to see us port all of our FAQ items to the documentation part of the wiki, so all of these things could be found in one place and thus easily searchable in one go. Any volunteers? Easy job, just a bit time-consuming, and a bit of thought needs to be put into how best to organize things. My guess is make them all children of an FAQ page so they're automatically indexed, but keep things one-question-per-page since it's unlikely that anyone'll ever want to print the entire FAQ. Similarly, installation docs, things like the backscatter information... all should be in one place. I was trying to explain to one of my department sysadmins where to find mailman help, and it was *embarrassing* when I started listing off the docs I wrote, the FAQ Wizard, the mailing lists, the help files included with the installation, the FAQ on list.org... really, I'd like to see a one- stop shop for documentation, and I think the wiki is the best choice (because more people can contribute!), with us exporting the bits that are useful to go with each release. I periodically try to coerce my little sister to import everything into the wiki for me, but she is strangely resistant to my offer of cookies in exchange for mind-numbing work. ;)But it is a pretty easy job with a script and some time to sanity-check the results, if anyone's got some time and interest. As added incentive, the offer of fresh cookies is open to anyone, not just my sister. I'll mail them out to any address you like, although obviously I can't guarantee that they'll be quite as fresh by the time you get 'em. ;) Hi Terri, I've been watching this thread with interest and would like to help where I can... I don't know Python, so I can't exactly help program, but I've been told I can translate technological info into something the normal person could understand. So what do I have to do to start helping? :) I have some nights/weekends free and I usually try and fill those with paying work, but need some good karma to go with my money! :) Besides, I love Mailman... Best mailing list software I've used! So let me know where I can help! Thanks! -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 3251 132nd ave Holland, MI, 49424-9337 www.raoset.com [EMAIL PROTECTED] ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
