Re: [Mailman-Developers] Bug? Refused subscription confirmation
Mark Sapiro wrote: Giuliano Gavazzi wrote: To: mylist-confirm+8a671672b88489848cd212b368d290cc343af848 [EMAIL PROTECTED] This is the problem. You have VERP_CONFIRMATIONS = Yes so the confirmation is From: and the user's reply should be To: [EMAIL PROTECTED] but the user's MUA has replied To: as above. VERP_CONFIRM_REGEXP doesn't expect this and parses the cookie as 8a671672b88489848cd212b368d290cc343af848 mylist-confirm+8a671672b88489848cd212b368d290cc343af848 which doesn't work. Then there's been an error, so the confirm command in the body is not processed. Solutions: The user can use a different MUA That's a work-around rather than a solution. This problem needlessly makes it harder for both list owners and subscribers to use Mailman hosted lists. The user can manually edit the To: to remove the real name IMHO, this is a bug. Mailman should correctly parse email sent to: mylist-confirm+8a671672b88489848cd212b368d290cc343af848 [EMAIL PROTECTED] since that is a correctly formatted email address header per the example: To: Mary Smith: Personal Account [EMAIL PROTECTED] in RFC 2822: http://www.faqs.org/rfcs/rfc2822.html jc ___ 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] Access options for command line tasks
Barry Warsaw wrote: I'm actually thinking we need /less/ magic in command line scripts, especially for typical user and admin tasks, because I think increasingly, fewer people have access to the command line (or know what to do with it when they've got it). Wearing my product manager's hat here - I request that EVERY administrative function be usable in all 3 methods - via the command line, via email, and via the admin webpage. The underlying function would always be the command line task but it could then be called via the other 2 methods. If this is not already a feature of MM3, I'm formally making it a request now. Please??? As a work-around for those who don't have direct command line access, and for ease of implementation in the web UI, I suggest we build a tool that takes a line of text via web form input, processes it on the command line, and spits the resulting command line text back out on a web page (concatenated with previous (in the past x minutes) commands and their results from this user, e.g. a screenshot of the command line interface). This tool would be a work-around for all the places where we haven't built a more elegant web interface for the given command line tool/function. The server admin should have options to enable or disable this access when installing mailman, or when installing/configuring each new list. Are there security implications with this that are not easily addressed? Finally, to address Barry's concern that many people don't know what to do with the command line - even if they don't know what to do, it's still useful for them to have access to it. I've done a lot of work on other people's PCs where I access the command line and type a few commands and this gets me info to help me solve their problem. In some cases I talk them thru using the command line themselves (e.g. tell them how to do a ping, or tracert). If this tool was not available at all, it would make it much harder for me to help them fix their problems. I expect that similar things will happen when experienced mailing list server admins try to help novices, so we avoid designing a system without the tools that the experienced server admins need to get the job done. jc ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] On allowing any list member to be an email moderator
R. Bernstein wrote: Please allow me explain why I initially posted to mailman-developer. Your reasons make perfect sense. I don't want you to think I was saying your reasons were wrong when I mentioned in my prior post that I might not have approved your initial post. Just that there is room for interpretation about if a post is on-topic or not, or if it's being posted to the right list or if there's a better list for the particular discussion. My point was that even moderators who are trying to follow the same policy and who have very similar opinions about when a post is on- or off-topic can still disagree sometimes. (I have no idea if this will make it to the mailman-developers list given what I'm reading so far. As I write this, my first reply to Brad Knowles is, as far as I know, being held for moderation. But I've received two other emails from that list on the thread, one of which seems to reinterpret the problem I stated.) I wanted to request a new feature. I looked at http://www.gnu.org/software/mailman/bugs.html to find out the proper way to do so. I submitted a feature request on sourceforge.net. But I also read at the URL mentioned: It is also recommended that you email a note about your submission to the mailman-developers mailing list, but don't rely on just the email to get the attention of the Mailman developers. There still exist some disconnects between some of the webpages (that were often written years ago) and the mailing list policies that have been changed or updated in more recent times. A bit of history might help you to understand how we got to where we are today. When I first joined mailman-users, it was an open list that non-members could post to. Unfortunately, it started getting a lot of spam. First Barry tried filtering out the spam and letting all non-spam thru to the list, but still a lot of spam got thru. Then Barry solicited volunteers to help administrate the list (and I volunteered), and we started approving non-member (non-spam) posts, and rejecting non-member (spam) posts. At this point 2 new issues surfaced. 1) The percentage of spam kept increasing until it was much too difficult for the owners and moderators to keep up with the moderation duties. Some days we would have upwards of 100 spam posts that had slipped past the initial spam filters and were in the moderation queue, and perhaps only a handful of on-topic posts that needed to be approved. 2) Some -users were replying to the list only - assuming that the person who asked was subscribed to the list and would see the reply - meanwhile the user didn't get their question answered (so they thought) and then posted the same question again. I take the blame (for good or bad) of persuading Barry that due to the changing environment it was not unreasonable to require a mailman user to subscribe to the mailman-users list before posting. Once Barry agreed we changed the list to reject all non-member posts. If a mailman user had a question for -users, they had to subscribe and confirm before posting. New users on that list are not moderated. When we made this change we had to change the list info pages, the welcome message, and the text describing the mailman-users link on many different webpages. Getting this all sorted out took several months and there may still be links out there that imply that mailman-users goes to a person rather than being an address for a discussion list where one has to subscribe before posting. So, that's how we ultimately dealt with the moderation problem you presently have when we encountered it on the mailman-users list. The mailman-developers list is different. The primary purpose of -dev is for discussion about development of mailman code. Feature requests are a gray area - are we discussing code development, or are we discussing using mailman? Many feature request *discussions* are better held on -users where more actual users of mailman can participate. We also had problems with discussions that weren't actually about developing mailman becoming a predominant part of the list traffic on -dev, overwhelming the subscribers on -dev that only wanted to discuss actual development issues. But, as you noted, the feature request process on sourceforge suggests you mail the -dev list when you submit a new request. We haven't quite figured out how to address this item with our current list policies. I'd love to hear your suggestions on this topic! So I do that. I have to subscribe to the mailing list first. Not to be able to post -- but to have it looked at by a moderator for posting. A little bit involved, but okay. I'm actually am lucky that the initial post was accepted. The primary reason that new subscribers to -dev are moderated is that for a while we were getting a lot of users who thought that their particular problem with mailman was the type of problem that they need advanced
Re: [Mailman-Developers] On allowing any list member to be an email moderator
R. Bernstein wrote: I guess sometimes things are not what they may seem initally, so many thanks for the detailed explanation; it all makes sense. It is also interesting to learn that the GNU mailman mailing lists have the same problems as other GNU lists. But it sounds like the GNU mailman lists have very dedicated moderators. blush I don't write code - my role in projects is as a product manager. Helping administer/moderate the mailman lists is one of the ways I can help contribute to mailman. Again at the risk of beating this horse dead, what we're looking for is a way for mailing lists to distribute the burden of moderation such as by having the mailing list be more self moderating as it appears that the wiki works. (I could be wrong here about the wiki.) There are a lot of differences between editing a wiki and moderating a list. Most people edit a wiki by adding content in areas where they have knowledge. Sometimes this contribution is prodded by going to the wiki to *get* the information and discovering that it's not there, and realizing that they are well suited for putting it there. There's also immediate positive reinforcement, their words are now on the web for all to see. When they need to refer someone to the content they can say go to the wiki and their words will be there for the other person to refer to. So they get value (something they made is there and can be used later) and recognition from this activity, and that positively reinforces their efforts and encourages them to do more of it. The process of digging thru spam to find on-topic posts that should go to a mailing list is not nearly so rewarding. (The term Thankless task comes to mind.) Without receiving reminders that there are posts waiting for moderation, there is no event to nudge moderators to go moderate. Once they have moderated the posts, there is no recognition that they discarded all that spam, that they were the ones who freed the held posts for delivery on to the list. I don't think you will get a lot of participation from a wide range of your list membership. I think that you will find that a very small number of your list members regularly do the moderation duties and that occasional moderation by other list members is very very rare. Another option for the solution I proposed is to just give out the moderator's username and password in the footer of the main list, in addition to having a moderators list. Now a would-be moderator has 2 different ways they can participate - they can just randomly log in from time to time to see if there is anything that needs moderating, or they can subscribe to the moderator's list to receive notices when there are posts that need moderating. You still don't have any way to track who moderated the post, but you would make participation easier because they don't have to subscribe to the moderator's list to get the username and password. In your original proposal you suggested a box or flag that allows anyone who is a subscriber to the list to moderate the list, which provides the individual activity tracking. If we were to add this, I think that this should be a *member* setting (mod-access) rather than a *list* setting, and then it can be added to the new member config options. A list owner could then configure the list to have new members automatically included in the people who can moderate the list, and the mod-access flag can be turned off (or back on) member by member for existing members. The observation is that right now, a number of mailing lists at least GNU mailing lists are just getting neglected, and this suggests something is wrong. Maybe it's just a global misunderstanding of how to set up a general help list (e.g. a documentation change), but I have a feeling it's not just that. Moderating a mailing list is a different type of activity than contributing code. For best results you need to enlist, encourage, and reward (with recognition from the list owners or key developers) the people who do this work, even if you do all the reward and encouragement in private email to your helpers. This goes a long way towards keeping them happy. I do this work on the mailman lists as a service to the mailman community, but when Barry says thanks that's a real motivator for me to continue. I'm pretty sure Brad feels similarly. I don't know how to or have a suggestion as to how to deal with concerns of the getting discussions to the right user/developer group or what should be indicated when making a feature request. However I do see the wisdom in discussing things in the right venue. After all, what's important is getting ideas and solving this problem, not bothering or using up the bandwidth of the wrong people. So if this discussion should be moved to the user list, please let me know. The -dev list is fairly quiet right now, so it's not a bad thing to have this discussion here. You
Re: [Mailman-Developers] On allowing any list member to be an email moderator
Brad Knowles wrote: But there's a problem with multiple moderators, one that we have on the mailman-users and mailman-developers lists ourselves -- in addition to many other lists hosted on python.org. In short, the problem is getting all the moderators to follow the same moderation policy. Even if you have agreed on a moderation policy, there is still a certain amount of judgement required, and Barry might feel one way regarding a given post, JC might feel a different way, and I might be somewhere on the fence -- or any other combination of the various people involved. That's a very interesting and accurate observation. In fact, the moderated post that started this thread is one that I don't think I would have approved for posting to this list! I felt mildly (but not strongly) that this was a discussion that should probably take place on -users first, because it's a discussion about the possibility of changing the way the mailman list is used (by it's users) rather than a discussion about developing a new feature, per se. But, it's not totally off-topic for -dev so Brad is also correct for approving it. The main problem I think Rocky is experiencing is the problem of absent moderators, period. Rather than some automated method of turning the moderator tasks over to others, I suggest that a better way is to more closely oversee pending moderator tasks so that the list owner and the list server administrator receive notices when a moderator's queue has not been recently attended to, and address the lack of moderation while the queue is still small and relatively fresh. To this end, I suggest a list server setting and a per-list setting for sending email notices (to the list server admin and to the list owner, respectively) daily, listing the number and type of stale moderation requests for each list. My suggestion is that the default state of this setting be set to on and it can be toggled off as desired, and that the default is to start sending these emails once daily when there are pending moderator items in the queue that are older than 3 days (72 hours). List server admins and list owners could then adjust these settings based on their list traffic etc. It might also be useful to provide a cc field for the list-owner setting so that when the owner is going to be absent from list management duties this message (and all other messages that go to the list owner) could be sent to a co-owner, and to allow the owner address to be set to nomail when there's a co-owner address entered. jc ___ 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-users%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=showamp;file=faq01.027.htp
[Mailman-Developers] On-topic-ness for -users and -dev
Brad Knowles wrote: Unless you're talking about Python code you've developed to implement this feature, or commenting on Python code that someone else has developed to implement this feature, I'm pretty certain that this discussion belongs on mailman-users and not here. When we get down to the point where we're talking about going to the archives of the list to see the previous discussion on this topic, and to see the patch that was produced, etc... then we are definitely into mailman-users territory and not mailman-developers. If Barry or JC disagree, then I'm willing to bow to their greater knowledge on this topic, since they've been moderators of this list longer than I have. If Tokio or Mark disagree, I'm willing to bow to their greater knowledge because I know they've been hacking on the code longer than I've been associated with the project. IMHO, -users is for discussions about using mailman (installing it, using the features it has, integrating it with other software, etc.). The posts we are hoping to keep OFF of -dev and ON -users are the posts by users who are having what they believe are complicated use problems and they want advanced support and thus try to post a -users appropriate question to -dev to get an answer faster or from someone with more knowledge than those who answer posts on -users. (This is almost always an inappropriate use of -dev and an intrusion on developer time.) As long as the topic brought here is about *how* to develop a new feature, I believe it's on-topic for -dev. It can often be a good idea to get feedback on the idea and the proposed implementation before spending time on writing the code. This way one can avoid writing one's way into a rat-hole because of a lack of knowledge about why it is the way it is now, and learn the best way to incorporate the proposed fix into the existing design. Then go code it! I believe the discussion about a this is spam button is appropriate for -dev. I agree that there are a lot of technical issues that need to be addressed about if or how to implement it.[1] I believe that -dev IS the right list for that discussion. When all is said and done though, I'm not a developer. My role here is more of product manager - I help with input on priorities, user interface, and of course with the boring details of administering -users and -dev so that the developers can spend their time on actual code development. So Barry (and Tokio and Mark, et al) really have the final say on what they want -dev to include or exclude. Until one of the key developers opines that this is off-topic I encourage using -dev for further discussion on the this is spam button topic. jc [1] Does it belong in the headers, the footer, the body? Should it be a configuration option to place it in one or more of these locations? What happens when the button (or link) is clicked? What if non-spam is reported? What about RFCs? Etc. ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Spam/Scam button
Nigel Metheringham wrote: While agreeing that MM is not really a good spam control place, my life would be made easier if:- * Marking a message as spam killed all other messages sent by the same sender address to that and all other lists currently awaiting moderation. * Marking a message as spam killed all other messages sent with the same subject to that and all other lists currently awaiting moderation. If this marking is taking place within the mailman admin webpage structure, this could be accomplished by providing checkboxes for each of these actions, and the default setting would be to have those boxes pre-checked so that when you click the button, those actions happen. The setting should be changeable within the mailman configuration so that one or both of these boxes are not pre-checked if desired by that mailman admin. jc ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Make web_page_url visible in the admin GUI?
John W. Baxter wrote: Max == Max Bowsher [EMAIL PROTECTED] writes: Max Is there any reason not to add web_page_url to the Max configurable options in the admin GUI? Right below host_name Max in the general category would be a good place. Yes, there is a reason. It is the same reason that the ability was taken out many Mailman versions ago. Thought experiment: 1. Make a typo which cripples the URL such that you can't reach the admin web page. As I read it, Max's request is to be able to set the URL to the user webpage, not for the admin webpage. Then the right URL will show up in the list footer, etc. 2. Now fix it from the browser. The sort of thing in #1 (sometimes not a typo but a more fundamental mistake) happened often enough to make removing the ability seem quite desirable. One thing which has changed since the decision is that a much higher proportion of list operators don't have command line access than was the case then. So *perhaps* it would make sense to revisit the decision (making it a site option, please). How about an option to set a new URL as the default for displaying in the footer (and archives, and elsewhere within your list's web structure), while still maintaining an alias (or having the new URL be the alias) to the machine address. That way the machine address will always work and give you a way to reach your list via the default machine name/listname path if you make a typo or otherwise change the URL in a way that doesn't work. As an example, this list is at: http://mail.python.org/mailman/listinfo/mailman-developers We could add a function to let the list admin set a default URL. If Barry wanted to change this list to: http://www.list.org/mailman/listinfo/mailman-developers Then this would be the new URL displayed in the list footer, and mail sent to [EMAIL PROTECTED] would be sent on to the list membership etc, BUT we could still always reach the list thru the original (default servername) URL and email address. jc ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Sibling list
Stephen J. Turnbull wrote: Tokio == Tokio Kikuchi [EMAIL PROTECTED] writes: Tokio - Is the terminology 'sibling' appropriate? I hesistate to give it a +1 because I know I think differently from most people, but FWIW I *did* guess what it does from that name. Ditto. jc ___ 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-users%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=showamp;file=faq01.027.htp
[Mailman-Developers] Head's UP - we changed administrivia settings for the mailman-users and -dev lists
Because the mailman-users and mailman-developers lists frequently discuss administrivia matters and because most users on these lists know how to properly email the list server for administrivia tasks, most administrivia filter matches to these lists are false positives. We have just changed the list config to no longer try to filter out administrivia requests. When you send email to unsubscribe or otherwise change your list settings be *extra* careful to send your request to the server address and not the list submission address, lest your mistake go out to the whole list. (You probably won't like the flames this is likely to produce.) jc - volunteer assistant list admin for -users and -dev ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Head's UP - we changed administrivia settings for the mailman-users and -dev lists
Brad Knowles wrote: At 4:35 PM -0400 2005-06-24, Barry Warsaw wrote: Just out of curiosity, what was the reason of the change? Does it drastically decrease the server load or the something else? I think it's primarily to reduce the workload of the volunteer moderators. There are occasionally postings to the list that have words like subscribe or unsubscribe in the first five lines or so, but which are perfectly valid postings. And yes, the result is that there should be fewer messages which have to be approved by the moderator volunteers. In many cases the poster is actively working on a problem and posts the question hoping to get help right away (i.e. in the next hour or so). If the message is held for moderator approval it may not get approved and posted on to the list for several hours, or even a day or two if all owners/moderators are particularly busy that day or it's a weekend and we aren't checking non-essential email as often, etc. So while an occasional administrivia post may get thru due to this change, it also means that on-topic posts that false-positive trigger the administrivia filter will now be sent on to the list in a more timely fashion. jc (now you have heard from all 3 of us, Barry, Brad, and JC :-) ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Search members bug?
Barry Warsaw wrote: On Sat, 2005-05-14 at 09:11, Jimmy Svensson wrote: I'm using the latest release candidate of Mailman and have a problem with the search function. When the result from the search is more than could be viewed on one page the result is divided into several pages depending on the beginning character of the email address... but when I want to view the results from the search beginning with anything other than A (for example B) the search is forgotten and all members beginning with B is shown instead of the ones I searched for. The problem is that the links for the different characters only contain the get variable letter and not findmember which is the variable posted by the search form. Have anyone else had the same problem? Would be nice with a fix for this. JC Dill mentioned the same thing to me in private email. Jimmy's bug report is different from mine. I was reporting the pagination - I hadn't seen letter-paginated search results for wild-card searches before. (I don't do them very often, so I don't know how long this has been the case.) Jimmy's bug is reporting something worse, not only are the results paginated but when you click on a letter to get the results starting with that letter, you don't GET the paginated results page for results starting with that letter. My report was about UI clumsiness (bad design), Jimmy's report is about something that is truly broken and not working as designed. Since the paginated results are broken, I suggest we try to fix both problems by generating the results on a single page (no pagination) or paginating by count (using the maximum number of members per page setting) rather than first letter. jc ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Search members bug?
Barry Warsaw wrote: On Sat, 2005-05-14 at 13:30, Mark Sapiro wrote: At least since 2.1.4 I think unfortunately, we're going to have to postpone fixing this until after 2.1.6. We /really/ need to get this release out to fix the security issues. OK. Can we document the search result work around in the release notes? jc ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] [Mailman-Developers] Patch for Mail Archive mirroring
Barry Warsaw wrote: On Tue, 2005-05-03 at 04:45, Fil wrote: I would see it that way, in the Archiving section of admin : Archiving on a foreign system : --- prevent archiving on foreign systems yes [] no [x] (adds a X-NO-Archive: header) You'd have to make clear that this would just be a hint to the foreign system, of course. Good point. It would probably be simpler and clearer to just say: Add X-NO-Archive: Yes header yes [] no [x] Do we need to explain what this header does (and doesn't) do, or could we assume that if the list owner doesn't know that they can google to find out? jc ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Patch for Mail Archive mirroring
Brad Knowles wrote: At 7:17 PM +0900 2005-05-06, Stephen J. Turnbull wrote: Maybe you could make it part of the user's configuration. Then the list master could default it to X-No-Archive: yes; individual users could turn it to no if they want to, including on a message by message basis. A stretch, I know, but it would be really horrible to have to have separate archiving control headers for the user and the list, and to have to establish a precedence, etc. Allowing users to set their archive preference in their list settings is a completely different feature. If someone wants to write a patch that does that, it should act on incoming email before mailman processes that mail for local archiving so that the local archive honors the user's setting. Then the list archive process would happen after the local archive is written. I think the concept of having Mailman optionally add it's own X-No-Archive: header would greatly complicate the situation, and I would be opposed to spending a whole lot of time working on this unless someone else can provide us a pretty much complete feature-rich patch that allows for modifying where in the stream this process is done and where in the stream Mailman pays attention to this header itself, and on a per-user basis. Personally, I don't see this as a big problem. If the header is inserted at a single specific place in the stream that is OK *as long as it's properly documented*. Then each list server admin or list owner can choose to turn this feature on or not, knowing exactly what it will do. IMHO, the correct place to insert this header is after mailman has processed the incoming message and archived it locally. That way the original sender's x-no-archive setting (set in the original incoming email or by the *other* x-no-archive patch that might someday be added) is correct for the local archive, and the outgoing mail is correct for the list's preference. jc ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Patch for Mail Archive mirroring
Stephen J. Turnbull wrote: The second is that this patch evidently constitutes a significant endorsement of The Mail Archive. As I understand Jeff's post, he went to the trouble of asking Lars if he would like a similar setup added for Gmane, patch to be coded by Jeff || Jeff. I have to admit that somebody who would go to that much trouble to implement the same feature for a close substitute sounds pretty endorsable to me! ... if Mailman is going to endorse services that way. I don't really think it's a good idea in principle, though. What happens if The Mail Archive goes away or goes proprietary? What are people going to think if The Mail Archive's maintainers hire Barry or Brad? Etc, etc. On the pro side, there is the point that this would make such mirroring an opt-in on the listmaster's side, which is good. So it might be worth Mailman thinking about under what conditions it would be good to make such an endorsement, and adding anybody who satisfied those conditions. I personally don't see it as being a significant endorsement. AIUI, it's a patch that allows 2 software programs to work well together. Mailman already provides patches or directions to make mailman work well with qmail and postfix, but I don't believe this constitutes an endorsement of qmail and/or postfix. Patches/directions that make mailman work well with archivers are similar - both with local archiver software and with mirror site archiver software. The documentation for these patches (or directions) should simply make it clear that the other programs - *all* the other programs (qmail, postfix, MHonArc, gmane, Mail Archive, etc.) - are not Mailman programs, and that the patches (or directions) are included solely for those who want to make mailman work well with the indicated outside-provided software or service. A simple patch philosophy that will address this and future patches: If the patch is incorporated into the main mailman build then the default state should be off so that the listmaster has to proactively turn the feature on for their mailman list server. If the patch remains as an add-on feature that has to be downloaded separately from the main build, then the default state could be on (since downloading the patch separately would be a clear indication that the listmaster desired to implement this feature on their mailman list server). This should be the same for all patches that specifically enable cooperation between mailman and any other outside-provided software or service. IMHO, etc. Caveat: I'm not a developer so those of you who actually write code and build/install the software (I just run it after someone else installed it for me :-) have much more say on this than I do. So if you hate my idea, speak up! jc ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Patch for Mail Archive mirroring
Stephen J. Turnbull wrote: JC == JC Dill [EMAIL PROTECTED] writes: JC I personally don't see it as being a significant endorsement. JC AIUI, it's a patch that allows 2 software programs to work JC well together. My understanding is that the programs already work well together; you just type [EMAIL PROTECTED] into Mass Subscribe, hit Submit and you're there. The patch changes this to one-click, ie, advertises the Mail Archive as part of the ordinary configuration process. But *only* for lists on a server whose listmaster has explicitly: A) patched mailman to add this feature or B) toggled the setting in a mailman install to turn this feature on. so it's the *listmaster* who has to do something to make this available for the server users in the ordinary configuration process. This is very different from patching the docs to explain that the Mail Archive is an alternative / supplement to pipermail, MHonArc, or Gmane. Mailman is what the listmaster makes of it, isn't it? The listmaster makes various decisions about how to patch and install mailman on their particular server. Once installed, it's not our mailman it is their mailman with the features and customization the listmaster selects. A patch that defaults to off unless the listmaster does something explicit to turn it on (by downloading a separate patch or by specifically changing the setting to on) is not an endorsement, IMHO. It's just one more feature that allows the listmaster to easily customize mailman for their particular user needs. From a technical standpoint, I'm all for it (subject to the defaults to OFF policy). Archiving is a sore point with all the MLMs; giving admins another easy-to-install option is a plus. But from a support and PR standpoint, I think it does constitute an endorsement. Would it help if the patch documentation elaborated on this concern? Example: This patch is provided for those who wish to enable their list owners to have a one-click option to have their lists archived with The Mail Archive. This patch is not an endorsement for The Mail Archive, each mailman server installer needs to make their own determination if this feature is desired on their server or not. jc ___ 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-users%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=showamp;file=faq01.027.htp
Re: [Mailman-Developers] Patch for Mail Archive mirroring
Tobias Eigen wrote: - New third party archiving option that uses The Mail Archive. The implementation subscribes or unsubscribes the archive@mail-archive.com address from the subscriber list. I find this whole discussion fascinating. I've been thinking about these types of possibilities for a while, and have been watching gmane and mail-archive off and on for inspiration for what Kabissa might do. Archiving is getting to be a big 'problem' at Kabissa currently, esp as our archives get older and bigger, and we desire to move to a more interactive and useful format for archiving discussions and making them more accessible via the web, i.e. in forums. Maybe the short-term answer is to encourage the listowners of our very busy lists to move their archives to mail-archive or gmane. This looks like a good opportunity to mention that mailman-users and mailman-developers are now also archived at: http://archives.free.net.ph/splash/index.en.html See this particular thread at: http://archives.free.net.ph/message/20050429.220927.207b9a02.en.html They asked for permission to join -dev so that it could be archived on their site. At the time, their archives didn't have munged email addresses, and Barry and I decided that if they fixed their archives to not expose email addresses, he would give them permission to join -dev and to archive mailman lists.. I like gmane's feature of making lists accessible in a newsgroup fashion, and I like free.net's format of providing the list in a threaded fashion via the web. This is not an endorsement of either site, just a personal observation of some of the positive features each of them offers over traditional list archives. Some list admins might want to offer their lists to be mirrored/archived at more than one site. While RFC 2369 only allows for one List-Archive: URL, I wonder if email client implementations that understand 2369 (is there a list of which ones are?) are generous in their response when a list email has more than List-Archive header... Be generous in what you accept and all that... :-) jc ___ 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-users%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=showamp;file=faq01.027.htp
Re: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck)
Adrian Bye wrote: If someone wanted to pay large sums of money to make an open source Yahoo! Groups-beating package, and pay people to work on that as their full-time job, we might be able to change this situation -- in time. We've previously had conversations about some Yahoo groups functionality which you said wasn't possible: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq04.039.htp Yesterday I contributed patches which enables Mailman to have this exact functionality which we borrowed from Yahoo Groups. Yet I've seen no response from you yet, and only one half dismissive response from another mailman developer. Sometimes the key developers are busy on other things (the recent security issues obviously screwed up their work schedules) and patches aren't immediately evaluated. You should give them more than just one day before you determine if your patch is appreciated and accepted etc. Mailman CAN be as good - and better - than Yahoo Groups. It doesn't have to take lots of money and resources. Just being willing to accept our code a piece at a time, and encouraging those who contribute will go a long way towards getting there. There may be some disagreement on the unsubscribe styff, but the header/footer handling only benefits everyone. I certainly hope that the mailman team will be responsive, and accept these patches and integrate them into the codebase. From my side we'll do whatever it takes to make that happen. Just tell us what we have to do. Right now, I would suggest being patient. I suggest you give it a week for Barry and the other key developers to to find the time to start looking at new code after they dig out from their present schedule overload caused by the recent security incident. I don't know what Brad's key focus is on this list, but I can share with you that *I* am not a developer in that I don't write code. My role here is that I help in a product management type role, helping prioritize, helping define, helping with documentation (FAQ entries etc.), enter feature requests, etc. And I help with the day-to-day management of the mailman -users and -dev mailing lists so that the key developers can focus their time on code instead of running the lists. Sometimes when we have list management related email threads it takes the key developers more than a week to chime in on something too jc ___ 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-users%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=showamp;file=faq01.027.htp
[Mailman-Developers] Your pending subscription request to mailman-developers - more info needed, please reply ASAP (second request)
Hello, We have set the mailman-developers list to require list admin approval for membership requests because of a recent problem with some people subscribing to this list and then posting messages that belong elsewhere. Can you please share with us your background with mailman and your purpose for subscribing to the developers list so we can approve your membership request? Thanks! This is our second request. If we don't get a response from you within 4 days your subscription request will be rejected. jc ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
[Mailman-Developers] Your pending subscription request to mailman-developers - more info needed, please reply ASAP
Hello, We have set the mailman-developers list to require list admin approval for membership requests because of a recent problem with some people subscribing to this list and then posting messages that belong elsewhere. Can you please share with us your background with mailman and your purpose for subscribing to the developers list so we can approve your membership request? Thanks! This is our second request. If we don't get a response from you within 4 days your subscription request will be rejected. jc ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] Your pending subscription request to mailman-developers - more info needed, please reply ASAP
oops. Apologies for typo-ing the cc on these emails. jc ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] [Fwd: [vendor-sec] Weak auto-generated passwords in Mailman]
Florian Weimer wrote: Last time I checked, Mailman lables its member-only archives private, and the implicit promise to keep things posted to the list private is not kept if the software assigns easily guessed to new members. I can only repeat that Mailman's current behavior surprises your users *a* *lot*, I disagree. So called private archives are only kept from prying eyes until those eyes subscribe at which time they are then visible. As I see it, the point of Mailman's security measures is not to keep anyone else from ever viewing the archives, it is to keep random web browsers and web spiders from accessing the archives. If someone has the ability to script a password guessing algorithm to try to guess an acceptable username/password pair to access the archives, they can more easily script a program to subscribe, confirm, and then access the archives as a subscriber. Plus, no matter how simple or secure the password, if you are scripting a password cracker then it's just a matter of time, the more easily guessed password is cracked *faster* (on average) but even secure passwords will be cracked eventually. If your mailing list archives need greater security than this, then you need a different system. I don't think it is necessary or useful for Mailman to be the system that meets those needs, especially at the cost of making Mailman less useful for others who don't need such strong security measures for their list archives. and leads to security breaches. I would love to see a cite for your claim of leads to security breaches. Do you know of actual cases where someone has gained access to private archives by cracking a mailman generated semi-random password rather than by simply subscribing, or by gaining access to a single password thru intercept or social engineering means? jc ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
