From tkikuchi at is.kochi-u.ac.jp Tue Feb 1 03:39:12 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue Feb 1 03:54:27 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] respond_to_post_requests and header_filter_rules In-Reply-To: <20050131181439.N33736@tnetnzry.hgf.qh.rqh> References: <20050131181439.N33736@tnetnzry.hgf.qh.rqh> Message-ID: <41FEEBD0.3010207@is.kochi-u.ac.jp> Hi, Ivan Fetch wrote: > Hello, > > I'm wondering whether there is a way to have respond_to_post_requests > set to yes (so that senders will be notified if their message is held > due to posting to a members-only list, their message exceeds mailman's > size limit, Etc), yet not send notifications to senders who's messages > are held because they match a filter rule (privacy | spam ). > > The help section of respond_to_post_requests says the following, > which leads me to believe that it will not notify senders of messages > which match spam filter rules: > "Approval notices are sent when mail triggers certain of the limits > except routine list moderation and spam filters, for which notices are > not sent. This option overrides ever sending the notice." > Looks like this detail is outdated. I think new spam filters should be used to silently discard the known spams. Ivan, what version are you using? Newer version has more generic header_filter_rules to hold/reject/discard such messages. Developers, I think I will remove 'spam filters' from the detailed description above but what is the 'routine list moderation'? I think list-wide moderation was replaced by per-member moderation, right? > > However when I send a message to a list and it matches against a spam > filter, I receive an email back notifying me that my message was held > because a filter was matched. It would be nice to be able to avoid > responding to messages which Mailman matches against the spam filters, > as often the From address is forged anyhow... > > IS there something I'm missing which will give me the behavior I'm > looking for RE: spam filtering? > > > Thank you - Ivan Fetch. > > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Tue Feb 1 12:39:47 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue Feb 1 12:55:04 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] respond_to_post_requests and header_filter_rules In-Reply-To: <20050131215620.I33736@tnetnzry.hgf.qh.rqh> References: <20050131181439.N33736@tnetnzry.hgf.qh.rqh> <41FEEBD0.3010207@is.kochi-u.ac.jp> <20050131215620.I33736@tnetnzry.hgf.qh.rqh> Message-ID: <41FF6A83.3070105@is.kochi-u.ac.jp> Hi again, Ivan Fetch wrote: > Hello, > > Thank you for your reply -- I'm using Mailman 2.1.5 (sorry for not > mentioning this previously). We'd rather be able to configure the > filters to hold (not discard) spam, at least for those lists where the > list administrators prefer to double check what is being tagged as spam. > You can create two or more new header_filter_rules. I suggest you create one for hold and another for discard. You can add a test regex into the first box and when you learn that it works right then move it to the second one to discard the spam silently. > Is the help text of respond_to_post_requests inaccurate in how it > claims that notifying posters of held messages excludes spam filtering? Historically, it was right statement once upon a time in 2.0.x era. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Wed Feb 2 02:20:31 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed Feb 2 02:22:13 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] Sendmail Milter subsystem telling sendmail todiscard Mailman digests In-Reply-To: <420023D7.4020208@krenim.org> References: <420023D7.4020208@krenim.org> Message-ID: <42002ADF.8050900@is.kochi-u.ac.jp> Jeff Groves wrote: > So, I'm going to have to learn python and figure out where it's not > putting the Date: header and make it do it myself. > Hi, I think I can fix this in Handlers/ToDigest.py The digests don't go through Message.py which was fixed in 2.1 beta 1. # I think someone posted the patch but it slipped off from my search paths. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From iane at sussex.ac.uk Wed Feb 2 17:26:45 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed Feb 2 17:29:21 2005 Subject: [Mailman-Developers] MAX_RESTARTS Message-ID: Hi, mailmanctl has a mechanism for restarting failed qrunners. Very handy, but I just got bit by MAX_RESTARTS. A resource problem on our mail server meant that the virgin runner was failing every half hour or so - so after a few hours Mailman stopped sending notifications of various things. What is the purpose of MAX_RESTARTS? I can see that we might want to stop if a runner is restarted ten times a minute, but not ten times a day, surely? Could we get an mm_cfg setting to control this please? That would give an easy workaround. More principled, perhaps, would be to store not the number of restarts, but the time of the last restart. If this restart is occuring less than one minute after the last, AND MAX_RESTARTS has been exceeded..... or something.... then we stop. -- Ian Eiloart Servers Team Sussex University ITS From thien.vu at gmail.com Wed Feb 2 21:00:01 2005 From: thien.vu at gmail.com (Thien Vu) Date: Wed Feb 2 21:00:05 2005 Subject: [Mailman-Developers] Possible error in Mailman/Cgi/confirm.py Message-ID: <9f7fa000502021200145e0252@mail.gmail.com> I think I found a bug in mailman. If you get an email confirmation for a pending request and you go to the web page. If you hit 'cancel' it will to to Mailman/Cgi/confirm.py will call subscription_cancel : def subscription_cancel(mlist, doc, cookie): # Discard this cookie userdesc = mlist.pend_confirm(cookie)[1] lang = userdesc.language i18n.set_language(lang) doc.set_language(lang) doc.AddItem(_('You have canceled your subscription request.')) The problem is in mlist.pend_confirm: def pend_confirm(self, cookie, expunge=True): """Return data for cookie, or None if not found. If optional expunge is True (the default), the record is also removed from the database. """ db = self.__load() # If we're not expunging, the database is read-only. if not expunge: return db.get(cookie) # Since we're going to modify the database, we must make sure the list # is locked, since it's the list lock that protects pending.pck. assert self.Locked() content = db.get(cookie, _missing) if content is _missing: return None # Do the expunge del db[cookie] del db['evictions'][cookie] self.__save(db) return content There is an assert self.Locked() which will always fail because we've never locked the list. The question is what's the correct thing to do here? It seems the safe thing to do is the wrap a lock the call to pend_confirm in subscription_cancel, but is pending.pck even used anymore? If not do we still need the lock? It seems like we would because we're going to be updating whereever the db is... Just asking because I'm not very familiar with this part of the code. Thien From wheakory at isu.edu Wed Feb 2 21:07:19 2005 From: wheakory at isu.edu (Kory Wheatley) Date: Wed Feb 2 21:09:27 2005 Subject: [Mailman-Developers] Mailman Qrunner Sleep Time Option Message-ID: <420132F7.9040501@isu.edu> If I change the configuration variable in Mailman: qrunner_sleep_time = 1 to qrunner_sleep_time = 60 Will this slow the delivery of Mailman's Queue to outgoing recipients. I'm looking for a way to slow the number of emails or connections to Postfix, because of rate control issues. I've already slowed the performance of Postfix I think. -- Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From mm at mewes.tv Wed Feb 2 21:17:24 2005 From: mm at mewes.tv (Martin Mewes) Date: Wed Feb 2 21:17:30 2005 Subject: [Mailman-Developers] [OT] mailman-devel mbox/maildir - download Message-ID: <200502022117.25113.mm@mewes.tv> Hi folks, I am new to this list and need to start with a a one time ever off-topic post to this list. As mailman-devel does not provide the full mbox-archive for download I kindly ask if someone can provide me with a tar of the posts up to one year back in time from now. This would make things easier for me to read and understand the background here instead of browsing the searchable archive online. Sorry for any inconvinience if any ... bis dahin/kind regards Martin Mewes -- Hi. I'm thinking about what you've just sent me. Please wait by your PC for my response. From brad at stop.mail-abuse.org Wed Feb 2 22:25:44 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed Feb 2 22:35:07 2005 Subject: [Mailman-Developers] Mailman Qrunner Sleep Time Option In-Reply-To: <420132F7.9040501@isu.edu> References: <420132F7.9040501@isu.edu> Message-ID: At 1:07 PM -0700 2005-02-02, Kory Wheatley wrote: > If I change the configuration variable in Mailman: > qrunner_sleep_time = 1 to qrunner_sleep_time = 60 > > Will this slow the delivery of Mailman's Queue to outgoing recipients. See . -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tkikuchi at is.kochi-u.ac.jp Thu Feb 3 00:55:47 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu Feb 3 00:56:00 2005 Subject: [Mailman-Developers] Possible error in Mailman/Cgi/confirm.py In-Reply-To: <9f7fa000502021200145e0252@mail.gmail.com> References: <9f7fa000502021200145e0252@mail.gmail.com> Message-ID: <42016883.2020707@is.kochi-u.ac.jp> Thien Vu wrote: > I think I found a bug in mailman. If you get an email confirmation for > a pending request and you go to the web page. If you hit 'cancel' it > will to to Mailman/Cgi/confirm.py will call subscription_cancel : > > def subscription_cancel(mlist, doc, cookie): > # Discard this cookie > userdesc = mlist.pend_confirm(cookie)[1] > lang = userdesc.language > i18n.set_language(lang) > doc.set_language(lang) > doc.AddItem(_('You have canceled your subscription request.')) > There is an assert self.Locked() which will always fail because we've > never locked the list. The question is what's the correct thing to do > here? As a developer, the correct thing to do is to upgrade your mailman to the most recent 2.1.6b2. This bug is already corrected. http://www.mail-archive.com/mailman-developers%40python.org/msg08456.html http://mm.tkikuchi.net/mailman-2.1.6b2.tgz -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From msapiro at value.net Thu Feb 3 03:06:45 2005 From: msapiro at value.net (Mark Sapiro) Date: Thu Feb 3 03:06:51 2005 Subject: [Mailman-Developers] Status of www.list.org? Message-ID: Does anyone know the status of www.list.org? I have been unable to get a ping response or a response from port 80 for a day or two now? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From brad at stop.mail-abuse.org Thu Feb 3 03:11:45 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Feb 3 03:12:01 2005 Subject: [Mailman-Developers] Status of www.list.org? In-Reply-To: References: Message-ID: At 6:06 PM -0800 2005-02-02, Mark Sapiro wrote: > Does anyone know the status of www.list.org? I have been unable to get > a ping response or a response from port 80 for a day or two now? Barry told me a couple of days ago that the machine was down for repairs, but that it should be coming back up later that day. I asked him if he thought an announcement should be made to the lists, and he said that there are two other operational mirrors for that content, and that an announcement shouldn't be necessary. Since then, I have tried to leave it up to Barry to make the announcement, but I guess that hasn't happened. I have mentioned the issue in passing on a couple of posts, but haven't said anything else up until now. Meanwhile, I point people at instead of . Note that the FAQ Wizard is not affected, nor are the mailing lists or archives, since they are hosted at python.org. Only the stuff at list.org is unavailable, although it is mirrored elsewhere. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From barry at python.org Thu Feb 3 04:38:30 2005 From: barry at python.org (Barry Warsaw) Date: Thu Feb 3 04:38:48 2005 Subject: [Mailman-Developers] Status of www.list.org? In-Reply-To: References: Message-ID: <1107401910.10014.8.camel@geddy.wooz.org> On Wed, 2005-02-02 at 21:06, Mark Sapiro wrote: > Does anyone know the status of www.list.org? I have been unable to get > a ping response or a response from port 80 for a day or two now? The machine had a hardware failure, and it took a while to rebuild, but it should be back up tomorrow. In the meantime, please use one of the mirrors (e.g. mailman.sf.net). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050202/89241e6a/attachment.pgp From mm at mewes.tv Thu Feb 3 08:16:12 2005 From: mm at mewes.tv (Martin Mewes) Date: Thu Feb 3 08:16:16 2005 Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman/templates/de admlogin.html, 1.2, 1.2.2.1 bounce.txt, 1.3, 1.3.2.1 verify.txt, 1.2.2.2, 1.2.2.3 In-Reply-To: References: Message-ID: <200502030816.12279.mm@mewes.tv> Hi Peer, pheinlein@users.sourceforge.net wrote : > Modified Files: > Tag: Release_2_1-maint > admlogin.html bounce.txt verify.txt There is a inconsistency in bounce.txt and verify.txt in the german translation. > Index: bounce.txt [...] > - Abonnent: %(addr)s > + Mitglied: %(addr)s > Index: verify.txt [...] > -Abonnenmentsbestätigung für die Mailing-Liste %(listname)s > +Abonnenmentsbestätigung für die Mailing-Liste %(listname)s If you say "Mitglied" in first and "Abonnement" in the second place, wouldn't it be better to say "Mitgliedsbestätigung" in the second place? Sorry if not all english readers can follow this ;-) bis dahin/kind regards Martin Mewes -- I am on holiday. Your e-mail has been deleted. From tobias at kabissa.org Thu Feb 3 17:22:00 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Thu Feb 3 17:21:28 2005 Subject: [Mailman-Developers] Re: [Pydotorg] Volunteer sought to code Mailman/Plesk integration script for use by African organizations In-Reply-To: <16891.42476.159508.328453@montanaro.dyndns.org> References: <2547E0DA-648C-11D9-9AE5-000D934F6C70@kabissa.org> <20050119182525.GB9122@authsmtp.dds.nl> <16891.42476.159508.328453@montanaro.dyndns.org> Message-ID: <276520ccd89baf2ef567d8f4d8a284e9@kabissa.org> Hi Skip, Thanks for the reply. To tell you the truth, I looked at the volunteer opportunities wiki and it took me just a little bit too much effort to figure out at the brief moment I took to look at it so I gave it up! Also had the bad luck of writing a lengthy email to the mailman-developers list which I then lost through a glitch in my mac email client. Proof, really, that I am completely useless with email and should never be allowed to administrate a mailman server. In the meanwhile, since I've not managed to get a volunteer to help out with this particular problem, I have decided to go ahead and pay a Rackspace (our hosting provider) technician to take care of it for me. When I have it I'll share the code. I'll keep you all posted. Cheers, Tobias -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * On Jan 29, 2005, at 10:04 AM, Skip Montanaro wrote: > > Tobias> I'll post my problem in more detail on the mailman-dev > list and > Tobias> perhaps someone will come forward. > > Also, check out the new (and so far empty) VolunteerOpportunities wiki > page: > > http://www.python.org/moin/VolunteerOpportunities > > There's a link from the existing jobs page to try and increase > visibility. > > Skip > From brad at stop.mail-abuse.org Thu Feb 3 20:01:09 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Feb 3 20:34:59 2005 Subject: [Mailman-Developers] Re: [Pydotorg] Volunteer sought to code Mailman/Plesk integration script for use by African organizations In-Reply-To: <276520ccd89baf2ef567d8f4d8a284e9@kabissa.org> References: <2547E0DA-648C-11D9-9AE5-000D934F6C70@kabissa.org> <20050119182525.GB9122@authsmtp.dds.nl> <16891.42476.159508.328453@montanaro.dyndns.org> <276520ccd89baf2ef567d8f4d8a284e9@kabissa.org> Message-ID: At 11:22 AM -0500 2005-02-03, Tobias Eigen wrote: > Thanks for the reply. To tell you the truth, I looked at the volunteer > opportunities wiki and it took me just a little bit too much effort to > figure out at the brief moment I took to look at it so I gave it up! I was afraid of that. ;( > Also had the bad luck of writing a lengthy email to the > mailman-developers list which I then lost through a glitch in my mac > email client. Proof, really, that I am completely useless with email > and should never be allowed to administrate a mailman server. Here, the archives of the mailing list could have been useful. For example, the message I think you're talking about is at . > In the meanwhile, since I've not managed to get a volunteer to help > out with this particular problem, I have decided to go ahead and pay > a Rackspace (our hosting provider) technician to take care of it for > me. When I have it I'll share the code. I'll keep you all posted. Thanks! -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tobias at kabissa.org Fri Feb 4 04:11:40 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Fri Feb 4 04:10:45 2005 Subject: [Mailman-Developers] Re: [Pydotorg] Volunteer sought to code Mailman/Plesk integration script for use by African organizations In-Reply-To: References: <2547E0DA-648C-11D9-9AE5-000D934F6C70@kabissa.org> <20050119182525.GB9122@authsmtp.dds.nl> <16891.42476.159508.328453@montanaro.dyndns.org> <276520ccd89baf2ef567d8f4d8a284e9@kabissa.org> Message-ID: <7423d18f3b8cb8e1a2315e87be16688b@kabissa.org> Hi, I'm pleased to report that the Rackspace tech did the work I needed, and now Mailman 2.1.2 is working beautifully on my Plesk 7.03 server! Woohoo! Kabissa member organizations with hosting accounts on the Kabissa server are now able to create, manage, and delete their own lists. Web interface is at http://lists.foo.com and lists are reachable at listname@foo.com and associated -request etc addresses. I have asked for permission to share the code for the cronjob he created that makes this possible and if I get it will write it up and make it available here. Some responses to your message interspersed below. Cheers, Tobias -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * On Feb 3, 2005, at 2:01 PM, Brad Knowles wrote: > At 11:22 AM -0500 2005-02-03, Tobias Eigen wrote: > >> Thanks for the reply. To tell you the truth, I looked at the >> volunteer >> opportunities wiki and it took me just a little bit too much effort >> to >> figure out at the brief moment I took to look at it so I gave it up! > > I was afraid of that. ;( no worries - this is my own ignorance.. I think a wiki is cool for this sort of thing. I need to learn wikis anyway. Would be nice to have a simple form alternative for those of us who haven't taken the wiki leap yet. :-) >> Also had the bad luck of writing a lengthy email to the >> mailman-developers list which I then lost through a glitch in my mac >> email client. Proof, really, that I am completely useless with email >> and should never be allowed to administrate a mailman server. > > Here, the archives of the mailing list could have been useful. For > example, the message I think you're talking about is at > 017649.html>. Thanks, but that's not it - I wrote another lengthy message describing our plans in more detail but it was lost. I'll get back on it soon when I have some spare time. >> In the meanwhile, since I've not managed to get a volunteer to help >> out with this particular problem, I have decided to go ahead and pay >> a Rackspace (our hosting provider) technician to take care of it for >> me. When I have it I'll share the code. I'll keep you all posted. > > Thanks! I'm happy about the setup on my server now - I'll be back soon with more info. Cheers, Tobias From brad at stop.mail-abuse.org Fri Feb 4 19:10:08 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri Feb 4 19:10:17 2005 Subject: [Mailman-Developers] Hacking pipermail... Message-ID: Folks, I've just had to rebuild an archive for a list, thus causing pipermail to regenerate message numbers and breaking all the links that previously used to work. I'd like to try to figure out a way to avoid that problem. Looking at pipermail.py in processUnixMailbox, around lines 565-568, the critical code appears to be: msgid = m.get('message-id', 'n/a') self.message(_('#%(counter)05d %(msgid)s')) a = self._makeArticle(m, self.sequence) self.sequence += 1 Am I missing something here? Could we simply rip out the references to "self.sequence" and instead drop in a call to "md5(m)"? Of course, we'd also have to adjust the initialization of "sequence" to be the empty string and make sure that all other references to it are as a string instead of a number, but I don't think that would be too hard. Certainly, it seems that this would be an easy way to avoid having to break all existing links because the sequence number arbitrarily changed when the archive was regenerated. Or does Python not have an internal implementation of MD5, or even a shim to a library function that does MD5? -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Sat Feb 5 11:25:12 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat Feb 5 11:25:20 2005 Subject: [Mailman-Developers] Patch 1107169: Re-use member_moderation_notice for generic_nonmember_action Message-ID: Folks, I asked a couple of questions about this a while back, and got a bit of help that allowed me to develop a patch, which I've now had on SourceForge for a while (see ). However, I haven't heard any further commentary on this. I'm not a programmer in any language, especially Python, but I hope that I've been able to at least hack something together without causing too much collateral damage. Feedback would be appreciated. Tokio -- can I get you to take a look at this and consider it for inclusion in your next beta roll-up for 2.1.6? This would solve some problems for us on the mailman-users and mailman-developers mailing lists, and without at least some commentary from you or Barry, I'm hesitant to just go ahead and apply this to the mailing list server for python.org. Thanks! -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tkikuchi at is.kochi-u.ac.jp Sat Feb 5 14:22:52 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat Feb 5 14:23:00 2005 Subject: [Mailman-Developers] Patch 1107169: Re-use member_moderation_notice for generic_nonmember_action In-Reply-To: References: Message-ID: <4204C8AC.7000607@is.kochi-u.ac.jp> Hi, Brad Knowles wrote: > Folks, > > I asked a couple of questions about this a while back, and got a bit > of help that allowed me to develop a patch, which I've now had on > SourceForge for a while (see > ). > > > However, I haven't heard any further commentary on this. I'm not a > programmer in any language, especially Python, but I hope that I've been > able to at least hack something together without causing too much > collateral damage. Feedback would be appreciated. > I was thinking that it would be better to have another text box to input say 'nonmember_rejection_notice' in the admin/privacy/sender page so the list owner can differentiate members and nonmembers. And I, having troubled by my students' theses, thought it would also better not to integrate your patch now but leave it open for use who need this. > > Tokio -- can I get you to take a look at this and consider it for > inclusion in your next beta roll-up for 2.1.6? This would solve some > problems for us on the mailman-users and mailman-developers mailing > lists, and without at least some commentary from you or Barry, I'm > hesitant to just go ahead and apply this to the mailing list server for > python.org. But, you need this for python.org mailing list! Python.org should use non-patched version of mailman.... I think I can find a time to add a text box and new attribute now. (May be in a day or two) -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From brad at stop.mail-abuse.org Sat Feb 5 16:26:52 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat Feb 5 16:36:18 2005 Subject: [Mailman-Developers] Patch 1107169: Re-use member_moderation_notice for generic_nonmember_action In-Reply-To: <4204C8AC.7000607@is.kochi-u.ac.jp> References: <4204C8AC.7000607@is.kochi-u.ac.jp> Message-ID: At 10:22 PM +0900 2005-02-05, Tokio Kikuchi wrote: > I was thinking that it would be better to have another text box to input > say 'nonmember_rejection_notice' in the admin/privacy/sender page so the > list owner can differentiate members and nonmembers. That would be a better way to solve the problem. Either that, or a new template, somewhat akin to postheld.txt, but used for rejections instead. > And I, having > troubled by my students' theses, thought it would also better not to > integrate your patch now but leave it open for use who need this. Ahh. Sorry, didn't realize the time/resource crunch. My apologies. > But, you need this for python.org mailing list! Python.org should > use non-patched version of mailman.... Agreed. ;) > I think I can find a time to > add a text box and new attribute now. (May be in a day or two) Much appreciated. Thanks! -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From msapiro at value.net Sat Feb 5 23:49:04 2005 From: msapiro at value.net (Mark Sapiro) Date: Sat Feb 5 23:49:17 2005 Subject: [Mailman-Developers] Hacking pipermail... In-Reply-To: Message-ID: Brad Knowles wrote: > > I've just had to rebuild an archive for a list, thus causing >pipermail to regenerate message numbers and breaking all the links >that previously used to work. I'd like to try to figure out a way to >avoid that problem. > > Looking at pipermail.py in processUnixMailbox, around lines >565-568, the critical code appears to be: > > msgid = m.get('message-id', 'n/a') > self.message(_('#%(counter)05d %(msgid)s')) > a = self._makeArticle(m, self.sequence) > self.sequence += 1 > > Am I missing something here? Could we simply rip out the >references to "self.sequence" and instead drop in a call to "md5(m)"? >Of course, we'd also have to adjust the initialization of "sequence" >to be the empty string and make sure that all other references to it >are as a string instead of a number, but I don't think that would be >too hard. > > Certainly, it seems that this would be an easy way to avoid >having to break all existing links because the sequence number >arbitrarily changed when the archive was regenerated. This is not a comment on Brad's suggested hack which I actually think is a good idea which can save much grief. Rather, this is an attempt to suggest a recovery from the immediate situation. In my admitedly limited experience, I have not seen message sequence numbers "arbitrarily" changed. Sequence numbers are assigned to messages in the order that they are read from the mbox file(s). Thus the only times they change is if: 1)messages are added to or deleted from the mbox files which can be avoided by only adding to the end of the last (current) mbox if necessary and just deleting most of the body and perhaps changing the subject instead of totally deleting the messages. There is a caveat about deleting messages in http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.003.htp 2)there is more than one mbox file and they are not processed in the original sequence. 3)there is more than one mbox file and when the archive was last built, the current listname.mbox/listname.mbox file was not processed last. Note that even case 3 can be recovered by removing the messages that existed when the archive was last rebuilt and putting them in a separate mbox which is processed in the original sequence and leaving the recent messages in the listname.mbox/listname.mbox file and processing it last. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From brad at stop.mail-abuse.org Sun Feb 6 01:48:40 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sun Feb 6 02:18:07 2005 Subject: [Mailman-Developers] Hacking pipermail... In-Reply-To: References: Message-ID: At 2:49 PM -0800 2005-02-05, Mark Sapiro wrote: > In my admitedly limited experience, I have not seen message sequence > numbers "arbitrarily" changed. Sequence numbers are assigned to > messages in the order that they are read from the mbox file(s). Thus > the only times they change is if: No, they're not arbitrarily changed. But they are changed if you have to rebuild the archives, something that I have had to do several times this past week. And something that I've had to do in the past, and on which I filed a bug report which seems to have disappeared. And something that will be an issue for anyone who follows the instructions in FAQ 3.3, and has to delete an old message in the archives. > 1)messages are added to or deleted from the mbox files which can be > avoided by only adding to the end of the last (current) mbox if > necessary and just deleting most of the body and perhaps changing the > subject instead of totally deleting the messages. There is a caveat > about deleting messages in > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.003.htp At least a couple of times this year we have gotten requests to remove messages from the mailman-users and mailman-developers archives, which would have broken all the existing links over the last couple of years to those lists if we had implemented the instructions in FAQ 3.3. We're still trying to work out how we can find a way to comply with the requests with regards to the publicly accessible version of the archives we maintain, without actually editing the source mbox files. > Note that even case 3 can be recovered by removing the messages that > existed when the archive was last rebuilt and putting them in a > separate mbox which is processed in the original sequence and leaving > the recent messages in the listname.mbox/listname.mbox file and > processing it last. A fairly complex process to go through, and I'm still not convinced that it would work if you had to delete a message in the archives from a couple of years ago. I'd like to try to find a better way to solve this problem once and for all, so that the sequence id would never be changed. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From msapiro at value.net Sun Feb 6 02:40:26 2005 From: msapiro at value.net (Mark Sapiro) Date: Sun Feb 6 02:40:34 2005 Subject: [Mailman-Developers] Hacking pipermail... In-Reply-To: Message-ID: ----- Original Message --------------- Brad Knowles wrote: >At 2:49 PM -0800 2005-02-05, Mark Sapiro wrote: > >> In my admitedly limited experience, I have not seen message sequence >> numbers "arbitrarily" changed. Sequence numbers are assigned to >> messages in the order that they are read from the mbox file(s). Thus >> the only times they change is if: > > No, they're not arbitrarily changed. But they are changed if you >have to rebuild the archives, something that I have had to do several >times this past week. And something that I've had to do in the past, >and on which I filed a bug report which seems to have disappeared. >And something that will be an issue for anyone who follows the >instructions in FAQ 3.3, and has to delete an old message in the >archives. Are you referring to http://sourceforge.net/tracker/index.php?func=detail&aid=1059566&group_id=103&atid=350103 >> 1)messages are added to or deleted from the mbox files which can be >> avoided by only adding to the end of the last (current) mbox if >> necessary and just deleting most of the body and perhaps changing the >> subject instead of totally deleting the messages. There is a caveat >> about deleting messages in >> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.003.htp > > At least a couple of times this year we have gotten requests to >remove messages from the mailman-users and mailman-developers >archives, which would have broken all the existing links over the >last couple of years to those lists if we had implemented the >instructions in FAQ 3.3. > > We're still trying to work out how we can find a way to comply >with the requests with regards to the publicly accessible version of >the archives we maintain, without actually editing the source mbox >files. I think if you follow the suggestion in the last paragraph of this caveat which I added to http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.003.htp last July, you can edit the source mbox without changing the numbering when you rebuild. CAVEAT: If you delete entire messages from the archive two side effects occur: 1) Threading may be broken - if C is In-Reply-To: B which is In-Reply-To: A, and B is deleted, C will no longer be threaded with A. 2) Messages will be renumbered - this may be important if there are saved links to archive messages. Since the message number is part of the URI, the saved link will no longer work or will retrieve the wrong message. To avoid these problems, instead of deleting the entire message, leave the headers intact and replace the body with "Message deleted" or some other meaningful text. Please let me know if this is not correct. > I'd like to try to find a better way to solve this problem once >and for all, so that the sequence id would never be changed. I absolutely agree. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From tkikuchi at is.kochi-u.ac.jp Sun Feb 6 02:43:45 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sun Feb 6 02:43:52 2005 Subject: [Mailman-Developers] Patch 1107169: Re-use member_moderation_notice for generic_nonmember_action In-Reply-To: References: <4204C8AC.7000607@is.kochi-u.ac.jp> Message-ID: <42057651.30603@is.kochi-u.ac.jp> Hi, Brad Knowles wrote: > At 10:22 PM +0900 2005-02-05, Tokio Kikuchi wrote: > >> I was thinking that it would be better to have another text box to input >> say 'nonmember_rejection_notice' in the admin/privacy/sender page so the >> list owner can differentiate members and nonmembers. > >> I think I can find a time to >> add a text box and new attribute now. (May be in a day or two) I've just commited in the developers cvs. It should appear in the public cvs within 24 hours. Please run 'bin/update -f' if you want to test it before the next beta release because usual install will not check the data file version. (You think me fast? I've almost done this when I mailed last night ;-) Need-a-sleep-and-a-cup-of-morning-coffee-before-commiting-ly, Tokio From brad at stop.mail-abuse.org Sun Feb 6 03:03:42 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sun Feb 6 03:06:58 2005 Subject: [Mailman-Developers] Hacking pipermail... In-Reply-To: References: Message-ID: At 5:40 PM -0800 2005-02-05, Mark Sapiro wrote: > Are you referring to > >http://sourceforge.net/tracker/index.php?func=detail&aid=1059566&group_id=103&atid=350103 Dang. I had searched for it as a bug, and had forgotten that I'd filed it as an RFE instead. Sigh.... > To avoid these problems, instead of deleting the entire message, leave > the headers intact and replace the body with "Message deleted" or some > other meaningful text. > > Please let me know if this is not correct. No, you've got it right. That would help us on mailman-users and mailman-developers, for the requests that we've gotten to delete some old messages from the archives. Except that there has been a policy decision that we don't want to edit the source mailbox itself, we want that to be kept as a permanent record of what was sent to the list. We're still trying to figure out how we're going to make that work. However, the problem I had on the other list was that there had been a problem on the system, and I only had February 2005 archives available, with message numbers starting at the beginning. How do you backfill the older archives (from the same source mbox file) without regenerating the message numbers? I guess if I'd been thinking about it, I could have broken the mbox file into two parts, one that had already been processed and the rest, and avoid blowing away the old archives while I import the previously unprocessed mbox file But what do you do afterwards? Do you re-stitch the mbox files together so that you can re-create the archives in the future if there is a catastrophic failure, or do you leave the mbox files permanently separated? If you do leave them permanently separated, where do you leave them and how do you make sure that the right thing happens to the right ones, as new messages are processed? At the time, the only thing I could figure was to follow the instructions in FAQ 3.3. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Sun Feb 6 03:06:48 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sun Feb 6 03:07:06 2005 Subject: [Mailman-Developers] Patch 1107169: Re-use member_moderation_notice for generic_nonmember_action In-Reply-To: <42057651.30603@is.kochi-u.ac.jp> References: <4204C8AC.7000607@is.kochi-u.ac.jp> <42057651.30603@is.kochi-u.ac.jp> Message-ID: At 10:43 AM +0900 2005-02-06, Tokio Kikuchi wrote: > I've just commited in the developers cvs. It should appear in the public > cvs within 24 hours. Cool! Thanks! > Please run 'bin/update -f' if you want to test it > before the next beta release because usual install will not check the > data file version. I'm not going to update the version we're running on python.org without first talking to Barry, and seeing if there is some process he wants to go through to do QA testing on it, before we push into production. I don't want to be known as the guy who broke the installation of Mailman on the site where Mailman is developed/supported. At least not without having at least a couple of other people I can make sure will share the blame with me. ;) -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From msapiro at value.net Sun Feb 6 03:45:09 2005 From: msapiro at value.net (Mark Sapiro) Date: Sun Feb 6 03:45:20 2005 Subject: [Mailman-Developers] Hacking pipermail... In-Reply-To: Message-ID: Brad Knowles wrote: > > But what do you do afterwards? Do you re-stitch the mbox files >together so that you can re-create the archives in the future if >there is a catastrophic failure, or do you leave the mbox files >permanently separated? If you do leave them permanently separated, >where do you leave them and how do you make sure that the right thing >happens to the right ones, as new messages are processed? What I did with several lists for which I imported archives from prior versions of the list is this. The current mbox for the Mailman list is .mbox/.mbox. In addition there are older, imported archives in files in the same .mbox/ directory named .mbox/-topica.mbox and .mbox/-yahoo.mbox. Then there are instructions in a Wiki detailing the archive rebuilding process and processing order. With any luck, whoever has to rebuild the archive will refer to the Wiki. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From msapiro at value.net Mon Feb 7 02:39:41 2005 From: msapiro at value.net (Mark Sapiro) Date: Mon Feb 7 02:39:52 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] complete personalisation In-Reply-To: <353592404.20050206224257@Hofmeir.de> Message-ID: Stefan Hofmeir wrote: > >each subscriber of a newsletter list should see his email address in >the "to" field, so I have set "personalize: complete >personalisation". > >But why is every newsletter sent in "cc" to the list address? >To: Subscriber123 >CC: mailmanlist The Cc is added so the recipient can reply to the list with the reply-all feature of his/her MUA. I gather from your other post that your list is also anonymous and in this case the Cc is redundant as the list posting address is already in From and Reply-To: >How can I delete the "cc" field? I have submitted a patch for this at http://sourceforge.net/tracker/index.php?func=detail&aid=1117618&group_id=103&atid=300103 This patch will supress adding the Cc if the list is anonymous. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From tkikuchi at is.kochi-u.ac.jp Mon Feb 7 05:55:06 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Mon Feb 7 05:55:27 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] complete personalisation In-Reply-To: References: Message-ID: <4206F4AA.1010008@is.kochi-u.ac.jp> Mark, I reviewed the patch and think it reasonable to be included in 2.1.6. I will find time to test on my site and check in within a week. Thanks a lot, Mark Sapiro wrote: > Stefan Hofmeir wrote: > >>each subscriber of a newsletter list should see his email address in >>the "to" field, so I have set "personalize: complete >>personalisation". >> >>But why is every newsletter sent in "cc" to the list address? >>To: Subscriber123 >>CC: mailmanlist > > > The Cc is added so the recipient can reply to the list with the > reply-all feature of his/her MUA. > > I gather from your other post that your list is also anonymous and in > this case the Cc is redundant as the list posting address is already > in From and Reply-To: > > >>How can I delete the "cc" field? > > > I have submitted a patch for this at > http://sourceforge.net/tracker/index.php?func=detail&aid=1117618&group_id=103&atid=300103 > > This patch will supress adding the Cc if the list is anonymous. > > -- > Mark Sapiro The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From chris at digital-waves.net Mon Feb 7 18:18:36 2005 From: chris at digital-waves.net (Chris Malatesta) Date: Mon Feb 7 18:18:50 2005 Subject: [Mailman-Developers] Subject_prefix doesn't get added for posts from one domain In-Reply-To: Message-ID: I posted this to the mailman-users list and no one seemed to have any idea, so I thought I'd give you all a shot. Appreciate anything that you come up with... Chris ------ Forwarded Message > From: Chris Malatesta > Date: Fri, 04 Feb 2005 20:17:03 -0800 > To: "mailman-users@python.org" > Subject: Subject_prefix doesn't get added for posts from one domain > > Hopefully someone has an answer for this one, I haven?t been able to find it > anywhere... > > I have setup a new mailman server for a client (RHE3/netmail 1.0.5/Mailman > 2.1.5) when people from one domain running qmail post to a newly created list > with the default options, the subject_prefix doesn?t get added to the subject > line, but it does for everyone else??? > > The only thing I can think could be different is the header of the email, > There are some differences with mail from this domain, but I don?t believe > they are necessarily wrong, but it is the only thing I can see would be different... > > Any ideas would be appreciated. > > Chris > > > I.e. Here is a header from this domain, with the actual address names and ip's > changed. > > Received: from domain.com ([55.255.255.255]) by otherdomain.com with Microsoft > SMTPSVC(6.0.3790.211); > Wed, 2 Feb 2005 17:30:07 -0800 > Received: (qmail 508 invoked by uid 14282); 3 Feb 2005 01:33:53 -0000 > Received: from user@domain.com by domain.com by uid 505 with > qmail-scanner-1.22 > (avp: 5.0.2.0. f-prot: 3.12/. Clear:RC:1(10.250.100.83):. > Processed in 0.557572 secs); 03 Feb 2005 01:33:53 -0000 > Received: from in.domain.com (HELO usersname) (10.250.100.83) > by 0 with SMTP; 3 Feb 2005 01:33:53 -0000 > Reply-To: > From: "First Last" > To: "'First Last'" > Subject: Same Problem > Date: Wed, 2 Feb 2005 17:34:44 -0800 > Organization: Company Name > > Message-ID: <012b01c50990$8cf42bc0$a764fa0a@usersname> > > MIME-Version: 1.0 > Content-Type: multipart/mixed; > boundary="----=_NextPart_000_012C_01C5094D.7ED0EBC0" > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook, Build 10.0.2627 > Importance: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 > X-Bogosity: No, tests=bogofilter, spamicity=0.500000, version=0.17.5 > Return-Path: user@domain.com > X-OriginalArrivalTime: 03 Feb 2005 01:30:08.0062 (UTC) > FILETIME=[E53905E0:01C5098F] > ------ End of Forwarded Message From claw at kanga.nu Mon Feb 7 21:00:57 2005 From: claw at kanga.nu (J C Lawrence) Date: Mon Feb 7 21:01:02 2005 Subject: [Mailman-Developers] MACE, Internet2, mailing lists etc Message-ID: <27687.1107806457@kanga.nu> Middleware-Enabled Mailing List Working Group (MACE-MLIST): http://middleware.internet2.edu/mlist/ ---- Charter The I2 MACE-MLIST working group intends to address the following sets of issues: - The WG will research the issues surrounding middleware-enablement of mailing list services. Where possible, the WG will document how to perform this integration and provide forums where people can learn and help each other in addressing these integration issues within campus contexts. Where appropriate, the WG will collaborate with open source communities to consider needed modifications or other techniques for achieving better integration with the enterprise/federation. - The WG will consider and implement a survey of current university mailing list users to identify favorite features, needed improvements, and notable warts. We will map existing mailing list capabilities to a matrix of available functionality. - The WG will include persons who are actively working on integration with the enterprise/federation using non-proprietary technology; experiences will be shared regarding application designs best supporting infrastructure. Working group members will test-drive pilot/prototype solutions. Outcomes / Deliverables 1. Survey results, identifying best features, absent features, and desired improvements from users of mailing list software, along with a mapping of this feature set to existing mailing list software. 2. A simple model of mailing list management software operations, with middleware enablement points identified. 3. At least one open-source list software prototype (Sympa is a likely candidate) using federated authN/Z. 4. Documentation describing methods for modifying open source list software for use in federated environments. ---- -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From brad at stop.mail-abuse.org Tue Feb 8 02:30:00 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue Feb 8 02:30:12 2005 Subject: [Mailman-Developers] Mail-to-news gatewaying? Message-ID: Folks, Okay, so we know about the issue of munging Message-ID: (if you don't know what I'm talking about, see ). The latest crisis that has me wondering is the subject prefix stuff. Looking in NewsRunner.py, starting at line 104, we have: # Should we restore the original, non-prefixed subject for gatewayed # messages? origsubj = msgdata.get('origsubj') if not mlist.news_prefix_subject_too and origsubj is not None: del msg['subject'] msg['subject'] = origsubj However, we still have a problem. If mail clients reply to the message to the list (which will include the subject prefix), then this will result in a new message with a subject prefix for the list already present. Now, Mailman is smart and avoids adding a second subject prefix, but it doesn't strip out the subject prefix if one already exists. For the mailing list, this subject prefix stripping isn't necessary. But for gatewaying to the newsgroup, it might be desirable. This would also resolve the issue of restoring the original subject when gatewaying -- don't bother, and just let the subject prefix stripper deal with it. If this were sed or Perl, I could quickly put together a one-line hack to implement this feature. For example, just doing something off the top of my head, you might be able to use something like: subject=y/\w*$prefix\w*/ /; But this is Python, and I don't really grok Python. Can someone help me out here? Looking at , I'm imagining some sort of permutation of find(), split(), either lstrip() or rstrip(), and then join(), should be sufficient to do the job. But I'm not quite able to figure out how to put them all together. Of course, the reason why I ask is that I'm getting complaints about the mail-to-news gateway I'm running at another site, and I don't want this to blow up into an ugly situation. Sigh.... -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tkikuchi at is.kochi-u.ac.jp Tue Feb 8 04:11:12 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue Feb 8 04:11:20 2005 Subject: [Mailman-Developers] Mail-to-news gatewaying? In-Reply-To: References: Message-ID: <42082DD0.7070408@is.kochi-u.ac.jp> Hi, Brad Knowles wrote: > The latest crisis that has me wondering is the subject prefix > stuff. Looking in NewsRunner.py, starting at line 104, we have: > > # Should we restore the original, non-prefixed subject for gatewayed > # messages? > origsubj = msgdata.get('origsubj') > if not mlist.news_prefix_subject_too and origsubj is not None: > del msg['subject'] > msg['subject'] = origsubj > > > However, we still have a problem. If mail clients reply to the > message to the list (which will include the subject prefix), then this > will result in a new message with a subject prefix for the list already > present. Now, Mailman is smart and avoids adding a second subject > prefix, but it doesn't strip out the subject prefix if one already > exists. For the mailing list, this subject prefix stripping isn't > necessary. But for gatewaying to the newsgroup, it might be desirable. Sorry but I have no newsgroup forwarding environment here. Our system administrator (myself) determined long ago that newsgroups (usenet and fj) have extremely low S/N ratio and waste of storage and bandwidth. ;-) > > This would also resolve the issue of restoring the original subject > when gatewaying -- don't bother, and just let the subject prefix > stripper deal with it. > > > If this were sed or Perl, I could quickly put together a one-line > hack to implement this feature. For example, just doing something off > the top of my head, you might be able to use something like: > > subject=y/\w*$prefix\w*/ /; Things are not easy because there are MIME subjects and we also start numbering prefix in mailman 2.1.6. May be we can calculate 'stripped_subject' in CookHeaders.py and store in msgdata for later use. Or, strip in a magical ;-) way which I use in CookHeaders.py and in HyperArch.py, in NewsRunner.py again. Anyway, I will try. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tobias at kabissa.org Tue Feb 8 04:18:45 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Tue Feb 8 04:17:56 2005 Subject: [Mailman-Developers] Fwd: Volunteer sought to code Mailman/Plesk integration script for use by African organizations In-Reply-To: References: Message-ID: <59a9633628adb8120ac310d6eb0463c5@kabissa.org> Hi Brad, As regards your two faq questions - > It's funny. A totally different question regarding integration > between Mailman and Plesk finally lead me to create FAQ 6.15 at > req=show&file=faq06.015.htp>. This FAQ I think is still perfectly adequate, except perhaps you may want to refer people to the Plesk Forum at http://forum.sw-soft.com/ for help. SW-SOFT is notoriously soft (I mean poor) on tech support for end users, although folks on the forum are really helpful. There's alot of community support archived in there waiting to be searched for using the keyword 'mailman'. For us Rackspace (our hosting provider) is also very helpful, but we have been nurturing a relationship with them over the course of the last couple of years and they know I have been trying very hard to solve most Mailman problems on my own and only turn to them when I've hit a dead end. Any version of Plesk higher than Plesk 7 comes with an older version of Mailman installed, and enables Plesk clients to add/remove mailman lists through their control panel. This is nifty, but does not come with the benefits of newer versions of Mailman, and because it seems so simple it trips alot of people up since it encourages them to set up Mailman lists when really they probably only need something simpler. It is possible to trick Plesk into recognizing newer versions installed manually but it's not for the faint of heart. For me the trick is the combination of the qmail-to-mailman script which I've been using solidly for years and the new scripts I now have (and will share as soon as I'm positive it's working correctly) that scan the maildir directories and make sure the .qmail aliases created by Plesk for lists are all correctly pointing to the qmail-to-mailman script. Works like a charm! > Only now that I happen to be looking through my Python-related e-mail > for other things, do I come back to this and realize that you're > talking about the same sort of thing -- only you're talking about > fixing the problem that we cannot (today) fix ourselves. > > Of course, when you're talking about simulating the functionality of > Yahoo!Groups, there's also FAQ 1.26 at > req=show&file=faq01.026.htp>. I think this FAQ needs to be updated. I would not recommend m2f which has been stuck at beta for a very long time and seems to be going nowhere fast. Love the dedication of those guys but really it seems they've bitten off more than they can chew. A successful forum/list integration is done over at the unfortunately named FUDFORUM - http://www.fudforum.org. We use it very actively for two discussion lists and it has perfect bidirectional communication between the Mailman lists and forums. I am incredibly impressed by what the single developer of FUD has been able to achieve with this forum. Very much to be recommended. He also helped me personally to make it work with Mailman by making it possible to put the list name on the command line so that I could set up FUD's maillist.php script as a drop-in replacement for mhonarc/pipermail archiving. Wow. Unfortunately for us, FUD only has one developer and also does not integrate well with Mambo Open Source, the CMS we have chosen for our own Website. We are looking at developing open source Mambo components to connect Mailman lists with existing components in Mambo. This would include synchronizing subscriber lists with the user database and some sort of Mambo frontend for managing subscriptions. For discussions, it would provide bidirectional posting via either email or a fully-fledged web forum. For newsletters, it would provide an archive. For what it's worth, and for the record: for a few years now, to no avail so far, I've been probing the community forums for various promising forums about mailing list/forum/CMS integration: FUD Forum: http://www.fudforum.org PHPBB: http://www.phpbb.com M2F for phpbb: http://m2f.sourceforge.net Simple Machines Forum: http://www.simplemachines.org Mambo Simpleboard: http://tsmf.jigsnet.com/ > Speaking only for myself, I would very much like to see us get to a > situation where we can eliminate these two FAQ entries, and basically > "just make it work". I think this would be a huge benefit to the > entire Mailman community. Well, I think I addressed this above in part - the problem really is that Plesk makes it very easy to do alot of very powerful things. Like with the mysql databases you can set up, for example, people have an expectation that Mailman will be turnkey, which it really is not. I'm not sure it ever should be, though I do think (as I discussed above too) it would be helpful to have an easier frontend for subscribers and even for basic moderator functions. This would make Mailman more ready for wide adoption, even by regular everyday people who just want to set up a newsletter or discussion group and aren't interested in the technical aspects. > I can't help you with the Python coding, and I don't know squat about > Plesk, but if you need help with Mailman administration, please let me > know. Super - would be grateful for help here too, actually. > I'm willing to step up and do what I can to help towards this goal, > and I hope that other people on this list are willing and able to do > the same. Great - would be happy to talk with anyone about this! Cheers, Tobias -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From bob at nleaudio.com Tue Feb 8 06:07:00 2005 From: bob at nleaudio.com (Bob Puff@NLE) Date: Tue Feb 8 06:14:33 2005 Subject: [Mailman-Developers] Mail-to-news gatewaying? In-Reply-To: <42082DD0.7070408@is.kochi-u.ac.jp> References: <42082DD0.7070408@is.kochi-u.ac.jp> Message-ID: <420848F4.1070004@nleaudio.com> Tokio Kikuchi wrote: > Things are not easy because there are MIME subjects and we also start > numbering prefix in mailman 2.1.6. Why are we doing this, again? Bob From brad at stop.mail-abuse.org Tue Feb 8 09:49:32 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue Feb 8 10:01:09 2005 Subject: [Mailman-Developers] Fwd: Volunteer sought to code Mailman/Plesk integration script for use by African organizations In-Reply-To: <59a9633628adb8120ac310d6eb0463c5@kabissa.org> References: <59a9633628adb8120ac310d6eb0463c5@kabissa.org> Message-ID: At 10:18 PM -0500 2005-02-07, Tobias Eigen wrote: > As regards your two faq questions - > >> It's funny. A totally different question regarding integration >> between Mailman and Plesk finally lead me to create FAQ 6.15 at >> . > > This FAQ I think is still perfectly adequate, except perhaps you may > want to refer people to the Plesk Forum at http://forum.sw-soft.com/ > for help. Done. > Any version of Plesk higher than Plesk 7 comes with an older version > of Mailman installed, and enables Plesk clients to add/remove mailman > lists through their control panel. This is nifty, but does not come > with the benefits of newer versions of Mailman, and because it seems > so simple it trips alot of people up since it encourages them to set > up Mailman lists when really they probably only need something simpler. > > It is possible to trick Plesk into recognizing newer versions > installed manually but it's not for the faint of heart. Hmm. This is a good note to include in the FAQ entry. I hope you don't mind if I use it, but would you like this quote to be attributed to you by name? I didn't do that initially, because I feared you might get inundated with e-mail questions from other people, and I don't want to put you in that kind of a position unless you're willing to take that risk. >> Of course, when you're talking about simulating the functionality >> of Yahoo!Groups, there's also FAQ 1.26 at >> . > > I think this FAQ needs to be updated. I would not recommend m2f which > has been stuck at beta for a very long time and seems to be going > nowhere fast. Will do. > Love the dedication of those guys but really it seems they've bitten > off more than they can chew. A successful forum/list integration is > done over at the unfortunately named FUDFORUM - > http://www.fudforum.org. We use it very actively for two discussion > lists and it has perfect bidirectional communication between the > Mailman lists and forums. I am incredibly impressed by what the > single developer of FUD has been able to achieve with this forum. Is this stuff publicly available? Should we refer people to it? > For what it's worth, and for the record: for a few years now, to no > avail so far, I've been probing the community forums for various > promising forums about mailing list/forum/CMS integration: > > FUD Forum: http://www.fudforum.org > PHPBB: http://www.phpbb.com > M2F for phpbb: http://m2f.sourceforge.net > Simple Machines Forum: http://www.simplemachines.org > Mambo Simpleboard: http://tsmf.jigsnet.com/ Of these, we know that you like FUD Forum, and m2f leaves much to be desired. Do any of the others provide any integration features with Mailman? > Well, I think I addressed this above in part - the problem really > is that Plesk makes it very easy to do alot of very powerful things. > Like with the mysql databases you can set up, for example, people > have an expectation that Mailman will be turnkey, which it really is > not. I'm not sure it ever should be, though I do think (as I > discussed above too) it would be helpful to have an easier frontend > for subscribers and even for basic moderator functions. This would > make Mailman more ready for wide adoption, even by regular everyday > people who just want to set up a newsletter or discussion group and > aren't interested in the technical aspects. I agree that we can (and should) make Mailman easier to use and administrate. Of course, that has to be balanced with the desire to have additional features, usually coming from the more advanced sites and programmers. I wouldn't want to create a fork of Mailman, but it would be nice if we could find some way to combine both ease-of-use and power features. Of course, others can always disagree with the balance that we try to strike, but it would be nice if we could get their help in trying to fix those issues from within Mailman, as opposed to having them take what we've got and then add their own tools to munge it beyond recognition. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Tue Feb 8 09:25:58 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue Feb 8 10:01:10 2005 Subject: [Mailman-Developers] Mail-to-news gatewaying? In-Reply-To: <42082DD0.7070408@is.kochi-u.ac.jp> References: <42082DD0.7070408@is.kochi-u.ac.jp> Message-ID: At 12:11 PM +0900 2005-02-08, Tokio Kikuchi wrote: > Things are not easy because there are MIME subjects There's that damn pesky MIME problem again. ;) > and we also start > numbering prefix in mailman 2.1.6. Ouch! I had forgotten about that. > May be we can calculate > 'stripped_subject' in CookHeaders.py and store in msgdata for > later use. Or, strip in a magical ;-) way which I use in > CookHeaders.py and in HyperArch.py, in NewsRunner.py again. Hmm. Maybe we can have a library routine that all programs could use? > Anyway, I will try. Much appreciated. Thanks! -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From msapiro at value.net Tue Feb 8 17:17:30 2005 From: msapiro at value.net (Mark Sapiro) Date: Tue Feb 8 17:17:41 2005 Subject: [Mailman-Developers] Mail-to-news gatewaying? In-Reply-To: <420848F4.1070004@nleaudio.com> Message-ID: Bob Puff@NLE wrote: > >Tokio Kikuchi wrote: > >> Things are not easy because there are MIME subjects and we also start >> numbering prefix in mailman 2.1.6. > >Why are we doing this, again? It's optional and the default is not to. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From brad at stop.mail-abuse.org Tue Feb 8 17:49:56 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue Feb 8 17:50:10 2005 Subject: [Mailman-Developers] Mail-to-news gatewaying? In-Reply-To: References: Message-ID: At 2:30 AM +0100 2005-02-08, Brad Knowles wrote: > The latest crisis that has me wondering is the subject prefix stuff. > Looking in NewsRunner.py, starting at line 104, we have: > > # Should we restore the original, non-prefixed subject for gatewayed > # messages? > origsubj = msgdata.get('origsubj') > if not mlist.news_prefix_subject_too and origsubj is not None: > del msg['subject'] > msg['subject'] = origsubj Okay, I broke down and bought the three primary Python books -- Learning, Programming, and Nutshell. Looking at the string functions, and not accounting for MIME encoding, Unicode encoding, or subject numbering, to my na?eve perspective, it looks like we should be able to turn this into something like the following: # Should we restore the original, non-prefixed subject for gatewayed # messages? origsubj = msgdata.get('origsubj') if not mlist.news_prefix_subject_too and origsubj is not None: stripped_subj = subject.replace(r'\s*'+subject_prefix+r'\s*', ' ') del msg['subject'] msg['subject'] = stripped_subj The s.replace() function should grab any leading whitespace and trailing whitespace surrounding the subject_prefix, and replace all of that with a single space character. Now, to go off and look at CookHeaders.py and see just how far off I am.... -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From joe at cmsinfo.org Tue Feb 8 19:00:08 2005 From: joe at cmsinfo.org (Joe Stewart) Date: Tue Feb 8 19:26:51 2005 Subject: [Mailman-Developers] Fwd: Volunteer sought to code Mailman/Plesk integration script for use by African organizations In-Reply-To: References: <59a9633628adb8120ac310d6eb0463c5@kabissa.org> Message-ID: <4208FE28.9040202@cmsinfo.org> > > >> For what it's worth, and for the record: for a few years now, to no >> avail so far, I've been probing the community forums for various >> promising forums about mailing list/forum/CMS integration: >> >> FUD Forum: http://www.fudforum.org >> PHPBB: http://www.phpbb.com >> M2F for phpbb: http://m2f.sourceforge.net >> Simple Machines Forum: http://www.simplemachines.org >> Mambo Simpleboard: http://tsmf.jigsnet.com/ > > > Of these, we know that you like FUD Forum, and m2f leaves much to > be desired. Do any of the others provide any integration features > with Mailman? > > phorum3 had the phorummail script to pipe mail into a post. I asked Brian last week and he was working on the updated one for phorum5 at that time. I looked and didn't see any cvs commits though. It didn't communicate with mailman though so subscriptions and users are completely separated. drupal has a listhandler module. Joe From bob at nleaudio.com Tue Feb 8 20:25:32 2005 From: bob at nleaudio.com (Bob Puff@NLE) Date: Tue Feb 8 20:33:00 2005 Subject: [Mailman-Developers] Mail-to-news gatewaying? In-Reply-To: References: Message-ID: <4209122C.4040207@nleaudio.com> Right, but why are we providing the option in the first place? To try to show threading? Seems that it would cause more grief like that which Brad was alluding to earlier. I'm just wondering if we're losing a good fix due to an incompatibility with a feature that might not be used. Bob Mark Sapiro wrote: > Bob Puff@NLE wrote: > >>Tokio Kikuchi wrote: >> >> >>>Things are not easy because there are MIME subjects and we also start >>>numbering prefix in mailman 2.1.6. >> >>Why are we doing this, again? > > > It's optional and the default is not to. > > -- > Mark Sapiro The highway is for gamblers, > San Francisco Bay Area, California better 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-users%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > From brad at stop.mail-abuse.org Tue Feb 8 21:24:01 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue Feb 8 21:31:25 2005 Subject: [Mailman-Developers] Mail-to-news gatewaying? In-Reply-To: <4209122C.4040207@nleaudio.com> References: <4209122C.4040207@nleaudio.com> Message-ID: At 2:25 PM -0500 2005-02-08, Bob Puff@NLE wrote: > Right, but why are we providing the option in the first place? To try > to show threading? Seems that it would cause more grief like that which > Brad was alluding to earlier. I'm not 100% certain, but I don't think that the subject numbering issue has any direct relation to the mail/news gateway process. I think it's intended for use in mail-only environments, perhaps such as an official support mailing list where things need to be tracked by ticket number, etc.... In this case, the subject numbering would presumably become the ticket number. > I'm just wondering if we're losing a good fix due to an incompatibility > with a feature that might not be used. So long as there's an optional way to cause that to be pulled back out when the message is gatewayed to a newsgroup, and the overall feature defaults to off, I don't see that there's much of a problem here. But it certainly can make life in other areas more complex. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From ml at ancalagon.inka.de Tue Feb 8 21:31:49 2005 From: ml at ancalagon.inka.de (Thomas Hochstein) Date: Tue Feb 8 21:32:05 2005 Subject: [Mailman-Developers] Mail-to-news gatewaying? References: <4209122C.4040207@nleaudio.com> Message-ID: "Bob Puff@NLE" schrieb: > Right, but why are we providing the option in the first place? IIRC because it was requested by quite a lot of users. -thh From bernhard at bksys.at Wed Feb 9 12:08:12 2005 From: bernhard at bksys.at (Bernhard Kuemel) Date: Wed Feb 9 12:08:19 2005 Subject: [Mailman-Developers] mailman email harvester Message-ID: <4209EF1C.20200@bksys.at> This mail got blocked at first because I was not subscribed with my current email address. Some of you may remember that I announced the release of the harvester script. We discussed the issue and as the result was, not to change mailman, I now released the script to raise public awareness of the problem. Bernhard -------- Original Message -------- Subject: mailman email harvester Date: Mon, 07 Feb 2005 23:48:44 +0100 From: Bernhard Kuemel To: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com, mailman-developers@python.org Hi! Tons of email addresses from mailman mailing lists are vulnerable to be collected by spammers. They are "protected" by obfuscation (user@example.com -> user at example.com) and access to the subscriber list can be restricted to subscribers. The obfuscation is trivially reversed and harvester scripts can subscribe to gain access to restricted lists. I suggested a graphical turing test that would bar scripts but the mailman developers argued spammers might hire a couple of temps that would solve the test as it already happened for the creation of email accounts. The only solution would be not to have the desired information available. This is already an option by restricting access to the member list to the list administrator. However, still many lists either have the member list openly published, or available to the list members. To raise awareness to this issue I wrote a script that collects addresses from openly accessible lists. It stops after processing 1000 (the maximum allowed) search results from google and collects 76772 email addresses (61124 unique). It is attached as mmxp1. An improved version that collects addresses that are restricted to subscribers, processes more lists and works more parallelized is planned. Bye, Bernhard -------------- next part -------------- #!/usr/bin/perl -w #http://www.google.com/search?q=%22list+is+only+available+to+the+list+members%22+mailman/listinfo&start=600&num=100 #2.1.4 "current archive" "private list which" mailman/listinfo site:org $n=0; $u=0; for ($i=0;1;$i+=10) { $#urls=-1; $google=`wget -qO - -U 'any browser' 'http://www.google.com/search?q=%22Click+here+for+the+list%22+mailman%2Flistinfo&start=$i'`; # print $google; @urls=($google=~m*

