Mailman-Developers February 2008

mailman-developers@python.org

10 participants
9 discussions

by Jennifer Redman

Hello! The Systers (http://anitaborg.org/initiatives/systers/) community uses a modified version of Mailman that extends functionality to include dynamic sublists (a person can chose to unsubscribe to individual conversations if they are not interested, without removing themselves from the main list). The extension has been running well for the last 4+ years, but it's time to sync to the current version of Mailman to remedy some problems with the upgrade path, security concerns, and bugs that have appeared due to bit rot. The original project is located here: http://sourceforge.net/projects/dsub/ Ellen Spertus, the author of the extensions, posted previously many years ago -- around 2002 if you'd like to search for the original threads. My questions for the Mailman Development Community: 1) Is there any interest in helping us bring the code up to date? 2) Is the correct first step to create an unofficial branch and move the project into Launchpad under the auspices of the Mailman project? 3) Has anyone developed something similar in the past few years which provides similar functionality that may be an acceptable alternative? 4) What steps would we need to take to get the extensions included upstream? Thanks for your help! Jennifer

13 years

Mailboxes of various sorts (archive subthread)

by Stephen J. Turnbull

Barry Warsaw writes: > The archives is an entirely different subsystem, and without a > volunteer stepping forward (for which I've been practically begging > for years ;), Are you able and willing to mentor said volunteer? > That's the unfortunate reality, but I do have thoughts about our > archiver situation, which I'll outline at some future date. Yes, please. And sooner rather than later.

13 years

[Bug] 2x decode_header? [was: No subscription is made ...]

by Stephen J. Turnbull

Moving to -developers, reply-to set. Please keep Henrik in the loop. Seems to be the same as http://sourceforge.net/tracker/index.php?func=detail&aid=1186819&group_id=1… Henrik Rasmussen writes: > Stephen J. Turnbull wrote: > > Henrik Rasmussen writes: > > Of course it's possible that the MUA is just inserting those headers > > but it's a lie (the MUA thinks that's enough to let it get away with > > just putting UTF-8 *anywhere*). But note that 0xF8 is illegal in > > UTF-8 (for several reasons), so most likely that is intended as an ISO > > 8-bit character. > > Do you agree that the interpretation of 0xF8 as "ø" is likely here? > > I'm not sure. The mail body contains a signature "Nørregaard" in > the plain text section and "N=C3=B8rregaard" in the HTML section, > but there is no "ø" in the header (and thus nor the e-mail address > of the subscriber). This sounds like a bug in Mailman; if the headers do not contain any characters outside of ASCII, then for some reason Mailman (or the email module that it calls) is trying to decode the headers twice. Can you provide a verbatim copy of the original message? (If privacy is a problem, send it to Mark Sapiro <mark(a)sapiro.net>. Mark is the likely person to actually do any fixing; I know how this stuff works in principle but haven't yet actually hacked the core code.) The whole thing, with no changes at all, please (you never know what matters in these things, even changing the .sig could make the bug go away!) > But even so, the fact that Mailman issued a 'new' command, the user > should have been put on the list (i'm just speculating here, I'm > not that familiar with e-mail handeling and especially not Mailman > nor Python). "Issue" a command and "complete" a command are two different things. I've already archived the earlier posts so I can't evaluate your conjecture offhand.

13 years

Re: [Mailman-Developers] [Mailman-Users] RFC: X-Archive header fields

by Stephen J. Turnbull

Moving to Mailman-Developers per BAW. CC to -Users; Reply-To set to -Developers only. Barry Warsaw writes: > Hi Richard, > > Please see RFC 5064: http://www.ietf.org/rfc/rfc5064.txt Argh. You'd think they'd get in touch with the maintainers and users of the most popular mailing list software before approving it. It doesn't even mention the word "thread". If somebody knows offhand how to find the archived discussions for the RFC, please post an URL. It's hard to imagine these guys didn't already cover a lot of the ground that we'll want to (especially the point that X-Archived-Thread may be a YAGNI). Richard Hartman writes: > I was wondering if anyone would think X-Archive-Thread and > X-Archive-Mail would make sense. A couple of minutes' reflection suggests to me that this distinction may be artificial. Specifically, (1) It's not obvious to me how many such distinctions make sense. For example, User A may wish to jump to head of thread to see the whole thing, while User B may wish to jump to most recent to see if there's been a resolution (or maybe the list is infested with top-posters so reading the most recent in last-line-first mode is the most efficient way to get the whole thread!) Some users may want to see an index, which might be by-date or by-author or by-subject. (2) This URL "works" in the sense that you get the specified document, and the query part is ignored. I don't know if this is an artifact of the server daemon or if it's part of the specification of the query part. http://www.ietf.org/rfc/rfc2822.txt?bogusquery=doesnotmatter (3) In current best practice (heck, even pipermail does it) each message contains "up" pointers to one or more relevant indicies. This means that you're at most three clicks from where you want to be (archive link in current message, thread index, thread-head message). Given those three points, I suggest that a better way to do this is to provide some standard queries *relative to an archived message* that dynamic archive servers can support, while with a static server the user is not very far from where she wants to be in any case. Some additional comments: (1) suggests that "archived thread" is premature in the RFC tradition; there's no practice to support it yet AFAIK. We could support it, but use of URLs with derived queries generated by MUAs is somewhat more flexible (there's no backward compatibility problem with archaic X-Headers).

13 years

Logging lossage

by Stephen J. Turnbull

Moved from mailman-users. Mark Sapiro writes: > If this is the case, there will be 'Message discarded' entries in > Mailman's vette log, but they will only tell you the message was > discarded, not why. I've long thought that this is a design bug. This is one nice thing about SpamAssassin: it tells you which rules were triggered. Is this already improved in 3.0? Would better logging be something to target in 2.2?

13 years

Re: [Mailman-Developers] Fwd: Feedback for mailman developers

by Stephen J. Turnbull

Adrian Bye writes: > I don't know the specifics. I just told the developer to remove > all headers which identified mailman as mailman. Well, could you ask him which they were? It matters. BTW, a look at the patch suggests it's incomplete; I couldn't find any templates for headers and footers, nor documentation for how to generate the 1-click unsubscribe button. > When we did this, mail got into the inbox. We tested this > definitively and the mailman headers was the difference. Sure, but that doesn't necessarily mean that Mailman or Mailman lists have bad reputations per se. The big email providers are known to have screwed up MTAs and filters that do not conform to the relevant standards in ways that "just happen" to misidentify legitimate use of certain headers by Mailman as spammer spoor.

13 years

Fwd: Feedback for mailman developers

by Barry Warsaw

Begin forwarded message: > From: "Adrian Bye" <adrian(a)tasmaniaconsulting.com> > Date: February 7, 2008 5:53:21 PM EST > To: barry(a)list.org > Subject: Fwd: [Mailman-Developers] Feedback for mailman developers > > Barry, > > Could you do me a huge favor and make sure this gets to the list. > It doesn't show up in the archives. > > Warm regards, > > Adrian > > ---------- Forwarded message ---------- > From: Adrian Bye <adrian(a)tasmaniaconsulting.com> > Date: Feb 7, 2008 2:08 PM > Subject: Re: [Mailman-Developers] Feedback for mailman developers > To: Barry Warsaw <barry(a)list.org> > Cc: mailman-developers(a)python.org, rms(a)gnu.org, bmurdoch(a)lwb.org.au, tmihalicek(a)mihainside.com > , techsupport(a)meridian-ds.com, Peter Brown <peterb(a)fsf.org> > > > Hi guys, > > I've copied 3 people who emailed me since May 2007 about this > issue. I don't know any of them, they just found my post from 3 > years ago on the web and wrote to me. Clearly its important to them > since they emailed me about it. > > Guys: I encourage you to subscribe to the mailman-developers list > so you can communicate your needs directly with the mailman > development team. > > The one-click unsubscribe is a critical feature for mailman and will > open up a much larger interest base. I am not proposing 1-click > unsubscribe for discussion mailing lists such as this one - that > would obviously cause problems with people unsubscribing each other > by mistake. However a lot of organizations use mailing list > software to broadcast newsletters to their membership. If users > cannot unsubscribe via some kind of (simple) 1-click interface then > it limits the people who can use the system and may not be CANSPAM > compliant. The FSF is one organization that has been running a > newsletter for a while and they have had to manually handle > unsubscribe requests. Peter Brown is copied as well as RMS and may > be able to respond if necessary. > > When many users cannot unsubscribe from an announcement list (as the > FSF used mailman for) they often don't bother, instead they just hit > the "this is spam" button. Neither the sender or receiver notices > anything when this happens. For the receiver, future emails from > the list go into the trash, so hitting the "this is spam" button > accomplished their purpose. The sender doesn't realise there was a > problem because they never heard from the recipient. But the mail > services know (eg hotmail/gmail/yahoo/aol) and they begin to mark > the IP address/domain of the sender as a spam sender. This causes > future WANTED mail from that sender to go into the trash. > > When we were experimenting with mailman 3 years ago, we found that > in fact mailman already has a bad reputation for email. We found > our mail was directly going into the trash when it included mailman > headers. When we modified mailman to send but hide the mailman > headers, we got directly into the inbox. This testing is 3 years > old, and I don't remember the specific services we were testing to, > but it included one of hotmail or yahoo. > > While mailman continues not to support easy unsubscribe in the > footers, it will continue to hamper the growth of free software, as > free software organizations will not have a reliable product to mail > to broadcast to interested users. This demand is evidenced by the > emails I get every 2 months from people asking me for this patch due > to my emails in the archives from 3 years ago. > > I'm not here to get into a debate - I only joined the list again to > ask to have that post removed because I'm tired of responding to > these requests which I cannot help with. > > I hope this explains my point of view. Best of luck, > > Adrian > > > On 2/7/08, Barry Warsaw <barry(a)list.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Feb 5, 2008, at 4:07 PM, Adrian Bye wrote: > > > Hi guys (and RMS, copied), > > > > About 3 years ago I made this post: > > > > http://mail.python.org/pipermail/mailman > > -developers/2005-February/017850.html > > > > As a result, I get an email every 1-2 months from people asking > for an > > updated patch. > > It looks to me like there are really two separate unrelated features > here. Distributing them in the same patch would make it difficult to > review, discuss, test and integrate, regardless of whether they are > good ideas or not. > > I would like to encourage you to develop your patches in a different > way. I'm not making any promises about whether they would be > integrated if you do this, but it would make it easier for us to look > at, and I believe easier for your to maintain separately if you decide > to continue to do so. > > I would highly recommend creating two separate Bazaar branches of the > Mailman 2.1 code. Each would implement just one of your features. > You could create a third branch with the whole thing if you wanted, > but I don't think it would be necessary. You should then register on > Launchpad and push these branches, publishing them in a live source > code repository for all to see. > > I'm really trying to encourage this style of development. To me, > patches living in a tracker is dead code. With a published, public > branch, the entire process is more transparent, we can easily do a > merge and test if we wanted to look at it. We can even find these > branches easily via Launchpad. And you will have an easier time > maintaining them, because as new revisions get pushed to Mailman 2.1 > trunk, you can just merge, commit, and push to update your own branch. > > If you -- or anybody else -- has questions about this workflow, please > ping me on #mailman on irc.freenode.net. I will happily walk you > through it. > > Cheers, > - -Barry > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > > iD8DBQFHqvot2YZpQepbvXERAqmsAJ9H2Y9EBEIw03mDt/NPUHsL7EcYlACggzB3 > pcP+bzgjF1D1dIv89m8VLCY= > =BC8W > -----END PGP SIGNATURE----- > > > > -- > Adrian Bye > Tasmania Consulting Group > http://TasmaniaConsulting.com > adrian.bye(a)tasmaniaconsulting.com > Phone: 305-433-8188 Fax: 305-428-2665 > > Mailing address: > 8260 NW 14th St, EPS-Y12457 > Doral, FL, 33126-1502 > > > -- > Adrian Bye > Tasmania Consulting Group > http://TasmaniaConsulting.com > adrian.bye(a)tasmaniaconsulting.com > Phone: 305-433-8188 Fax: 305-428-2665 > > Mailing address: > 8260 NW 14th St, EPS-Y12457 > Doral, FL, 33126-1502

13 years, 1 month

Feedback for mailman developers

by Adrian Bye

Hi guys (and RMS, copied), About 3 years ago I made this post: http://mail.python.org/pipermail/mailman -developers/2005-February/017850.html As a result, I get an email every 1-2 months from people asking for an updated patch. I felt at the time it was an important project. I was told it was not, so I made it myself. And, it was refused to be added to the main fork of mailman which was quite frustrating. Given the volume of email requests I get about it, my opinion seems to be confirmed. I wanted to bring it to your attention, and hope something will be done about it. These are just people who are figuring out my email address on the web and contacting me. There must be many more who don't actually ask me about it. If another group wants to step up and improve mailman, it might be a good time to do so. This is a critical project which could become the centerpiece of a lot of important software if it was improved. Best regards, Adrian

13 years, 1 month

Mailman 2.1.10b1 Released

by Mark Sapiro

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am happy to announce the first beta release of Mailman 2.1.10. This is a security and bug fix release and it is highly recommended that all sites upgrade to this version. Mailman 2.1.10 also adds support for two new language translations, Hebrew and Slovak and a few new features. Mailman is free software for managing email mailing lists and e- newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, including download links, please see: http://www.list.org http://mailman.sf.net http://www.gnu.org/software/mailman Special thanks are due to Barry Warsaw and Tokio Kikuchi for much coding and support, Moritz Naumann for help with security issues and Jim Tittsler for a significant patch. Here's a list of the major changes. Security - The 2.1.9 fixes for CVE-2006-3636 have been enhanced. In particular, many potential cross-site scripting attacks have are now detected in editing templates and updating the list's info attribute via the web admin interface. Thanks again to Moritz Naumann for assistance with this. New Features - Changed cmd_who.py to list all members if authorization is with the list's admin or moderator password and to accept the password if the roster is public. Also changed the web roster to show hidden members when authorization is by site or list's admin or moderator password (1587651). - Added the ability to put a list name in accept_these_nonmembers to accept posts from members of that list (1220144). - Added a new 'sibling list' feature to exclude members of another list from receiving a post from this list if the other list is in the To: or Cc: of the post or to include members of the other list if that list is not in the To: or Cc: of the post (Patch ID 1347962). - Added the admin_member_chunksize attribute to the admin General Options interface (Bug 1072002, Partial RFE 782436). Internationalization - Added the Hebrew translation from Dov Zamir. This includes addition of a direction ('ltr', 'rtl') to the LC_DESCRIPTIONS table. The add_language() function defaults direction to 'ltr' to not break existing mm_cfg.py files. - Added the Slovak translation from Martin Matuska. - -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD4DBQFHVjjPVVuXXpU7hpMRArQHAJ9NE4Fj8b2rpWaXX6+BFa27wWB2MACWIGqJ 1wxPhA7ZBRVG9gSiEhTb2A== =vzXz -----END PGP SIGNATURE-----

13 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers February 2008