*g); # print join("\n",@urls); if ($#urls==-1) {last;} # print "\naoeu $#urls\n"; foreach $url (@urls) { $u++; $url=~s*/listinfo/*/roster/*; print STDERR "$url...\n"; $roster=`lynx -connect_timeout=10 -dump $url`; # print $roster; @mails=$roster=~/^ +\* \(?\[\d+\](.* at .*?)\)?$/mgo; foreach $mail (@mails) { $mail=~s/ at /@/; print "$mail\n"; $n++; } print STDERR "mails=".($#mails+1).", total=$n, url=$u, google=$i\n"; # exit; } #foreach url } #while google From tkikuchi at is.kochi-u.ac.jp Wed Feb 9 23:00:08 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed Feb 9 23:00:28 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] security heads up - path traversal with 2.1.5 In-Reply-To: <200502091119.46050.rb@islandnet.com> References: <200502091119.46050.rb@islandnet.com> Message-ID: <420A87E8.9070200@is.kochi-u.ac.jp> Hi, Ron Brogden wrote: > Hey folks. I haven't see an official post here yet but as this has already > gone out on at least one full-disclosure list I thought it worth mentioning > since this will be an actively exploited 0 day: > > http://lists.netsys.com/pipermail/full-disclosure/2005-February/031562.html Barry and I are notified on this subject but both are busy on their job so he requested for delay in the disclosure. > > Basically, there is a path traversal issue with mailman 2.1.5 which will let > you access any file that the Mailman user has read access to (at least under > Apache 1.3, can't speak for other web servers). I have tested this on a > personal box and it does indeed work as advertised. I've tested with my 1.3.29 installation and verified apache PATH_INFO does convert '//' to '/'. Barry also wanted to clarify which apache version/installation (combination with mailman) is valnerable. Return code of 200 doesn't mean sucessful exploit. You should check mailman logs/error also. (If there is none chances are succesful exploit.) > > One temporary workaround is to stop access to "/mailman/private" via your web > server configuration. I would wait for a formal patch notice from the > developers before patching the actual Mailman code. Also newly introduced script bin/reset_pw.py may be useful if your list has been really exploited. (It should be veiwable from SourceForge CVS but it looks like currently in trouble.) -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From chris at digital-waves.net Wed Feb 9 23:15:24 2005 From: chris at digital-waves.net (Chris Malatesta) Date: Wed Feb 9 23:15:30 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] Subject_prefix doesn't get added for posts from one domain - Solved In-Reply-To: Message-ID: So here is the answer, The domain that I used to setup the mailman server used to be managed by the domain/server that was sending the problem posts. They still had this domain in the virtualdomain file for their qmail server. Now why the email was even getting out of their qmail server and actually posted to the list is beyond me as these are 2 different servers on different networks, but just removing this domain from virtualdomains solved the problem. Thanks, Chris On 2/7/05 11:51 AM, "Mark Sapiro" wrote: > Chris Malatesta wrote: > >> So here is the issue, posts from this one domain don't get mailman header >> information added to the email, although they get posted to the list. >> >> What would cause a post to go to the list and not get header info and the >> Subject_prefix added to that post? > > The message is not being processed by CookHeaders which is the module > that adds the subject prefix and headers X-BeenThere, > X-Mailman-Version, Precedence and maybe others depending on list > options. > > CookHeaders must be in the list pipeline since it is there for messages > from other domains. I can't see how it would be avoided for just the > messages from this one domain. Presumably the rest of the pipline is > processed since without CalcRecips and ToOutgoing or at least > ToDigest, the message wouldn't be sent to anyone. > > This is really puzzling. > > -- > Mark Sapiro The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > From tobias at kabissa.org Thu Feb 10 02:52:54 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Thu Feb 10 03:20:22 2005 Subject: [Mailman-Developers] Fwd: [SourceForge.net Release] m2f : m2f Message-ID: <08ac9b6da36ba0e925ecad08163a485a@kabissa.org> fyi - maybe I was wrong.. release candidate of m2f has been released today. Begin forwarded message: > From: "SourceForge.net" > Date: February 9, 2005 8:22:13 PM EST > To: noreply@sourceforge.net > Subject: [SourceForge.net Release] m2f : m2f > > Project: mail2forum (m2f) > Package: m2f > Date : 2005-02-09 22:22 > > Project "mail2forum" ('m2f') has released the new version of package > 'm2f'. > You can download it from SourceForge.net by following this link: > group_id=68964&release_id=303790> > or browse Release Notes and ChangeLog by visiting this link: > > > You receive this email because you requested to be notified when new > versions > of this package were released. If you don't wish to be notified in the > future, > please login to SourceForge.net and click this link: > filemodule_id=67748> > If you lost your SourceForge.net login name or password, refer to this > document: > > > Note that you may receive this message indirectly via one of your > mailing list > subscriptions. Please review message headers before reporting > unsolicited > mailings. > -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From barry at python.org Thu Feb 10 15:41:05 2005 From: barry at python.org (Barry Warsaw) Date: Thu Feb 10 15:41:08 2005 Subject: [Mailman-Developers] Critical security update for Mailman 2.1.5 and earlier Message-ID: <1108046465.8044.63.camel@presto.wooz.org> There is a critical security flaw in Mailman 2.1.5 and earlier Mailman 2.1 versions which can allow remote attackers to gain access to member passwords under certain conditions. The extent of the vulnerability depends on what version of Apache you are running, and (possibly) how you have configured your web server. However, the flaw is in Mailman and has been fix in CVS and will be included in the Mailman 2.1.6 release. This issue has been assigned CVE number CAN-2005-0202. We currently believe that Apache 2.0 sites are not vulnerable, and that many if not most Apache 1.3 sites are. In any event, the safest approach is to assume the worst and take the remediation steps indicated below as soon as possible. The quickest fix is to remove the /usr/local/mailman/cgi-bin/private executable. This will disable all access to all private archives on your system. While this is the quickest and easiest way to close the hole, it will also break all your private archives. If all the lists on your site only run public archives, this won't matter to you. Until Mailman 2.1.6 is released, the longer term fix is to apply this patch: http://www.list.org/CAN-2005-0202.txt For additional piece of mind, it is recommended that you regenerate your member passwords. Instructions on how to do this, and more information about this vulnerability are available here: http://www.list.org/security.html My thanks to Tokio Kikuchi, Mark J Cox, and the folks on vendor-sec. This issue was found by Marcus Meissner. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050210/4f0f07e1/attachment.pgp From barry at python.org Thu Feb 10 16:02:21 2005 From: barry at python.org (Barry Warsaw) Date: Thu Feb 10 16:02:23 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck Message-ID: <1108047741.8045.81.camel@presto.wooz.org> I think CAN-2005-0202 gives us the opportunity to finally implement what we have long considered an embarrassing exposure in Mailman's config.pck databases. Member passwords are kept in this database in the clear. The obvious fix is to hash member passwords and keep only the hash in the database. We haven't changed this before now for two reasons: 1. We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement checks to see if the passwords were cleartext or hashed and do the password comparison accordingly. 2. This breaks all password reminders. To fully address CAN-2005-0202 we're recommending sites regenerate their member passwords anyway, so this gives us an opening to fix this properly. And we have a better internal password generator now too. As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3. I don't think many people would shed too many tears if we killed off monthly password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to function as the sender of the reminder messages. To do this for 2.1.6, we'd have to change the "Email My Password To Me" feature in the options page and in the member login page. These would have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that script should turn into a simple "here's the lists you are on" reminder, without the password information in it. This will require i18n updates too. The downside to doing this now is that it's more coding work for 2.1.6 and I'd like to get the new version out asap. Still, this seems like an opportunity that we shouldn't lightly dismiss. What do you all think? Is anybody willing to take a crack at a patch for this? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050210/a6adc3c7/attachment.pgp From jbebel at ncsu.edu Thu Feb 10 16:44:37 2005 From: jbebel at ncsu.edu (Joel Ebel) Date: Thu Feb 10 16:44:40 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108047741.8045.81.camel@presto.wooz.org> References: <1108047741.8045.81.camel@presto.wooz.org> Message-ID: <420B8165.5030108@ncsu.edu> I can't speak to whether the work is worth the benefit, but I'm definitely in favor of the change. I've always questioned the benefit of having recoverable passwords. I feel like a password should be a one way thing. You put it in, and you can't get it back. If you forget it, you have to reset it. I think password reminders are unnecessary, and I don't really like having passwords in my email anyway. Perhaps a reminder of how to access your membership settings and reset your password would be a better option anyway. Joel Barry Warsaw wrote: > I think CAN-2005-0202 gives us the opportunity to finally implement what > we have long considered an embarrassing exposure in Mailman's config.pck > databases. Member passwords are kept in this database in the clear. > The obvious fix is to hash member passwords and keep only the hash in > the database. > > We haven't changed this before now for two reasons: > > 1. We would have to regenerate all member passwords, which is an > administrative burden. We might also need to implement checks to see if > the passwords were cleartext or hashed and do the password comparison > accordingly. > > 2. This breaks all password reminders. > > To fully address CAN-2005-0202 we're recommending sites regenerate their > member passwords anyway, so this gives us an opening to fix this > properly. And we have a better internal password generator now too. > > As for #2, well, I think most people hate those password reminders > anyway, and we've decided that they are going away for MM3. I don't > think many people would shed too many tears if we killed off monthly > password reminders for 2.1.6. Doing that would also eliminate the > requirement for the site list, since its primary purpose is to function > as the sender of the reminder messages. > > To do this for 2.1.6, we'd have to change the "Email My Password To Me" > feature in the options page and in the member login page. These would > have to become a "create a new password for me" feature. Also, > crontab.in should not call mailpasswds anymore, or that script should > turn into a simple "here's the lists you are on" reminder, without the > password information in it. This will require i18n updates too. > > The downside to doing this now is that it's more coding work for 2.1.6 > and I'd like to get the new version out asap. Still, this seems like an > opportunity that we shouldn't lightly dismiss. > > What do you all think? Is anybody willing to take a crack at a patch > for this? > > -Barry > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/jbebel%40ncsu.edu From mm at mewes.tv Thu Feb 10 17:08:23 2005 From: mm at mewes.tv (Martin Mewes) Date: Thu Feb 10 17:08:29 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420B8165.5030108@ncsu.edu> References: <1108047741.8045.81.camel@presto.wooz.org> <420B8165.5030108@ncsu.edu> Message-ID: <200502101708.24184.mm@mewes.tv> Hi all, I am new to this list and just want to give my two cents as a first step. I mainly will give my best on i18n things in future (en->de). Joel Ebel wrote : > I can't speak to whether the work is worth the benefit, but I'm > definitely in favor of the change. I've always questioned the > benefit of having recoverable passwords. I feel like a password > should be a one way thing. You put it in, and you can't get it back. > If you forget it, you have to reset it. I think password reminders > are unnecessary, and I don't really like having passwords in my email > anyway. Perhaps a reminder of how to access your membership settings > and reset your password would be a better option anyway. *subscribed* However I am not impressed by the fact that such a "major" change should be done to 2.1.6 but if the majority says "yes" I will follow. Maybe it would be possible to give the installer options like (just out of my brain): ./install update - preserves settings like in 2.1.5 with monthly password reminders ./install upgrade - rewrites everything to Barry's suggestions ./install - defaults to upgrade Again however, a GUI-Option should be possible to "upgrade" later if the valued ListAdmin did an "update" in first instance. I know, this will cause in double work maintaining two areas of MM and as I am not that much into coding, but I think this would be pretty. Upgrading should mean to install the "Technology Preview for MM3" ;-) bis dahin/kind regards Martin Mewes -- You are receiving this automatic notification because I am out of the office. If I was in, chances are you wouldn't have received anything at all. From tobias at kabissa.org Thu Feb 10 17:17:02 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Thu Feb 10 17:16:30 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108047741.8045.81.camel@presto.wooz.org> References: <1108047741.8045.81.camel@presto.wooz.org> Message-ID: <8ecb2733f212dff7189919c470609e78@kabissa.org> Hi Barry, While you're on this subject, I was intrigued by the password resetting script but was disappointed that there is no way to actually configure the password on the command-line. I was thinking this would enable integration of Mailman subscriptions into an existing user database (i.e. via a nightly cron). If you use a commonly used encryption, then doing this on the command line shouldn't pose any security issues. On Kabissa this would be a key aspect to making Mailman continue to work as our list manager of choice for e-mail newsletters and discussions in our CMS of choice, Mambo Open Source. Then again, if you're thinking of rewriting how passwords are kept, perhaps it might be useful to think about using a different type of container anyway, one that works with other, more sophisticated user management systems like those that come with CMSs. I.e. LDAP or simply mysql. And this, plus the CAN prefix to the patch name, reminds me: correct me if I'm wrong, but my understanding is that Mailman as it exists does not comply with the new (unfortunately named) CAN SPAM act. According to this act, a recipient of an email from a given site has to be able to opt out from receiving ANY MAIL from that site. Right now all mailman lists are treated completely separately, and nobody (not even the subscriber) can easily find out which lists subscribers are subscribed to. What I envision having in my Mailman/Mambo system is a single user database with one password per username for all services. Users can then go to a simple preferences page on Mambo and do basic things like change their email address or password, tick a box to opt in/out of various mailings, and in particular opt to receive no mail at all. Other Mambo components would handle reading forums and newsletters online and enable users to subscribe/unsubscribe to them. If anybody's got any suggestions on how to achieve this or is interested in working with us to develop this functionality, let me know. Cheers, Tobias On Feb 10, 2005, at 10:02 AM, Barry Warsaw wrote: > I think CAN-2005-0202 gives us the opportunity to finally implement > what > we have long considered an embarrassing exposure in Mailman's > config.pck > databases. Member passwords are kept in this database in the clear. > The obvious fix is to hash member passwords and keep only the hash in > the database. > > We haven't changed this before now for two reasons: > > 1. We would have to regenerate all member passwords, which is an > administrative burden. We might also need to implement checks to see > if > the passwords were cleartext or hashed and do the password comparison > accordingly. > > 2. This breaks all password reminders. > > To fully address CAN-2005-0202 we're recommending sites regenerate > their > member passwords anyway, so this gives us an opening to fix this > properly. And we have a better internal password generator now too. > > As for #2, well, I think most people hate those password reminders > anyway, and we've decided that they are going away for MM3. I don't > think many people would shed too many tears if we killed off monthly > password reminders for 2.1.6. Doing that would also eliminate the > requirement for the site list, since its primary purpose is to function > as the sender of the reminder messages. > > To do this for 2.1.6, we'd have to change the "Email My Password To Me" > feature in the options page and in the member login page. These would > have to become a "create a new password for me" feature. Also, > crontab.in should not call mailpasswds anymore, or that script should > turn into a simple "here's the lists you are on" reminder, without the > password information in it. This will require i18n updates too. > > The downside to doing this now is that it's more coding work for 2.1.6 > and I'd like to get the new version out asap. Still, this seems like > an > opportunity that we shouldn't lightly dismiss. > > What do you all think? Is anybody willing to take a crack at a patch > for this? > > -Barry > > _______________________________________________ > 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/ > tobias%40kabissa.org -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From chuqui at plaidworks.com Thu Feb 10 17:22:29 2005 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Thu Feb 10 17:23:14 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108047741.8045.81.camel@presto.wooz.org> References: <1108047741.8045.81.camel@presto.wooz.org> Message-ID: <7fb40126b90c5b2289b871345f64e5aa@plaidworks.com> On Feb 10, 2005, at 7:02 AM, Barry Warsaw wrote: > I think CAN-2005-0202 gives us the opportunity to finally implement > what > we have long considered an embarrassing exposure in Mailman's > config.pck > databases. Member passwords are kept in this database in the clear. > The obvious fix is to hash member passwords and keep only the hash in > the database. +1 > As for #2, well, I think most people hate those password reminders > anyway, yes. we have some folks on our lists who send us monthly "why haven't you stopped doing this yet?" messages. it'd almost be amusing, if it weren't so annoying... (grin) > To do this for 2.1.6, we'd have to change the "Email My Password To Me" > feature in the options page and in the member login page. These would > have to become a "create a new password for me" feature. +1 > The downside to doing this now is that it's more coding work for 2.1.6 > and I'd like to get the new version out asap. Still, this seems like > an > opportunity that we shouldn't lightly dismiss. > get the patch out with 2.1.6, then do 2.1.7 with the new password stuff. I think that's reasonable. From tobias at kabissa.org Thu Feb 10 17:36:10 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Thu Feb 10 17:35:38 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <8ecb2733f212dff7189919c470609e78@kabissa.org> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> Message-ID: Ah - I had forgotten the ~mailman/bin/withlist script. Sorry, folks, still just getting back into Mailman. If it works as advertised, then I also vote for the changes Barry is recommending. It makes Mailman completely compatible with the type of CMS integration I'm describing. Joel's point about passwords being one-way "You put it in, and you can't get it back" is perfectly true. Cheers, Tobias On Feb 10, 2005, at 11:17 AM, Tobias Eigen wrote: > Hi Barry, > > While you're on this subject, I was intrigued by the password > resetting script but was disappointed that there is no way to actually > configure the password on the command-line. I was thinking this would > enable integration of Mailman subscriptions into an existing user > database (i.e. via a nightly cron). If you use a commonly used > encryption, then doing this on the command line shouldn't pose any > security issues. On Kabissa this would be a key aspect to making > Mailman continue to work as our list manager of choice for e-mail > newsletters and discussions in our CMS of choice, Mambo Open Source. > > Then again, if you're thinking of rewriting how passwords are kept, > perhaps it might be useful to think about using a different type of > container anyway, one that works with other, more sophisticated user > management systems like those that come with CMSs. I.e. LDAP or simply > mysql. > > And this, plus the CAN prefix to the patch name, reminds me: correct > me if I'm wrong, but my understanding is that Mailman as it exists > does not comply with the new (unfortunately named) CAN SPAM act. > According to this act, a recipient of an email from a given site has > to be able to opt out from receiving ANY MAIL from that site. Right > now all mailman lists are treated completely separately, and nobody > (not even the subscriber) can easily find out which lists subscribers > are subscribed to. What I envision having in my Mailman/Mambo system > is a single user database with one password per username for all > services. Users can then go to a simple preferences page on Mambo and > do basic things like change their email address or password, tick a > box to opt in/out of various mailings, and in particular opt to > receive no mail at all. Other Mambo components would handle reading > forums and newsletters online and enable users to > subscribe/unsubscribe to them. > > If anybody's got any suggestions on how to achieve this or is > interested in working with us to develop this functionality, let me > know. > > Cheers, > > Tobias > > On Feb 10, 2005, at 10:02 AM, Barry Warsaw wrote: > >> I think CAN-2005-0202 gives us the opportunity to finally implement >> what >> we have long considered an embarrassing exposure in Mailman's >> config.pck >> databases. Member passwords are kept in this database in the clear. >> The obvious fix is to hash member passwords and keep only the hash in >> the database. >> >> We haven't changed this before now for two reasons: >> >> 1. We would have to regenerate all member passwords, which is an >> administrative burden. We might also need to implement checks to see >> if >> the passwords were cleartext or hashed and do the password comparison >> accordingly. >> >> 2. This breaks all password reminders. >> >> To fully address CAN-2005-0202 we're recommending sites regenerate >> their >> member passwords anyway, so this gives us an opening to fix this >> properly. And we have a better internal password generator now too. >> >> As for #2, well, I think most people hate those password reminders >> anyway, and we've decided that they are going away for MM3. I don't >> think many people would shed too many tears if we killed off monthly >> password reminders for 2.1.6. Doing that would also eliminate the >> requirement for the site list, since its primary purpose is to >> function >> as the sender of the reminder messages. >> >> To do this for 2.1.6, we'd have to change the "Email My Password To >> Me" >> feature in the options page and in the member login page. These would >> have to become a "create a new password for me" feature. Also, >> crontab.in should not call mailpasswds anymore, or that script should >> turn into a simple "here's the lists you are on" reminder, without the >> password information in it. This will require i18n updates too. >> >> The downside to doing this now is that it's more coding work for 2.1.6 >> and I'd like to get the new version out asap. Still, this seems like >> an >> opportunity that we shouldn't lightly dismiss. >> >> What do you all think? Is anybody willing to take a crack at a patch >> for this? >> >> -Barry >> >> _______________________________________________ >> 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/ >> tobias%40kabissa.org > -- > Tobias Eigen > Executive Director > > Kabissa - Space for Change in Africa > http://www.kabissa.org > > * Kabissa's vision is for a socially, economically, politically, and > environmentally vibrant Africa, supported by a strong network of > effective civil society organizations. * > > _______________________________________________ > 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/ > tobias%40kabissa.org > -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From tobias at kabissa.org Thu Feb 10 17:40:29 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Thu Feb 10 17:39:54 2005 Subject: [Mailman-Developers] mailman email harvester In-Reply-To: <4209EF1C.20200@bksys.at> References: <4209EF1C.20200@bksys.at> Message-ID: Hi all, Is there a way to change the setting to restrict access to the roster for all lists, globally? If there isn't one, would one of you be willing to write one quickly? The only other option I see is to remove the ~mailman/cgi-bin/roster script which would be a pity. Given the risk, now made worse by Bernhard's very helpfully distributing this script for spammers, this is a really urgent issue. Cheers, Tobias On Feb 9, 2005, at 6:08 AM, Bernhard Kuemel wrote: > This mail got blocked at first because I was not subscribed with my > current email address. > > Some of you may remember that I announced the release of the harvester > script. We discussed the issue and as the result was, not to change > mailman, I now released the script to raise public awareness of the > problem. > > Bernhard > > -------- Original Message -------- > Subject: mailman email harvester > Date: Mon, 07 Feb 2005 23:48:44 +0100 > From: Bernhard Kuemel > To: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com, > mailman-developers@python.org > > Hi! > > Tons of email addresses from mailman mailing lists are vulnerable to > be collected by spammers. > > They are "protected" by obfuscation (user@example.com -> user at > example.com) and access to the subscriber list can be restricted to > subscribers. The obfuscation is trivially reversed and harvester > scripts can subscribe to gain access to restricted lists. > > I suggested a graphical turing test that would bar scripts but the > mailman developers argued spammers might hire a couple of temps that > would solve the test as it already happened for the creation of > email accounts. The only solution would be not to have the desired > information available. This is already an option by restricting > access to the member list to the list administrator. > > However, still many lists either have the member list openly > published, or available to the list members. To raise awareness to > this issue I wrote a script that collects addresses from openly > accessible lists. It stops after processing 1000 (the maximum > allowed) search results from google and collects 76772 email > addresses (61124 unique). It is attached as mmxp1. > > An improved version that collects addresses that are restricted to > subscribers, processes more lists and works more parallelized is > planned. > > Bye, Bernhard > #!/usr/bin/perl -w > > #http://www.google.com/search? > q=%22list+is+only+available+to+the+list+members%22+mailman/ > listinfo&start=600&num=100 > #2.1.4 "current archive" "private list which" mailman/listinfo site:org > > $n=0; > $u=0; > for ($i=0;1;$i+=10) { > $#urls=-1; > $google=`wget -qO - -U 'any browser' > 'http://www.google.com/search? > q=%22Click+here+for+the+list%22+mailman%2Flistinfo&start=$i'`; > # print $google; > @urls=($google=~m*

*g); > # print join("\n",@urls); > if ($#urls==-1) {last;} > # print "\naoeu $#urls\n"; > > foreach $url (@urls) { > $u++; > $url=~s*/listinfo/*/roster/*; > print STDERR "$url...\n"; > $roster=`lynx -connect_timeout=10 -dump $url`; > # print $roster; > @mails=$roster=~/^ +\* \(?\[\d+\](.* at .*?)\)?$/mgo; > foreach $mail (@mails) { > $mail=~s/ at /@/; > print "$mail\n"; > $n++; > } > print STDERR "mails=".($#mails+1).", total=$n, url=$u, google=$i\n"; > # exit; > } #foreach url > > } #while google > > _______________________________________________ > 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/ > tobias%40kabissa.org -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From r.barrett at openinfo.co.uk Thu Feb 10 18:24:08 2005 From: r.barrett at openinfo.co.uk (Richard Barrett) Date: Thu Feb 10 18:24:22 2005 Subject: [Mailman-Developers] Re: [Mailman-Announce] Critical security update for Mailman 2.1.5 and earlier In-Reply-To: <1108046465.8044.63.camel@presto.wooz.org> References: <1108046465.8044.63.camel@presto.wooz.org> Message-ID: <92999004-7B88-11D9-BF34-000A957C9A50@openinfo.co.uk> Barry I am not convinced that all the potential security problems with private.py are covered by the patch being published. For some time I have added modifications to private.py as part of my htdig integration patch which maybe should be considered for addition to the standard MM distribution. I give below the patch to private.py for MM release 2.1.4 (although the same fix applies to later releases) and some notes on the matter in the INSTALL.htdig-mm file added by my patch. Of course, these changes may be judged irrelevant by Mailman's developers. As an aside, I am not able to: 1. identify exactly what the exploit is. 2. see why it impacts solely on private archive access via private.py. 3. why Apache version is relevant to private.py operates unless the PATH_INFO environment variable value being set up for the CGI script by Apache is a result of version-dependent processing done by Apache on the request URI. Richard $build/INSTALL.htdig-mm ------------------------------------------------------------------------ - $prefix/Mailman/Cgi/private.py There is a security hole in the released Mailman code via which private.py will serve files such as a list's archive pipermail.pck and files in the list's archive database sub-directory. This hole also allows access to the list's archive htdig sub-directory. Fixes for this are applied. As htdig.py (see below) is based on private.py the same security fix has been incorporated into it. Notes and Warnings? ---------------- Archive security problems resolved by htdig-2.1.3-0.2 patch This patch is hopefully the final step in closing security holes in archive access. In version htdig-2.1.3-0.1.patch, htdig.py was rebased on the standard MM release's private.py which had moved on since the snapshot of it used as the basis for htdig.py was originally taken. Among other things, htdig.py had been modified to prevent access to some files in list archive directories such as a list's archive pipermail.pck and files in the list's archive database sub-directory. This rebasing action re-introduced to htdig.py the security holes, still extant in private.py despite it being later code, via which private.py would serve files such as a list's archive pipermail.pck and files in the list's archive database sub-directory. The permissions on these files and directories mean that they are inaccessible via the web server using /pipermail/ URIs if a list's archive is public. ------------------------------------------------------------------------ - ------------------------------------------------------------------------ - diff -r -u -P --exclude=.DS_Store mailman-2.1.4-index/Mailman/Cgi/private.py mailman-2.1.4-htdig/Mailman/Cgi/private.py --- mailman-2.1.4-index/Mailman/Cgi/private.py Sat Feb 8 07:13:50 2003 +++ mailman-2.1.4-htdig/Mailman/Cgi/private.py Thu Jan 1 12:43:24 2004 @@ -21,6 +21,7 @@ import sys import cgi import mimetypes +import re from Mailman import mm_cfg from Mailman import Utils @@ -71,7 +72,7 @@ listname = parts[0].lower() mboxfile = '' - if len(parts) > 1: + if len(parts) == 2: mboxfile = parts[1] # See if it's the list's mbox file is being requested @@ -100,6 +101,26 @@ doc.AddItem(Header(2, msg)) print doc.Format() syslog('error', 'No such list "%s": %s\n', listname, e) + return + + # If the path is not: + # .mbox/.mbox + # it should conform to: + # //... + # / + # and any filenames starting with '.' are also not allowed + num_parts = len(parts) + if not mboxfile and num_parts > 1 and \ + (parts[1] in ('database', 'htdig') or \ + (num_parts == 2 and \ + not re.compile(r'\.(html|txt|txt\.gz)$').search(true_filename) \ + ) or parts[-1][0] == '.' \ + ): + msg = _('Invalid archive file requested') + doc.SetTitle(msg) + doc.AddItem(Header(2, msg)) + print doc.Format() + syslog('error', 'Invalid archive file requested: %s', true_filename) return i18n.set_language(mlist.preferred_language) ------------------------------------------------------------------------ - On 10 Feb 2005, at 14:41, Barry Warsaw wrote: > There is a critical security flaw in Mailman 2.1.5 and earlier Mailman > 2.1 versions which can allow remote attackers to gain access to member > passwords under certain conditions. The extent of the vulnerability > depends on what version of Apache you are running, and (possibly) how > you have configured your web server. However, the flaw is in Mailman > and has been fix in CVS and will be included in the Mailman 2.1.6 > release. > > This issue has been assigned CVE number CAN-2005-0202. > > We currently believe that Apache 2.0 sites are not vulnerable, and that > many if not most Apache 1.3 sites are. In any event, the safest > approach is to assume the worst and take the remediation steps > indicated > below as soon as possible. > > The quickest fix is to remove the /usr/local/mailman/cgi-bin/private > executable. This will disable all access to all private archives on > your system. While this is the quickest and easiest way to close the > hole, it will also break all your private archives. If all the lists > on > your site only run public archives, this won't matter to you. > > Until Mailman 2.1.6 is released, the longer term fix is to apply this > patch: > > http://www.list.org/CAN-2005-0202.txt > > For additional piece of mind, it is recommended that you regenerate > your > member passwords. Instructions on how to do this, and more information > about this vulnerability are available here: > > http://www.list.org/security.html > > My thanks to Tokio Kikuchi, Mark J Cox, and the folks on vendor-sec. > This issue was found by Marcus Meissner. > > -Barry ----------------------------------------------------------------------- Richard Barrett http://www.openinfo.co.uk From jdennis at redhat.com Thu Feb 10 18:32:50 2005 From: jdennis at redhat.com (John Dennis) Date: Thu Feb 10 18:32:54 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <8ecb2733f212dff7189919c470609e78@kabissa.org> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> Message-ID: <1108056770.27472.97.camel@finch.boston.redhat.com> My suggestion would be: 1) As soon as possible post MM 2.1.6 with the security patch. 2) Quickly follow up with MM 2.1.7 with the member passwords hashed. At the same time I think we should implement the stronger password generation suggested in this open advisory against mailman. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-1143 I believe this will need a little support in configure.in to detect and be able to utilize the presence of /dev/urandom with an appropriate fall back in its absence. One of my hesitations to injecting the stronger password generation into mailman was the resulting password is then sent in the clear via SMTP, the same is true for the "lost password" feature, and the monthly password reminders. Until all these clear transmissions of passwords are turned off stronger password generation seems a moot point to me. Thus I agree with Barry, turn off the monthly reminders, "mail my password to me" needs to be changed to generate a new password (using the stronger mechanism in CAN-2004-1143), AND the generated password sent in the clear needs to expire in a configurable amount of time (default = 8 hours?) and with first use (e.g. must reset password) so that any password sent in the clear has very limited utility. Then in the MM 3.0 time frame the entire mailman security framework should be revisited, there are many security issues that should be addressed. At a minimum the suggestion of supporting alternate authentication mechanisms (e.g. pam, ldap, kerberos, etc.) should be implemented. In my mind, this is too radical for a 2.1.x release. 3.0 is the right time debut a more configurable and robust security framework. -- John Dennis From jdennis at redhat.com Thu Feb 10 18:35:45 2005 From: jdennis at redhat.com (John Dennis) Date: Thu Feb 10 18:35:56 2005 Subject: [Mailman-Developers] Re: [Mailman-Announce] Critical security update for Mailman 2.1.5 and earlier In-Reply-To: <92999004-7B88-11D9-BF34-000A957C9A50@openinfo.co.uk> References: <1108046465.8044.63.camel@presto.wooz.org> <92999004-7B88-11D9-BF34-000A957C9A50@openinfo.co.uk> Message-ID: <1108056945.27472.100.camel@finch.boston.redhat.com> On Thu, 2005-02-10 at 17:24 +0000, Richard Barrett wrote: > As an aside, I am not able to: > > 1. identify exactly what the exploit is. > > 2. see why it impacts solely on private archive access via private.py. > > 3. why Apache version is relevant to private.py operates unless the > PATH_INFO environment variable value being set up for the CGI script by > Apache is a result of version-dependent processing done by Apache on > the request URI. Please, lets not discuss the recipe for the attack on an open mailing list. -- John Dennis From r.barrett at openinfo.co.uk Thu Feb 10 18:38:13 2005 From: r.barrett at openinfo.co.uk (Richard Barrett) Date: Thu Feb 10 18:38:26 2005 Subject: [Mailman-Developers] Re: [Mailman-Announce] Critical security update for Mailman 2.1.5 and earlier In-Reply-To: <1108046465.8044.63.camel@presto.wooz.org> References: <1108046465.8044.63.camel@presto.wooz.org> Message-ID: <8A3CACFE-7B8A-11D9-BF34-000A957C9A50@openinfo.co.uk> Regarding my previous post on this subject. Having read http://lists.netsys.com/pipermail/full-disclosure/2005-February/ 031562.html my lack of comprehension noted in my previous post is resolved but my comments about other issues with private.py stand. ----------------------------------------------------------------------- Richard Barrett http://www.openinfo.co.uk From wilder at eskimo.com Thu Feb 10 19:32:43 2005 From: wilder at eskimo.com (Dan Wilder) Date: Thu Feb 10 19:33:40 2005 Subject: [Mailman-Developers] mailman email harvester In-Reply-To: References: <4209EF1C.20200@bksys.at> Message-ID: <20050210183243.GC12675@eskimo.com> On Thu, Feb 10, 2005 at 11:40:29AM -0500, Tobias Eigen wrote: > Hi all, > > Is there a way to change the setting to restrict access to the roster > for all lists, globally? If there isn't one, would one of you be > willing to write one quickly? The only other option I see is to remove > the ~mailman/cgi-bin/roster script which would be a pity. > > Given the risk, now made worse by Bernhard's very helpfully > distributing this script for spammers, this is a really urgent issue. Not that hard to write such a script. I expect the spammers already have several alternatives to choose from. So, it's quite likely no harm has been done, and some good, arising from Bernhard's raising the issue in public. I'd go further and mention that while Berhhard's script harvests membership rosters, it isn't that much more difficult to write a script that gets around the obfuscation of email addresses in the list archives. A list I used to manage until a few weeks ago (Hey, anybody got a lead on a Seattle-area opportunity for a rabid Python developer? Who also does C, SQL, HTML, CSS and various assemblers?) apparently had its archives harvested recently by some bank phishing folk. Emails were obscured in the archives using the "user at wherever.domain" option, and the archives had been regenerated quite some time ago back to their beginning, with that option in force. The roster has never been open to anybody but the list admin, so I don't believe it was the roster. Hence, likely it was the archives that were harvested. There are a pretty fair number of good reasons for keeping list archives open. My opinion is a person posting to a list assumes the risk of having his or her email address harvested, and that one unwilling to assume this risk should refrain from posting. However I understand if others do not subscribe to that belief, and that there may be circumstances where there are reasonable grounds for wanting to manage a list by some other policy. My suggestion is that an option be considered to redact all email addresses whatsoever from a list archive. Including anything mentioned in-line in the text of the post that even vaguely looks like an email address. No doubt somebody on this list manages a list where users are quite sensitive to public exposure, who might care to advocate for such an option, and even code it, should the idea meet with sufficient approval. -- Dan Wilder From bob at nleaudio.com Thu Feb 10 19:29:51 2005 From: bob at nleaudio.com (Bob Puff@NLE) Date: Thu Feb 10 19:36:59 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108047741.8045.81.camel@presto.wooz.org> References: <1108047741.8045.81.camel@presto.wooz.org> Message-ID: <420BA81F.4060504@nleaudio.com> I've -always- disabled the monthly reminders, so that would be no great loss. If we convert to one-way passwords, could the upgrade script convert the current passwords? It would be a -big- deal if everyone had to reset their passwords. Bob Barry Warsaw wrote: > I think CAN-2005-0202 gives us the opportunity to finally implement what > we have long considered an embarrassing exposure in Mailman's config.pck > databases. Member passwords are kept in this database in the clear. > The obvious fix is to hash member passwords and keep only the hash in > the database. > > We haven't changed this before now for two reasons: > > 1. We would have to regenerate all member passwords, which is an > administrative burden. We might also need to implement checks to see if > the passwords were cleartext or hashed and do the password comparison > accordingly. > > 2. This breaks all password reminders. > > To fully address CAN-2005-0202 we're recommending sites regenerate their > member passwords anyway, so this gives us an opening to fix this > properly. And we have a better internal password generator now too. > > As for #2, well, I think most people hate those password reminders > anyway, and we've decided that they are going away for MM3. I don't > think many people would shed too many tears if we killed off monthly > password reminders for 2.1.6. Doing that would also eliminate the > requirement for the site list, since its primary purpose is to function > as the sender of the reminder messages. > > To do this for 2.1.6, we'd have to change the "Email My Password To Me" > feature in the options page and in the member login page. These would > have to become a "create a new password for me" feature. Also, > crontab.in should not call mailpasswds anymore, or that script should > turn into a simple "here's the lists you are on" reminder, without the > password information in it. This will require i18n updates too. > > The downside to doing this now is that it's more coding work for 2.1.6 > and I'd like to get the new version out asap. Still, this seems like an > opportunity that we shouldn't lightly dismiss. > > What do you all think? Is anybody willing to take a crack at a patch > for this? > > -Barry > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/bob%40nleaudio.com From adrian at tasdevil.com Thu Feb 10 19:44:22 2005 From: adrian at tasdevil.com (Adrian Bye) Date: Thu Feb 10 19:44:26 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420BA81F.4060504@nleaudio.com> Message-ID: <20050210184424.D56AC1E417C@bag.python.org> Why even bother with passwords? They're good to include in the unsubscribe URL, so that if someone maliciously gets your list, they can't unsubscribe everyone manually. But mainstream commercial autoresponders have no passwords, and they work great. Sure, it _is_ possible that someone could cause problems, which a password prevents. But in practice this rarely happens. We're not talking the 80/20 rule - we're talking the 99.99/0.01 rule. Your average user is over burdened with passwords, and most mailing lists are pretty low involvement - users don't want to have to remember another password just for a mailing list. I've actually had some changes to my mailman install made so that users can unsubscribe without a password - I'll share the code next week so you can take a look at it. We also shorted the unsubscribe URLs so it was below 60 chars, ensuring that it would work more reliably and not get broken on some mail clients. Getting rid of passwords would open up mailman to usage to a much wider range of users, which should mean more development resources and interest. > -----Original Message----- > From: Bob Puff@NLE [mailto:bob@nleaudio.com] > Sent: Thursday, February 10, 2005 2:30 PM > To: Barry Warsaw > Cc: mailman-developers@python.org > Subject: Re: [Mailman-Developers] Hashing member passwords in > config.pck > > I've -always- disabled the monthly reminders, so that would > be no great loss. > > If we convert to one-way passwords, could the upgrade script > convert the current passwords? It would be a -big- deal if > everyone had to reset their passwords. > > Bob > > Barry Warsaw wrote: > > > I think CAN-2005-0202 gives us the opportunity to finally implement > > what we have long considered an embarrassing exposure in Mailman's > > config.pck databases. Member passwords are kept in this > database in the clear. > > The obvious fix is to hash member passwords and keep only > the hash in > > the database. > > > > We haven't changed this before now for two reasons: > > > > 1. We would have to regenerate all member passwords, which is an > > administrative burden. We might also need to implement > checks to see > > if the passwords were cleartext or hashed and do the password > > comparison accordingly. > > > > 2. This breaks all password reminders. > > > > To fully address CAN-2005-0202 we're recommending sites regenerate > > their member passwords anyway, so this gives us an opening > to fix this > > properly. And we have a better internal password generator now too. > > > > As for #2, well, I think most people hate those password reminders > > anyway, and we've decided that they are going away for MM3. > I don't > > think many people would shed too many tears if we killed > off monthly > > password reminders for 2.1.6. Doing that would also eliminate the > > requirement for the site list, since its primary purpose is to > > function as the sender of the reminder messages. > > > > To do this for 2.1.6, we'd have to change the "Email My > Password To Me" > > feature in the options page and in the member login page. > These would > > have to become a "create a new password for me" feature. Also, > > crontab.in should not call mailpasswds anymore, or that > script should > > turn into a simple "here's the lists you are on" reminder, > without the > > password information in it. This will require i18n updates too. > > > > The downside to doing this now is that it's more coding > work for 2.1.6 > > and I'd like to get the new version out asap. Still, this > seems like > > an opportunity that we shouldn't lightly dismiss. > > > > What do you all think? Is anybody willing to take a crack > at a patch > > for this? > > > > -Barry > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > 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/bob%40nleaud > > io.com > _______________________________________________ > 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/adri > an%40tasdevil.com > > From bob at nleaudio.com Thu Feb 10 19:41:09 2005 From: bob at nleaudio.com (Bob Puff@NLE) Date: Thu Feb 10 19:48:14 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050210184424.D56AC1E417C@bag.python.org> References: <20050210184424.D56AC1E417C@bag.python.org> Message-ID: <420BAAC5.403@nleaudio.com> Private mailing list archives. Needed for that. Adrian Bye wrote: > Why even bother with passwords? They're good to include in the unsubscribe URL, > so that if someone maliciously gets your list, they can't unsubscribe everyone > manually. But mainstream commercial autoresponders have no passwords, and they > work great. > > Sure, it _is_ possible that someone could cause problems, which a password > prevents. But in practice this rarely happens. We're not talking the 80/20 rule > - we're talking the 99.99/0.01 rule. > > Your average user is over burdened with passwords, and most mailing lists are > pretty low involvement - users don't want to have to remember another password > just for a mailing list. > > I've actually had some changes to my mailman install made so that users can > unsubscribe without a password - I'll share the code next week so you can take a > look at it. We also shorted the unsubscribe URLs so it was below 60 chars, > ensuring that it would work more reliably and not get broken on some mail > clients. > > Getting rid of passwords would open up mailman to usage to a much wider range of > users, which should mean more development resources and interest. > > >>-----Original Message----- >>From: Bob Puff@NLE [mailto:bob@nleaudio.com] >>Sent: Thursday, February 10, 2005 2:30 PM >>To: Barry Warsaw >>Cc: mailman-developers@python.org >>Subject: Re: [Mailman-Developers] Hashing member passwords in >>config.pck >> >>I've -always- disabled the monthly reminders, so that would >>be no great loss. >> >>If we convert to one-way passwords, could the upgrade script >>convert the current passwords? It would be a -big- deal if >>everyone had to reset their passwords. >> >>Bob >> >>Barry Warsaw wrote: >> >> >>>I think CAN-2005-0202 gives us the opportunity to finally implement >>>what we have long considered an embarrassing exposure in Mailman's >>>config.pck databases. Member passwords are kept in this >> >>database in the clear. >> >>>The obvious fix is to hash member passwords and keep only >> >>the hash in >> >>>the database. >>> >>>We haven't changed this before now for two reasons: >>> >>>1. We would have to regenerate all member passwords, which is an >>>administrative burden. We might also need to implement >> >>checks to see >> >>>if the passwords were cleartext or hashed and do the password >>>comparison accordingly. >>> >>>2. This breaks all password reminders. >>> >>>To fully address CAN-2005-0202 we're recommending sites regenerate >>>their member passwords anyway, so this gives us an opening >> >>to fix this >> >>>properly. And we have a better internal password generator now too. >>> >>>As for #2, well, I think most people hate those password reminders >>>anyway, and we've decided that they are going away for MM3. >> >> I don't >> >>>think many people would shed too many tears if we killed >> >>off monthly >> >>>password reminders for 2.1.6. Doing that would also eliminate the >>>requirement for the site list, since its primary purpose is to >>>function as the sender of the reminder messages. >>> >>>To do this for 2.1.6, we'd have to change the "Email My >> >>Password To Me" >> >>>feature in the options page and in the member login page. >> >>These would >> >>>have to become a "create a new password for me" feature. Also, >>>crontab.in should not call mailpasswds anymore, or that >> >>script should >> >>>turn into a simple "here's the lists you are on" reminder, >> >>without the >> >>>password information in it. This will require i18n updates too. >>> >>>The downside to doing this now is that it's more coding >> >>work for 2.1.6 >> >>>and I'd like to get the new version out asap. Still, this >> >>seems like >> >>>an opportunity that we shouldn't lightly dismiss. >>> >>>What do you all think? Is anybody willing to take a crack >> >>at a patch >> >>>for this? >>> >>>-Barry >>> >>> >>> >>> >> >>---------------------------------------------------------------------- >> >>>-- >>> >>>_______________________________________________ >>>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/bob%40nleaud >> >>>io.com >> >>_______________________________________________ >>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/adri >>an%40tasdevil.com >> >> > > > _______________________________________________ > 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/bob%40nleaudio.com > From tobias at kabissa.org Thu Feb 10 19:50:13 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Thu Feb 10 19:49:40 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420BA81F.4060504@nleaudio.com> References: <1108047741.8045.81.camel@presto.wooz.org> <420BA81F.4060504@nleaudio.com> Message-ID: <4656de44da5b2af91f5ec82f1724064d@kabissa.org> I'm with Bob here - I did a scan of the httpd log on my mailman server and I'm pretty sure we were not hit by either the spammers using the ~mailman/cgi-bin/roster vulnerability or the hackers via the ~mailman/cgi-bin/private vulnerability. I've now disabled both of these scripts for the time being until I find a way to plug the holes. Encrypting passwords will go a long way to fixing the risk in the future, and forcing everyone to change their passwords is really a big burden on them, especially if we're pretty sure they aren't compromised. Cheers, Tobias On Feb 10, 2005, at 1:29 PM, Bob Puff@NLE wrote: > I've -always- disabled the monthly reminders, so that would be no > great loss. > > If we convert to one-way passwords, could the upgrade script convert > the current passwords? It would be a -big- deal if everyone had to > reset their passwords. > > Bob > > Barry Warsaw wrote: > >> I think CAN-2005-0202 gives us the opportunity to finally implement >> what >> we have long considered an embarrassing exposure in Mailman's >> config.pck >> databases. Member passwords are kept in this database in the clear. >> The obvious fix is to hash member passwords and keep only the hash in >> the database. >> We haven't changed this before now for two reasons: >> 1. We would have to regenerate all member passwords, which is an >> administrative burden. We might also need to implement checks to see >> if >> the passwords were cleartext or hashed and do the password comparison >> accordingly. >> 2. This breaks all password reminders. >> To fully address CAN-2005-0202 we're recommending sites regenerate >> their >> member passwords anyway, so this gives us an opening to fix this >> properly. And we have a better internal password generator now too. >> As for #2, well, I think most people hate those password reminders >> anyway, and we've decided that they are going away for MM3. I don't >> think many people would shed too many tears if we killed off monthly >> password reminders for 2.1.6. Doing that would also eliminate the >> requirement for the site list, since its primary purpose is to >> function >> as the sender of the reminder messages. >> To do this for 2.1.6, we'd have to change the "Email My Password To >> Me" >> feature in the options page and in the member login page. These would >> have to become a "create a new password for me" feature. Also, >> crontab.in should not call mailpasswds anymore, or that script should >> turn into a simple "here's the lists you are on" reminder, without the >> password information in it. This will require i18n updates too. >> The downside to doing this now is that it's more coding work for 2.1.6 >> and I'd like to get the new version out asap. Still, this seems like >> an >> opportunity that we shouldn't lightly dismiss. >> What do you all think? Is anybody willing to take a crack at a patch >> for this? >> -Barry >> ---------------------------------------------------------------------- >> -- >> _______________________________________________ >> 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/ >> bob%40nleaudio.com > _______________________________________________ > 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/ > tobias%40kabissa.org > -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From chuqui at plaidworks.com Thu Feb 10 19:55:52 2005 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Thu Feb 10 19:56:04 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050210184424.D56AC1E417C@bag.python.org> References: <20050210184424.D56AC1E417C@bag.python.org> Message-ID: <8d75968bac541f84b859950bd97bddbf@plaidworks.com> this might not be a bad idea, but -- would require all operations to be validated via a URL emailed to the affected address. But I could live with that. On Feb 10, 2005, at 10:44 AM, Adrian Bye wrote: > Getting rid of passwords would open up mailman to usage to a much > wider range of > users, which should mean more development resources and interest. From chuqui at plaidworks.com Thu Feb 10 18:50:24 2005 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Thu Feb 10 20:09:17 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108056770.27472.97.camel@finch.boston.redhat.com> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> Message-ID: On Feb 10, 2005, at 9:32 AM, John Dennis wrote: > My suggestion would be: > > 1) As soon as possible post MM 2.1.6 with the security patch. > > 2) Quickly follow up with MM 2.1.7 with the member passwords hashed. At > > Then in the MM 3.0 time frame the entire mailman security framework > should be revisited, there are many security issues that should be > addressed. +1 From correia.rui at gmail.com Thu Feb 10 20:18:36 2005 From: correia.rui at gmail.com (Rui Correia) Date: Thu Feb 10 20:18:55 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420B8165.5030108@ncsu.edu> Message-ID: <000601c50fa5$5769d020$0100a8c0@Laptop> To make Joel's words mine. Even, where the password is set by the server, there are only so many passwords a person can remember - and invariably if one signs up to multiple forums/ lists/ one tends to repeat the password. So having the password mailed back is an unnecessary exposure. All that is waiting to happen is for someone to develop code to sit waiting for the monthly list reminders from Mailman and others, capture the login details and access mailboxes. Rui ________________________________________________ ? ? Rui Correia Advocacy, Media and Language Consultant 36 Finch St, Ontdekkers Park, Roodepoort, Johannesburg, South Africa Tel/ Fax (+27-11) 766-4336 Cell (+27) (0) 83-368-1214 -----Original Message----- From: mailman-developers-bounces+correia.rui=gmail.com@python.org [mailto:mailman-developers-bounces+correia.rui=gmail.com@python.org] On Behalf Of Joel Ebel Sent: 10 February 2005 17:45 To: mailman-developers@python.org Subject: Re: [Mailman-Developers] Hashing member passwords in config.pck I can't speak to whether the work is worth the benefit, but I'm definitely in favor of the change. I've always questioned the benefit of having recoverable passwords. I feel like a password should be a one way thing. You put it in, and you can't get it back. If you forget it, you have to reset it. I think password reminders are unnecessary, and I don't really like having passwords in my email anyway. Perhaps a reminder of how to access your membership settings and reset your password would be a better option anyway. Joel Barry Warsaw wrote: > I think CAN-2005-0202 gives us the opportunity to finally implement what > we have long considered an embarrassing exposure in Mailman's config.pck > databases. Member passwords are kept in this database in the clear. > The obvious fix is to hash member passwords and keep only the hash in > the database. > > We haven't changed this before now for two reasons: > > 1. We would have to regenerate all member passwords, which is an > administrative burden. We might also need to implement checks to see if > the passwords were cleartext or hashed and do the password comparison > accordingly. > > 2. This breaks all password reminders. > > To fully address CAN-2005-0202 we're recommending sites regenerate their > member passwords anyway, so this gives us an opening to fix this > properly. And we have a better internal password generator now too. > > As for #2, well, I think most people hate those password reminders > anyway, and we've decided that they are going away for MM3. I don't > think many people would shed too many tears if we killed off monthly > password reminders for 2.1.6. Doing that would also eliminate the > requirement for the site list, since its primary purpose is to function > as the sender of the reminder messages. > > To do this for 2.1.6, we'd have to change the "Email My Password To Me" > feature in the options page and in the member login page. These would > have to become a "create a new password for me" feature. Also, > crontab.in should not call mailpasswds anymore, or that script should > turn into a simple "here's the lists you are on" reminder, without the > password information in it. This will require i18n updates too. > > The downside to doing this now is that it's more coding work for 2.1.6 > and I'd like to get the new version out asap. Still, this seems like an > opportunity that we shouldn't lightly dismiss. > > What do you all think? Is anybody willing to take a crack at a patch > for this? > > -Barry > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/jbebel%40ncsu.edu _______________________________________________ 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/correia.rui%40gmai l.com From jared at puck.nether.net Thu Feb 10 20:42:54 2005 From: jared at puck.nether.net (Jared Mauch) Date: Thu Feb 10 20:42:58 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420BAAC5.403@nleaudio.com> References: <20050210184424.D56AC1E417C@bag.python.org> <420BAAC5.403@nleaudio.com> Message-ID: <20050210194254.GC88197@puck.nether.net> (sorry for the top posting..) I actually the the (yes, call me a fool) passwords of some private lists as a unified authentication system so the passwords are used to gain access to other 'authorized' content for list members. of course there's issues with them being sent out in plaintext monthly, but it does help provide unified access control to a private list. Ideally i'd like some hooks such that people could register their pgp/gpg keys and those messages could be encrypted but i've not had time to investigate such hooks. On Thu, Feb 10, 2005 at 01:41:09PM -0500, Bob Puff@NLE wrote: > Private mailing list archives. Needed for that. > > Adrian Bye wrote: > > >Why even bother with passwords? They're good to include in the > >unsubscribe URL, > >so that if someone maliciously gets your list, they can't unsubscribe > >everyone > >manually. But mainstream commercial autoresponders have no passwords, and > >they > >work great. Yes, but they tend to not host closed lists. They want people to join their lists and increase the marketing footprint. If it were a per-list setting, that would be great, combined with a mailman <-> gpg interface to load in trusted user pgp keys or to access a local keyserver.. this way the technical users can still have their cake and the "just host my list" people get theirs as well. - jared > >Sure, it _is_ possible that someone could cause problems, which a password > >prevents. But in practice this rarely happens. We're not talking the > >80/20 rule > >- we're talking the 99.99/0.01 rule. > > > >Your average user is over burdened with passwords, and most mailing lists > >are > >pretty low involvement - users don't want to have to remember another > >password > >just for a mailing list. > > > >I've actually had some changes to my mailman install made so that users can > >unsubscribe without a password - I'll share the code next week so you can > >take a > >look at it. We also shorted the unsubscribe URLs so it was below 60 chars, > >ensuring that it would work more reliably and not get broken on some mail > >clients. > > > >Getting rid of passwords would open up mailman to usage to a much wider > >range of > >users, which should mean more development resources and interest. > > > > > >>-----Original Message----- > >>From: Bob Puff@NLE [mailto:bob@nleaudio.com] > >>Sent: Thursday, February 10, 2005 2:30 PM > >>To: Barry Warsaw > >>Cc: mailman-developers@python.org > >>Subject: Re: [Mailman-Developers] Hashing member passwords in > >>config.pck > >> > >>I've -always- disabled the monthly reminders, so that would > >>be no great loss. > >> > >>If we convert to one-way passwords, could the upgrade script > >>convert the current passwords? It would be a -big- deal if > >>everyone had to reset their passwords. > >> > >>Bob > >> > >>Barry Warsaw wrote: > >> > >> > >>>I think CAN-2005-0202 gives us the opportunity to finally implement > >>>what we have long considered an embarrassing exposure in Mailman's > >>>config.pck databases. Member passwords are kept in this > >> > >>database in the clear. > >> > >>>The obvious fix is to hash member passwords and keep only > >> > >>the hash in > >> > >>>the database. > >>> > >>>We haven't changed this before now for two reasons: > >>> > >>>1. We would have to regenerate all member passwords, which is an > >>>administrative burden. We might also need to implement > >> > >>checks to see > >> > >>>if the passwords were cleartext or hashed and do the password > >>>comparison accordingly. > >>> > >>>2. This breaks all password reminders. > >>> > >>>To fully address CAN-2005-0202 we're recommending sites regenerate > >>>their member passwords anyway, so this gives us an opening > >> > >>to fix this > >> > >>>properly. And we have a better internal password generator now too. > >>> > >>>As for #2, well, I think most people hate those password reminders > >>>anyway, and we've decided that they are going away for MM3. > >> > >>I don't > >> > >>>think many people would shed too many tears if we killed > >> > >>off monthly > >> > >>>password reminders for 2.1.6. Doing that would also eliminate the > >>>requirement for the site list, since its primary purpose is to > >>>function as the sender of the reminder messages. > >>> > >>>To do this for 2.1.6, we'd have to change the "Email My > >> > >>Password To Me" > >> > >>>feature in the options page and in the member login page. > >> > >>These would > >> > >>>have to become a "create a new password for me" feature. Also, > >>>crontab.in should not call mailpasswds anymore, or that > >> > >>script should > >> > >>>turn into a simple "here's the lists you are on" reminder, > >> > >>without the > >> > >>>password information in it. This will require i18n updates too. > >>> > >>>The downside to doing this now is that it's more coding > >> > >>work for 2.1.6 > >> > >>>and I'd like to get the new version out asap. Still, this > >> > >>seems like > >> > >>>an opportunity that we shouldn't lightly dismiss. > >>> > >>>What do you all think? Is anybody willing to take a crack > >> > >>at a patch > >> > >>>for this? > >>> > >>>-Barry > >>> > >>> > >>> > >>> > >> > >>---------------------------------------------------------------------- > >> > >>>-- > >>> > >>>_______________________________________________ > >>>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/bob%40nleaud > >> > >>>io.com > >> > >>_______________________________________________ > >>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/adri > >>an%40tasdevil.com > >> > >> > > > > > >_______________________________________________ > >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/bob%40nleaudio.com > > > _______________________________________________ > 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/jared%40puck.nether.net -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From brad at stop.mail-abuse.org Thu Feb 10 19:08:51 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Feb 10 22:05:00 2005 Subject: [Mailman-Developers] mailman email harvester In-Reply-To: References: <4209EF1C.20200@bksys.at> Message-ID: At 11:40 AM -0500 2005-02-10, Tobias Eigen wrote: > Is there a way to change the setting to restrict access to the roster for > all lists, globally? That should be possible to do using "withlist". However, I don't know the specifics of how to do that. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Thu Feb 10 19:07:31 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Feb 10 22:05:04 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108047741.8045.81.camel@presto.wooz.org> References: <1108047741.8045.81.camel@presto.wooz.org> Message-ID: At 10:02 AM -0500 2005-02-10, Barry Warsaw wrote: > As for #2, well, I think most people hate those password reminders > anyway, and we've decided that they are going away for MM3. I don't hate them. I find them quite useful. I do have filters set up to filter them all off into their own mail folder, but I appreciate getting them and I will definitely miss them when they're gone. > What do you all think? Is anybody willing to take a crack at a patch > for this? As I've demonstrated previously, I'm not really a programmer. I wish that this was an area where I could help. ;( -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Thu Feb 10 19:01:49 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Feb 10 22:10:21 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <8ecb2733f212dff7189919c470609e78@kabissa.org> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> Message-ID: At 11:17 AM -0500 2005-02-10, Tobias Eigen wrote: > And this, plus the CAN prefix to the patch name, reminds me: correct me > if I'm wrong, but my understanding is that Mailman as it exists does > not comply with the new (unfortunately named) CAN SPAM act. According > to this act, a recipient of an email from a given site has to be able > to opt out from receiving ANY MAIL from that site. Right now all mailman > lists are treated completely separately, and nobody (not even the > subscriber) can easily find out which lists subscribers are subscribed to. Actually, you can easily see which lists you're subscribed to. Go to the listinfo page for the mailing list in question, and log in using your e-mail address and password. There's a button that says "List my other subscriptions". Unfortunately, you can't unsubscribe from all of them with a single command, you will have to unsubscribe from each of them individually. But you can globally change all your passwords for all the lists you're subscribed to, change your e-mail address, and if you scroll down to the bottom of the list, you can change a number of other options, most of which can be applied globally. However, this is only a on a per-address basis. If you have multiple different addresses subscribed to different lists, you will have to handle them each individually. > What I envision having in my Mailman/Mambo system is a single user > database with one password per username for all services. Users can > then go to a simple preferences page on Mambo and do basic things > like change their email address or password, tick a box to opt in/out > of various mailings, and in particular opt to receive no mail at all. You can pretty much do all of that today. Go to the listinfo page and log in with your e-mail address and password. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From thien.vu at gmail.com Thu Feb 10 23:28:14 2005 From: thien.vu at gmail.com (Thien Vu) Date: Thu Feb 10 23:28:17 2005 Subject: [Mailman-Developers] mailman email harvester In-Reply-To: References: <4209EF1C.20200@bksys.at> Message-ID: <9f7fa000502101428176d7aae@mail.gmail.com> [whoops, meant to send to the whole list] def roster_privatize(mlist): mlist.private_roster = 1 m.Save() m.Unlock() Put that into your mailman/bin/roster_privatize.py and then run withlist -a -l -r roster_privatize Yeah I haven't tested that code but that's the rough idea. Take a look at setting mm_cfg.DEFAULT_PRIVATE_ROSTER also. Thien On Thu, 10 Feb 2005 19:08:51 +0100, Brad Knowles wrote: > At 11:40 AM -0500 2005-02-10, Tobias Eigen wrote: > > > Is there a way to change the setting to restrict access to the roster for > > all lists, globally? > > That should be possible to do using "withlist". However, I don't > know the specifics of how to do that. > > -- > Brad Knowles, > > "Those who would give up essential Liberty, to purchase a little > temporary Safety, deserve neither Liberty nor Safety." > > -- Benjamin Franklin (1706-1790), reply of the Pennsylvania > Assembly to the Governor, November 11, 1755 > > SAGE member since 1995. See for more info. > _______________________________________________ > 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/thien.vu%40gmail.com > From tobias at kabissa.org Fri Feb 11 00:01:57 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Fri Feb 11 00:44:05 2005 Subject: [Mailman-Developers] mailman email harvester In-Reply-To: <20050210183243.GC12675@eskimo.com> References: <4209EF1C.20200@bksys.at> <20050210183243.GC12675@eskimo.com> Message-ID: Hi Dan, >> Given the risk, now made worse by Bernhard's very helpfully >> distributing this script for spammers, this is a really urgent issue. > > Not that hard to write such a script. I expect the spammers already > have several alternatives to choose from. So, it's quite likely > no harm has been done, and some good, arising from Bernhard's > raising the issue in public. Ok - granted. Sorry for sounding a little passive aggressive there. :-) > I'd go further and mention that while Berhhard's script harvests > membership rosters, it isn't that much more difficult to write a > script that gets around the obfuscation of email addresses in the > list archives. Mhonarc on my system actually removes the email address completely in the archives. The mbox archives are still intact though, so if someone knows how mailman works they could probably hack their way into there. MBOX files generally are a motherlode for spammers. My idea eventually is to replace mhonarc archives with a forum for discussion groups and newsletter archives, all integrated with my Mambo CMS. It's great to have the mbox files ready to be imported. This way you don't end up with disabled archives and you don't open up subscribers to having their email addresses harvested. > (Hey, anybody got a lead on a Seattle-area opportunity for a rabid > Python > developer? Who also does C, SQL, HTML, CSS and various assemblers?) Try introducing yourself to the nonprofit open source initiative folks. They're very into drupal etc, and of course also use mailman. http://www.nosi-net > There are a pretty fair number of good reasons for keeping list > archives > open. My opinion is a person posting to a list assumes the risk of > having his or her email address harvested, and that one unwilling to > assume > this risk should refrain from posting. However I understand if others > do not subscribe to that belief, and that there may be circumstances > where > there are reasonable grounds for wanting to manage a list by some other > policy. I think the answer to this is that not everybody is as familiar with these tools as we are, and we can't assume that the people we are trying to serve are willing or able to put up with confusion about this sort of thing. Hence, again, my plans to develop a yahoo-like service that is more transparent and easy to navigate and use. These types of questions simply shouldn't even come up. > My suggestion is that an option be considered to redact all email > addresses whatsoever from a list archive. Including anything mentioned > in-line in the text of the post that even vaguely looks like an email > address. Yes. This is what mhonarc does. > No doubt somebody on this list manages a list where users are quite > sensitive to public exposure, who might care to advocate for such an > option, > and even code it, should the idea meet with sufficient approval. Yes. We do. We also often find ourselves in the awkward position of having to manually remove postings from our archives because people are being defamed etc or have posted something that they didn't realize was going to be archived and are now regretting it. Many people using our lists are African activists and this can (to be dramatic) be a matter of life and death. Cheers, Tobias -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From tkikuchi at is.kochi-u.ac.jp Fri Feb 11 01:29:58 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri Feb 11 01:30:13 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108056770.27472.97.camel@finch.boston.redhat.com> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> Message-ID: <420BFC86.3080100@is.kochi-u.ac.jp> Hi, John Dennis wrote: > My suggestion would be: > > 1) As soon as possible post MM 2.1.6 with the security patch. +1 > > 2) Quickly follow up with MM 2.1.7 with the member passwords hashed. I would suggest 'mailman 2.2' and introduce password-less membership. Most of the user operations should be done by confirmation string sent by email message. Users can optionally have their passwords which should be stored in hashed format. Other 2.2 features I imagine are: - Languages are selectable at configure option. - Internal strings are unified to unicode to reduce type checking. - Utf-8 web pages for > At > the same time I think we should implement the stronger password > generation suggested in this open advisory against mailman. > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-1143 > This has been integrated in 2.1.6 CVS. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Fri Feb 11 01:34:19 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri Feb 11 01:34:29 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420BFC86.3080100@is.kochi-u.ac.jp> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> <420BFC86.3080100@is.kochi-u.ac.jp> Message-ID: <420BFD8B.2020008@is.kochi-u.ac.jp> > Other 2.2 features I imagine are: > - Languages are selectable at configure option. > - Internal strings are unified to unicode to reduce type checking. > - Utf-8 web pages for - Uft-8 web pages for all languages. Sorry for the incomplete post. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From brad at stop.mail-abuse.org Fri Feb 11 01:46:56 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri Feb 11 01:49:02 2005 Subject: [Mailman-Developers] Website www.python.org down... Message-ID: Folks, Just to let you know, the machine that normally provides service for www.python.org is currently down. The facility that provides the co-location is having power problems, and they are working on solving it. We have temporarily moved the www.python.org hostname to a different machine, which does not include any of the original content from www.python.org, and ftp.python.org and other non-mail or mailing list related services are still down. However, the temporary home for www.python.org does have a list of known mirrors, so you should hopefully be able to access the content you need from one of them. I'll post more information as I get it. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From adrian at tasdevil.com Fri Feb 11 02:34:23 2005 From: adrian at tasdevil.com (Adrian Bye) Date: Fri Feb 11 02:34:26 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420BFC86.3080100@is.kochi-u.ac.jp> Message-ID: <20050211013425.1F50B1E4004@bag.python.org> > I would suggest 'mailman 2.2' and introduce password-less membership. > Most of the user operations should be done by confirmation > string sent by email message. Users can optionally have their > passwords which should be stored in hashed format. This would be great. As an additional note, I have had my developer make a pretty good solution for adding headers and footers in HTML. We did a _lot_ of research as to how yahoogroups implements this, and have copied their implementation. Its not 100% perfect - for example if the background color of a message is black, the headers and footers won't show properly. But it covers probably 98% of mail and successfully adds headers and footers to all kinds of multi-part mime email. It also handles badly formed email, again using the same implementation as yahoo groups. I have the patches for mailman 2.5 here, and will send them out next week so you can check them out. This will make password-less membership quite easy to implement, since it will support both html and plain text. Adrian From tobias at kabissa.org Fri Feb 11 04:07:51 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Fri Feb 11 04:06:48 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050211013425.1F50B1E4004@bag.python.org> References: <20050211013425.1F50B1E4004@bag.python.org> Message-ID: >> I would suggest 'mailman 2.2' and introduce password-less membership. >> Most of the user operations should be done by confirmation >> string sent by email message. Users can optionally have their >> passwords which should be stored in hashed format. > > This would be great. I'm very into this idea of password-less membership too. Cheers, Tobias -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From bob at nleaudio.com Fri Feb 11 05:44:34 2005 From: bob at nleaudio.com (Bob Puff) Date: Fri Feb 11 05:44:39 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420BFC86.3080100@is.kochi-u.ac.jp> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> <420BFC86.3080100@is.kochi-u.ac.jp> Message-ID: <20050211044328.M81861@nleaudio.com> I'm all for the password-less stuff, but then how do you authenticate for members-only archives? I've got big lists that must be members-only for the archives. Bob ---------- Original Message ----------- From: Tokio Kikuchi To: John Dennis Cc: mailman-developers@python.org, Barry Warsaw Sent: Fri, 11 Feb 2005 09:29:58 +0900 Subject: Re: [Mailman-Developers] Hashing member passwords in config.pck > Hi, > > John Dennis wrote: > > > My suggestion would be: > > > > 1) As soon as possible post MM 2.1.6 with the security patch. > > +1 > > > > > 2) Quickly follow up with MM 2.1.7 with the member passwords hashed. > > I would suggest 'mailman 2.2' and introduce password-less membership. > Most of the user operations should be done by confirmation string > sent by email message. Users can optionally have their passwords > which should be stored in hashed format. > > Other 2.2 features I imagine are: > - Languages are selectable at configure option. > - Internal strings are unified to unicode to reduce type checking. > - Utf-8 web pages for > > > At > > the same time I think we should implement the stronger password > > generation suggested in this open advisory against mailman. > > > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-1143 > > > This has been integrated in 2.1.6 CVS. > > -- > Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp > http://weather.is.kochi-u.ac.jp/ > > _______________________________________________ > 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/bob%40nleaudio.com ------- End of Original Message ------- From tkikuchi at is.kochi-u.ac.jp Fri Feb 11 05:55:26 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri Feb 11 05:55:43 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050211044328.M81861@nleaudio.com> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> <420BFC86.3080100@is.kochi-u.ac.jp> <20050211044328.M81861@nleaudio.com> Message-ID: <420C3ABE.7090506@is.kochi-u.ac.jp> Bob Puff wrote: > I'm all for the password-less stuff, but then how do you authenticate for > members-only archives? I've got big lists that must be members-only for the > archives. > >>Most of the user operations should be done by confirmation string >>sent by email message. Operations include authentication. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From brad at python.org Fri Feb 11 10:03:40 2005 From: brad at python.org (Brad Knowles) Date: Fri Feb 11 10:03:52 2005 Subject: [Mailman-Developers] www.python.org back online... Message-ID: Folks, The power problem has been resolved. It turns out that the machine itself was not down, but the switch it was connected to was. So, as far as it was concerned, it was the rest of the world that went away. ;) Anyway, www.python.org now points back to the original server, and everything should be as it was. Sorry for any confusion that may have been caused. -- Brad Knowles Python.org Postmaster Team From iane at sussex.ac.uk Fri Feb 11 11:01:37 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri Feb 11 11:01:55 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420C3ABE.7090506@is.kochi-u.ac.jp> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> <420BFC86.3080100@is.kochi-u.ac.jp> <20050211044328.M81861@nleaudio.com> <420C3ABE.7090506@is.kochi-u.ac.jp> Message-ID: <6D5DEE8CB0870E533F4E3B70@lewes.staff.uscs.susx.ac.uk> --On February 11, 2005 13:55:26 +0900 Tokio Kikuchi wrote: > Bob Puff wrote: > >> I'm all for the password-less stuff, but then how do you authenticate for >> members-only archives? I've got big lists that must be members-only for >> the archives. >> > >>> Most of the user operations should be done by confirmation string >>> sent by email message. > > Operations include authentication. So, to access the private archive I have to wait for an email message? Hmm, there was some plan for LDAP integration for version 3.0, no? What I'm hoping for is that people who subscribe to my lists with a sussex.ac.uk email address will be able to authenticate from our LDAP server. This avoids mailman having to store their passwords. With support for a variety of external authentication mechanisms, Mailman can become a much more useful tool for Universities and large corporations. -- Ian Eiloart Servers Team Sussex University ITS From iane at sussex.ac.uk Fri Feb 11 11:05:45 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri Feb 11 11:05:47 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050210184424.D56AC1E417C@bag.python.org> References: <20050210184424.D56AC1E417C@bag.python.org> Message-ID: <0194F7485A16B2B539EF5E7E@lewes.staff.uscs.susx.ac.uk> --On February 10, 2005 14:44:22 -0400 Adrian Bye wrote: > Getting rid of passwords would open up mailman to usage to a much wider > range of users, which should mean more development resources and interest. No, no, no, no! The web application can be much improved in various ways, but having to authenticate via mailback verification would be a usability nightmare. It would take longer to do anything, and require the user to continually switch windows. -- Ian Eiloart Servers Team Sussex University ITS From iane at sussex.ac.uk Fri Feb 11 12:17:23 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri Feb 11 12:17:25 2005 Subject: [Mailman-Developers] Re: Please confirm your message In-Reply-To: <1108116120.3176.TMDA@web3.nlenet.net> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> <420BFC86.3080100@is.kochi-u.ac.jp> <20050211044328.M81861@nleaudio.com> <420C3ABE.7090506@is.kochi-u.ac.jp> <6D5DEE8CB0870E533F4E3B70@lewes.staff.uscs.susx.ac.uk> <1108116120.3176.TMDA@web3.nlenet.net> Message-ID: --On February 11, 2005 05:02:00 -0500 Bob Puff wrote: > Hello iane@sussex.ac.uk, > > ** IMPORTANT! Please Read! ** > In an effort to reduce spam, a message filtering service called TMDA has > been implemented on this mailbox. Bob, Can you please remove your TMDA protected email address from this list. Imagine if everyone on a thousand member list used TMDA. Every time you posted a message, you'd get a thousand requests to click on a link. For the list to work properly, a million clicks would be required, followed by another two thousand for every new member. > The purpose of this message is to verify that you, a live human, did > indeed sent a message (shown below) to this mailbox. > > It is IMPORTANT that you do one of the following two things: > > > 1. Simply reply to THIS message (you don't need to type anything, just > send a blank message), or > > 2. Click on this link: > http://nleaudio.com/cgi-bin/tmda.cgi?501.1108116120.3176.21a674 > > > After doing so, your messages will go through automatically, and you will > not see this message again. If you do not reply to this email within > three weeks, your original message may be lost. > > Thank you for your patience. This one small step saves this user from a > ton of spam. > -- Ian Eiloart Servers Team Sussex University ITS From tkikuchi at is.kochi-u.ac.jp Fri Feb 11 14:53:34 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri Feb 11 14:53:43 2005 Subject: [Mailman-Developers] Mailman 2.1.6 beta 3 released Message-ID: <420CB8DE.2020900@is.kochi-u.ac.jp> Hi, I put together a tarball for Mailman 2.1.6 beta 3 and placed on my Japanese Mailman site at: http://mm.tkikuchi.net/mailman-2.1.6b3.tgz This is the third beta release of 2.1.6 which are roughly scheduled to be released by the end of February. Please grab it from above site and upgrade your mailman. Change from 2.1.6b2 are mainly to fix the directory traversal vulnerability CVE number CAN-2005-0202 http://www.list.org/security.html Here is excerpt from NEWS file: 2.1.6 (XX-XXX-200X) - Critical security patch for path traversal vulnerability in private archive script (CAN-2005-0202). - Date and Message-Id headers are added for digests. (1116952) - List owners can now cusomize the non-member rejection notice from admin//privacy/sender page. (1107169) - Most of the installation instructions have been moved to a latex document. See admin/www/mailman-install/index.html for details. - VERP_PROBES is disabled by default. - bin/withlist can be run without a list name, but only if -i is given. Also, withlist puts the directory it's found in at the end of sys.path, making it easier to run withlist scripts that live in $prefix/bin. - bin/newlist grew two new options: -u/--urlhost and -e/--emailhost which lets the user provide the web and email hostnames for the new mailing list. This is a better way to specify the domain for the list, rather than the old 'mylist@hostname' syntax (which is still supported for backward compatibility, but deprecated). - Added the ability for Mailman generated passwords (both member and list admin) to be more cryptographically secure. See new configuration variables USER_FRIENDLY_PASSWORDS, MEMBER_PASSWORD_LENGTH, and ADMIN_PASSWORD_LENGTH. Also added a new bin/withlist script called reset_pw.py which can be used to reset all member passwords. Passwords generated by Mailman are now 8 characters by default for members, and 10 characters for list administrators. - Allow editing of the welcome message from the admin page (1085501). - A potential cross-site scripting hole in the driver script has been closed. Thanks to Florian Weimer for its discovery. Also, turn STEALTH_MODE on by default. - Chinese languages moved from 'big5' and 'gb' to 'zh_TW' and 'zh_CN' respectively for compliance to the IANA spec. Note that neither language is supported yet. - Python 2.4 compatibility issue: time.strftime() became strict about the 'day of year' range. (1078482) - New feature: automatic discards of held messages. List owners can now set how many days to hold the messages in the moderator request queue. cron/checkdb will automatically discard old messages. (790494) - Improved mail address sanity check. (1030228) - SpamDetect.py now checks attachment header. (1026977) - New feature: subject_prefix can be configured to include a sequence number which is taken from the post_id variable. Also, the prefix is always put at the start of the subject, i.e. "[list-name] Re: original subject", if mm_cfg.OLD_STYLE_PREFIXING is set No. The default style is "Re: [list-name]" if numbering is not set, for backward compatibility. If the list owner is using numbering feature by "%d" directive, the new style, "[list-name 123] Re:", is always used. - List owners can now use Scrubber to get the attachments scrubbed (held in the web archive), if the site admin permits it in mm_cfg.py. New variables introduced are SCRUBBER_DONT_USE_ATTACHMENT_FILENAME and SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION in Defaults.py for scrubber behavior. (904850) - Filter attachments by filename extensions. (1027882) - Bugs and patches: 955381 (older Python compatibility), 1020102/1013079/ 1020013 (fix spam filter removed), 665569 (newer Postfix bounce detection), 970383 (moderator -1 admin requests pending), 873035 (subject handling in -request mail), 799166/946554 (makefile compatibility), 872068 (add header/footer via unicode), 1032434 (KNOWN_SPAMMERS check for multi-header), 1025372 (empty Cc:), 789015 (fix pipermail URL), 948152 (Out of date link on Docs), 1099138 (Scrubber.py breaks on None part), 1099840/1099840 (deprecated % insertion), 880073/933762 (List-ID RFC compliance), 1090439 (passwd reminder shunted), 1112349 (case insensitivity in acceptable_aliases) -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From brad at stop.mail-abuse.org Fri Feb 11 15:21:29 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri Feb 11 15:34:21 2005 Subject: [Mailman-Developers] Mailman 2.1.6 beta 3 released In-Reply-To: <420CB8DE.2020900@is.kochi-u.ac.jp> References: <420CB8DE.2020900@is.kochi-u.ac.jp> Message-ID: At 10:53 PM +0900 2005-02-11, Tokio Kikuchi wrote: > - Most of the installation instructions have been moved to a latex > document. See admin/www/mailman-install/index.html for details. Please note, this is just the source version of the documentation. A pre-generated copy of the documentation is also made available in text format, and there may also be other formats in which the documentation is made available in a pre-generated form. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From r_correia at telkomsa.net Fri Feb 11 15:50:39 2005 From: r_correia at telkomsa.net (Rui Correia) Date: Fri Feb 11 17:03:51 2005 Subject: [Mailman-Developers] Compatibility with Opera In-Reply-To: <000601c50fa5$5769d020$0100a8c0@Laptop> Message-ID: <001901c51049$11686b00$0100a8c0@Laptop> Hi When I open http://mailman.greennet.org.uk/mailman/listinfo/plenary using Opera, the last block just above the 'subscribe' button gets spread out in one long string. The result is that one can't see the 'subscribe' button. Is this a Opera-only problem, or would this be happening with other browsers too? Rui ________________________________________________ ? ? Rui Correia Advocacy, Media and Language Consultant 36 Finch St, Ontdekkers Park, Roodepoort, Johannesburg, South Africa Tel/ Fax (+27-11) 766-4336 Cell (+27) (0) 83-368-1214 From correia.rui at gmail.com Fri Feb 11 17:05:18 2005 From: correia.rui at gmail.com (correia.rui@gmail.com) Date: Fri Feb 11 18:37:55 2005 Subject: [Mailman-Developers] Compatibility with Opera In-Reply-To: <000601c50fa5$5769d020$0100a8c0@Laptop> Message-ID: <001b01c51053$7b9290a0$0100a8c0@Laptop> Hi When I open http://mailman.greennet.org.uk/mailman/listinfo/plenary using Opera, the last block just above the 'subscribe' button gets spread out in one long string. The result is that one can't see the 'subscribe' button. Is this a Opera-only problem, or would this be happening with other browsers too? Rui ________________________________________________ ? ? Rui Correia Advocacy, Media and Language Consultant 36 Finch St, Ontdekkers Park, Roodepoort, Johannesburg, South Africa Tel/ Fax (+27-11) 766-4336 Cell (+27) (0) 83-368-1214 From ml at ancalagon.inka.de Fri Feb 11 19:05:48 2005 From: ml at ancalagon.inka.de (Thomas Hochstein) Date: Fri Feb 11 19:32:05 2005 Subject: [Mailman-Developers] mailman email harvester References: <4209EF1C.20200@bksys.at> Message-ID: Tobias Eigen schrieb: > Given the risk, now made worse by Bernhard's very helpfully > distributing this script for spammers, this is a really urgent issue. Since it is known for many *years* that spammers are harvesting addresses from ML-archives, and since anybody can see that replacing "at" with "@" is ... not a very hard task, I fail to see any urgency here (or any problem in the very simple script Berhard distributed). -thh From jwblist at olympus.net Fri Feb 11 20:10:39 2005 From: jwblist at olympus.net (John W. Baxter) Date: Fri Feb 11 20:10:54 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <8d75968bac541f84b859950bd97bddbf@plaidworks.com> Message-ID: I used to be careful about saving my passwords for all the lists [Mailman*] I am subscribed to. I no longer bother...I request the mail out of the password if I need it (very rare). If the situation becomes a choice of 1. mail out the password becomes generate a new time-limited password and mail that Or 2. do away with passwords and have everything validated via a mailed-out URL I think I as a user would prefer 2. As a list owner, ANY change causes queries and unhappiness among the ranks of the subscribers. And as site administrator, I would have to coordinate removal of passwords or even the "new time-limited password" idea with our main list owner, who has her own scripting to hide the passwords from the subscribers (who don't do things via the Mailman web pages). I concur with the idea of getting the simple patch out for the CAN-2005-0202 problem quickly in 2.1.6 and getting the password removal/changes into a 2.1.7 [or 2.2 as has also been suggested] (pretty soon and with very little if anything else). We shouldn't assume MySQL as the SQL server; we shouldn't assume LDAP as the password database. Here, we're phasing out MySQL in favor of PostgreSQL for licensing reasons, and trying to phase out LDAP in favor of SQL for stability reasons. But we can't make those decisions for others, of course. Bigger stuff I think has to wait for Mailman 3...this would include password databases, subscriber databases site wide, etc. --John (who for medical reasons can't be of any help, but must continue cheering from the sidelines. Sorry!) On 2/10/2005 10:55, "Chuq Von Rospach" wrote: > this might not be a bad idea, but -- would require all operations to be > validated via a URL emailed to the affected address. But I could live > with that. > > > On Feb 10, 2005, at 10:44 AM, Adrian Bye wrote: > >> Getting rid of passwords would open up mailman to usage to a much >> wider range of >> users, which should mean more development resources and interest. From brad at stop.mail-abuse.org Fri Feb 11 21:13:01 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri Feb 11 21:19:47 2005 Subject: [Mailman-Developers] Compatibility with Opera In-Reply-To: <001b01c51053$7b9290a0$0100a8c0@Laptop> References: <001b01c51053$7b9290a0$0100a8c0@Laptop> Message-ID: At 6:05 PM +0200 2005-02-11, wrote: > When I open http://mailman.greennet.org.uk/mailman/listinfo/plenary using > Opera, the last block just above the 'subscribe' button gets spread out in > one long string. > > The result is that one can't see the 'subscribe' button. > > Is this a Opera-only problem, or would this be happening with other browsers > too? Using MacOS X 10.3.6, I see the same thing in Safari 1.2.4 (based on KHTML), Opera 7.51, and OmniWeb 5.0. Camino 0.8.2 (a Gecko-based browser from the Mozilla family, with a native Aqua user interface) and iCab 2.9.8 both seem to display the page with line-wrapping, which is presumably what you had intended. I'm not sure what to tell you about this particular problem. I will tell you that it is common practice for people who are doing web page design to use a wide variety of browsers on a large number of platforms, to check and make sure that what they're doing comes out looking at least reasonable, if not exactly what they were trying for. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From jwblist at olympus.net Fri Feb 11 22:05:50 2005 From: jwblist at olympus.net (John W. Baxter) Date: Fri Feb 11 22:06:01 2005 Subject: [Mailman-Developers] Compatibility with Opera In-Reply-To: Message-ID: On 2/11/2005 12:13, "Brad Knowles" wrote: > At 6:05 PM +0200 2005-02-11, wrote: > >> When I open http://mailman.greennet.org.uk/mailman/listinfo/plenary using >> Opera, the last block just above the 'subscribe' button gets spread out in >> one long string. >> >> The result is that one can't see the 'subscribe' button. >> >> Is this a Opera-only problem, or would this be happening with other browsers >> too? > > Using MacOS X 10.3.6, I see the same thing in Safari 1.2.4 (based > on KHTML), Opera 7.51, and OmniWeb 5.0. Camino 0.8.2 (a Gecko-based > browser from the Mozilla family, with a native Aqua user interface) > and iCab 2.9.8 both seem to display the page with line-wrapping, > which is presumably what you had intended. > > I'm not sure what to tell you about this particular problem. I suspect the horizontal long rows of checkboxes are the root of the problem. This web page falls into my "if it's hard to use, forget about it" category, which would have kept me off the list even if I otherwise cared. --John From brad at stop.mail-abuse.org Fri Feb 11 22:37:50 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri Feb 11 22:38:12 2005 Subject: [Mailman-Developers] Compatibility with Opera In-Reply-To: References: Message-ID: At 1:05 PM -0800 2005-02-11, John W. Baxter wrote: > This web page falls into my "if it's hard to use, forget about it" category, > which would have kept me off the list even if I otherwise cared. I must confess, when I first saw that page, my reaction was "Holy Bloody Cow!" That page would definitely send me screaming into the night, and I would never come back. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From msapiro at value.net Sat Feb 12 00:03:43 2005 From: msapiro at value.net (Mark Sapiro) Date: Sat Feb 12 00:03:55 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: Message-ID: John W. Baxter wrote: > >If the situation becomes a choice of >1. mail out the password becomes generate a new time-limited password and >mail that >Or >2. do away with passwords and have everything validated via a mailed-out >URL > >I think I as a user would prefer 2. It is already hard enough to visit a private archive. E.g. if I have a link to a specific post and I follow it, by the time I get done logging in, my original link is forgotten and I go to the archive index instead. If I now have to wait for an e-mail and follow some confirmation link, I'm going to give up before I ever get there. I think there has to be a way to get directly to a private archive without going through some e-mailed confirmation. I might even be trying to access the archive from some machine that doesn't have access to the confirmation e-mail (perhaps a computer in a public library). I agree that for most other things, e-mail confirmation is fine. I.e. if I go to my options page and change a few things, I don't mind having to answer an e-mail confirmation to make the changes effective, although I'm sure some would have privacy concerns about others being able to visit their options page without authorization. Thus, on the whole I prefer passwords. Having to reset a forgotten password rather than being able to retrieve it would not be a problem for me. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Sat Feb 12 00:20:54 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 00:21:02 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420B8165.5030108@ncsu.edu> References: <1108047741.8045.81.camel@presto.wooz.org> <420B8165.5030108@ncsu.edu> Message-ID: <1108164054.9913.21.camel@geddy.wooz.org> It seems to me that the pulse of this list is to leave the situation as is, and not make the password hashing change for 2.1.6. This should allow us to release this version sooner, so I'm fine with that. The reason I thought we'd have a good opportunity now is that one of the remediation steps for CAN-2005-0202 was to reset your passwords. I think it will be too much to ask admins to reset their passwords for 2.1.6 and then do it again for 2.1.7, so I'm against making this change until 2.2 or 3.0. Thanks everyone. I may follow up on specific messages in this thread. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050211/61902536/attachment.pgp From barry at python.org Sat Feb 12 00:27:31 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 00:27:36 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108056770.27472.97.camel@finch.boston.redhat.com> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> Message-ID: <1108164451.9913.25.camel@geddy.wooz.org> On Thu, 2005-02-10 at 12:32, John Dennis wrote: > At > the same time I think we should implement the stronger password > generation suggested in this open advisory against mailman. > > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-1143 > > I believe this will need a little support in configure.in to detect and > be able to utilize the presence of /dev/urandom with an appropriate fall > back in its absence. This is already in 2.1.6 CVS, and we do a run-time check, first for Python 2.4's os.urandom() and then for /dev/urandom. We fallback to the old scheme if neither of those can be found. > Then in the MM 3.0 time frame the entire mailman security framework > should be revisited, there are many security issues that should be > addressed. At a minimum the suggestion of supporting alternate > authentication mechanisms (e.g. pam, ldap, kerberos, etc.) should be > implemented. In my mind, this is too radical for a 2.1.x release. 3.0 is > the right time debut a more configurable and robust security framework. I agree completely, although we might be able to fit this into a 2.2 release if there is one. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050211/623189de/attachment.pgp From barry at python.org Sat Feb 12 00:29:57 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 00:30:02 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420BFC86.3080100@is.kochi-u.ac.jp> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> <420BFC86.3080100@is.kochi-u.ac.jp> Message-ID: <1108164597.9912.28.camel@geddy.wooz.org> On Thu, 2005-02-10 at 19:29, Tokio Kikuchi wrote: > Other 2.2 features I imagine are: > - Languages are selectable at configure option. > - Internal strings are unified to unicode to reduce type checking. Yes, yes, yes. > - Utf-8 web pages for [... all languages] Yes. The key thing here is that we should convert to Unicode on the way in and way out, and only deal with Unicode internally. It's the only way to remain sane. sanity-long-lost-ly y'rs, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050211/029b3a80/attachment.pgp From barry at python.org Sat Feb 12 00:31:24 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 00:31:27 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050211013425.1F50B1E4004@bag.python.org> References: <20050211013425.1F50B1E4004@bag.python.org> Message-ID: <1108164683.9917.30.camel@geddy.wooz.org> On Thu, 2005-02-10 at 20:34, Adrian Bye wrote: > I have the patches for mailman 2.5 here, and will send them out next week so you > can check them out. Please post them to SF instead of to this mailing list. But thanks! I'm interested in seeing them. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050211/00ea17a5/attachment.pgp From barry at python.org Sat Feb 12 00:38:43 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 00:38:47 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <6D5DEE8CB0870E533F4E3B70@lewes.staff.uscs.susx.ac.uk> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> <420BFC86.3080100@is.kochi-u.ac.jp> <20050211044328.M81861@nleaudio.com> <420C3ABE.7090506@is.kochi-u.ac.jp> <6D5DEE8CB0870E533F4E3B70@lewes.staff.uscs.susx.ac.uk> Message-ID: <1108165123.9913.38.camel@geddy.wooz.org> On Fri, 2005-02-11 at 05:01, Ian Eiloart wrote: > >> I'm all for the password-less stuff, but then how do you authenticate for > >> members-only archives? I've got big lists that must be members-only for > >> the archives. > >> > > > >>> Most of the user operations should be done by confirmation string > >>> sent by email message. > > > > Operations include authentication. > > So, to access the private archive I have to wait for an email message? One way to make this not suck as much is to drop a cookie that lives longer than the session, after you click-authenticate the first time. However, this is fairly dangerous if you were to read private archives from a public machine, which is why cookies all currently expire at the end of the browser session. The same situation occurs for accessing the options page, but that is a much less common operation. Maybe users are willing to wait for an email round-trip in order to change their options. I tend to think not though -- they may hitting the web interface from a machine that doesn't have access to their mail, and then they're screwed. Integrating with external user storages for authentication should help out a lot here, but I'm just not seeing how we can totally eliminate passwords. I'm willing to be convinced though. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050211/48ed65f1/attachment.pgp From barry at python.org Sat Feb 12 00:40:33 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 00:40:36 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <420BA81F.4060504@nleaudio.com> References: <1108047741.8045.81.camel@presto.wooz.org> <420BA81F.4060504@nleaudio.com> Message-ID: <1108165233.9910.40.camel@geddy.wooz.org> On Thu, 2005-02-10 at 13:29, Bob Puff@NLE wrote: > If we convert to one-way passwords, could the upgrade script convert the current passwords? It > would be a -big- deal if everyone had to reset their passwords. Yes, I think we could do that. I would not want to support a mix or dual-operation mode though. Either we hash or we don't. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050211/6440596d/attachment.pgp From barry at python.org Sat Feb 12 00:46:12 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 00:46:15 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050210184424.D56AC1E417C@bag.python.org> References: <20050210184424.D56AC1E417C@bag.python.org> Message-ID: <1108165572.9910.46.camel@geddy.wooz.org> On Thu, 2005-02-10 at 13:44, Adrian Bye wrote: > Why even bother with passwords? They're good to include in the unsubscribe URL, > so that if someone maliciously gets your list, they can't unsubscribe everyone > manually. But mainstream commercial autoresponders have no passwords, and they > work great. Since Mailman 2.1, passwords have not been required to unsubscribe, even though it is a common misconception that they are. I'm not sure why people forget that! Actually, I think that if we just shut off the monthly reminder, 99% of Mailman users would never even know they had a password (who reads those welcome messages anyway?). They wouldn't care either because most people don't change their options and private archives aren't as common as public archives. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050211/9a4887c3/attachment.pgp From barry at python.org Sat Feb 12 00:51:34 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 00:51:39 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: References: Message-ID: <1108165893.9912.52.camel@geddy.wooz.org> On Fri, 2005-02-11 at 18:03, Mark Sapiro wrote: > It is already hard enough to visit a private archive. E.g. if I have a > link to a specific post and I follow it, by the time I get done > logging in, my original link is forgotten and I go to the archive > index instead. Yeah, that's a bug. :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050211/8944d712/attachment-0001.pgp From adrian at tasdevil.com Sat Feb 12 01:29:14 2005 From: adrian at tasdevil.com (Adrian Bye) Date: Sat Feb 12 01:29:18 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108165572.9910.46.camel@geddy.wooz.org> Message-ID: <20050212002916.C01E91E4002@bag.python.org> > Since Mailman 2.1, passwords have not been required to > unsubscribe, even though it is a common misconception that > they are. I'm not sure why people forget that! > > Actually, I think that if we just shut off the monthly > reminder, 99% of Mailman users would never even know they had > a password (who reads those welcome messages anyway?). They > wouldn't care either because most people don't change their > options and private archives aren't as common as public archives. That sounds to me like the best of both worlds. Set it up so that no password is noticed for subscribing or unsubscribing. The password could be made completely transparent. Advanced users can access their password if they choose to do so for list archives, etc. Adrian From barry at python.org Sat Feb 12 02:16:20 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 02:16:27 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050212002916.C01E91E4002@bag.python.org> References: <20050212002916.C01E91E4002@bag.python.org> Message-ID: <1108170980.9912.63.camel@geddy.wooz.org> On Fri, 2005-02-11 at 19:29, Adrian Bye wrote: > That sounds to me like the best of both worlds. Set it up so that no password > is noticed for subscribing or unsubscribing. The password could be made > completely transparent. Advanced users can access their password if they choose > to do so for list archives, etc. My point was that if you disable cron/mailpasswds, you get exactly as you describe. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050211/0ed2a41e/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Sat Feb 12 02:30:52 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat Feb 12 02:31:07 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: References: Message-ID: <420D5C4C.1060906@is.kochi-u.ac.jp> Hi John, Your message was just the same as I had in mind. (Sorry that I am not good at wirting in english.) John W. Baxter wrote: > I used to be careful about saving my passwords for all the lists [Mailman*] > I am subscribed to. I no longer bother...I request the mail out of the > password if I need it (very rare). > > If the situation becomes a choice of > 1. mail out the password becomes generate a new time-limited password and > mail that > Or > 2. do away with passwords and have everything validated via a mailed-out > URL > > I think I as a user would prefer 2. I have been looking through the code and feel like doing away with passwords totally may be a bad idea because people may want to keep his password when changing their email addresses. 1. If user authentication is requied and not qualified by cookie, a login web page is sent. User can either enter his password or request a URL to be emailed out. 2. User can set his 'permanent' password in his option page. 3. User can set his cookie life time for later convenience. (May be when requesting the URL in 1.) 4. Password is reset every time a user request the URL or his password sent. It will take weeks for me to implement these in current code so... > I concur with the idea of getting the simple patch out for the CAN-2005-0202 > problem quickly in 2.1.6 and getting the password removal/changes into a > 2.1.7 [or 2.2 as has also been suggested] (pretty soon and with very little > if anything else). > > --John (who for medical reasons can't be of any help, but must continue > cheering from the sidelines. Sorry!) Take care. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From bernhard at bksys.at Sat Feb 12 02:48:56 2005 From: bernhard at bksys.at (Bernhard Kuemel) Date: Sat Feb 12 02:48:59 2005 Subject: [Mailman-Developers] mailman email harvester In-Reply-To: References: <4209EF1C.20200@bksys.at> Message-ID: <420D6088.8080400@bksys.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Hochstein wrote: |> Given the risk, now made worse by Bernhard's very helpfully |> distributing this script for spammers, this is a really urgent |> issue. | | Since it is known for many *years* that spammers are harvesting | addresses from ML-archives, and since anybody can see that | replacing "at" with "@" is ... not a very hard task, I fail to | see any urgency here (or any problem in the very simple script | Berhard distributed). There may be no urgency but something should be done. Obviously there is a problem (as can also be seen by the emotions). Since the only solution we found for now is not to publish the email addresses, we should do that. I pointed this out over a year ago and the number of vulnerable lists only grew. Probably because being able to see who else is on the list is a nice feature which we don't want to give up. We repress the problem: We think, spammers don't exploit it because they find enough addresses elsewhere. But spammers are smart: They play a lot of tricks to pass spam filters, they defeat graphical turing tests to semiautomatically sign up email accounts which the use for spamming, they make worms which act as mail relays. They probably already harvest mailing list subscriber addresses and if they don't do so by now, they sure will, sooner or later. But they would be fools to tell us about it. We would lock our email addresses away from them. I am writing the exploit code not for the spammers. They may already have one. I'm writing it to wake us up and treat this problem properly. Brad Knowles wrote: |> However, still many lists either have the member list openly |> published, or available to the list members. | | True enough. However, even if we changed the default in Mailman | to be accessible only to the list administrator, it would take a | very, very long time before 50% of all Mailman installations were | secured in this manner. I hope my exploit code will speed this up. I plan to release the improved version, which harvests addresses restricted to subscribers of about 100.000 mailing lists in several (3-6) months. | That said, changing the default is probably the right thing to | do. Please include a note of the upcoming exploit. The current exploit harvests about 600 lists where the addresses are published unrestricted. | Moreover, it would be trivially easy for spammers to subscribe to | the list and silently collect all address information that comes | across. | | There's enough schemes out there for finding addresses that no | one simple scheme is going to work, and the methods that we know | will work are going to take a long time to become the default | standard. If hashcash (http://www.hashcash.org/) gets integrated in our mail systems we no longer need to hide or obfuscate our email addresses. Bernhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFCDWCH9zL78+QhnUgRAhSfAJ9WpPLARJ4bTG6ZPGH7anxc4FA5YwCdGn0C nwSeZoHoitZKRA+6rE1hlFU= =lM5z -----END PGP SIGNATURE----- From bob at nleaudio.com Sat Feb 12 08:07:29 2005 From: bob at nleaudio.com (Bob Puff) Date: Sat Feb 12 08:07:34 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck References: <8d75968bac541f84b859950bd97bddbf@plaidworks.com> Message-ID: <20050212070711.M454@nleaudio.com> I'm in agreement with Barry, that I don't think we should phase out passwords for 2.1.x. I know several of my users who sign up to the lists using their corporate mailbox, yet log in from home and view archives (they remember their password). I'd have people screaming bloody murder if the archives were required to have email confirmation for each read. I'm sorry, but I just don't see other viable solutions except for passwords for this function. Every other "members-only" area on the internet today is authenticated by passwords, and they can be saved in the browsers for easy access. I don't see a problem limiting the passwords to private archives though. Yes, email authentication is perfect for subscription changes. So let me ask this: if we drop passwords for everything but the private archives, do we really need to do anything differently than the format currently in place? Do they really need to be one-way encrypted? Being able to email a forgotten password has its benefits. For sites that don't use private archives, passwords would be a non-issue. Bob From ml at ancalagon.inka.de Sat Feb 12 11:33:54 2005 From: ml at ancalagon.inka.de (Thomas Hochstein) Date: Sat Feb 12 12:05:11 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck References: <8d75968bac541f84b859950bd97bddbf@plaidworks.com> <20050212070711.M454@nleaudio.com> Message-ID: "Bob Puff" schrieb: > I don't see a problem limiting the passwords to private archives though. Yes, > email authentication is perfect for subscription changes. I don't think so. I'd prefer to change options *immediately*, without having to wait until I get my mail (partly via UUCP). Changing options per mail (with a passwort in it) is fine. But the possibility to change options on the web is even better, and I do think that's a reason for Mailman's success [1]: you don't have to be able to get your mail or to send mail, you just can do it on the web, from everywhere, public computers, workplace, and the like. You can even "read" the list via the archives, if you're interested. I fail to see a reason why we should change that to slow, cumbersome a challenge-response system for *every* change you make. So, I'm fine with an "password-less" option for those who don't want to remember passwords or who think passwords are not safe enough (as the connection may not be encrypted), but please, do make it an *option*. -thh [1] For me, it was one of the reasons to switch from ecartis to mailman. From ml at ancalagon.inka.de Sat Feb 12 11:26:14 2005 From: ml at ancalagon.inka.de (Thomas Hochstein) Date: Sat Feb 12 12:05:13 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck References: Message-ID: Mark Sapiro schrieb: > I agree that for most other things, e-mail confirmation is fine. I.e. > if I go to my options page and change a few things, I don't mind > having to answer an e-mail confirmation to make the changes effective, I do. > Thus, on the whole I prefer passwords. Having to reset a forgotten > password rather than being able to retrieve it would not be a problem > for me. Yep. +1 From bernhard at bksys.at Sat Feb 12 13:11:41 2005 From: bernhard at bksys.at (Bernhard Kuemel) Date: Sat Feb 12 13:11:51 2005 Subject: [Mailman-Developers] mailman email harvester In-Reply-To: <200502120334.j1C3YRBj007792@turing-police.cc.vt.edu> References: <4209EF1C.20200@bksys.at> <420D6088.8080400@bksys.at> <200502120334.j1C3YRBj007792@turing-police.cc.vt.edu> Message-ID: <420DF27D.2010706@bksys.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valdis.Kletnieks@vt.edu wrote: | On Sat, 12 Feb 2005 02:48:56 +0100, Bernhard Kuemel said: | | |>If hashcash (http://www.hashcash.org/) gets integrated in our mail |>systems we no longer need to hide or obfuscate our email addresses. | | | On the other hand, widespread distribution of hashcash will probably mean | the end of many mailing lists, because you can't trust users to actually | whitelist everything they subscribe to. If a user choses to use hashcash he must understand it. If he doesn't and subscribes to a mailing list all the list mail will go to his spam folder. He will learn from that and whitelist list mail. | And remember that the whole *idea* | of hashcash is that you make it impractical for somebody to send 3,000 pieces | of mail. I'm sure netsys.com wouldn't want to keep full-disclosure if they had | to do hashcash for even 10% of their users. They would not hashcash every mail, but sign each incoming mail so spammers can't spam suscribers whose addresses then can be published again. | I'll overlook the issues caused when you *dont know* what to whitelist. | For instance - many mailing lists (including this one) have a "confirmation | of subscription" check. For bonus points - should you have whitelisted: | | a) full-disclosure@lists.netsys.com (the actual list name) | b) full-disclosure-request@lists.netsys.com (the rfc822 header on my confirm) | c) full-disclosure-admin@lists.netsys.com (the rfc821 MAIL FROM:) | d) mailman@ | e) majordomo@ | f) listserv@ Subscribing to mailing lists has always been a process of following instructions. If you subscribe via a web page, this web page will tell you which addresses to whitelist. If you subscribe via email firstly there will also be some source of instructions how to subscribe, and secondly you can whitelist replies that reference (private) emails you sent recently. | There's also all the stuff that things like amazon, ebay, your bank, | your insurance company, your utility companies, etc... all send out, | that users will forget to whitelist. They can send hashcashed requests for being whitelisted which will pop up a window similar to message receipt requests. | Hashcash really sucks if you're a mail server admin who has to crank 50,000 | hash cashes a day at 5 CPU seconds a pop because people forgot to whitelist | your server. I don't understand the situation. Human edited mail is usually created on a workstation that is capable of making hashcash while the mail is edited. Mass mail generated on a server falls into several categories: 1) spam: let them make hashcash 2) solicited recurring mail: send hashcashed whitelist request and follow up with unpaid mail. If unpaid mail gets rejected stop sending mail. Actually, there is little reason not to make the whitelisting part of the service subscription process. 3) Replies should be whitelisted automatically. 4) legitimate systems that initiate mail conversation must make hashcash. Can you think of any examples? | Hashcash isn't even a tiny speed bump if you're a spammer and have 50,000 | zombies - each one only takes a 5 second hiccup and continues spamming.... Configure your system to require more. 1 minute. Or 10. Or 20. The amount of hashcash can be put in an email address comment or if insufficient cash is sent, the receiving system can automatically request more. | But yeah, other than all those minor details, hashcash is a fine solution. ;) ecash may be even better. You don't have to accept the postage. Only take it from unwanted mail. Bernhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFCDfJ89zL78+QhnUgRAu+pAJ95pzHYaMatinzyQ3wtIIeQqGb/uwCgi+4o 4I44MDzL2TeHQ1KLQGW7kts= =HCYs -----END PGP SIGNATURE----- From barry at python.org Sat Feb 12 15:02:54 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 15:02:56 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050212070711.M454@nleaudio.com> References: <8d75968bac541f84b859950bd97bddbf@plaidworks.com> <20050212070711.M454@nleaudio.com> Message-ID: <1108216973.20405.33.camel@presto.wooz.org> On Sat, 2005-02-12 at 02:07, Bob Puff wrote: > So let me ask this: if we drop passwords for everything but the private > archives, do we really need to do anything differently than the format > currently in place? Do they really need to be one-way encrypted? Being able > to email a forgotten password has its benefits. It's still worthwhile (in the long run) to hash the passwords. Some people tend to re-use them, so stealing Mailman passwords can potentially lead to cascading attacks. Password resets are fine. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050212/9b77003e/attachment.pgp From barry at python.org Sat Feb 12 15:04:36 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 15:04:39 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: References: <8d75968bac541f84b859950bd97bddbf@plaidworks.com> <20050212070711.M454@nleaudio.com> Message-ID: <1108217076.20402.35.camel@presto.wooz.org> On Sat, 2005-02-12 at 05:33, Thomas Hochstein wrote: > I don't think so. I'd prefer to change options *immediately*, without > having to wait until I get my mail (partly via UUCP). I agree. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050212/ebd4caf7/attachment.pgp From adrian at tasdevil.com Sat Feb 12 18:08:55 2005 From: adrian at tasdevil.com (Adrian Bye) Date: Sat Feb 12 18:08:57 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108217076.20402.35.camel@presto.wooz.org> Message-ID: <20050212170856.2CC8C1E4006@bag.python.org> > On Sat, 2005-02-12 at 05:33, Thomas Hochstein wrote: > > > I don't think so. I'd prefer to change options > *immediately*, without > > having to wait until I get my mail (partly via UUCP). > > I agree. And without passwords, you don't have to. Instead of a password to access member options, you access it via the custom URL at the footer of every message. You can either save the URL in a password storage someplace, or just refer to an older message in your mail. Adrian From barry at python.org Sat Feb 12 18:25:43 2005 From: barry at python.org (Barry Warsaw) Date: Sat Feb 12 18:25:49 2005 Subject: [Mailman-Developers] [Fwd: Fwd: Re: [Mailman-Announce] Critical security update for Mailman 2.1.5 and earlier [origin: mailman-developers-owner@python.org]] Message-ID: <1108229143.19019.4.camel@geddy.wooz.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050212/1a073552/attachment-0001.pgp From bob at nleaudio.com Sat Feb 12 18:36:29 2005 From: bob at nleaudio.com (Bob Puff) Date: Sat Feb 12 18:36:34 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050212170856.2CC8C1E4006@bag.python.org> References: <1108217076.20402.35.camel@presto.wooz.org> <20050212170856.2CC8C1E4006@bag.python.org> Message-ID: <20050212173545.M44447@nleaudio.com> ... and then what happens when someone replies to the message, quoting the whole message? That "sensitive" URL is exposed. -1. Bob ---------- Original Message ----------- From: "Adrian Bye" To: "'Barry Warsaw'" , "'Thomas Hochstein'" Cc: mailman-developers@python.org Sent: Sat, 12 Feb 2005 13:08:55 -0400 Subject: RE: [Mailman-Developers] Hashing member passwords in config.pck > > On Sat, 2005-02-12 at 05:33, Thomas Hochstein wrote: > > > > > I don't think so. I'd prefer to change options > > *immediately*, without > > > having to wait until I get my mail (partly via UUCP). > > > > I agree. > > And without passwords, you don't have to. Instead of a password to access > member options, you access it via the custom URL at the footer of > every message. You can either save the URL in a password storage > someplace, or just refer to an older message in your mail. > > Adrian > > _______________________________________________ > 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/bob%40nleaudio.com ------- End of Original Message ------- From msapiro at value.net Sat Feb 12 18:50:48 2005 From: msapiro at value.net (Mark Sapiro) Date: Sat Feb 12 18:51:06 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050212170856.2CC8C1E4006@bag.python.org> Message-ID: Adrian Bye wrote: >> On Sat, 2005-02-12 at 05:33, Thomas Hochstein wrote: >> >> > I don't think so. I'd prefer to change options >> *immediately*, without >> > having to wait until I get my mail (partly via UUCP). >> >> I agree. > >And without passwords, you don't have to. Instead of a password to access >member options, you access it via the custom URL at the footer of every message. >You can either save the URL in a password storage someplace, or just refer to an >older message in your mail. Which at a minimum would require personalization of all lists with its attendant performance hit, plus this URL would have to contain the equivalent of a password whether you call it that or not, thus exposing it to compromise by including it in every mail. I used to run some lists on Topica.com and they have an 'easy unsubscribe' link at the bottom of every mail, and I am amazed at the number of people who don't edit this out of mail they forward (and the number who still don't know how to get off a list). -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From iane at sussex.ac.uk Mon Feb 14 13:30:52 2005 From: iane at sussex.ac.uk (iane@sussex.ac.uk) Date: Mon Feb 14 13:30:55 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <20050212070711.M454@nleaudio.com> References: <8d75968bac541f84b859950bd97bddbf@plaidworks.com> <20050212070711.M454@nleaudio.com> Message-ID: <6FAC2EF70D080E28A8E5492C@lewes.staff.uscs.susx.ac.uk> --On February 12, 2005 02:07:29 -0500 Bob Puff wrote: > I'm in agreement with Barry, that I don't think we should phase out > passwords for 2.1.x. I know several of my users who sign up to > the lists > using their corporate mailbox, yet log in from home and view archives > (they remember their password). > I'd have people screaming bloody murder > if the archives were required to have email confirmation for each read. > > I'm sorry, but I just don't see other viable solutions except for > passwords for this function. Every other "members-only" area on the > internet today is authenticated by passwords, and they can be saved in > the browsers for easy access. +1. Actually, +15,000 for all the students and staff on campus that use Mailman here. They remember their passwords because they use them to log in to the machines on campus. Of course, I'd like Mailman to authenticate from our LDAP server instead of any password that Mailman stored - for users in our domain. For external users of our lists, then they'd need to have Mailman passwords - unless they had different functionality, I suppose. -- Ian Eiloart Servers Team Sussex University ITS From brad at python.org Mon Feb 14 16:23:15 2005 From: brad at python.org (Brad Knowles) Date: Mon Feb 14 16:23:28 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] security heads up - path traversal with 2.1.5 In-Reply-To: <87brans2z4.fsf@deneb.enyo.de> References: <200502091119.46050.rb@islandnet.com> <200502091208.38665.rb@islandnet.com> <821e234d4d5194c4eb7d177fc79ab78f@plaidworks.com> <87y8druy5u.fsf@deneb.enyo.de> <87brans2z4.fsf@deneb.enyo.de> Message-ID: At 2:09 PM +0100 2005-02-14, Florian Weimer wrote: > The underlying assumption seems to be that Mailman security bugs can > only be disclosed by posting them on the Mailman lists. In response to this issue, FAQ 1.27 has been updated, and the mailman-users and mailman-developers mailing lists have likewise been modified to include suitable text at the bottom of every message, as well as on the "listinfo" page, and in the "welcome" message that is sent to all new subscribers. This matter is now closed. -- Brad Knowles Python.org Postmaster Team From Janssen at rz.uni-frankfurt.de Mon Feb 14 16:46:10 2005 From: Janssen at rz.uni-frankfurt.de (Michael Janssen) Date: Mon Feb 14 16:46:17 2005 Subject: [Mailman-Developers] Re: [Mailman-Announce] Critical security update for Mailman 2.1.5 and earlier In-Reply-To: <20050210151633.GB1704@ecos.de> References: <1108046465.8044.63.camel@presto.wooz.org> <20050210151633.GB1704@ecos.de> Message-ID: On Thu, 10 Feb 2005, Axel Beckert wrote: > Am Thu, Feb 10, 2005 at 09:41:05AM -0500, Barry Warsaw schrieb: > > Until Mailman 2.1.6 is released, the longer term fix is to apply > > this patch: > > > > http://www.list.org/CAN-2005-0202.txt > > Which unfortunately only works with Python 2. Python 1 (respective at > least 1.5.2) complains about syntax errors. (Which, in fact, also > helps against the vulnerability by displaying the "You've found a > Mailman bug" page. ;-) > > Is there any patch which complies with Python 1 syntax? not as a patch, cause I haven't got a CVS repository available but you can change the line safe = [x for x in parts if x not in ('.', '..')] which is list comprehension syntax into: safe = [] for x in parts: if x not in ('.', '..'): safe.append(x) which does obviously the same: Append to safe every x in parts which are not "." or ".." regards Michael From jwblist at olympus.net Mon Feb 14 19:48:52 2005 From: jwblist at olympus.net (John W. Baxter) Date: Mon Feb 14 19:49:06 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108216973.20405.33.camel@presto.wooz.org> Message-ID: On 2/12/2005 6:02, "Barry Warsaw" wrote: > On Sat, 2005-02-12 at 02:07, Bob Puff wrote: > >> So let me ask this: if we drop passwords for everything but the private >> archives, do we really need to do anything differently than the format >> currently in place? Do they really need to be one-way encrypted? Being able >> to email a forgotten password has its benefits. > > It's still worthwhile (in the long run) to hash the passwords. Some > people tend to re-use them, so stealing Mailman passwords can > potentially lead to cascading attacks. Password resets are fine. > I don't see how users remote from their normal email can make use of password resets. Without the old password, how do they prove they should be able to reset a subscriber's password? Thus they can't designate the new password, nor learn the generated one, remotely. I don't think the above kills the idea (I've changed my mind, with respect to the private archives, from what I said earler). --John From darrell at grumblesmurf.net Mon Feb 14 22:29:08 2005 From: darrell at grumblesmurf.net (Darrell Fuhriman) Date: Mon Feb 14 22:29:16 2005 Subject: [Mailman-Developers] Hashing member passwords in config.pck In-Reply-To: <1108165123.9913.38.camel@geddy.wooz.org> (Barry Warsaw's message of "Fri, 11 Feb 2005 18:38:43 -0500") References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <1108056770.27472.97.camel@finch.boston.redhat.com> <420BFC86.3080100@is.kochi-u.ac.jp> <20050211044328.M81861@nleaudio.com> <420C3ABE.7090506@is.kochi-u.ac.jp> <6D5DEE8CB0870E533F4E3B70@lewes.staff.uscs.susx.ac.uk> <1108165123.9913.38.camel@geddy.wooz.org> Message-ID: > Integrating with external user storages for authentication should help > out a lot here, but I'm just not seeing how we can totally eliminate > passwords. I'm willing to be convinced though. Speaking of which. MM3 seems to be pretty stalled out. Is there anything I/we can do to get the ball rolling again? Darrell From barry at python.org Mon Feb 14 23:08:24 2005 From: barry at python.org (Barry Warsaw) Date: Mon Feb 14 23:08:31 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] security heads up - path traversal with 2.1.5 In-Reply-To: <420A87E8.9070200@is.kochi-u.ac.jp> References: <200502091119.46050.rb@islandnet.com> <420A87E8.9070200@is.kochi-u.ac.jp> Message-ID: <1108418904.31178.71.camel@geddy.wooz.org> On Wed, 2005-02-09 at 17:00, Tokio Kikuchi wrote: > I've tested with my 1.3.29 installation and verified apache PATH_INFO > does convert '//' to '/'. Barry also wanted to clarify which apache > version/installation (combination with mailman) is valnerable. Return > code of 200 doesn't mean sucessful exploit. You should check mailman > logs/error also. (If there is none chances are succesful exploit.) Tokio, do you do any rewrites in your 1.3.29 config file? I just have this gut feeling like there's some kind of rewrite rule that caused this slash-collapse behavior to be disabled. FWIW, python.org does not do rewrites and we weren't vulnerable. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050214/2d77a7e2/attachment.pgp From barry at python.org Mon Feb 14 23:12:37 2005 From: barry at python.org (Barry Warsaw) Date: Mon Feb 14 23:13:41 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] security heads up - path traversal with 2.1.5 In-Reply-To: References: <200502091119.46050.rb@islandnet.com> <200502091208.38665.rb@islandnet.com> <821e234d4d5194c4eb7d177fc79ab78f@plaidworks.com> <87y8druy5u.fsf@deneb.enyo.de> <87brans2z4.fsf@deneb.enyo.de> Message-ID: <1108419157.31182.74.camel@geddy.wooz.org> On Mon, 2005-02-14 at 10:23, Brad Knowles wrote: > In response to this issue, FAQ 1.27 has been updated Wow Brad, I was just about to change this to read mailman-security@python.org but you beat me to it by seconds. :) > , and the > mailman-users and mailman-developers mailing lists have likewise been > modified to include suitable text at the bottom of every message, as > well as on the "listinfo" page, and in the "welcome" message that is > sent to all new subscribers. I have to agree with Chuq here. I don't the extra text on the footers. Can you please remove them? It's just not information that every message needs to carry. Thanks. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050214/2f8e41be/attachment.pgp From brad at stop.mail-abuse.org Mon Feb 14 23:22:09 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Mon Feb 14 23:30:39 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] security heads up - path traversal with 2.1.5 In-Reply-To: <1108419157.31182.74.camel@geddy.wooz.org> References: <200502091119.46050.rb@islandnet.com> <200502091208.38665.rb@islandnet.com> <821e234d4d5194c4eb7d177fc79ab78f@plaidworks.com> <87y8druy5u.fsf@deneb.enyo.de> <87brans2z4.fsf@deneb.enyo.de> <1108419157.31182.74.camel@geddy.wooz.org> Message-ID: At 5:12 PM -0500 2005-02-14, Barry Warsaw wrote: >> In response to this issue, FAQ 1.27 has been updated > > Wow Brad, I was just about to change this to read > mailman-security@python.org but you beat me to it by seconds. :) Mark had clued me in that someone had changed the security-related pages at www.list.org, and that we should make the same change to FAQ 1.27, which I did. > I have to agree with Chuq here. I don't the extra text on the footers. > Can you please remove them? It's just not information that every > message needs to carry. Given the above change, I didn't want to have to keep editing this text every time something changes, so I had already cut the added text down to one line, which references FAQ 1.27. Is that suitable? -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tkikuchi at is.kochi-u.ac.jp Tue Feb 15 09:26:04 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue Feb 15 09:26:21 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] security heads up - path traversal with 2.1.5 In-Reply-To: <1108418904.31178.71.camel@geddy.wooz.org> References: <200502091119.46050.rb@islandnet.com> <420A87E8.9070200@is.kochi-u.ac.jp> <1108418904.31178.71.camel@geddy.wooz.org> Message-ID: <4211B21C.5090405@is.kochi-u.ac.jp> Hi, Barry Warsaw wrote: > On Wed, 2005-02-09 at 17:00, Tokio Kikuchi wrote: > > >>I've tested with my 1.3.29 installation and verified apache PATH_INFO >>does convert '//' to '/'. Barry also wanted to clarify which apache >>version/installation (combination with mailman) is valnerable. Return >>code of 200 doesn't mean sucessful exploit. You should check mailman >>logs/error also. (If there is none chances are succesful exploit.) > > > Tokio, do you do any rewrites in your 1.3.29 config file? I just have > this gut feeling like there's some kind of rewrite rule that caused this > slash-collapse behavior to be disabled. FWIW, python.org does not do > rewrites and we weren't vulnerable. > I might have confused about which server I was testing. I tested again today and found all the 1.3 servers (on FreeBSD, Solaris, and BSD/OS) I administering were vulnerable. (Not all are mailman installed). They are all not using mod_rewrite. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From Kai.Palomaki at vlp.fi Tue Feb 15 11:22:50 2005 From: Kai.Palomaki at vlp.fi (=?iso-8859-1?Q?Palom=E4ki_Kai?=) Date: Tue Feb 15 11:22:53 2005 Subject: [Mailman-Developers] Userdefined HELO with SMTPDirect Message-ID: <5BC52ECBF0071C45821BCD2511BE4725244CF7@zeus.intra.vlp.fi> Hello, It would be useful in some situations (for example Mailman and Postfix running on same host) to define custom HELO when using Mailman SMTPDirect delivery module. I made simple patch to achieve this. But since my experience with Python is minimal I don't know if this is "the right way(tm)". diff -u -r mailman-2.1.6b3/Mailman/Defaults.py.in mailman-2.1.6b3-patched/Mailman/Defaults.py.in --- mailman-2.1.6b3/Mailman/Defaults.py.in 2005-01-22 08:55:28.000000000 +0200 +++ mailman-2.1.6b3-patched/Mailman/Defaults.py.in 2005-02-13 12:59:28.000000000 +0200 @@ -422,6 +422,11 @@ SMTPHOST = 'localhost' SMTPPORT = 0 # default from smtplib +# SMTP HELO sent by Mailman, when DELIVERY_MODULE is 'SMTPDirect'. Default +# is FQDN of localhost (as returned by socket.getfqdn()) +# SMTPHELO = 'my.own.fqdn.hostname' +SMTPHELO = None + # Command for direct command pipe delivery to sendmail compatible program, # when DELIVERY_MODULE is 'Sendmail'. SENDMAIL_CMD = '/usr/lib/sendmail' diff -u -r mailman-2.1.6b3/Mailman/Handlers/SMTPDirect.py mailman-2.1.6b3-patched/Mailman/Handlers/SMTPDirect.py --- mailman-2.1.6b3/Mailman/Handlers/SMTPDirect.py 2004-01-23 01:02:07.000000000 +0200 +++ mailman-2.1.6b3-patched/Mailman/Handlers/SMTPDirect.py 2005-02-13 12:29:59.000000000 +0200 @@ -59,7 +59,7 @@ self.__conn = None def __connect(self): - self.__conn = smtplib.SMTP() + self.__conn = smtplib.SMTP('', 0, mm_cfg.SMTPHELO) self.__conn.connect(mm_cfg.SMTPHOST, mm_cfg.SMTPPORT) self.__numsessions = mm_cfg.SMTP_MAX_SESSIONS_PER_CONNECTION From tkikuchi at is.kochi-u.ac.jp Tue Feb 15 14:04:12 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue Feb 15 14:04:20 2005 Subject: [Mailman-Developers] Mail-to-news gatewaying? In-Reply-To: References: <42082DD0.7070408@is.kochi-u.ac.jp> Message-ID: <4211F34C.6000005@is.kochi-u.ac.jp> Hi Brad, While we are at security bug fix. I also worked on this and checked in the CVS/2.1.6b3. I could only test it by logging the news message because I don't have inn server around. I hope you can test it by yourself. Brad Knowles wrote: > At 12:11 PM +0900 2005-02-08, Tokio Kikuchi wrote: > >> Things are not easy because there are MIME subjects > > > There's that damn pesky MIME problem again. ;) > >> and we also start >> numbering prefix in mailman 2.1.6. > > > Ouch! I had forgotten about that. > >> May be we can calculate >> 'stripped_subject' in CookHeaders.py and store in msgdata for >> later use. Or, strip in a magical ;-) way which I use in >> CookHeaders.py and in HyperArch.py, in NewsRunner.py again. > > > Hmm. Maybe we can have a library routine that all programs could use? > >> Anyway, I will try. > > > Much appreciated. Thanks! > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From adrian at tasdevil.com Tue Feb 15 16:50:02 2005 From: adrian at tasdevil.com (Adrian Bye) Date: Tue Feb 15 16:50:13 2005 Subject: [Mailman-Developers] Html headers & footers, unsubscribe Message-ID: <20050215155012.417C91E4005@bag.python.org> Hi guys, I have had patches made for two issues: 1. HTML headers & footers handling 2. 1 click list unsubscribe You can get our patches here: https://sourceforge.net/tracker/index.php?func=detail&aid=1121257&group_id=103&a tid=300103 Or also here: http://tasdevil.com/mailman_developers.zip Installation instructions are found in readme.txt What we did: 1. Reasonably good handling of HTML headers & footers The issue we wanted to address is this one: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.039.htp I wanted to be able to put html headers and footers into messages. I did not like the current mailman style of adding an attachment. I knew this must be possible to do because yahoo groups is doing it. So we spent a LOT of time testing how yahoo groups adds footers to mails. We tested multipart messages with varying numbers of attachments, badly formed html and a bunch of other stuff. We have documented our testing process in mime.txt. Our implementation is about 95% perfect, and works identical to yahoo groups, which is sending millions of emails/day. It will correctly handle badly formed html, and various mimetypes. Sometimes, depending on the colors of a message, it will not be possible to view the headers & footers. Otherwise it works really well. 2. 1-click unsubscribe with the URL under 60 characters. I've been involved in some discussions on this topic on the developers list. The current unsubscribe process was not clear to me, and I wanted it to be very easy for my users. I also wanted the URLs to be short, so they would never get broken by various mail clients. We made some small changes to encode the users email address and listnames to the footer, along with the user password. When a user wishes to unsubscribe, they click on the link, it passes this information to mailman, and a confirmation page is then shown. The user can choose to unsubscribe by clicking on the "yes, I want to unsubscribe" button. I work with users who are less advanced than your average AOL customer, so both of these points were extremely important to solve. While many do feel its important to continue requiring passwords for mailman accounts, I would strongly advocate that those passwords become hidden just for access to archives. I'd like to see mailman become capable of handling millions of messages/day, and it is only when simple unsubscribe functionality is incorporated that the resources will start to appear to make that possible. Yes, this may represent some change, but I believe it can be done in a way which leaves everyone happy. Anyways, those are our modifications. If you have code questions, all coding was done by Bushmanov Efim, who can be reached at binworkers@dcemail.com. He is available for more work of this kind if you need it, and I would highly recommend him as a great programmer. For other questions drop me a line. Cheers, Adrian From msapiro at value.net Tue Feb 15 18:45:47 2005 From: msapiro at value.net (Mark Sapiro) Date: Tue Feb 15 18:48:03 2005 Subject: [Mailman-Developers] Html headers & footers, unsubscribe In-Reply-To: <20050215155012.417C91E4005@bag.python.org> Message-ID: Adrian Bye wrote: > >I wanted to be able to put html headers and footers into messages. I did not >like the current mailman style of adding an attachment. I have only looked briefly at the patches, but one problem I noticed is that the long description of msg_html_header in the patch to Mailman/Gui/NonDigest.py says "appended to the bottom" instead of "prepended to the top". >2. 1-click unsubscribe with the URL under 60 characters. > > >I work with users who are less advanced than your average AOL customer, ... I suggest that while this 1-click unsubscribe may work well for you, it does not work well in general. I have managed lists on Topica.com where every delivered message contains a footer with the address it was sent to and a 1-click unsubscribe link. My experience as a Topica list manager and member of the LOD (list owner's discussion) list is: 1) These things do not substantially reduce the number of "unsubscribe me" messages sent to the list manager or the OP or posted to the list. 2) These things cause problems for users when a user forwards or replies to a message containing the footer without removing it and a subsequent recipient follows the 1-click unsubscribe out of curiosity, in a mistaken attempt to unsubscribe him/herself, maliciously or just to try to "teach" the user not to do that. This occurs on Topica lists despite the fact that Topica removes the footer from incoming posts and even if the footer has been mangled so it is not recognizable as such and not removable, the 1-click unsubscribe URI is recognized and munged so it doesn't work. If these 1-click unsubscribe links are not removed from replies to the list (your "less advanced than your average AOL customer" users won't remove them before replying), they are going to be widely available on your lists and people are going to be unsubscribed without their knowledge or consent. Even if they are removed from list posts as in the Topica case, they are still available in off-list replies, Ccs and forwards and still cause problems. I am not trying to denegrate the work you've done or your contribution back to the Mailman project. I think this is a fine example of how open source works. I'm only trying to point out that there can be a "dark side" to this feature. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From brad at stop.mail-abuse.org Tue Feb 15 21:18:06 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue Feb 15 21:18:15 2005 Subject: [Mailman-Developers] mmdsr -- Mailman Daily Status Reports script... Message-ID: Folks, I just posted a patch for this at . I'd appreciate any feedback that you may have. Thanks! -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From fil at rezo.net Wed Feb 16 00:41:52 2005 From: fil at rezo.net (Fil) Date: Wed Feb 16 00:41:50 2005 Subject: [Mailman-Developers] bug in mailman 2.1.6b2 Message-ID: <20050215234152.GE8305@rezo.net> Hi, I just installed Mailman from CVS two days ago, and on a new list I just created I'm hit by a bug : http://listes.rezo.net/mailman/admin/spip-trac/privacy/sender Bug in Mailman version 2.1.6b2 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. the error log is attached -- Fil -------------- next part -------------- Feb 16 00:38:40 2005 admin(27737): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(27737): [----- Mailman Version: 2.1.6b2 -----] admin(27737): [----- Traceback ------] admin(27737): Traceback (most recent call last): admin(27737): File "/var/local/mailman/scripts/driver", line 101, in run_main admin(27737): main() admin(27737): File "/var/local/mailman/Mailman/Cgi/admin.py", line 196, in main admin(27737): show_results(mlist, doc, category, subcat, cgidata) admin(27737): File "/var/local/mailman/Mailman/Cgi/admin.py", line 520, in show_results admin(27737): form.AddItem(show_variables(mlist, category, subcat, cgidata, doc)) admin(27737): File "/var/local/mailman/Mailman/Cgi/admin.py", line 569, in show_variables admin(27737): add_options_table_item(mlist, category, subcat, table, item) admin(27737): File "/var/local/mailman/Mailman/Cgi/admin.py", line 584, in add_options_table_item admin(27737): val = get_item_gui_value(mlist, category, kind, varname, params, extra) admin(27737): File "/var/local/mailman/Mailman/Cgi/admin.py", line 623, in get_item_gui_value admin(27737): value = getattr(mlist, varname) admin(27737): File "/var/local/mailman/Mailman/MailList.py", line 145, in __getattr__ admin(27737): raise AttributeError, name admin(27737): AttributeError: nonmember_rejection_notice admin(27737): [----- Python Information -----] admin(27737): sys.version = 2.3.4 (#2, Dec 3 2004, 13:53:17) [GCC 3.3.5 (Debian 1:3.3.5-2)] admin(27737): sys.executable = /usr/bin/python admin(27737): sys.prefix = /usr admin(27737): sys.exec_prefix = /usr admin(27737): sys.path = /usr admin(27737): sys.platform = linux2 admin(27737): [----- Environment Variables -----] admin(27737): HTTP_REFERER: http://listes.rezo.net/mailman/admin/spip-trac/privacy/spam admin(27737): SERVER_SOFTWARE: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-2 admin(27737): SCRIPT_NAME: /mailman/admin admin(27737): SERVER_SIGNATURE: admin(27737): REQUEST_METHOD: GET admin(27737): PATH_INFO: /spip-trac/privacy/sender admin(27737): SERVER_PROTOCOL: HTTP/1.1 admin(27737): QUERY_STRING: admin(27737): HTTP_USER_AGENT: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr-fr) AppleWebKit/125.5.6 (KHTML, like Gecko) Safari/125.12 admin(27737): HTTP_CONNECTION: keep-alive admin(27737): HTTP_COOKIE: site=2802000000695b871242732800000034646330633934396138376235383136346131633865303236393031656439393238613838336637 admin(27737): SERVER_NAME: listes.rezo.net admin(27737): REMOTE_ADDR: 130.238.5.5 admin(27737): PATH_TRANSLATED: /var/shim/listes/Web/spip-trac/privacy/sender admin(27737): SERVER_PORT: 80 admin(27737): SERVER_ADDR: 217.24.84.2 admin(27737): DOCUMENT_ROOT: /var/shim/listes/Web admin(27737): PYTHONPATH: /var/local/mailman admin(27737): SCRIPT_FILENAME: /var/local/mailman/cgi-bin/admin admin(27737): SERVER_ADMIN: listes@rezo.net admin(27737): SCRIPT_URI: http://listes.rezo.net/mailman/admin/spip-trac/privacy/sender admin(27737): HTTP_HOST: listes.rezo.net admin(27737): SCRIPT_URL: /mailman/admin/spip-trac/privacy/sender admin(27737): REQUEST_URI: /mailman/admin/spip-trac/privacy/sender admin(27737): HTTP_ACCEPT: */* admin(27737): GATEWAY_INTERFACE: CGI/1.1 admin(27737): REMOTE_PORT: 46927 admin(27737): HTTP_ACCEPT_LANGUAGE: fr-fr, ja;q=0.14, en-us;q=0.93, en;q=0.90, de-de;q=0.86, de;q=0.83, nl-nl;q=0.79, nl;q=0.76, it-it;q=0.72, it;q=0.69, es-es;q=0.66, es;q=0.62, da-dk;q=0.59, da;q=0.55, fi-fi;q=0.52, fi;q=0.48, ko-kr;q=0.45, ko;q=0.41, no-no;q=0.38 admin(27737): HTTP_ACCEPT_ENCODING: gzip, deflate;q=1.0, identity;q=0.5, *;q=0 admin(27737): UNIQUE_ID: QhKIANkYVAIAAGmh0DY From msapiro at value.net Wed Feb 16 01:11:16 2005 From: msapiro at value.net (Mark Sapiro) Date: Wed Feb 16 01:11:39 2005 Subject: [Mailman-Developers] bug in mailman 2.1.6b2 In-Reply-To: <20050215234152.GE8305@rezo.net> Message-ID: Fil wrote: > >Hi, I just installed Mailman from CVS two days ago, and on a new list I just >created I'm hit by a bug : > >http://listes.rezo.net/mailman/admin/spip-trac/privacy/sender > >Bug in Mailman version 2.1.6b2 > >admin(27737): File "/var/local/mailman/Mailman/MailList.py", line 145, in __getattr__ >admin(27737): raise AttributeError, name >admin(27737): AttributeError: nonmember_rejection_notice Looks like MailList.InitVars() is missing self.nonmember_rejection_notice = '' -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From tkikuchi at is.kochi-u.ac.jp Wed Feb 16 01:25:36 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed Feb 16 01:25:45 2005 Subject: [Mailman-Developers] bug in mailman 2.1.6b2 In-Reply-To: References: Message-ID: <42129300.3040601@is.kochi-u.ac.jp> Mark Sapiro wrote: > Fil wrote: > >>Hi, I just installed Mailman from CVS two days ago, and on a new list I just >>created I'm hit by a bug : >> >>http://listes.rezo.net/mailman/admin/spip-trac/privacy/sender >> >>Bug in Mailman version 2.1.6b2 >> > > > >>admin(27737): File "/var/local/mailman/Mailman/MailList.py", line 145, in __getattr__ >>admin(27737): raise AttributeError, name >>admin(27737): AttributeError: nonmember_rejection_notice > > > Looks like MailList.InitVars() is missing > self.nonmember_rejection_notice = '' > Thank you Mark and sorry for the inconvenience Fil. I've just fixed the developers CVS. I will be cutting beta 4 by this weekend. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From fil at rezo.net Wed Feb 16 08:35:32 2005 From: fil at rezo.net (Fil) Date: Wed Feb 16 08:35:28 2005 Subject: [Mailman-Developers] bug in mailman 2.1.6b2 In-Reply-To: <42129300.3040601@is.kochi-u.ac.jp> References: <42129300.3040601@is.kochi-u.ac.jp> Message-ID: <20050216073532.GB22899@rezo.net> > >Looks like MailList.InitVars() is missing > > self.nonmember_rejection_notice = '' > > Thank you Mark and sorry for the inconvenience Fil. No problem; that's what betas are for :)) -- Fil From fil at rezo.net Wed Feb 16 08:41:29 2005 From: fil at rezo.net (Fil) Date: Wed Feb 16 08:41:24 2005 Subject: [Mailman-Developers] bug in mailman 2.1.6b2 In-Reply-To: <42129300.3040601@is.kochi-u.ac.jp> References: <42129300.3040601@is.kochi-u.ac.jp> Message-ID: <20050216074129.GD22899@rezo.net> > >Looks like MailList.InitVars() is missing > > self.nonmember_rejection_notice = '' If anyone else gets biten, here's how to fix the list: mailman@lists# bin/withlist -l spip-trac Loading list spip-trac (locked) The variable `m' is the spip-trac MailList instance >>> m.nonmember_rejection_notice = '' >>> m.Save() >>> ^D -- Fil From tobias at kabissa.org Wed Feb 16 14:54:27 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Wed Feb 16 14:53:24 2005 Subject: making Mailman CAN-SPAM compliant (was Re: [Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> Message-ID: <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> Hi Brad - Sorry for sitting on this for so long - would like to respond to it though.. see below. >> And this, plus the CAN prefix to the patch name, reminds me: correct >> me >> if I'm wrong, but my understanding is that Mailman as it exists does >> not comply with the new (unfortunately named) CAN SPAM act. According >> to this act, a recipient of an email from a given site has to be able >> to opt out from receiving ANY MAIL from that site. Right now all >> mailman >> lists are treated completely separately, and nobody (not even the >> subscriber) can easily find out which lists subscribers are >> subscribed to. > > Actually, you can easily see which lists you're subscribed to. Go to > the listinfo page for the mailing list in question, and log in using > your e-mail address and password. There's a button that says "List my > other subscriptions". Unfortunately, you can't unsubscribe from all > of them with a single command, you will have to unsubscribe from each > of them individually. But you can globally change all your passwords > for all the lists you're subscribed to, change your e-mail address, > and if you scroll down to the bottom of the list, you can change a > number of other options, most of which can be applied globally. > > However, this is only a on a per-address basis. If you have multiple > different addresses subscribed to different lists, you will have to > handle them each individually. I know all this - and I know you know it, and I know all Mailman geeks like us get it. The problem is with regular, every day people who are expecting (and really can be expected to expect) Yahoogroups type interfaces. I'm sorry to say it, but Mailman's web interfaces are extremely daunting and confusing. It's really weird to have to log in multiple times to access multiple list settings, especially if it's the same password being used everywhere. It's likewise weird to then be able to make "global" changes from one list's preferences page. Has anybody considered having a usability expert look at the Mailman interfaces and redesign them so they make more sense from a user's point of view? How easy is it to customize these pages? Are they perchance templatable? And we're only talking about the frontend (listinfo interface) here now, not even the backend (admin interface) for list owners. The backend is so incredibly complex and overwhelming that it has become a serious stumbling block for us in offering a service that people will actually use. For Kabissa these interfaces have to be as easy to use as Yahoo Groups or Google (has anyone tried Google's groups? They are quite nifty actually). We have people coming online from all over Africa who pay dearly for every precious minute they spend online. >> What I envision having in my Mailman/Mambo system is a single user >> database with one password per username for all services. Users can >> then go to a simple preferences page on Mambo and do basic things >> like change their email address or password, tick a box to opt in/out >> of various mailings, and in particular opt to receive no mail at all. > > You can pretty much do all of that today. Go to the listinfo page > and log in with your e-mail address and password. Perhaps, but you can't do it "easily". Cheers, Tobias -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From brad at stop.mail-abuse.org Wed Feb 16 15:52:43 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed Feb 16 15:53:26 2005 Subject: making Mailman CAN-SPAM compliant (was Re: [Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> Message-ID: At 8:54 AM -0500 2005-02-16, Tobias Eigen wrote: > I know all this - and I know you know it, and I know all Mailman geeks > like us get it. The problem is with regular, every day people who are > expecting (and really can be expected to expect) Yahoogroups type > interfaces. All I can say is that Mailman is a non-profit open source project, run by a group of people in whatever spare time they can manage to scrape together. The Linux folks haven't cracked the ease-of-use aspects of their OS compared to Microsoft, not even for the companies that are spending large quantities of money to try to make that happen. We're a much, much smaller group, and although this is also a smaller target, I don't see us being likely to succeed in this area where the Linux folks have not. 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. If people really need those kinds of features today, then they should be using Yahoo! Groups and not Mailman. In the meanwhile, we do what we can, and we accept what donations of time, code, or money that is offered to us. > Has anybody considered having a usability expert look at the Mailman > interfaces and redesign them so they make more sense from a user's point > of view? I don't know, but I would doubt it. For the official story, you'd have to ask Barry. > How easy is it to customize these pages? Are they perchance > templatable? The template facilities within Mailman are fairly limited, but I have not looked into whether they attempt to address these areas. >> You can pretty much do all of that today. Go to the listinfo page >> and log in with your e-mail address and password. > > Perhaps, but you can't do it "easily". The miracle of a talking dog is not how well it speaks or the fact that it always uses proper grammar, but that it speaks at all. Perhaps with your help, we can help that dog speak a little better. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From adrian at tasdevil.com Wed Feb 16 16:28:45 2005 From: adrian at tasdevil.com (Adrian Bye) Date: Wed Feb 16 16:28:52 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: Message-ID: <20050216152850.EEB2D1E4012@bag.python.org> > All I can say is that Mailman is a non-profit open > source project, run by a group of people in whatever spare > time they can manage to scrape together. > > The Linux folks haven't cracked the ease-of-use aspects > of their OS compared to Microsoft, not even for the companies > that are spending large quantities of money to try to make > that happen. We're a much, much smaller group, and although > this is also a smaller target, I don't see us being likely to > succeed in this area where the Linux folks have not. > > 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. Brad, 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=show&file=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. 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. Adrian From lists05 at equinephotoart.com Wed Feb 16 17:13:22 2005 From: lists05 at equinephotoart.com (JC Dill) Date: Wed Feb 16 17:13:30 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <20050216152850.EEB2D1E4012@bag.python.org> References: <20050216152850.EEB2D1E4012@bag.python.org> Message-ID: <42137122.6040906@equinephotoart.com> 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=show&file=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 From darrell at grumblesmurf.net Wed Feb 16 17:24:12 2005 From: darrell at grumblesmurf.net (Darrell Fuhriman) Date: Wed Feb 16 17:24:16 2005 Subject: [Mailman-Developers] Re: making Mailman CAN-SPAM compliant In-Reply-To: <20050216152850.EEB2D1E4012@bag.python.org> (Adrian Bye's message of "Wed, 16 Feb 2005 11:28:45 -0400") References: <20050216152850.EEB2D1E4012@bag.python.org> Message-ID: "Adrian Bye" writes: > 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. I agree. I'd love to see some real movement on Mailman, but it does seem a bit stalled. (Note the lack of response to my recent MM3 query). Maybe open up the code to a few more commiters would help? But, I don't get the impression there's much interest in letting others have a crack at it. I'd really like to see some serious discussion about the architecture of mailman3, so we can get coding. Darrell From barry at python.org Wed Feb 16 17:24:26 2005 From: barry at python.org (Barry Warsaw) Date: Wed Feb 16 17:24:43 2005 Subject: making Mailman CAN-SPAM compliant (was Re: [Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> Message-ID: <1108571066.10587.41.camel@geddy.wooz.org> On Wed, 2005-02-16 at 08:54, Tobias Eigen wrote: > It's really weird to have to log in > multiple times to access multiple list settings, especially if it's the > same password being used everywhere. It's likewise weird to then be > able to make "global" changes from one list's preferences page. There's no question that this is a major usability issue, but it's a result of an ancient architectural decision that is difficult to fix and not backwards compatible. > Has > anybody considered having a usability expert look at the Mailman > interfaces and redesign them so they make more sense from a user's > point of view? How easy is it to customize these pages? Are they > perchance templatable? Not easily. One of the goals of MM3 is to make the u/i fully templated. I certainly make no claims to web u/i artistry, and there have been a few attempts over the years to improve things, but no one with the expertise has stepped forward and owned the task of doing this. I'd welcome it though. > And we're only talking about the frontend (listinfo interface) here > now, not even the backend (admin interface) for list owners. The > backend is so incredibly complex and overwhelming that it has become a > serious stumbling block for us in offering a service that people will > actually use. I agree. Somehow we need to make the admin interface much simpler, without sacrificing the important features that (some) people will need. It's a challenge. I actually think that list styles will help a lot here. > For Kabissa these interfaces have to be as easy to use as > Yahoo Groups or Google (has anyone tried Google's groups? They are > quite nifty actually). We have people coming online from all over > Africa who pay dearly for every precious minute they spend online. I hear you. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050216/06d66fa7/attachment.pgp From kmccann at bellanet.org Wed Feb 16 17:42:52 2005 From: kmccann at bellanet.org (Kevin McCann) Date: Wed Feb 16 17:29:06 2005 Subject: making Mailman CAN-SPAM compliant (was Re: [Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> Message-ID: <4213780C.10201@bellanet.org> Tobias Eigen wrote: >>> What I envision having in my Mailman/Mambo system is a single user >>> database with one password per username for all services. Users can >>> then go to a simple preferences page on Mambo and do basic things >>> like change their email address or password, tick a box to opt in/out >>> of various mailings, and in particular opt to receive no mail at all. >> Hello Tobias, I have been meaning to respond to several of your emails lately, but free time has been scarce. We seem to have the same goal, and many people are looking for the same thing, too -- a Yahoogroups-ish solution. I looked at Mailman for this for quite a while before coming to the realization that it just wasn't going to happen easily. There are simply too many problems with MM 2.x: one-to-one relationships between members and lists, awkward pickle file storage, limited customization capabilities and much more. To me, radical changes are required in the mailing list software. And I believe this needs to happen in the Mailman 3 project due to the considerable design changes required. Barry is already looking at significant changes for MM3 such as SQL-based storage (this in itself is huge for our purposes), so I would suggest that efforts should be spent there. I'd like to invite you to work with my organization, Bellanet, in any way possible. We are also in the international development sector and have been wanting to create an open source version of our Dgroups product (see www.dgroups.org) using Mailman and a CMS. In our case we were favoring Xaraya. But MM 2.x just wasn't going to cut it. We are looking at putting $ into MM3, and, as it turns out, we want some African developer involvement. Please contact me off-list if you're interested in brainstorming. I really want to help move MM3 development forward -- with money and/or people -- so that creating a YahooGroups tool, using your favorite CMS as a frontend, would be a cinch. BARRY: would now be a good time to re-energize discussions on the MM3 development list? What is your time like? And are there any plans for a MM3 sprint? I can send people. - Kevin From barry at python.org Wed Feb 16 17:41:26 2005 From: barry at python.org (Barry Warsaw) Date: Wed Feb 16 17:41:29 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <42137122.6040906@equinephotoart.com> References: <20050216152850.EEB2D1E4012@bag.python.org> <42137122.6040906@equinephotoart.com> Message-ID: <1108572086.10588.51.camel@geddy.wooz.org> On Wed, 2005-02-16 at 11:13, JC Dill wrote: > 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. Right now, I am focusing what spare time I have on getting 2.1.6 out the door. Tokio has been a lifesaver for this release, and I think he's primarily focused on the same thing. Once 2.1.6 is out, I would like to have a longer discussion on where we go next. > 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.... Trust me, work like this is greatly appreciated. Just so everyone knows, you don't have to be writing code to help move the Mailman project out. JC, Brad, Chuq, Terri, and others have been an incredible help. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050216/4fe5fb96/attachment.pgp From brad at stop.mail-abuse.org Wed Feb 16 17:38:40 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed Feb 16 17:45:49 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <200502161528.j1GFSnR13087@stop.mail-abuse.org> References: <200502161528.j1GFSnR13087@stop.mail-abuse.org> Message-ID: At 11:28 AM -0400 2005-02-16, Adrian Bye wrote: > 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=show&file=faq04.039.htp Indeed, we have. > 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. I've been waiting to see what Barry, Tokio, or one of the other core developers think of these patches. Keep in mind that they are exceptionally busy people, and it may take a long time for them to be able to take a look at them. I have not yet had a chance to look at them myself. I've been focused on putting together my own little script to assist in the day-to-day site administration tasks for running a Mailman mailing list server, one of the few areas where I can see that Mailman can use improvement, and where my previous experience and limited scripting skills can be put to good use in helping to make this situation better. Well, at least better for me, and then contribute the patch to SourceForge so that others can take a look at it and see if it's useful for them. My hope is that this might be able to be incorporated into future versions of Mailman as well. So, you take me to task for not having yet posted an exhaustive analysis of your patch, but I don't see a comment from you on my script. Can we call it even? > 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. You are right that Mailman can be better than Yahoo!Groups. I don't think you're going to make Mailman better than Yahoo!Groups in every respect, at least not without spending a lot of money. But we can continue to take steps towards that goal. That said, we do gladly accept contributions, but since this is a non-profit open source project which is maintained in what little spare time that people have, you have to accept that it may take a while for the contributions to be reviewed and analyzed by the appropriate people. As for Tobias' contributions to Mailman, he has already given us quite a lot, and has a great deal more that has been done for his own site and which I believe he is happy to contribute to the project. I look forward to continuing to work with him in the future. However, just because I've agreed to work with him in doing Mailman administration for his site and I will try to do what I can to help him get better integration between Mailman and an amazingly wide variety of other projects, and hopefully be able to bring this experience back to the Mailman project, that doesn't necessarily mean that I will always agree with him 100% -- either in private or public. You should not make any assumptions about general attitudes towards all possible future contributions from the community or third parties, based on a single response. In this particular matter, I was talking about the current capabilities of Mailman, not where we hope to ultimately be able to take it. > 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. That's great news! However, we do ask that you give the core developers a little time to look over your contribution and make their analysis. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Wed Feb 16 17:45:21 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed Feb 16 17:45:54 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <42137122.6040906@equinephotoart.com> References: <20050216152850.EEB2D1E4012@bag.python.org> <42137122.6040906@equinephotoart.com> Message-ID: At 8:13 AM -0800 2005-02-16, JC Dill wrote: > 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. I'm not a developer, either. I can do a little bit of hacking together scripts, but that's about it. > 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. Pretty much the same for me, although I also have some additional access to the servers so that I can help monitor and administer the mail system as a whole, etc.... I try to do all the little things I can, so that Barry and the core developers can focus their attention on the big things that I have no hope of ever being able to touch. For the most part, I try to follow the lead of people like Barry, Chuq, JC, and the others who have been here longer than I have. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From barry at python.org Wed Feb 16 17:45:56 2005 From: barry at python.org (Barry Warsaw) Date: Wed Feb 16 17:46:01 2005 Subject: [Mailman-Developers] Re: making Mailman CAN-SPAM compliant In-Reply-To: References: <20050216152850.EEB2D1E4012@bag.python.org> Message-ID: <1108572356.10581.56.camel@geddy.wooz.org> On Wed, 2005-02-16 at 11:24, Darrell Fuhriman wrote: > Maybe open up the code to a few more commiters would help? But, I > don't get the impression there's much interest in letting others > have a crack at it. I agree that I am going to have to open the project up to more committers if Mailman 3 (or 2.2 or whatever) is going to make any serious progress. I will admit that I have had a hard time until now doing this, but I have been very happy with what Tokio's done for 2.1.6, so I'm willing to start thinking about expanding access. > I'd really like to see some serious discussion about the > architecture of mailman3, so we can get coding. Yes, but not here. There is a mailman3-dev mailing list for this. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050216/575e84ca/attachment.pgp From barry at python.org Wed Feb 16 17:50:19 2005 From: barry at python.org (Barry Warsaw) Date: Wed Feb 16 17:50:22 2005 Subject: making Mailman CAN-SPAM compliant (was Re: [Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <4213780C.10201@bellanet.org> References: <1108047741.8045.81.camel@presto.wooz.org> <8ecb2733f212dff7189919c470609e78@kabissa.org> <4433bfe0a8986784aeb024d25aa773b3@kabissa.org> <4213780C.10201@bellanet.org> Message-ID: <1108572619.10594.60.camel@geddy.wooz.org> On Wed, 2005-02-16 at 11:42, Kevin McCann wrote: > BARRY: would now be a good time to re-energize discussions on the MM3 > development list? What is your time like? And are there any plans for a > MM3 sprint? I can send people. Yes, let's start things back up on mailman3-dev. I definitely plan on having a MM3 sprint at Pycon this year and if we can get a critical mass of developers, I think we can make some significant progress. Let's take further discussion to that list. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050216/b5d4e3b5/attachment.pgp From barry at python.org Wed Feb 16 18:06:27 2005 From: barry at python.org (Barry Warsaw) Date: Wed Feb 16 18:06:32 2005 Subject: [Mailman-Developers] Sprinting at Pycon 2005 Message-ID: <1108573587.10593.67.camel@geddy.wooz.org> I encourage everyone who wants to help speed Mailman3 progress to join us at Pycon 2005 for a Mailman 3 sprint. Here's the sprint page: http://www.python.org/moin/Mailman3Sprint If you're coming, please add your name to the list. I think we can make some significant progress if we get enough people. I'm willing to talk about how to improve the process so more people can contribute. Pycon2005 is in Washington DC March 23-25, 2005. While there is a fee for the main conference, there are 4 days of planned sprints from March 19-22 and these are free. I am currently planning on attending the entire conference, including all 4 sprint days, and I'd be happy to sprint on MM3 the whole time. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050216/47a0b612/attachment.pgp From msapiro at value.net Wed Feb 16 18:45:32 2005 From: msapiro at value.net (Mark Sapiro) Date: Wed Feb 16 18:45:39 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers]Hashing member passwords in config.pck) In-Reply-To: <20050216152850.EEB2D1E4012@bag.python.org> Message-ID: Adrian Bye wrote: > >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. Since mine was to only reply to your post, I assume it is that to which you refer. I didn't intend to be "dismissive". I'm sorry it came across that way. In fact, I specifically wrote "I am not trying to denegrate the work you've done or your contribution back to the Mailman project. I think this is a fine example of how open source works." While I did add "I'm only trying to point out that there can be a "dark side" to this feature.", I didn't intend that to mean that it shouldn't be an option for those who might want it. Also, while I may be prolific on the Mailman-Users list, for the record I have no official connection to the Mailman project. I'm just another Mailman administrator with a lot of software experience and evidently, way too much time on his hands. I wouldn't describe myself as a mailman developer, just an interested party trying to learn and contribute back. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From chuqui at plaidworks.com Wed Feb 16 19:32:58 2005 From: chuqui at plaidworks.com (Chuq Von Rospach) Date: Wed Feb 16 19:33:05 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: References: <20050216152850.EEB2D1E4012@bag.python.org> <42137122.6040906@equinephotoart.com> Message-ID: <09add6aaaba04365c519f6c8ce72d346@plaidworks.com> On Feb 16, 2005, at 8:45 AM, Brad Knowles wrote: > > I try to do all the little things I can, so that Barry and the core > developers can focus their attention on the big things that I have no > hope of ever being able to touch. For the most part, I try to follow > the lead of people like Barry, Chuq, JC, and the others who have been > here longer than I have. > It's been a crazy year for everyone on the mailman team -- I know Barry's done what he can, but in the end, he has to earn a paycheck and have a life, and Mailman simply can't be considered more important than either of those. I've been the same way, working on a project that's gotten hugely popular at work and taken up a huge amount of time and energy -- 50 and 60 hour weeks have been common the last year as we try to not choke on success, and I've had other non-work complications sucking up time and energy. To give you an idea how bad it's been -- a server upgrade I'd planned for last March finally is happening, where last night I migrated my blog to a new environment. Having a project like that slip almost a year (and that was a REVISED date. sigh) is scary in a way, but it gives you an idea just how little my spare time and my energy to do things have coincided. Once this server upgrade is complete, I'll be able to finally get started on a couple of projects I announced a couple of years ago and still want to see happen, along with getting more involved with Mailman again. The last few months, I sort of feel all I've accomplished is trying to shield Barry from having to deal with list logistics and the like, and the project needs more than that.... I think its safe to say that it's not lack of interest or intent here with any of us, but a lack of free time. And time, of course is one commodity you can't do much about some times. From fehwalker at gmail.com Wed Feb 16 21:39:26 2005 From: fehwalker at gmail.com (Bryan Fullerton) Date: Wed Feb 16 21:39:30 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <09add6aaaba04365c519f6c8ce72d346@plaidworks.com> References: <20050216152850.EEB2D1E4012@bag.python.org> <42137122.6040906@equinephotoart.com> <09add6aaaba04365c519f6c8ce72d346@plaidworks.com> Message-ID: <35de0c30050216123919c0af61@mail.gmail.com> On Wed, 16 Feb 2005 10:32:58 -0800, Chuq Von Rospach wrote: [snip] > I think its safe to say that it's not lack of interest or intent here > with any of us, but a lack of free time. And time, of course is one > commodity you can't do much about some times. Ditto. My daughter just turned two; between new family and the day job and my own business, I'm looking at a decision between sleep or participating with the project (or any other OSS project). :/ Bryan From harald.meland at usit.uio.no Thu Feb 17 02:09:52 2005 From: harald.meland at usit.uio.no (Harald Meland) Date: Thu Feb 17 02:09:57 2005 Subject: [Mailman-Developers] [Fwd: Fwd: Re: [Mailman-Announce] Critical security update for Mailman 2.1.5 and earlier [origin: mailman-developers-owner@python.org]] In-Reply-To: <1108229143.19019.4.camel@geddy.wooz.org> (Barry Warsaw's message of "Sat, 12 Feb 2005 12:25:43 -0500") References: <1108229143.19019.4.camel@geddy.wooz.org> Message-ID: > From: Axel Beckert > Subject: Re: [Mailman-Announce] Critical security update for Mailman 2.1.5 > and earlier > To: mailman-developers@python.org > > I just want to share my experiences with the patch: > > Am Thu, Feb 10, 2005 at 09:41:05AM -0500, Barry Warsaw schrieb: >> There is a critical security flaw in Mailman 2.1.5 and earlier Mailman >> 2.1 versions > > As I noticed, 2.0.x versions (at least 2.0.13) are vulnerable, too. I suspect that even 1.x versions of Mailman are vulnerable. > Is there any patch which complies with Python 1 syntax? I think something like this should work, slightly tested using Python 1.5.2. ------------------------------------------------------------------------ SLASH = '/' def true_path(path): "Ensure that the path is safe by removing .." parts = string.split(path, SLASH) safe = filter(lambda x: x not in ('.', '..'), parts) if parts <> safe: # No easy "syslog()" function is necessarily available in # early Mailman versions. # # syslog('mischief', 'Directory traversal attack thwarted') pass return string.join(safe, SLASH)[1:] ------------------------------------------------------------------------ -- Harald From tkikuchi at is.kochi-u.ac.jp Thu Feb 17 14:47:15 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu Feb 17 14:47:26 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] How to get the sender id when the list is set to annoymous mode In-Reply-To: References: <20050215110654.94698.qmail@web14127.mail.yahoo.com> Message-ID: <4214A063.8070501@is.kochi-u.ac.jp> Hi, Brad Knowles wrote: > At 3:06 AM -0800 2005-02-15, vijayan p wrote: > >> I would like to know if as a administrator, is there a >> way i can get the senders email id for the messages >> posted. > > > If you have access to the server logs, you can track them by > message-id. It should be easy to track the original poster of anonymous list, so I added a function to log anonymizing action in post log. Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Thu Feb 17 14:47:20 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu Feb 17 14:47:37 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] from field with real name In-Reply-To: References: Message-ID: <4214A068.4000003@is.kochi-u.ac.jp> Hi, Mark Sapiro wrote: > Stefan Hofmeir wrote: > >>the sender (from field) of a newsletter list should be the address of >>the list (anonymous_list = yes). >> >>previous from field (of the test list "mailman"): >>From: mailman@testdomain.de >> >>How it is possible to sent also a real name like >>From: "list ABC " in every newsletter? > > > You have to hack Mailman/Handlers/Cleanse.py to do this. > It sounded like a reasonablly small and nice hack request so I inserted a few steps of code in Cleanse.py. I used internal_name instead of real_name though. It was checked in CVS and will be in 2.1.6 soon. Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From tkikuchi at is.kochi-u.ac.jp Thu Feb 17 15:33:56 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu Feb 17 15:34:26 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <20050216152850.EEB2D1E4012@bag.python.org> References: <20050216152850.EEB2D1E4012@bag.python.org> Message-ID: <4214AB54.3020503@is.kochi-u.ac.jp> Hi, Sorry I'm responding late. We had presentations of master theses and I had to look after 3 out of 8 students for qualification. Moreover, 2 students are Chinese and difficulty in expressing themselves in Japanese. (Like myself in English :-( ) Adrian Bye wrote: > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=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. I looked through your code and my feeling is not integrating this patch in 2.1.6. The Decorate.py file was considerably patched in CVS by myself and it will take time to adjust the submitted 2.1.5 patch. Also, there are some functions copied from other sources not importing nor inheriting. And, if you write code for immediate integration in the CVS, you should read http://barry.warsaw.us/software/STYLEGUIDE.txt and PEP 8, or at least read the existing code and learn the style. > > 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. > I think the patch should be available in the SF tracker and tested by users who want the functionality. Number of unofficial patches are living like this. It took two years for my first patch (subject prefix numbering) to be integrated in the CVS. ;-) -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From barry at python.org Thu Feb 17 18:15:44 2005 From: barry at python.org (Barry Warsaw) Date: Thu Feb 17 18:15:52 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <4214AB54.3020503@is.kochi-u.ac.jp> References: <20050216152850.EEB2D1E4012@bag.python.org> <4214AB54.3020503@is.kochi-u.ac.jp> Message-ID: <1108660543.10069.21.camel@geddy.wooz.org> On Thu, 2005-02-17 at 09:33, Tokio Kikuchi wrote: > I looked through your code and my feeling is not integrating this patch > in 2.1.6. We need to put a freeze on new features for 2.1.6. In fact, I think we should freeze all checkins except show-stopping bug fixes. I'd like to take between now and the end of February for testing. I'll spin a beta4 today and upload it to SF. In the future, Tokio will also be able to do SF file releases (although unfortunately, he won't be able to update the web sites). I plan on installing the current 2.1.6 on my various sites and I hope others can do the same thing to help test 2.1.6 in order to get an end-of-February release. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050217/a8249fcb/attachment.pgp From barry at python.org Thu Feb 17 18:19:44 2005 From: barry at python.org (Barry Warsaw) Date: Thu Feb 17 18:19:49 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <1108660543.10069.21.camel@geddy.wooz.org> References: <20050216152850.EEB2D1E4012@bag.python.org> <4214AB54.3020503@is.kochi-u.ac.jp> <1108660543.10069.21.camel@geddy.wooz.org> Message-ID: <1108660784.10045.23.camel@geddy.wooz.org> On Thu, 2005-02-17 at 12:15, Barry Warsaw wrote: > We need to put a freeze on new features for 2.1.6. In fact, I think we > should freeze all checkins except show-stopping bug fixes. I'd like to > take between now and the end of February for testing. Oh yes, and for all i18n champions to finish updating their translations for this release! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050217/91838e85/attachment.pgp From fehwalker at gmail.com Thu Feb 17 18:50:58 2005 From: fehwalker at gmail.com (Bryan Fullerton) Date: Thu Feb 17 18:51:01 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <1108660543.10069.21.camel@geddy.wooz.org> References: <20050216152850.EEB2D1E4012@bag.python.org> <4214AB54.3020503@is.kochi-u.ac.jp> <1108660543.10069.21.camel@geddy.wooz.org> Message-ID: <35de0c3005021709506e8d4396@mail.gmail.com> On Thu, 17 Feb 2005 12:15:44 -0500, Barry Warsaw wrote: [snip] > I plan on installing the current 2.1.6 > on my various sites and I hope others can do the same thing to help test > 2.1.6 in order to get an end-of-February release. I'm willing to install the pending beta 4 if it's feature-frozen and there are no significant known bugs (unknown bugs are OK ;). The feature shift between betas has been a little disconcerting. Bryan From adrian at tasdevil.com Thu Feb 17 19:22:55 2005 From: adrian at tasdevil.com (Adrian Bye) Date: Thu Feb 17 19:23:02 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers]Hashing member passwords in config.pck) In-Reply-To: <1108660543.10069.21.camel@geddy.wooz.org> Message-ID: <20050217182300.A9B4B1E4005@bag.python.org> > We need to put a freeze on new features for 2.1.6. In fact, > I think we should freeze all checkins except show-stopping > bug fixes. I'd like to take between now and the end of > February for testing. And, I just talked with my developer, and he got quite upset about the idea of fixing his code to conform to your coding style. So I guess that won't be possible for now. I certainly understand why you have coding guidelines, I agree they are important. I would have happily paid my developer to bring his code in line with your standards. I'm disappointed; we put quite a lot of work in to get this working right, and the work we've done fits very smoothly into the our mailman installation (from an administrator perspective). I've updated the wiki page here: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.039.htp Hopefully someone in the future can see what we've done and implement this properly for everyone to use. Adrian From barry at python.org Thu Feb 17 19:46:19 2005 From: barry at python.org (Barry Warsaw) Date: Thu Feb 17 19:46:25 2005 Subject: [Mailman-Developers] Mailman 2.1.6b4 Message-ID: <1108665979.10068.29.camel@geddy.wooz.org> Okay, I've pushed the 2.1.6b4 tarball out to SourceForge (now that file uploads are working again ;). I will likely be off-line until Tuesday. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050217/73eee107/attachment.pgp From barry at python.org Thu Feb 17 19:55:18 2005 From: barry at python.org (Barry Warsaw) Date: Thu Feb 17 19:55:23 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers]Hashing member passwords in config.pck) In-Reply-To: <20050217182300.A9B4B1E4005@bag.python.org> References: <20050217182300.A9B4B1E4005@bag.python.org> Message-ID: <1108666518.10068.37.camel@geddy.wooz.org> On Thu, 2005-02-17 at 13:22, Adrian Bye wrote: > And, I just talked with my developer, and he got quite upset about the idea of > fixing his code to conform to your coding style. So I guess that won't be > possible for now. I certainly understand why you have coding guidelines, I > agree they are important. I would have happily paid my developer to bring his > code in line with your standards. Sorry, but that's non-negotiable. I know that you understand, but for the record, I'm not just stroking my ego. Coding standards are critical for long term maintenance. Without a standard, the readability of the code goes to hell and code is read orders of magnitude more often than it's written. Adhering to the guidelines (hobgoblins notwithstanding) is our responsibility to those that come after us. It's unfortunate that your developer can't adapt to the Mailman coding style. I work on tons of open source software, and of course lots of software at my job, and each project has its own coding guidelines. "When in Rome..." is the operative phrase here. Hopefully someone else will adapt the code to the style guide. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050217/c0973299/attachment.pgp From maat at vilarem.net Thu Feb 17 19:59:05 2005 From: maat at vilarem.net (Maat) Date: Thu Feb 17 19:59:09 2005 Subject: [Mailman-Developers] new on list. Message-ID: <4214E979.4010200@vilarem.net> hi all, I'm new on this list. hope i will be able to help (little and very humble patches). first i'm wondering : the cvs tree @sourceforge seems to be out of date... have i smoked something too stong for me or am i right ? if i'm right where is the true tree please ? grtx Pascal -- Pascal Vilarem "Alterius non sit qui suus esse potest" From barry at python.org Thu Feb 17 20:41:07 2005 From: barry at python.org (Barry Warsaw) Date: Thu Feb 17 20:41:11 2005 Subject: [Mailman-Developers] new on list. In-Reply-To: <4214E979.4010200@vilarem.net> References: <4214E979.4010200@vilarem.net> Message-ID: <1108669267.10056.46.camel@geddy.wooz.org> On Thu, 2005-02-17 at 13:59, Maat wrote: > first i'm wondering : the cvs tree @sourceforge seems to be out of > date... have i smoked something too stong for me or am i right ? The CVS tree on SF is the canonical tree, but remember that you want to work on the Release_2_1-maint branch, which is where MM2.1.x is released from. The trunk is what may someday be Mailman 2.2, but it is terribly bitrotted right now. Tokio has threatened to merge the branch back into the trunk, in preparation for a possible 2.2 release, but right now, you should consider the trunk unusable. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050217/23102a20/attachment.pgp From bob at nleaudio.com Thu Feb 17 20:54:02 2005 From: bob at nleaudio.com (Bob Puff@NLE) Date: Thu Feb 17 21:01:38 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers]Hashing member passwords in config.pck) In-Reply-To: <1108666518.10068.37.camel@geddy.wooz.org> References: <20050217182300.A9B4B1E4005@bag.python.org> <1108666518.10068.37.camel@geddy.wooz.org> Message-ID: <4214F65A.2060800@nleaudio.com> Perhaps I missed this thread, but what standards are there? Link to doc? Barry Warsaw wrote: > On Thu, 2005-02-17 at 13:22, Adrian Bye wrote: > > >>And, I just talked with my developer, and he got quite upset about the idea of >>fixing his code to conform to your coding style. So I guess that won't be >>possible for now. I certainly understand why you have coding guidelines, I >>agree they are important. I would have happily paid my developer to bring his >>code in line with your standards. > > > Sorry, but that's non-negotiable. I know that you understand, but for > the record, I'm not just stroking my ego. Coding standards are critical > for long term maintenance. Without a standard, the readability of the > code goes to hell and code is read orders of magnitude more often than > it's written. Adhering to the guidelines (hobgoblins notwithstanding) > is our responsibility to those that come after us. > > It's unfortunate that your developer can't adapt to the Mailman coding > style. I work on tons of open source software, and of course lots of > software at my job, and each project has its own coding guidelines. > "When in Rome..." is the operative phrase here. > > Hopefully someone else will adapt the code to the style guide. > > -Barry > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/bob%40nleaudio.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp From barry at python.org Thu Feb 17 22:09:21 2005 From: barry at python.org (Barry Warsaw) Date: Thu Feb 17 22:09:24 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers]Hashing member passwords in config.pck) In-Reply-To: <4214F65A.2060800@nleaudio.com> References: <20050217182300.A9B4B1E4005@bag.python.org> <1108666518.10068.37.camel@geddy.wooz.org> <4214F65A.2060800@nleaudio.com> Message-ID: <1108674561.14022.3.camel@presto.wooz.org> On Thu, 2005-02-17 at 14:54, Bob Puff@NLE wrote: > Perhaps I missed this thread, but what standards are there? Link to doc? http://barry.warsaw.us/software/STYLEGUIDE.txt -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050217/4f7e8a82/attachment.pgp From tobias at kabissa.org Thu Feb 17 19:08:01 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Thu Feb 17 22:11:09 2005 Subject: making Mailman CAN-SPAM compliant (was Re:[Mailman-Developers] Hashing member passwords in config.pck) In-Reply-To: <4214AB54.3020503@is.kochi-u.ac.jp> References: <20050216152850.EEB2D1E4012@bag.python.org> <4214AB54.3020503@is.kochi-u.ac.jp> Message-ID: Dear friends, I had *no idea* my post was going to generate this level of response. Thank you all. I'm simply fascinated by the dynamics in the group, inspired by your generosity, and eager to help out in any way I can. Let me make a few brief points, then forward another message I just sent to another list which is inspired by this discussion and by a number of other ongoing threads that seem to be coming together right now and make for what I think is a tremendous opportunity for those of us interested in this yahoogroups type functionality. 1) I am not a coder. I am very into open source software, though, and have been for a long time. I have installed many open source tools on the Kabissa server over the years which are used very actively by people in Africa working for nonprofits. This includes Mailman, phpbb, horde and more. I am able to hack around in existing scripts and follow instructions to do limited customization. I've had Mailman running on Kabissa for over four years now, and have many thousands of posts in list archives and tens of thousands of subscribers participating in lists hosted on Kabissa. 2) I am currently dedicated to taking all of these disparate tools that people are making great use of on Kabissa, and integrating them into a single community Web site so that they can use them better. I am therefore interested in Mambo CMS (http://www.mamboserver.com) and am eager to encourage any efforts that will enable me to take existing Kabissa services (like Mailman) and integrate them into Mambo components (existing or new). 3) This is the background to my post about making Mailman CAN-SPAM compliant. It helps to know that there are developers interested in addressing usability issues and also to have confirmed that there is a general understanding that Mailman can be improved. 4) As Brad mentioned, he is now volunteering at Kabissa on mailman administration.. which is great! With his involvement, there are some small contributions Kabissa can make as relates to helping others to make Mailman work well in a plesk/qmail setup like ours, and which I'd like to see incorporated in future versions of Plesk. However, I think Kabissa may be able to help more by drumming up interest in Mailman, by partnering with other likeminded organizations seeking the same functionality like Bellanet, and perhaps by raising funds to pay for the development of some key features that Kabissa needs particularly urgently. Best wishes, Tobias On Feb 17, 2005, at 9:33 AM, Tokio Kikuchi wrote: > Hi, > > Sorry I'm responding late. We had presentations of master theses and I > had to look after 3 out of 8 students for qualification. Moreover, 2 > students are Chinese and difficulty in expressing themselves in > Japanese. (Like myself in English :-( ) > > Adrian Bye wrote: > >> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=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. > > I looked through your code and my feeling is not integrating this > patch in 2.1.6. The Decorate.py file was considerably patched in CVS > by myself and it will take time to adjust the submitted 2.1.5 patch. > Also, there are some functions copied from other sources not importing > nor inheriting. And, if you write code for immediate integration in > the CVS, you should read > http://barry.warsaw.us/software/STYLEGUIDE.txt and PEP 8, or at least > read the existing code and learn the style. > >> 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. > > I think the patch should be available in the SF tracker and tested by > users who want the functionality. Number of unofficial patches are > living like this. It took two years for my first patch (subject prefix > numbering) to be integrated in the CVS. ;-) > > -- > Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp > http://weather.is.kochi-u.ac.jp/ > > -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * From brad at stop.mail-abuse.org Thu Feb 17 22:23:20 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Feb 17 22:50:48 2005 Subject: [Mailman-Developers] Re: [Mailman-Users] How to get Sender Id from the Mailing List where the annoymous option is set In-Reply-To: <20050208115729.82951.qmail@web14126.mail.yahoo.com> References: <20050208115729.82951.qmail@web14126.mail.yahoo.com> Message-ID: At 3:57 AM -0800 2005-02-08, vijayan p wrote: > Can anyone tell me how to obtain the statistics of > which member has posted how many messages. I think you'd have to look at the incoming messages in the MTA logs, before they get handed off to Mailman. But keep in mind that Mailman does not have any facility for creating or monitoring statistics, unless you want to create a script to do that. > Also is there a way to know who has posted a > particular mail. Basically the same issue. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From tobias at kabissa.org Thu Feb 17 19:12:40 2005 From: tobias at kabissa.org (Tobias Eigen) Date: Thu Feb 17 23:06:39 2005 Subject: [Mailman-Developers] Fwd: [NOSI discussion] Same planet, different worlds Message-ID: <52e971c20f76a100f517106c09e2da95@kabissa.org> As promised - a message I posted this morning to the Nonprofit Open Source Initiative discussion list (see http://www.nosi.net for details on NOSI). Let me know, perhaps off-list if this discussion is starting to seem a bit off-topic, if you are interested in getting involved in this. Check out http://www.penguinday.org for info about Penguin Day, which is taking place this year a day after the Nonprofit Technology Conference (http://www.nten.org/ntc). I will be at both events and look forward to opportunities to talk to people about Mailman usability and replicating Yahoogroups-like functionality using open source. Best wishes, Tobias -- Tobias Eigen Executive Director Kabissa - Space for Change in Africa http://www.kabissa.org * Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. * Begin forwarded message: > From: Tobias Eigen > Date: February 17, 2005 11:51:45 AM EST > To: nosi-discussion@nosi.net > Subject: Re: [NOSI discussion] Same planet, different worlds > >> On a related note, how many of you will be at NTC next month and the >> associated Penguin Day Chicago on the following Saturday? > > Ah! So that's when it's going to be! I've been waiting for news via > penguinday.org... now I can book my flight! > >> Anyone got something really profound or eye-poppingly cool that you >> want to demo, discuss, or proclaim at PD? > > For Kabissa, I've been tracking and actively participating in lots of > discussions about yahoogroups and replicating the best aspects of it > using open source. I would be really interested in taking advantage of > Penguin Day to raise awareness of the need for this and to generate > momentum to raise funds, find partners and recruit developers to work > on it. > > While alot of great work is being done on open source list managers > and on discussion forums/web collaboration tools, there is not much > progress being made on bringing the two together in an open source > project that can be replicated and made broadly useful by many > organizations. It's happening, but piecemeal and in the meantime it's > a shame to subject ordinary people to Mailman's web interfaces (try > accessing the private archives for the NOSI discussion list and you'll > see what I'm talking about) and to not properly take advantage of the > dynamic and empowering effect of connecting people through their > mailboxes as well as through a beautiful community Web site. For > Kabissa it's incredibly important because the people in Africa we > serve pay dearly for their Internet connection and we want to empower > them to make the most of their limited time oline. > > Now there seems to be a particularly grand opportunity because a bunch > of things are coming together at the same time: > > 1) Mambo was awarded a Product Excellence Award at LinuxWorld this > week (http://www.mamboserver.com) - one of the things that makes Mambo > excellent is that it can be easily extended using optional components, > and it's easy to create and share components > 2) Opendgroups is being developed to share the functionality of the > already successful dgroups.org service using open source (see > http://www.opendgroups.net). One of the models being considered is a > Mailman/Drupal integration. > 3) Mailman developers are recognizing the need for making its web > interfaces more usable (see > http://www.mail-archive.com/mailman-developers%40python.org/ > msg08628.html and subsequent onslaught of messages). > 4) Mail2forum, a phpbb add-on that provides bidirectional email/list > support, is now at v1.0 RC2. (http://www.mail2forum.com) - m2f > developers claim it can be easily ported to other forums and welcome a > project team to port it to another forum that integrates better with > Mambo (see http://www.mail2forum.com/forums/viewtopic.php?t=796). > 5) Alot of reputable, open source friendly web developers are using > Mambo - i.e. Sangonet in South Africa (http://www.sn.apc.org) and > Picnet (http://www.picnet.net - also will be at NTC). Picnet is > interested in developing a CAN-SPAM act compliant Mambo newsletter > component (http://www.picnet.net). This could complement an integrated > forum component nicely and share code with it to interact with a list > manager like Mailman. > 6) Kabissa's interest in all of this is that we want to deepen the > impact of our programs by integrating and improving our existing > online offerings through the development of a new integrated Web site. > We have 850 member organizations throughout Africa that are seeking to > make better use of ICT for the benefit of their communities, and many > of them are hosting their Web sites and domain names on Kabissa, > participating in our Time To Get Online training program, and finding > each other online through our member contact directory, bulletin board > and mailing lists. Having bidirectional functionality for newsletters > and discussion groups integrated into our site will really help us to > deliver on our promise to the African civil society sector. This user > group also provides a great source of willing volunteers for pilot > testing. > 7) Kabissa is also involved in developing a community Web site for the > Africa Democracy Forum (http://www.africademocracyforum) which > currently interacts primarily through a Yahoo Group and face-to-face > meetings. We are planning to work with the ADF to move their Yahoo > Group to a Mambo-integrated forum, where we can then do alot more to > help ADF members to interact online, discuss key topics and share > information about opportunities. One of the key requirements for the > forum is to have bidirectional email support, in part also to ease the > pain of migrating from yahoogroups. > > Sorry for the lengthy list - I'm throwing this out there for > discussion. I'm sure I and others on this list could come up with even > more ideas. :-) If we could bring together a group at Penguin Day to > discuss some of these different pieces of the puzzle perhaps we could > come up with a collaborative plan for producing a very useful and > broadly replicable open source product. > > Cheers, > > Tobias From dan.mick at sun.com Fri Feb 18 06:07:39 2005 From: dan.mick at sun.com (Dan Mick) Date: Fri Feb 18 06:07:44 2005 Subject: [Mailman-Developers] SMTPDeliver.py still can't do MTA VERP? Message-ID: <4215781B.4070604@sun.com> a long long *long* time ago now, I made a small hack to SMTPDeliver.py to add options to the sendmail connection EHLO, to enable VERP generation in the MTA (so that the sending system didn't have to send N messages to the MTA to accomplish VERP, but rather let the MTA deal with it). For Postfix, this is as simple as adding the XVERP option. I still don't see any facility for doing this in a generic way; has anyone addressed the problem, and if so can someone point me at the solution?.. From pabs at cat.org.au Sat Feb 19 09:41:50 2005 From: pabs at cat.org.au (pabs) Date: Sat Feb 19 09:41:32 2005 Subject: [Mailman-Developers] bin/update slowness fix Message-ID: <1108802510.6587.18.camel@localhost> Hi mailman devs, listworkers, We recently upgraded lists.indymedia.org from version 2.1.4 to 2.1.5[0]. We soon found that update_pending in the update script was a little slow [1] (taking a couple of minutes to complete each list, for a total of 22 hours or so - we have > 1000 lists). Long story short, here[2] is a patch that we used to speed that up to 0-2 seconds per list (against mm 2.1.6b3). It isn't exactly correct, because I wasn't able to work out how to call private members of MailList subclasses quickly and the priority was just to get the upgrade done, but it does work. I really think that either it, or a properly done patch (with no code duplication) should go into the upcoming release of 2.1.6. 0. This was debian 2.1.4-5 to 2.1.5-6 btw. 1. A quote from the script: # This is not the most efficient way to do this because it loads and # saves the pending.pck file each time. :( 2. http://sf.net/tracker/?func=detail&aid=1124510&group_id=103&atid=300103 PS: We've some other patches too that may or may not be useful, please visit http://lists.indymedia.org/patches/index.en.html and let us know if you would like us to update them for 2.1.7/2.2 (and non-debian). -- bye, pabs http://docs.indymedia.org/view/Main/PaulWise -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050219/f1781432/attachment.pgp From dig.list at nm.ru Sat Feb 19 10:42:07 2005 From: dig.list at nm.ru (DIG) Date: Sat Feb 19 10:42:17 2005 Subject: [Mailman-Developers] withlist and RFC 2606 Message-ID: <20050219094207.GA23622@phenix.rootshell.be> Hi, mailman-dev! Shouldn't the host name in the example be made compliant with the RFC 2606 (Reserved Top Level DNS Names)? ,--[ cvs diff ]-- | Index: withlist | =================================================================== | RCS file: /cvsroot/mailman/mailman/bin/withlist,v | retrieving revision 2.11 | diff -u -r2.11 withlist | --- withlist 17 Apr 2003 03:52:08 -0000 2.11 | +++ withlist 19 Feb 2005 09:26:56 -0000 | @@ -115,7 +115,7 @@ | print 'No address matched:', addr | | and run this from the command line: | -%% bin/withlist -l -r changepw mylist somebody@somewhere.org foobar | +%% bin/withlist -l -r changepw mylist name@example.org foobar | """ | | import sys `--[ ]-- Best regards, -- DIG (Dmitri I GOULIAEV) 1024D/63A6C649: 26A0 E4D5 AB3F C2D4 0112 66CD 4343 C0AF 63A6 C649 From pabs at cat.org.au Fri Feb 25 04:03:34 2005 From: pabs at cat.org.au (pabs) Date: Fri Feb 25 04:04:36 2005 Subject: [Mailman-Developers] ping Message-ID: <1109300614.13124.11.camel@localhost> Hi, Is this list broken, or has everyone left? -- bye, pabs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050225/865d8f73/attachment.pgp From claw at kanga.nu Fri Feb 25 08:49:20 2005 From: claw at kanga.nu (J C Lawrence) Date: Fri Feb 25 08:49:38 2005 Subject: [Mailman-Developers] ping In-Reply-To: Message from pabs of "Fri, 25 Feb 2005 11:03:34 +0800." <1109300614.13124.11.camel@localhost> References: <1109300614.13124.11.camel@localhost> Message-ID: <6971.1109317760@kanga.nu> On Fri, 25 Feb 2005 11:03:34 +0800 pabs wrote: > Is this list broken, or has everyone left? Wha? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From harald.meland at usit.uio.no Fri Feb 25 09:02:38 2005 From: harald.meland at usit.uio.no (Harald Meland) Date: Fri Feb 25 09:02:45 2005 Subject: [Mailman-Developers] ping In-Reply-To: <1109300614.13124.11.camel@localhost> (pabs@cat.org.au's message of "Fri, 25 Feb 2005 11:03:34 +0800") References: <1109300614.13124.11.camel@localhost> Message-ID: [pabs] > Hi, > > Is this list broken, or has everyone left? The list seems to work, so I guess it's just a case of everyone being silent for a few days... -- Harald From dan.mick at sun.com Fri Feb 25 09:46:25 2005 From: dan.mick at sun.com (Dan Mick) Date: Fri Feb 25 09:46:30 2005 Subject: [Mailman-Developers] SMTPDeliver.py still can't do MTA VERP? In-Reply-To: <4215781B.4070604@sun.com> References: <4215781B.4070604@sun.com> Message-ID: <421EE5E1.9020504@sun.com> Dan Mick wrote: > a long long *long* time ago now, I made a small hack to SMTPDeliver.py > to add options to the sendmail connection EHLO, to enable VERP > generation in the MTA (so that the sending system didn't have to send N > messages to the MTA to accomplish VERP, but rather let the MTA deal with > it). For Postfix, this is as simple as adding the XVERP option. > > I still don't see any facility for doing this in a generic way; has > anyone addressed the problem, and if so can someone point me at the > solution?.. nobody knows? nobody cares? both? From barry at python.org Fri Feb 25 14:03:51 2005 From: barry at python.org (Barry Warsaw) Date: Fri Feb 25 14:03:56 2005 Subject: [Mailman-Developers] SMTPDeliver.py still can't do MTA VERP? In-Reply-To: <4215781B.4070604@sun.com> References: <4215781B.4070604@sun.com> Message-ID: <1109336631.9667.32.camel@geddy.wooz.org> On Fri, 2005-02-18 at 00:07, Dan Mick wrote: > a long long *long* time ago now, I made a small hack to SMTPDeliver.py > to add options to the sendmail connection EHLO, to enable VERP > generation in the MTA (so that the sending system didn't have to send N > messages to the MTA to accomplish VERP, but rather let the MTA deal with > it). For Postfix, this is as simple as adding the XVERP option. > > I still don't see any facility for doing this in a generic way; has > anyone addressed the problem, and if so can someone point me at the > solution?.. There's this: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=731100&group_id=103 but I haven't looked at the details of it. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050225/788ff44a/attachment.pgp From bob at nleaudio.com Fri Feb 25 16:28:35 2005 From: bob at nleaudio.com (Bob Puff) Date: Fri Feb 25 16:28:40 2005 Subject: [Mailman-Developers] SMTPDeliver.py still can't do MTA VERP? In-Reply-To: <421EE5E1.9020504@sun.com> References: <4215781B.4070604@sun.com> <421EE5E1.9020504@sun.com> Message-ID: <20050225152813.M83635@nleaudio.com> I would love to see something like that - letting Postfix do the VERPing for you. Bob ---------- Original Message ----------- From: Dan Mick To: Dan Mick Cc: mailman-developers@python.org Sent: Fri, 25 Feb 2005 00:46:25 -0800 Subject: Re: [Mailman-Developers] SMTPDeliver.py still can't do MTA VERP? > Dan Mick wrote: > > a long long *long* time ago now, I made a small hack to SMTPDeliver.py > > to add options to the sendmail connection EHLO, to enable VERP > > generation in the MTA (so that the sending system didn't have to send N > > messages to the MTA to accomplish VERP, but rather let the MTA deal with > > it). For Postfix, this is as simple as adding the XVERP option. > > > > I still don't see any facility for doing this in a generic way; has > > anyone addressed the problem, and if so can someone point me at the > > solution?.. > > nobody knows? nobody cares? both? > _______________________________________________ > 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/bob%40nleaudio.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp ------- End of Original Message ------- From fehwalker at gmail.com Fri Feb 25 17:38:41 2005 From: fehwalker at gmail.com (Bryan Fullerton) Date: Fri Feb 25 17:38:44 2005 Subject: [Mailman-Developers] ping In-Reply-To: <1109300614.13124.11.camel@localhost> References: <1109300614.13124.11.camel@localhost> Message-ID: <35de0c30050225083842984c6@mail.gmail.com> On Fri, 25 Feb 2005 11:03:34 +0800, pabs wrote: > Is this list broken, or has everyone left? Everyone's waiting expectantly for 2.1.6 to come out. I expect there'll be a bunch of posts of various types once that happens. :) Bryan From darrell at grumblesmurf.net Fri Feb 25 23:14:16 2005 From: darrell at grumblesmurf.net (Darrell Fuhriman) Date: Fri Feb 25 23:14:22 2005 Subject: [Mailman-Developers] SMTPDeliver.py still can't do MTA VERP? In-Reply-To: <1109336631.9667.32.camel@geddy.wooz.org> (Barry Warsaw's message of "Fri, 25 Feb 2005 08:03:51 -0500") References: <4215781B.4070604@sun.com> <1109336631.9667.32.camel@geddy.wooz.org> Message-ID: Barry Warsaw writes: > https://sourceforge.net/tracker/?func=detail&atid=300103&aid=731100&group_id=103 > > but I haven't looked at the details of it. I've been using that patch for months (I used it replace a patch of my own that did basically the same thing, but in a sightly less generic way.) In short, if you have mm_cfg.VERP_STYLE=Postfix defined, it will pass the ESMTP argument XVERP=+= to the RCPT command, then postfix will take care of it. I believe it also work on EXIM, though I don't have it here to try. If it does, then i would suggest changing to option name to something more generic applying the patch. Darrell From dan.mick at sun.com Sat Feb 26 03:55:53 2005 From: dan.mick at sun.com (Dan Mick) Date: Sat Feb 26 03:55:57 2005 Subject: [Mailman-Developers] SMTPDeliver.py still can't do MTA VERP? In-Reply-To: <1109336631.9667.32.camel@geddy.wooz.org> References: <4215781B.4070604@sun.com> <1109336631.9667.32.camel@geddy.wooz.org> Message-ID: <421FE539.9060002@sun.com> Barry Warsaw wrote: > On Fri, 2005-02-18 at 00:07, Dan Mick wrote: > >>a long long *long* time ago now, I made a small hack to SMTPDeliver.py >>to add options to the sendmail connection EHLO, to enable VERP >>generation in the MTA (so that the sending system didn't have to send N >>messages to the MTA to accomplish VERP, but rather let the MTA deal with >>it). For Postfix, this is as simple as adding the XVERP option. >> >>I still don't see any facility for doing this in a generic way; has >>anyone addressed the problem, and if so can someone point me at the >>solution?.. > > > There's this: > > https://sourceforge.net/tracker/?func=detail&atid=300103&aid=731100&group_id=103 > > but I haven't looked at the details of it. > -Barry > Yup, that's essentially what I did (except slightly nicer as it's configurable in mm_cfg.py). Any chance of getting this into A Mailman Near You? From tkikuchi at is.kochi-u.ac.jp Sat Feb 26 04:13:13 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat Feb 26 04:13:20 2005 Subject: [Mailman-Developers] SMTPDeliver.py still can't do MTA VERP? In-Reply-To: <421FE539.9060002@sun.com> References: <4215781B.4070604@sun.com> <1109336631.9667.32.camel@geddy.wooz.org> <421FE539.9060002@sun.com> Message-ID: <421FE949.30600@is.kochi-u.ac.jp> Hi, Dan Mick wrote: > Barry Warsaw wrote: > >> On Fri, 2005-02-18 at 00:07, Dan Mick wrote: >> >>> a long long *long* time ago now, I made a small hack to >>> SMTPDeliver.py to add options to the sendmail connection EHLO, to >>> enable VERP generation in the MTA (so that the sending system didn't >>> have to send N messages to the MTA to accomplish VERP, but rather let >>> the MTA deal with it). For Postfix, this is as simple as adding the >>> XVERP option. >>> >>> I still don't see any facility for doing this in a generic way; has >>> anyone addressed the problem, and if so can someone point me at the >>> solution?.. >> >> >> >> There's this: >> >> https://sourceforge.net/tracker/?func=detail&atid=300103&aid=731100&group_id=103 >> >> >> but I haven't looked at the details of it. >> -Barry >> > > Yup, that's essentially what I did (except slightly nicer as it's > configurable in mm_cfg.py). > > Any chance of getting this into A Mailman Near You? > I think I can integrate it into 2.2 which I am going to work on after the 2.1.6 release which is now in final stage. Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From Nigel.Metheringham at dev.intechnology.co.uk Sun Feb 27 16:30:20 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Sun Feb 27 16:30:24 2005 Subject: [Mailman-Developers] SMTPDeliver.py still can't do MTA VERP? In-Reply-To: References: <4215781B.4070604@sun.com> <1109336631.9667.32.camel@geddy.wooz.org> Message-ID: <1109518220.5676.37.camel@angua.localnet> On Fri, 2005-02-25 at 14:14 -0800, Darrell Fuhriman wrote: > In short, if you have mm_cfg.VERP_STYLE=Postfix defined, it will > pass the ESMTP argument XVERP=+= to the RCPT command, then > postfix will take care of it. > > I believe it also work on EXIM, though I don't have it here to > try. If it does, then i would suggest changing to option name to > something more generic applying the patch. Exim does not do XVERP However MTA side VERPing is easy to do in Exim - see the Mailman HOWTO on the exim site http://www.exim.org/howto/mailman21.html Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From Preston_Wade at hilton.com Mon Feb 28 02:46:55 2005 From: Preston_Wade at hilton.com (Preston Wade) Date: Mon Feb 28 02:47:14 2005 Subject: [Mailman-Developers] High Availability Message-ID: <2AD11ACF7FB44945B30ED14ACA672B56169FB8@cmxsmbx1.hq.ad.hilton.com> Hello, I read some old post back in 2002 on this list about Load balancing. In my scenario I don't have near the volume to warrant load balancing but I am interested in fail over capabilities. Would it cause Mailman any heartburn if I simply wrote an rsync script to keep the trees in sync? And then use the heartbeat package to do automatic fail over. I realize depending on my sync cycle I will potentially loose some data. Is there a better alternative to this? Also I saw there are plans to move to a user store were users would have one password for all list. Have there been any considerations for LDAP as that user store? Thanks, Preston From jdennis at redhat.com Mon Feb 28 16:34:49 2005 From: jdennis at redhat.com (John Dennis) Date: Mon Feb 28 16:34:58 2005 Subject: [Mailman-Developers] when is "driver" script invoked? Message-ID: <1109604889.5396.7.camel@finch.boston.redhat.com> In the scripts subdirectory is a file called "driver", the comments at the top of the file say its used to run CGI scripts. In a standard 2.1.5 installation I don't see anything that actually invokes "driver", but perhaps I've overlooked something. When is driver invoked? Is it only for optional third party cgi scripts? -- John Dennis From msapiro at value.net Mon Feb 28 17:14:42 2005 From: msapiro at value.net (Mark Sapiro) Date: Mon Feb 28 17:14:59 2005 Subject: [Mailman-Developers] when is "driver" script invoked? In-Reply-To: <1109604889.5396.7.camel@finch.boston.redhat.com> Message-ID: John Dennis wrote: >In the scripts subdirectory is a file called "driver", the comments at >the top of the file say its used to run CGI scripts. In a standard 2.1.5 >installation I don't see anything that actually invokes "driver", but >perhaps I've overlooked something. When is driver invoked? Is it only >for optional third party cgi scripts? "driver" is invoked directly by the wrappers in cgi-bin. See src/cgi-wrapper.c -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Mon Feb 28 17:42:39 2005 From: barry at python.org (Barry Warsaw) Date: Mon Feb 28 17:42:45 2005 Subject: [Mailman-Developers] when is "driver" script invoked? In-Reply-To: <1109604889.5396.7.camel@finch.boston.redhat.com> References: <1109604889.5396.7.camel@finch.boston.redhat.com> Message-ID: <1109608959.28418.10.camel@geddy.wooz.org> On Mon, 2005-02-28 at 10:34, John Dennis wrote: > In the scripts subdirectory is a file called "driver", the comments at > the top of the file say its used to run CGI scripts. In a standard 2.1.5 > installation I don't see anything that actually invokes "driver", but > perhaps I've overlooked something. When is driver invoked? Is it only > for optional third party cgi scripts? Look in src/cgi-wrapper.c. This C file is compiled into the actual binaries that live in cgi-bin, and it's used to hop into the CGI Python scripts, via... yep! the driver script. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050228/08f526f5/attachment.pgp From jwblist at olympus.net Mon Feb 28 18:22:48 2005 From: jwblist at olympus.net (John W. Baxter) Date: Mon Feb 28 18:23:02 2005 Subject: [Mailman-Developers] High Availability In-Reply-To: <2AD11ACF7FB44945B30ED14ACA672B56169FB8@cmxsmbx1.hq.ad.hilton.com> Message-ID: On 2/27/2005 17:46, "Preston Wade" wrote: > Hello, > > I read some old post back in 2002 on this list about Load balancing. In my > scenario I don't have near the volume to warrant load balancing but I am > interested in fail over capabilities. Would it cause Mailman any heartburn if > I simply wrote an rsync script to keep the trees in sync? We do this. It seems to be successful. > And then use the > heartbeat package to do automatic fail over. I realize depending on my sync > cycle I will potentially loose some data. Is there a better alternative to > this? We stopped trying to use heartbeat long ago, when of the first 10 auto-triggered switches, all proved to be false "alarms" by the heartbeat code. (Not just for this purpose.) > > Also I saw there are plans to move to a user store were users would have one > password for all list. Have there been any considerations for LDAP as that > user store? There have...I hope LDAP isn't the only choice when the change happens (we're moving away from LDAP, having become tired of repairing broken LDAP databases). --John From j.e.vanbaal at uvt.nl Mon Feb 28 18:40:22 2005 From: j.e.vanbaal at uvt.nl (Joost van Baal) Date: Mon Feb 28 18:36:47 2005 Subject: [Mailman-Developers] PGP and Mailman Message-ID: <20050228174022.GT6533@banach.uvt.nl> Hi, I will write and publish a patch which integrates PGP signature validation and re-encryption of encrypted posts to mailman. Specs are: - A post will be distributed only if the PGP signature on the post is from one of the list members. - For sending encrypted email, a list member encrypts to the public key of the list. The post will be decrypted and re-encrypted to the public keys of all list members. (Later, the patch will handle RFC 2633 (S/MIME) messages too, next to RFC 2440 (OpenPGP)). I've taken a look at the NAH6 secure list patch #646989 at http://sourceforge.net/tracker/index.php?func=detail&aid=646989&group_id=103&atid=300103 and at Ben Laurie's patch #645297 at http://sourceforge.net/tracker/index.php?func=detail&aid=645297&group_id=103&atid=300103 , but I believe none of these completely implements the listed requirements (although these will help me implementing, of course). I am asking you to take a look at my plan for implementation. Am I on the right track? So, the plan: I think one way to implement it would be to add two modules to GLOBAL_PIPELINE: in front, before SpamDetect, there would be 'PGPCheck'. PGPCheck would check wether the message is encrypted, and, if so, make a temporary decrypted copy in order to verify with which key is was signed. If the message is unencrypted, it would check the signature. It would store this information in new properties of the Mailman Message object. A second new module in GLOBAL_PIPELINE would be 'PGPRecrypt', to be called after CookHeaders' and before 'ToDigest'. This would, if needed, decrypt the message and reencrypt it to all recipients, and would sign it. If for instance a list member erroneously signs a post with a wrong public key, and encrypts the message, this message should be handled carefully. I believe the Hold module should be adapted for this. A copy of the original encrypted message should be kept. The message should be decrypted, signed with the listkey, encrypted to the list moderator key, and sent for acknowledgement. If the moderator chooses to deny the message, the poster should get her original message back. (I guess.) For all PGP handling, I plan to use Frank J. Tobin's GnuPGInterface ( http://py-gnupg.sourceforge.net/ ). I plan to write the patch against current stable Mailman. Any insight to share on this? Thanks! Bye, Joost -- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal@uvt.nl The Netherlands -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20050228/484a0ba1/attachment.pgp