From barry at python.org Mon May 1 15:12:26 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 01 May 2006 09:12:26 -0400 Subject: [Mailman-Developers] [Mailman-Users] Sender field In-Reply-To: References: <44525979.6040301@imsa.edu> <1146268220.10790.160.camel@resist.wooz.org> Message-ID: <1146489146.11009.13.camel@geddy.wooz.org> On Fri, 2006-04-28 at 19:12 -0500, Brad Knowles wrote: > I think we need to gather a lot more information about the likely > outcome from this change, and I think the best way to achieve this is > through giving admins (either site admins or list admins) the ability > to set an option and choose whether or not they want to see what > happens. I agree that we need a lot more data, but I'm not sure making this an option is the best way to gather that data. Besides, if we do it that way, it'll be Mailman 2.3 (or whatever <3.0 wink>) before we make the change. I'd like to work up an unofficial diff to Mailman 2.1 for people like Stephen who are willing to give it a try on a live site. We just have to agree as to what that change should be! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060501/fbd11fb6/attachment.pgp From barry at python.org Mon May 1 15:34:24 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 01 May 2006 09:34:24 -0400 Subject: [Mailman-Developers] [Mailman-Users] Sender field In-Reply-To: <87slnwe8ap.fsf@tleepslib.sk.tsukuba.ac.jp> References: <44525979.6040301@imsa.edu> <1146268220.10790.160.camel@resist.wooz.org> <87slnwe8ap.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <1146490464.11009.18.camel@geddy.wooz.org> On Sun, 2006-04-30 at 00:00 +0900, Stephen J. Turnbull wrote: > Sender doesn't instruct *conformant* MTAs at all, does it? AFAIK the > only thing that a RFC 2821-conforming MTA looks at is the Return-Path > header, and it's supposed to remove that. > > So this is purely a matter of pragmatic self-defense against broken > MTAs that do bounce to Sender. Correct, and what we're trying to figure out is whether we need that self-defense any longer. The change to test this may be as simple as commenting out "msg['Sender'] = envsender" in bulkdeliver() inside SMTPDirect.py (a little more complicated if you want to do it just for one domain though -- you'd want to test for something like "if 'xemacs.org' in mlist.host_name") > Agreed. For a number of reasons, I think this information can be > useful. As I mentioned elsewhere, the Resent-Message-Id field can be > used to supply a UUID that we can trust (eg, for constructing > canonical archive URLs). Unlike the Received headers, these are > readable by humans who aren't wall-eyed, helpful in tracing delays, > for example. It's an intersting idea. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060501/5471c4b3/attachment.pgp From barry at python.org Mon May 1 15:39:47 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 01 May 2006 09:39:47 -0400 Subject: [Mailman-Developers] Sender field In-Reply-To: References: Message-ID: <1146490787.10986.22.camel@geddy.wooz.org> On Sat, 2006-04-29 at 09:03 -0700, Mark Sapiro wrote: > This can be done by making a modified SMTPDirect.py and modifying the > pipeline for the XEmacs lists. I'm pretty sure you know how to do > this, but after I was recently reminded (by you I think - thank you) > that this is a good way to do lots of things, I wrote a FAQ on it > . > The specific changes to SMTPDirect.py would be at the beginning of > bulkdeliver(). Nice entry Mark, thanks. I'll add two things: * You could still add a handler to the global pipeline, but have it do a test of the listname or domain first, and if it doesn't match, do a quick return. You pay the cost of the handler for every mailing list, but it should be fairly minimal in the scheme of things * We should probably define a more convenient way to extend the pipeline for specific lists or domains (IOW, MM2.2 should have a more useful hook mechanism). > You would be looking for bounces being returned to inappropriate places > such as the original poster or the list itself. Thus, list members > would have to be aware of the fact that there was a change and that > they should try to observe and report any change in received bounces > or other autoresponses to their posts. It might be tricky to filter > out actual change from perceived change due to being more aware. Yep. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060501/98795d67/attachment.pgp From stephen at xemacs.org Mon May 1 19:56:51 2006 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 02 May 2006 02:56:51 +0900 Subject: [Mailman-Developers] Sender field In-Reply-To: <1146490787.10986.22.camel@geddy.wooz.org> (Barry Warsaw's message of "Mon, 01 May 2006 09:39:47 -0400") References: <1146490787.10986.22.camel@geddy.wooz.org> Message-ID: <8764kp7hng.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "BAW" == Barry Warsaw writes: * You could still add a handler to the global pipeline, but have it do a test of the listname or domain first, and if it doesn't match, do a quick return. You pay the cost of the handler for every mailing list, but it should be fairly minimal in the scheme of things I once added a maybe-log-and-return handler at every point in the pipeline on our busiest list. No effect on load. I dunno, if you're handling a million posts a day you might notice that. But handler calling is way down in the scheme of CPU suckers compared to spam and virus filtering. I'm unwilling to add to the global pipeline simply because there's no such thing as a 100% safe edit, not because I'm worried about function call overhead in Python. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. From barry at python.org Mon May 1 19:59:36 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 01 May 2006 13:59:36 -0400 Subject: [Mailman-Developers] Sender field In-Reply-To: <8764kp7hng.fsf@tleepslib.sk.tsukuba.ac.jp> References: <1146490787.10986.22.camel@geddy.wooz.org> <8764kp7hng.fsf@tleepslib.sk.tsukuba.ac.jp> Message-ID: <1146506376.2269.39.camel@resist.wooz.org> On Tue, 2006-05-02 at 02:56 +0900, Stephen J. Turnbull wrote: > I once added a maybe-log-and-return handler at every point in the > pipeline on our busiest list. No effect on load. I dunno, if you're > handling a million posts a day you might notice that. But handler > calling is way down in the scheme of CPU suckers compared to spam and > virus filtering. True. > I'm unwilling to add to the global pipeline simply because there's no > such thing as a 100% safe edit, not because I'm worried about function > call overhead in Python. Fair enough. Probably going with the extend.py stuff is your best bet at this point. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060501/03597f87/attachment.pgp From ngroot at imsa.edu Mon May 1 20:27:40 2006 From: ngroot at imsa.edu (Neal Groothuis) Date: Mon, 01 May 2006 13:27:40 -0500 Subject: [Mailman-Developers] [Mailman-Users] Sender field In-Reply-To: <1146489146.11009.13.camel@geddy.wooz.org> References: <44525979.6040301@imsa.edu> <1146268220.10790.160.camel@resist.wooz.org> <1146489146.11009.13.camel@geddy.wooz.org> Message-ID: <4456531C.3070809@imsa.edu> > I'd like to work up an unofficial diff to Mailman 2.1 for people like > Stephen who are willing to give it a try on a live site. I'm not sure this is even necessary. Ezmlm doesn't touch the Sender: header at all, Majordomo sets it to the owner of the list, and (AFAICT) Listserv sets it to the list itself. This would seem to me to indicate that incidences of mail being returned inappropriately to the sender are infrequent, at worst. The important question would seem to be "what's appropriate?" From RFC 2822, 3.6.2: "The originator fields indicate the mailbox(es) of the source of the message." Given this, the definition of the Sender and From headers, and the example given in this section, it seems that Outlook's interpretation of the fields ("SENDER on behalf of FROM") is reasonable. Mailman is not the originator of the message, so it should not be tampering with the From: or Sender: fields at all. It might be appropriate for Mailman to add Resent-* headers, depending on how one reads RFC 2822, 3.6.6. I personally don't think it's necessary or useful, since list servers add their own List-* headers, per RFC 2369. The Resent-* headers seem to exist for individuals resending messages, not automated systems. This is supported by the RFC: "Resent fields are used to identify a message as having been reintroduced into the transport system by a user." -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3283 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060501/00640a16/attachment.bin From qralston+ml.mailman-developers at andrew.cmu.edu Mon May 1 23:09:09 2006 From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston) Date: Mon, 01 May 2006 17:09:09 -0400 Subject: [Mailman-Developers] Sender field In-Reply-To: <1146268463.10788.165.camel@resist.wooz.org> References: <4450E5D3.10304@imsa.edu> <74581CA516FF252A4441207B@pcmy.sei.cmu.edu> <4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu> <1146268463.10788.165.camel@resist.wooz.org> Message-ID: <919C6A077935418C36260058@emerald.sei.cmu.edu> On 2006-04-28 at 19:54-04 Barry Warsaw wrote: > On Fri, 2006-04-28 at 17:32 -0400, James Ralston wrote: > > > I would argue that the best course of action is to excise Sender > > header rewriting entirely and provide no option to turn it on. > > (Mailman has way too many options already.) > > I agree that this is what we should hope for. Our data supporting > the rewriting of Sender is many years out of date, so we need to > gather more data. Who's brave enough to try it? :) We're going to implement it, because we really don't have any choice. :/ At our site, we have around 550 lists and 15,700 subscribers in total. We process (send) around 16,708 messages per day. Our list owners have discovered that a non-trivial number of the recipients on our lists have mail clients that include the Sender address in the reply-to-all feature. As a result, we have a continual stream of subscribers who are accidentally hosing their subscriptions (causing them to be suspended or removed) by accidentally replying to Mailman's bounce processing address in the Sender header. This problem is so bad for us that some list owners are demanding that we abandon Mailman in favor of some other list manager. (They're also incensed about Mailman's bounce processing options, but that's another topic.) Since disabling the Sender header processing is literally a one-line patch, we're going to go ahead and do it. If it breaks horribly (even for a small percentage of users) we'll know; if it makes our users happy, we'll know that too. James From barry at python.org Mon May 1 23:19:39 2006 From: barry at python.org (Barry Warsaw) Date: Mon, 01 May 2006 17:19:39 -0400 Subject: [Mailman-Developers] Sender field In-Reply-To: <919C6A077935418C36260058@emerald.sei.cmu.edu> References: <4450E5D3.10304@imsa.edu> <74581CA516FF252A4441207B@pcmy.sei.cmu.edu> <4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu> <1146268463.10788.165.camel@resist.wooz.org> <919C6A077935418C36260058@emerald.sei.cmu.edu> Message-ID: <1146518379.2267.75.camel@resist.wooz.org> On Mon, 2006-05-01 at 17:09 -0400, James Ralston wrote: > We're going to implement it, because we really don't have any choice. > :/ ...and later... > Since disabling the Sender header processing is literally a one-line > patch, we're going to go ahead and do it. If it breaks horribly (even > for a small percentage of users) we'll know; if it makes our users > happy, we'll know that too. Definitely let us know how it goes! > This problem is so bad for us that some list owners are demanding that > we abandon Mailman in favor of some other list manager. (They're also > incensed about Mailman's bounce processing options, but that's another > topic.) Please do start a new thread with your feedback here. Fixing the bounce processor is definitely one of the things I want to do for MM2.2. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060501/a052247f/attachment.pgp From msapiro at value.net Tue May 2 03:11:42 2006 From: msapiro at value.net (Mark Sapiro) Date: Mon, 1 May 2006 18:11:42 -0700 Subject: [Mailman-Developers] Sender field In-Reply-To: <919C6A077935418C36260058@emerald.sei.cmu.edu> Message-ID: James Ralston wrote: >As a result, we have a continual stream of >subscribers who are accidentally hosing their subscriptions (causing >them to be suspended or removed) by accidentally replying to Mailman's >bounce processing address in the Sender header. This should only be happening if Mailman's VERP delivery is enabled so the Sender is "list-bounces+user=users.domain at lists.domain. In the non-VERP case, a post or reply should be an 'unrecognozed bounce' - still a major annoyance for the admin who elects to see unrecognized bounces, but at least not a problem that disables the user. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From msapiro at value.net Tue May 2 03:16:48 2006 From: msapiro at value.net (Mark Sapiro) Date: Mon, 1 May 2006 18:16:48 -0700 Subject: [Mailman-Developers] [Mailman-Users] Sender field In-Reply-To: <4456531C.3070809@imsa.edu> Message-ID: Neal Groothuis wrote: > >Mailman is not the originator of the message, so it should >not be tampering with the From: or Sender: fields at all. This is arguably not true. Mailman may add a list header and/or list footer to the body of the message as well as potentially filtering or scrubbing various MIME parts. The message sent by Mailman can be significantly different from the one originally received. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From bob at nleaudio.com Tue May 2 03:18:48 2006 From: bob at nleaudio.com (Bob Puff) Date: Mon, 1 May 2006 21:18:48 -0400 Subject: [Mailman-Developers] Sender field In-Reply-To: <919C6A077935418C36260058@emerald.sei.cmu.edu> References: <4450E5D3.10304@imsa.edu> <74581CA516FF252A4441207B@pcmy.sei.cmu.edu> <4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu> <1146268463.10788.165.camel@resist.wooz.org> <919C6A077935418C36260058@emerald.sei.cmu.edu> Message-ID: <20060502011755.M46868@nleaudio.com> > As a result, we have a continual stream of > subscribers who are accidentally hosing their subscriptions (causing > them to be suspended or removed) by accidentally replying to > Mailman's bounce processing address in the Sender header. Curious: are your lists set up such that replies go to the list, or recipient? Bob From barry at python.org Tue May 2 16:03:31 2006 From: barry at python.org (Barry Warsaw) Date: Tue, 02 May 2006 10:03:31 -0400 Subject: [Mailman-Developers] [Mailman-Users] Sender field In-Reply-To: References: Message-ID: <1146578611.2267.84.camel@resist.wooz.org> On Mon, 2006-05-01 at 18:16 -0700, Mark Sapiro wrote: > Neal Groothuis wrote: > > > >Mailman is not the originator of the message, so it should > >not be tampering with the From: or Sender: fields at all. > > > This is arguably not true. Mailman may add a list header and/or list > footer to the body of the message as well as potentially filtering or > scrubbing various MIME parts. The message sent by Mailman can be > significantly different from the one originally received. The copy that Mailman sends is almost always modified in some way, and given the ambiguities in the standards, I think it's defensible to say that Mailman is the originator of the messages received by list members. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060502/58c12a4c/attachment.pgp From barry at python.org Tue May 2 16:22:17 2006 From: barry at python.org (Barry Warsaw) Date: Tue, 02 May 2006 10:22:17 -0400 Subject: [Mailman-Developers] [Mailman-Users] Sender field In-Reply-To: <4456531C.3070809@imsa.edu> References: <44525979.6040301@imsa.edu> <1146268220.10790.160.camel@resist.wooz.org> <1146489146.11009.13.camel@geddy.wooz.org> <4456531C.3070809@imsa.edu> Message-ID: <1146579737.2270.87.camel@resist.wooz.org> On Mon, 2006-05-01 at 13:27 -0500, Neal Groothuis wrote: > > I'd like to work up an unofficial diff to Mailman 2.1 for people like > > Stephen who are willing to give it a try on a live site. > > I'm not sure this is even necessary. > > Ezmlm doesn't touch the Sender: header at all, Majordomo sets it to the > owner of the list, and (AFAICT) Listserv sets it to the list itself. > This would seem to me to indicate that incidences of mail being returned > inappropriately to the sender are infrequent, at worst. As I said, I think it's defensible to claim Mailman is the originator, but practicality beats purity, and I do think a list manager falls into a gray area here. Having said all that, you might be right, in that we really don't need to do much except remove the addition of the Sender: header in bulkdeliver(). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060502/2f587ad8/attachment.pgp From dario at ita.chalmers.se Wed May 3 09:49:14 2006 From: dario at ita.chalmers.se (=?ISO-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Wed, 03 May 2006 09:49:14 +0200 Subject: [Mailman-Developers] why not PageTemplates for GUI? Message-ID: <4458607A.5030804@ita.chalmers.se> hello, I am wondering why any future template suggestion a priori rule out PageTemplates? I find them really handy to use, at least in zope-contexts. Is it becuase it is zope or other reasons? thanks, /dario -- -- ------------------------------------------------------------------- Dario Lopez-K?sten, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley From barry at python.org Wed May 3 16:57:24 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 03 May 2006 10:57:24 -0400 Subject: [Mailman-Developers] why not PageTemplates for GUI? In-Reply-To: <4458607A.5030804@ita.chalmers.se> References: <4458607A.5030804@ita.chalmers.se> Message-ID: <1146668244.2268.137.camel@resist.wooz.org> On Wed, 2006-05-03 at 09:49 +0200, Dario Lopez-K?sten wrote: > I am wondering why any future template suggestion a priori rule out > PageTemplates? I find them really handy to use, at least in zope-contexts. > > Is it becuase it is zope or other reasons? I actually tried to implement a u/i using ZPT a while ago and once I got into all the i18n stuff, I found the templates essentially impossible to read or understand. I am hoping for a much simpler solution (or some champion to step forth who can succeed where I failed :). Perhaps we need an "improve the u/i" subcommittee? If you have thoughts, please add them to the wiki: http://wiki.list.org/display/DEV/Mailman+2.2 -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060503/3b925580/attachment.pgp From msapiro at value.net Wed May 3 17:00:58 2006 From: msapiro at value.net (Mark Sapiro) Date: Wed, 3 May 2006 08:00:58 -0700 Subject: [Mailman-Developers] New Mailman logging In-Reply-To: <1146400434.2269.13.camel@resist.wooz.org> Message-ID: Barry Warsaw wrote: > >I'll make these changes to the scripts files when I get to them, if >nobody beats me to it. I've made the changes, but it will be a day or so before I can finish testing and check them in. -- 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 Thu May 4 08:36:03 2006 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu, 04 May 2006 15:36:03 +0900 Subject: [Mailman-Developers] logger umask Message-ID: <4459A0D3.2060406@is.kochi-u.ac.jp> Hi, I think our new logger should set group writable to the new logs. I tried a fresh install and get cgi error after mailmanctl start / mailmanctl errot after cgi execution, vice versa. The patch should look like this: Index: Mailman/loginit.py =================================================================== --- Mailman/loginit.py (revision 7892) +++ Mailman/loginit.py (working copy) @@ -103,6 +103,8 @@ # There was also a 'debug' logger, but that was mostly unused, so instead # we'll use debug level on existing loggers. # + # First set umask because both mailman/www write logs + oumask = os.umask(002) # Start by creating a common formatter and the root logger. formatter = logging.Formatter(fmt=FMT, datefmt=DATEFMT) log = logging.getLogger('mailman') @@ -120,6 +122,8 @@ _handlers.append(handler) handler.setFormatter(formatter) log.addHandler(handler) + # restore original umask + os.umask(oumask) -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From heikki.lampen at gmail.com Thu May 4 22:33:19 2006 From: heikki.lampen at gmail.com (=?ISO-8859-1?Q?Heikki_Lamp=E9n?=) Date: Thu, 4 May 2006 23:33:19 +0300 Subject: [Mailman-Developers] Mailman "true virtual hosting" and Google SoC In-Reply-To: <1145908660.13317.257.camel@resist.wooz.org> References: <1145908660.13317.257.camel@resist.wooz.org> Message-ID: On 4/24/06, Barry Warsaw wrote: > On Mon, 2006-04-24 at 16:21 +0300, Heikki Lamp?n wrote: > > I'm wondering about this "true virtual hosting" issue and what is > > going to happen to it. > > > > I see there's some talk about Google SoC in the wiki [0]. > > Unfortunately I don't see Mailman in the Google SoC participant list > > [1]. Has Mailman applied as a mentoring organization? The deadline is > > 1st of May. > > True, although I was thinking that if someone wants to do this, we could > do it under the auspices of the Python Software Foundation. There > really is no "Mailman organization" and the latter's SoC project page > does list Mailman as a possibility. Sounds good. > > Anyway, it'd be awesome if SoC could finish what the vhost branch has > > began. Or is it totally out of the question that such a patch would be > > integrated to 2.1? Even as a branch (that'd be kept up to date with > > 2.1) it could be very useful. > > It's not out of the question, although no way can it go into the > mainline 2.1 branch. Ideally, the work would be done on the Mailman > trunk for 2.2, although I wouldn't be opposed to an "unofficial" 2.1 > patch branch if the volunteers were so motivated. It's too big of > project to go into 2.1 proper though. Fair enough. > > Why or why not should the vhost branch development happen on the same > > subversion repository? In CVS there was the awful branching problem. I > > think Subversion is the most attracting version control system. Then > > again what I think doesn't matter but what you guys think is what > > matters. Of course moving off to another platform is always extra work > > and has to be motivated properly. > > My hesitance is much more the code disruption, upgrade testing, and > support costs involved in pulling this into 2.1. We just can't be > adding new features to 2.1 at this point. What we /really/ need to do > is get 2.2 moving so that we can release it fairly soon (this year, I > hope). > > > Also the usage of JIRA and Confluence should make it even more > > interesting as organizing the project becomes a whole lot easier that > > way. Maybe add a project for the vhost branch. > > > > Maybe I'm just being impatient but as I see it, this vhost stuff > > should really interest a lot of people. > > Definitely. Everyone wants to see it, and it will definitely happen for > 2.2. It would be awesome if a SoC volunteer wanted to take it on and I > would be more than happy to mentor the work. Are you a student and are > you interested in working on it? I'm unfortunately already employed during summer time (would've had been an interesting project). Maybe someone on the list is or knows a promising victim? -- heze heikki.lampen at gmail.com From dario at ita.chalmers.se Tue May 9 08:27:51 2006 From: dario at ita.chalmers.se (=?ISO-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Tue, 09 May 2006 08:27:51 +0200 Subject: [Mailman-Developers] why not PageTemplates for GUI? In-Reply-To: <1146668244.2268.137.camel@resist.wooz.org> References: <4458607A.5030804@ita.chalmers.se> <1146668244.2268.137.camel@resist.wooz.org> Message-ID: <44603667.3080502@ita.chalmers.se> Barry Warsaw said the following on 05/03/2006 04:57 PM: > I actually tried to implement a u/i using ZPT a while ago and once I got > into all the i18n stuff, I found the templates essentially impossible to > read or understand. I am hoping for a much simpler solution (or some > champion to step forth who can succeed where I failed :). ;-) I have an itch I need to scratch here, it's about integration etc, so perhaps I'll be able to produce something. Not anytime soon, though, but for my personal needs, Pagetemeplates would be the cleanest solution. > Perhaps we need an "improve the u/i" subcommittee? If you have > thoughts, please add them to the wiki: > > http://wiki.list.org/display/DEV/Mailman+2.2 > I will, thanks. /dario -- -- ------------------------------------------------------------------- Dario Lopez-K?sten, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley From barry at python.org Tue May 9 14:01:57 2006 From: barry at python.org (Barry Warsaw) Date: Tue, 09 May 2006 08:01:57 -0400 Subject: [Mailman-Developers] why not PageTemplates for GUI? In-Reply-To: <44603667.3080502@ita.chalmers.se> References: <4458607A.5030804@ita.chalmers.se> <1146668244.2268.137.camel@resist.wooz.org> <44603667.3080502@ita.chalmers.se> Message-ID: <1147176117.11945.51.camel@geddy.wooz.org> On Tue, 2006-05-09 at 08:27 +0200, Dario Lopez-K?sten wrote: > ;-) I have an itch I need to scratch here, it's about integration etc, > so perhaps I'll be able to produce something. Not anytime soon, though, > but for my personal needs, Pagetemeplates would be the cleanest solution. A little templating bake-off might not be such a bad thing. :) proof-is-in-the-code-ly y'rs, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060509/b881d01c/attachment.pgp From fil at rezo.net Tue May 9 14:21:35 2006 From: fil at rezo.net (Fil) Date: Tue, 9 May 2006 14:21:35 +0200 Subject: [Mailman-Developers] GNU FSF Assignment In-Reply-To: <1146358182.8250.42.camel@geddy.wooz.org> References: <20060429222213.GI6557@rezo.net> <1146358182.8250.42.camel@geddy.wooz.org> Message-ID: <20060509122133.GQ7266@rezo.net> > > can someone point me to the procedure/documents needed to assign copyright > > to Barry^H^H^H^H^H the FSF ? I can't find them on Google or on the GNU > > project pages (??). > > Well, if you assigning your changes to me, it would be simple ('cause I > wouldn't ask for assignment in the first place ;). But to assign your > changes to the FSF, AFAIK, you have to email assign at fsf.org and ask for > the appropriate form. They don't answer their email. This is so very cool. -- Fil From jag at fsf.org Tue May 9 20:36:35 2006 From: jag at fsf.org (Joshua Ginsberg) Date: Tue, 09 May 2006 14:36:35 -0400 Subject: [Mailman-Developers] GNU FSF Assignment In-Reply-To: <20060509122133.GQ7266@rezo.net> References: <20060429222213.GI6557@rezo.net> <1146358182.8250.42.camel@geddy.wooz.org> <20060509122133.GQ7266@rezo.net> Message-ID: <1147199795.9997.4.camel@localhost.localdomain> Let me see what I can do to nudge the copyright assignments clerk... Stay tuned... -jag On Tue, 2006-05-09 at 14:21 +0200, Fil wrote: > > > can someone point me to the procedure/documents needed to assign copyright > > > to Barry^H^H^H^H^H the FSF ? I can't find them on Google or on the GNU > > > project pages (??). > > > > Well, if you assigning your changes to me, it would be simple ('cause I > > wouldn't ask for assignment in the first place ;). But to assign your > > changes to the FSF, AFAIK, you have to email assign at fsf.org and ask for > > the appropriate form. > > They don't answer their email. This is so very cool. > > -- Fil > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/jag%40fsf.org > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > -- Joshua Ginsberg Free Software Foundation - Senior Systems Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060509/5c47deed/attachment.pgp From jag at fsf.org Tue May 9 23:01:15 2006 From: jag at fsf.org (Joshua Ginsberg) Date: Tue, 09 May 2006 17:01:15 -0400 Subject: [Mailman-Developers] GNU FSF Assignment In-Reply-To: <20060509122133.GQ7266@rezo.net> References: <20060429222213.GI6557@rezo.net> <1146358182.8250.42.camel@geddy.wooz.org> <20060509122133.GQ7266@rezo.net> Message-ID: <1147208476.9997.12.camel@localhost.localdomain> Sorry, y'all -- the copyright clerk has been out sick several days the last week or two, so he hasn't quite been able to keep up with the load of requests coming in... I nudged him this morning, and it looks like he started to address Barry's ticket... I keep an eye on Fil's... -jag On Tue, 2006-05-09 at 14:21 +0200, Fil wrote: > > > can someone point me to the procedure/documents needed to assign copyright > > > to Barry^H^H^H^H^H the FSF ? I can't find them on Google or on the GNU > > > project pages (??). > > > > Well, if you assigning your changes to me, it would be simple ('cause I > > wouldn't ask for assignment in the first place ;). But to assign your > > changes to the FSF, AFAIK, you have to email assign at fsf.org and ask for > > the appropriate form. > > They don't answer their email. This is so very cool. > > -- Fil > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at python.org > http://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/jag%40fsf.org > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > -- Joshua Ginsberg Free Software Foundation - Senior Systems Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060509/e0248df5/attachment.pgp From fil at rezo.net Tue May 9 23:14:24 2006 From: fil at rezo.net (Fil) Date: Tue, 9 May 2006 23:14:24 +0200 Subject: [Mailman-Developers] GNU FSF Assignment In-Reply-To: <1147208476.9997.12.camel@localhost.localdomain> References: <20060429222213.GI6557@rezo.net> <1146358182.8250.42.camel@geddy.wooz.org> <20060509122133.GQ7266@rezo.net> <1147208476.9997.12.camel@localhost.localdomain> Message-ID: <20060509211423.GG16576@rezo.net> > Sorry, y'all -- the copyright clerk has been out sick several days the OK. My apologies for having been so gross :( -- Fil From barry at python.org Wed May 10 18:04:02 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 10 May 2006 12:04:02 -0400 Subject: [Mailman-Developers] GNU FSF Assignment In-Reply-To: <20060509211423.GG16576@rezo.net> References: <20060429222213.GI6557@rezo.net> <1146358182.8250.42.camel@geddy.wooz.org> <20060509122133.GQ7266@rezo.net> <1147208476.9997.12.camel@localhost.localdomain> <20060509211423.GG16576@rezo.net> Message-ID: <1147277042.12713.254.camel@resist.wooz.org> For future reference, I've put a copy of the request form in our wiki: http://wiki.list.org/display/DEV/GNU+copyright+assignment+request+form Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060510/cb7ee2d6/attachment.pgp From qralston+ml.mailman-developers at andrew.cmu.edu Thu May 11 18:00:02 2006 From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston) Date: Thu, 11 May 2006 12:00:02 -0400 Subject: [Mailman-Developers] Sender field In-Reply-To: <1146518379.2267.75.camel@resist.wooz.org> References: <4450E5D3.10304@imsa.edu> <74581CA516FF252A4441207B@pcmy.sei.cmu.edu> <4AEB459E1D08D8F77FAEE25F@pcmy.sei.cmu.edu> <1146268463.10788.165.camel@resist.wooz.org> <919C6A077935418C36260058@emerald.sei.cmu.edu> <1146518379.2267.75.camel@resist.wooz.org> Message-ID: On 2006-05-01 at 17:19-04 Barry Warsaw wrote: > > Since disabling the Sender header processing is literally a > > one-line patch, we're going to go ahead and do it. If it breaks > > horribly (even for a small percentage of users) we'll know; if it > > makes our users happy, we'll know that too. > > Definitely let us know how it goes! We haven't rolled it out yet (because we want to do at least some cursory testing first), but just FYI, I've attached the patch we came up with. (I'm not sure if Mailman will eat it; if not, I'll resend it inline.) > > This problem is so bad for us that some list owners are demanding > > that we abandon Mailman in favor of some other list manager. > > ([Our list owners are] also incensed about Mailman's bounce > > processing options, but that's another topic.) > > Please do start a new thread with your feedback here. Fixing the > bounce processor is definitely one of the things I want to do for > MM2.2. Will do. James -------------- next part -------------- --- mailman-2.1.8/Mailman/Handlers/SMTPDirect.py.sender-header 2005-12-30 13:50:08.000000000 -0500 +++ mailman-2.1.8/Mailman/Handlers/SMTPDirect.py 2006-05-02 13:45:21.000000000 -0400 @@ -347,17 +347,23 @@ def bulkdeliver(mlist, msg, msgdata, envsender, failures, conn): - # Do some final cleanup of the message header. Start by blowing away - # any the Sender: and Errors-To: headers so remote MTAs won't be - # tempted to delivery bounces there instead of our envelope sender - # - # BAW An interpretation of RFCs 2822 and 2076 could argue for not touching - # the Sender header at all. Brad Knowles points out that MTAs tend to - # wipe existing Return-Path headers, and old MTAs may still honor - # Errors-To while new ones will at worst ignore the header. - del msg['sender'] + # Do some final cleanup of the message header. Start by blowing away any + # Errors-To: headers so remote MTAs won't be tempted to delivery bounces + # there instead of our envelope sender. + # + # Previously, we also blew away any Sender: headers, and added a new + # Sender: header with our envelope sender. However, this behavior seems to + # cause more problems than it solves, because various MUAs will include the + # Sender address in a reply-to-all, which is not only confusing to + # subscribers, but can actually disable/unsubscribe them from lists, + # depending on how often they accidentally reply to it. + # + # The drawback of not touching the Sender: header is that some MTAs might + # still send bounces to it, so by not trapping it, we can miss bounces. + # (Or worse, MTAs might send bounces to the From: address if they can't + # find a Sender: header.) But at least for now, we're going to take our + # chances with leaving the Sender: header alone. del msg['errors-to'] - msg['Sender'] = envsender msg['Errors-To'] = envsender # Get the plain, flattened text of the message, sans unixfrom msgtext = msg.as_string() From qralston+ml.mailman-developers at andrew.cmu.edu Thu May 11 19:24:36 2006 From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston) Date: Thu, 11 May 2006 13:24:36 -0400 Subject: [Mailman-Developers] thoughts on bounce processing Message-ID: <7EBC466A807232F7DBFB4EB2@emerald.sei.cmu.edu> Per Barry's request, I thought I'd describe some of the issues our sites has encountered with Mailman lists and bounce messages. At our site, we currently 15,775 subscribers (8,296 unique) across 549 lists. While a few of the lists are huge (hundreds or thousands of subscribers), the median list size is only 4 subscribers. The primary issue we are encountering is that the vast majority of our lists (even the ones with hundreds of subscribers) are announcement-type lists, not discussion-type lists. The list owners are using the lists to reach coworkers, specific customers, course attendees, etc. The list admins know exactly which addresses are on their lists, because they've added them all themselves. Situations like this happen all the time: 1. A VIP asks an administrative assistant to send out a message to a group of people: team members, specific customers, etc. 2. The AA sends the message to the appropriate Mailman list. Unbeknown to the AA, one of the addresses bounces. 3. The person whose address bounced doesn't get the message, and (e.g.) misses an important meeting, fails to provide some important information, etc. 4. The VIP comes down hard on the AA for failing to notify everyone. 5. The AA comes to us full a fire and brimstone, complaining the Mailman doesn't permit people to perform necessary business functions. The issue is that people in this situation *want* to see the individual bounces, and they want to see them *immediately*, because the bounces contain important information that they might need to act upon. The closest they can get to that right now is to configure the list so that a single bounce immediately removes the subscriber from the list. But this isn't always the correct thing to do. (For example, lots of people seem to have broken vacation programs that respond to *everything*, and they continually get unsubscribed from lists.) The more I think about this, the more I think that silently discarding bounces is an error. While some bounces are irrelevant (e.g. vacation messages), in the majority of cases, bounces are information that some entity should act upon. There should be two (and only two) options: 1. Mailman processes all bounces. 2. All bounces are forwarded to the list administrator(s). I've attached my first attempt at implementing this behavior. (I say "first attempt" because I'd really like to get both the listname and the address that bounced into the Subject header, but to do that requires more complicated logic than what I've implemented so far.) If list admins *really* want to (effectively) discard all bounces, they can e.g. set bounce_info_stale_after to 1 and then set bounce_score_threshold to something impossibly high (e.g. 500,000). Thoughts? James -------------- next part -------------- --- mailman-2.1.8/Mailman/Gui/Bounce.py.bounce-processing 2005-08-26 21:40:15.000000000 -0400 +++ mailman-2.1.8/Mailman/Gui/Bounce.py 2006-05-04 11:19:32.000000000 -0400 @@ -77,9 +77,10 @@ ('bounce_processing', mm_cfg.Toggle, (_('No'), _('Yes')), 0, _('Should Mailman perform automatic bounce processing?'), _("""By setting this value to No, you disable all - automatic bounce processing for this list, however bounce - messages will still be discarded so that the list administrator - isn't inundated with them.""")), + automatic bounce processing for this list. If automatic bounce + processing is disabled, all bounces will be forwarded to the list + administrator(s), and all other bounce-related settings are + ignored.""")), ('bounce_score_threshold', mm_cfg.Number, 5, 0, _("""The maximum member bounce score before the member's --- mailman-2.1.8/Mailman/Queue/BounceRunner.py.bounce-processing 2006-03-09 17:09:34.000000000 -0500 +++ mailman-2.1.8/Mailman/Queue/BounceRunner.py 2006-05-04 11:12:09.000000000 -0400 @@ -194,7 +194,21 @@ ) # List isn't doing bounce processing? if not mlist.bounce_processing: - return + adminurl = mlist.GetScriptURL('admin', absolute=1) + '/bounce' + mlist.ForwardMessage(msg, + text=_("""\ +The attached message was received as a bounce. Since automatic bounce +processing is disabled for this mailing list, the bounce is being sent +to the list administrator(s). + +For more information see: +%(adminurl)s + +"""), + subject=_('Bounce notification'), + tomoderators=0) + syslog('bounce', 'forwarding bounce, message-id: %s', + msg.get('message-id', 'n/a')) # Try VERP detection first, since it's quick and easy addrs = verp_bounce(mlist, msg) if addrs: From j.e.vanbaal at uvt.nl Thu May 11 19:52:37 2006 From: j.e.vanbaal at uvt.nl (Joost van Baal) Date: Thu, 11 May 2006 19:52:37 +0200 Subject: [Mailman-Developers] thoughts on bounce processing In-Reply-To: <7EBC466A807232F7DBFB4EB2@emerald.sei.cmu.edu> References: <7EBC466A807232F7DBFB4EB2@emerald.sei.cmu.edu> Message-ID: <20060511175237.GC1285@banach.uvt.nl> On Thu, May 11, 2006 at 01:24:36PM -0400, James Ralston wrote: > > The primary issue we are encountering is that the vast majority of our > lists (even the ones with hundreds of subscribers) are > announcement-type lists, not discussion-type lists. The list owners > are using the lists to reach coworkers, specific customers, course > attendees, etc. The list admins know exactly which addresses are on > their lists, because they've added them all themselves. > > > The issue is that people in this situation *want* to see the > individual bounces, and they want to see them *immediately*, because > the bounces contain important information that they might need to act > upon. > > The more I think about this, the more I think that silently discarding > bounces is an error. While some bounces are irrelevant (e.g. vacation > messages), in the majority of cases, bounces are information that some > entity should act upon. There should be two (and only two) options: > > 1. Mailman processes all bounces. > 2. All bounces are forwarded to the list administrator(s). > > Thoughts? The way Mailman is being used at your site is very similar to what we at the Tilburg University are doing (and, I bets, _lots_ of other big sites). What you're proposing seems to be what we need (we've been lucky thus far: I haven't had a raging VIP at my desk (yet!)) . Very likely, there are more interested sites. Thanks, Bye, Joost -- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal at uvt.nl The Netherlands -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: Digital signature Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060511/541f58a1/attachment.pgp From brad at stop.mail-abuse.org Thu May 11 21:34:45 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 11 May 2006 14:34:45 -0500 Subject: [Mailman-Developers] thoughts on bounce processing In-Reply-To: <7EBC466A807232F7DBFB4EB2@emerald.sei.cmu.edu> References: <7EBC466A807232F7DBFB4EB2@emerald.sei.cmu.edu> Message-ID: At 1:24 PM -0400 2006-05-11, James Ralston wrote: > The more I think about this, the more I think that silently discarding > bounces is an error. Mailman doesn't silently discard bounces. It keeps a counter, and for each day that a bounce is received, that counter is incremented. Multiple additional bounces on a single day do not cause the counter to be incremented, but they are still examined. > While some bounces are irrelevant (e.g. vacation > messages), in the majority of cases, bounces are information that some > entity should act upon. There should be two (and only two) options: > > 1. Mailman processes all bounces. > 2. All bounces are forwarded to the list administrator(s). In your example above, that would only be appropriate if the AA is the list administrator. I think a better method would be to have all bounces sent to the poster, regardless of who that poster is. If it's an announcement-only list, then presumably you have a restricted set of people who can post to that list, and any one of them should be able to handle bounces sent directly back to them. This would imply that the envelope sender is left unmodified by Mailman, and that could potentially cause problems with things like SPF or DKIM, which the sender would need to be aware of. And hopefully you wouldn't use this kind of mechanism on an announcement-only list with thousands of recipients. That said, I can see that this would be a reasonable enhancement to request. > If list admins *really* want to (effectively) discard all bounces, > they can e.g. set bounce_info_stale_after to 1 and then set > bounce_score_threshold to something impossibly high (e.g. 500,000). Keep in mind that I've seen mail loops quickly spin into the thousands in a matter of minutes, especially when the messages are passing through systems that scrub what they consider to be non-useful headers like "Received:". I don't know that there's much of anything you could do about such loops. I think the only thing I'd say here is that I'd tend to be a little more conservative in terms of what I'd call "impossibly high". ;) -- 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 LOPSA member since December 2005. See . From qralston+ml.mailman-developers at andrew.cmu.edu Thu May 11 22:50:14 2006 From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston) Date: Thu, 11 May 2006 16:50:14 -0400 Subject: [Mailman-Developers] thoughts on bounce processing In-Reply-To: References: <7EBC466A807232F7DBFB4EB2@emerald.sei.cmu.edu> Message-ID: <4151C03CCE8911AC299F9BE2@emerald.sei.cmu.edu> On 2006-05-11 at 14:34-05 Brad Knowles wrote: > At 1:24 PM -0400 2006-05-11, James Ralston wrote: > > > The more I think about this, the more I think that silently > > discarding bounces is an error. > > Mailman doesn't silently discard bounces. It does if bounce_processing is set to "no". That's my point: turning off bounce processing should mean "forward the bounces to the list administrator(s)", not "discard bounces". > > There should be two (and only two) options: > > > > 1. Mailman processes all bounces. > > 2. All bounces are forwarded to the list administrator(s). > > In your example above, that would only be appropriate if the AA is > the list administrator. I think a better method would be to have > all bounces sent to the poster, regardless of who that poster is. > If it's an announcement-only list, then presumably you have a > restricted set of people who can post to that list, and any one of > them should be able to handle bounces sent directly back to them. An intriguing thought. But... > This would imply that the envelope sender is left unmodified by > Mailman, and that could potentially cause problems with things like > SPF or DKIM, which the sender would need to be aware of. If the envelope sender is unmodified, then Mailman can't use VERP, which means that the likelihood that the bounce will contain useful information (such as, which address actually bounced) is reduced. :( I suppose Mailman could stuff the original envelope sender header into another header (e.g., "X-Mailman-Original-Env-Sender") and then pull it back out when processing a bounce, but that smells rather hackish to me. Perhaps VERP could be enhanced to encode both the original envelope sender and the recipient? > > If list admins *really* want to (effectively) discard all bounces, > > they can e.g. set bounce_info_stale_after to 1 and then set > > bounce_score_threshold to something impossibly high > > (e.g. 500,000). > > Keep in mind that I've seen mail loops quickly spin into the > thousands in a matter of minutes, especially when the messages are > passing through systems that scrub what they consider to be > non-useful headers like "Received:". > > I don't know that there's much of anything you could do about such > loops. I think the only thing I'd say here is that I'd tend to be a > little more conservative in terms of what I'd call "impossibly > high". ;) Point taken. But situations like this are what the "emergency moderation" setting is for, yes? James From brad at stop.mail-abuse.org Fri May 12 04:54:29 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 11 May 2006 21:54:29 -0500 Subject: [Mailman-Developers] thoughts on bounce processing In-Reply-To: <4151C03CCE8911AC299F9BE2@emerald.sei.cmu.edu> References: <7EBC466A807232F7DBFB4EB2@emerald.sei.cmu.edu> <4151C03CCE8911AC299F9BE2@emerald.sei.cmu.edu> Message-ID: At 4:50 PM -0400 2006-05-11, James Ralston wrote: >> Mailman doesn't silently discard bounces. > > It does if bounce_processing is set to "no". Ahh. Sorry, I had missed that part of the issue. > That's my point: turning > off bounce processing should mean "forward the bounces to the list > administrator(s)", not "discard bounces". s/list administrator(s)/appropriate place/ In some cases, the list moderator(s) might be the appropriate place, in others the original poster will be the appropriate place. I think there's some room here for further discussion. >> This would imply that the envelope sender is left unmodified by >> Mailman, and that could potentially cause problems with things like >> SPF or DKIM, which the sender would need to be aware of. > > If the envelope sender is unmodified, then Mailman can't use VERP, > which means that the likelihood that the bounce will contain useful > information (such as, which address actually bounced) is reduced. :( Not really. VERP could be used, but then that would require that the MTA of the poster would also understand that format. > I suppose Mailman could stuff the original envelope sender header into > another header (e.g., "X-Mailman-Original-Env-Sender") and then pull > it back out when processing a bounce, but that smells rather hackish > to me. That sort of thing may be the only alternative, if you want to have the bounces sent back to the original poster. Sending things to the list moderator(s) or administrator(s) would be simpler, since you wouldn't have to worry what the original envelope sender address was. But that would only help you if the original poster was also one of the list moderator(s) or administrator(s). > Perhaps VERP could be enhanced to encode both the original envelope > sender and the recipient? The problem is that subscribers might have their own plus-style addressing, on top of which we're trying to add VERP, and now you're trying to encode both the envelope sender and envelope recipient in the VERP. That might be theoretically possible, but I think it's going to take a lot more thought and design work to see if that can be done. I suspect it would be a lot easier to do some of the other sorts of things we're talking about. -- 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 LOPSA member since December 2005. See . From sub1.dev.mailman at msquared.id.au Fri May 12 05:53:59 2006 From: sub1.dev.mailman at msquared.id.au (Msquared) Date: Fri, 12 May 2006 11:53:59 +0800 Subject: [Mailman-Developers] thoughts on bounce processing In-Reply-To: <4151C03CCE8911AC299F9BE2@emerald.sei.cmu.edu> References: <7EBC466A807232F7DBFB4EB2@emerald.sei.cmu.edu> <4151C03CCE8911AC299F9BE2@emerald.sei.cmu.edu> Message-ID: <20060512035359.GI14072@sliderule.msquared.com.au> On Thu, May 11, 2006 at 04:50:14PM -0400, James Ralston wrote: > I suppose Mailman could stuff the original envelope sender header into > another header (e.g., "X-Mailman-Original-Env-Sender") and then pull it > back out when processing a bounce, but that smells rather hackish to me. > > Perhaps VERP could be enhanced to encode both the original envelope > sender and the recipient? I suppose this is more for MM3, but if the origina message IDs are preserved in bounce messages perhaps MM could keep a database of all messages that went through it including IDs. When a bounce comes back it could pull the original sender from that database and notify them, the list administrator, someone's next of kin, or whoever depending on what had been configured. Just thinking aloud... :o) Regards, Msquared... From hun at n-dimensional.de Sun May 14 02:06:06 2006 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Sun, 14 May 2006 02:06:06 +0200 Subject: [Mailman-Developers] Mailman "true virtual hosting" and Google SoC In-Reply-To: (Heikki =?utf-8?Q?Lamp=C3=A9n's?= message of "Thu, 4 May 2006 23:33:19 +0300") References: <1145908660.13317.257.camel@resist.wooz.org> Message-ID: <86wtcpsc5t.fsf@n-dimensional.de> "Heikki Lamp?n" writes: > On 4/24/06, Barry Warsaw wrote: >> On Mon, 2006-04-24 at 16:21 +0300, Heikki Lamp?n wrote: >> > I'm wondering about this "true virtual hosting" issue and what is >> > going to happen to it. It will happen some time, it's just a question of when. >> It's not out of the question, although no way can it go into the >> mainline 2.1 branch. Ideally, the work would be done on the Mailman >> trunk for 2.2, although I wouldn't be opposed to an "unofficial" 2.1 >> patch branch if the volunteers were so motivated. It's too big of >> project to go into 2.1 proper though. > Fair enough. Exactly. >> > Maybe I'm just being impatient but as I see it, this vhost stuff >> > should really interest a lot of people. >> >> Definitely. Everyone wants to see it, and it will definitely happen for >> 2.2. It would be awesome if a SoC volunteer wanted to take it on and I >> would be more than happy to mentor the work. Are you a student and are >> you interested in working on it? > > I'm unfortunately already employed during summer time (would've had > been an interesting project). Maybe someone on the list is or knows a > promising victim? I've been busy with other things, but I'm planning to finish the vhost stuff some time in June (if nobody has beat me to it until then). "Finish" would mean that we can go into production here with an unofficial 2.1-vhost branch based on 2.1 (we probably want this sooner than an official 2.2 release can be reasonably be expected to happen). This planning of mine includes getting the vhost branch ported to 2.2 while developing the 2.1 version. The idea is that we can just use the official Mailman code by the Mailman team after the 2.2 release. Practical issues: - I need to get the copyright assignment form stuff done. - Either I have to learn and cope with svk or someone with sufficient karma would need to trust me enough to provide me with svn write access. Then I'd probably best create an svk/svn branch each off 2.1 and 2.2, then start on the 2.1-vhost branch and maintain 2.2-vhost to keep in sync with my main project of 2.1-vhost. OK, and first I'd want to wait until 2006-05-23 to make sure there is no SoC project concurrently working on the vhost issue. Gru?, Uli From t.d.lee at durham.ac.uk Fri May 19 16:19:02 2006 From: t.d.lee at durham.ac.uk (David Lee) Date: Fri, 19 May 2006 15:19:02 +0100 (BST) Subject: [Mailman-Developers] sender-based authorisation Message-ID: Mailman: Proposed sender-based passwords ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note: this is based on Mailman 2.1.8 which, at the time of writing, is the current version. A discussion "approval password linked to sender rather than list?" on mailman-users around 15 May 2006 agreed on the desirability of a variant of the "Approved: password" mechanism, whose permission-granting password would be associated with the email's sender rather than with the list. The motivation is large sites with many "announcement" lists (in our case over 2,000), where the entire membership of each such list is moderated, and where several legitimate senders might regularly need to post single emails to several lists. These lists might well exist in clusters. But the option of allowing unmoderated access for those legitimate senders opens up a major problem with spoofed email. So everyone needs to be moderated. But then the potentially useful moderation-bypass "Approved: listpw" mechanism has the problems of requiring many people to share a particular list's password, and of the passwords across a cluster of lists having to be common. This "shared secret" problem grows even more alarmingly if the list clusters overlap which would force reduction to a single password across many lists, and widespread knowledge (hence leakage potential) of that password. Introducing an "Approval:"-like mechanism, whose password is associated with the sender ("From:"), is intended address all this. Virtual host considerations ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mailman is beginning to allow some virtual hosting (i.e. multiple domains ("... at dom1", "... at dom2"). Although this is currently limited (cannot have the same listname at multiple domains) it is clearly on the roadmap for the future. Accordingly this password proposal attempts to take full account of that direction. New "sender" role ~~~~~~~~~~~~~~~~~ Currently, according to "Mailman/SecurityManager.py": # There are current 5 roles defined in Mailman, [...] # user, list-creator, list-moderator, list-admin, site-admin. That is, five contexts in which passwords are used and supported. Clarification: "user" means the intersection of a particular email address and a particular list: the (in)famous "monthly password reminder" entity. Put another way: the same person (email address) on 'n' different lists is actually 'n' unrelated "users". A new "sender" role is proposed, available across all lists at all virtual hosts. It is implemeted as a site-wide database of email addresses and their passwords, with the same variety of options for encryption and storage as in (or potentially in) the other databases. Across virtual hosts it similarly remains the same, common, sender. Clarification: Unlike a "user", this is a single stored-once entity, representing a single email address across the entire installation. In each list a new list-admin function maintains a set of email addresses, herein called "authorised_senders", that can post through the list. On the GUI, this would present a little like various "*_these_nonmembers". An incoming email can specify "Authorised: sender-password" in the manner of the existing "Approved: list-password" mechanism (headers, first real blank-separated line, etc.). [Note: I have chosen a separate word "Authorised:". Perhaps we can conflate this new concept onto "Approved:" if there would be no loss of functionality. If so, then "authorised_senders" should perhaps be called "approved_senders".] Its processing confirms the "From:" in the list's "authorised_senders", then does an authorisation check against the site-wide "sender" (role) database. (If we conflate "Authorised:" and "Approved:", the password check would potentially need to be done on both the list and the "sender" databases.) If an incoming "Authorised:" email is destined for several lists, perhaps at several virtual hosts, its "From:" is processed within each list as described above against the site-wide "sender" database. Maintenance of "sender" ~~~~~~~~~~~~~~~~~~~~~~~ The new "sender" database requires maintenance. Insertion: How are email addresses and their passwords added? How is it requested? By whom or by what is it implemented? What should be done to detect and prevent malicious (spam-like, DOS-like) mass sign-up? Deletion: How can an email address be removed from the database? When it is removed, how is that reflected back into all the lists which had it in their "authorised_senders" table? (Analogous to removing a file in a filesystem but leaving behind dangling symbolic links.) Should those lists be left alone (but now containing redundant entries) or should their tables be amended? Suppose the deletion from "senders" was accidental or transient: how can any removed entries in the several "authorised_senders" tables be efficently restored? Changes: How does someone maintain (change) their email address and password? If a person changes their email address how is that reflected back to the lists? (See "Deletion".) Intuitively, the database key would have been the email address. But perhaps the real key should rather be some opaque, unique (UUID-like?) entity, with the email address simply being an attribute. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : From msapiro at value.net Fri May 19 17:44:00 2006 From: msapiro at value.net (Mark Sapiro) Date: Fri, 19 May 2006 08:44:00 -0700 Subject: [Mailman-Developers] Why does Mailman delete post recipients from Cc: header? Message-ID: In response to a question on mailman-users, I looked at AvoidDups.py, and I see that if an address is in the Cc: header of a post and is a candidate recipient and is a list member with DontReceiveDupes set, the address is removed from the recipient list and from the Cc: header of the post. I understand why it is removed from the recipient list - that's the whole point - but does anyone know/remember why it is also removed from the Cc: header? This seems unnecessary and inconsistent since it isn't removed from To:, Resent-To: or Resent-Cc:. Also, there is a docstring in the module that refers to an in memory Message-Id: list for avoiding cross-posted dups which I think was in the original patch, but was never incorporated. Perhaps this should be rewritten. -- 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 Fri May 19 18:03:22 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 19 May 2006 11:03:22 -0500 Subject: [Mailman-Developers] sender-based authorisation In-Reply-To: References: Message-ID: At 3:19 PM +0100 2006-05-19, David Lee wrote: > But then the potentially useful moderation-bypass "Approved: listpw" > mechanism has the problems of requiring many people to share a particular > list's password, Yup. > and of the passwords across a cluster of lists having to > be common. I'm not convinced that's necessary. Each list could have their own approval password, and there is no technical reason why they would need to share that password with any other list. That said, there may be operational reasons why you might end up going down this road, such as people not being good at remembering large numbers of passwords. Beyond that, I'm not sure that I can contribute much of anything more to this discussion. -- 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 LOPSA member since December 2005. See . From msapiro at value.net Fri May 19 18:12:09 2006 From: msapiro at value.net (Mark Sapiro) Date: Fri, 19 May 2006 09:12:09 -0700 Subject: [Mailman-Developers] Why does Mailman delete post recipients fromCc: header? In-Reply-To: Message-ID: Mark Sapiro wrote: > >I understand why it is removed from the recipient list - that's the >whole point - but does anyone know/remember why it is also removed >from the Cc: header? This seems unnecessary and inconsistent since it >isn't removed from To:, Resent-To: or Resent-Cc:. I looked at the subversion (from cvs) log messages and found from Barry: process(): If a member has enabled their DontReceiveDuplicates option, we'll also strip their addresses from CC headers in the list copy. This helps keep the CC lines from growing astronomically. I guess that answers the 'why'. Should we try to address the inconsistency? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From t.d.lee at durham.ac.uk Fri May 19 19:15:19 2006 From: t.d.lee at durham.ac.uk (David Lee) Date: Fri, 19 May 2006 18:15:19 +0100 (BST) Subject: [Mailman-Developers] sender-based authorisation In-Reply-To: References: Message-ID: On Fri, 19 May 2006, Brad Knowles wrote: > At 3:19 PM +0100 2006-05-19, David Lee wrote: > > > But then the potentially useful moderation-bypass "Approved: listpw" > > mechanism has the problems of requiring many people to share a particular > > list's password, > > Yup. > > > and of the passwords across a cluster of lists having to > > be common. > > I'm not convinced that's necessary. Each list could have their > own approval password, and there is no technical reason why they > would need to share that password with any other list. One of our site's uses is people in the top-level management of the university sending out an email (a few per week) to a set (order ten) of announcement lists. The set of lists might vary from email to email (e.g. email-1 about exams to the all student lists; email-2 about marking to to the academic-staff list and to the secretarial list; email-3 about holiday cover to all the staff lists). From: a.supremo at here.dom.ain To: list-1 at here.dom.ain, list-2 at here.dom.ain, ... list-10 at here.dom.ain My understanding is that to get this email straight through using the "Approved:" mechanism all those lists (i.e. their superset) would currently need to share a common password. (I haven't seen documented the ability to have multiple one-per-list, "Approved:" lines.) If I've misunderstood this functionality (i.e. perceived limitation) please let me know... it's central to what I'm looking for! And then there might be another cluster of announcement lists, say within a particular department, with a basically different set of people who would post, and so with a different password on their lists. But it might be highly desirable to permit occasional posting by a subset of the former (top-level management) group of people. They certainly won't want to have to know those (different) list-based passwords for the list clusters in and across every department! > That said, there may be operational reasons why you might end up > going down this road, such as people not being good at remembering > large numbers of passwords. Hence my suggestion of a person's (single) personal "sender" password into the overall system, entitling them to send to those Mailman lists whose "authorised_senders" includes them. This might be viewed as (very roughly) analogous to single sign-on. On the big, university-wide lists, the "authorised_senders" group would typically be the university's top-level management, and people such as "postmaster". On the departmental lists, "authorised_senders" might be several (all?) staff in the department, perhaps occasional guests, and (again) some (all?) of the university's top-level management. Does that help. > Beyond that, I'm not sure that I can contribute much of anything > more to this discussion. Simply sanity-checking my reasoning from your experience of mailman. (Whether you agree is another matter!) Until three weeks ago, I had never run a mailman installation, so I feel like a fish almost out of water. Thanks. Best wishes. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : From msapiro at value.net Sat May 20 00:21:31 2006 From: msapiro at value.net (Mark Sapiro) Date: Fri, 19 May 2006 15:21:31 -0700 Subject: [Mailman-Developers] sender-based authorisation In-Reply-To: Message-ID: David Lee wrote: > > From: a.supremo at here.dom.ain > To: list-1 at here.dom.ain, list-2 at here.dom.ain, ... list-10 at here.dom.ain > >My understanding is that to get this email straight through using the >"Approved:" mechanism all those lists (i.e. their superset) would >currently need to share a common password. (I haven't seen documented the >ability to have multiple one-per-list, "Approved:" lines.) You are correct. The alternative is to send 10 individual posts, each to a single list with that list's approval. >Hence my suggestion of a person's (single) personal "sender" password into >the overall system, entitling them to send to those Mailman lists whose >"authorised_senders" includes them. This might be viewed as (very >roughly) analogous to single sign-on. We definitely want to move towards a single 'user identity/account' per person per site with a single authorization and multiple email addresses and subscriptions. Quoting from the todo list # Have one account per user per site, with multiple email addresses and fallbacks. Allow them to subscribe whichever address they want to whichever list, with different options per subscription. Given that infrastructure, it seems simple to implement the authorized poster concept. In the mean time, I think you could accomplish much of what you want with a custom handler. It would need to have access to a user file which defined the user's capabilities and posting password, but it would be simple for it to then use some feature of the message to validate the poster, remove the secret information and set the approved flag in the message metadata (not the Approved: header, but the flag that the Approved header causes to be set.) See Mailman/Handlers/Approve.py for an example of doing approval and see for more on custom handlers. -- 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 Sat May 20 05:51:21 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 19 May 2006 22:51:21 -0500 Subject: [Mailman-Developers] sender-based authorisation In-Reply-To: References: Message-ID: At 6:15 PM +0100 2006-05-19, David Lee wrote: > My understanding is that to get this email straight through using the > "Approved:" mechanism all those lists (i.e. their superset) would > currently need to share a common password. (I haven't seen documented the > ability to have multiple one-per-list, "Approved:" lines.) If you wanted to send to all of those lists with a single message, that's probably true. However, I think that's also a sub-optimal way to send a message to mailing lists. If nothing else, I think it's really ugly for all recipients in all lists to get a complete list of all the other lists that were recipients of the original message. You could resolve that with an umbrella list, but I'm not sure where the list approval mechanism comes into play in that situation. Moreover, if the subset of lists the poster wanted to send to changed, then you'd have to create a new umbrella list, which would be a pain. I'm not sure there is a good/easy solution to this part of the problem, although it is probably mostly just cosmetic. -- 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 LOPSA member since December 2005. See . From barry at python.org Sat May 20 18:30:30 2006 From: barry at python.org (Barry Warsaw) Date: Sat, 20 May 2006 12:30:30 -0400 Subject: [Mailman-Developers] sender-based authorisation In-Reply-To: References: Message-ID: <1148142630.30194.69.camel@geddy.wooz.org> On Fri, 2006-05-19 at 15:21 -0700, Mark Sapiro wrote: > We definitely want to move towards a single 'user identity/account' per > person per site with a single authorization and multiple email > addresses and subscriptions. Quoting from the todo list > Yes, this is definitely on the list! > In the mean time, I think you could accomplish much of what you want > with a custom handler. It would need to have access to a user file > which defined the user's capabilities and posting password, but it > would be simple for it to then use some feature of the message to > validate the poster, remove the secret information and set the > approved flag in the message metadata (not the Approved: header, but > the flag that the Approved header causes to be set.) Another possibility is to extend Approve.py to accept multiple Approved: headers. This would be fairly easy: you need to use Message.get_all() and loop through every header value you found. You'd probably also want to extend the body search to accept multiple Approved lines as the first in a text/plain part. Additionally, you'd probably want to put some mm_cfg.py defined maximum number of headers to accept to cut down on trolling for passwords. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060520/ff782c0e/attachment.pgp From barry at python.org Sat May 20 18:32:01 2006 From: barry at python.org (Barry Warsaw) Date: Sat, 20 May 2006 12:32:01 -0400 Subject: [Mailman-Developers] Why does Mailman delete post recipients fromCc: header? In-Reply-To: References: Message-ID: <1148142721.30194.72.camel@geddy.wooz.org> On Fri, 2006-05-19 at 09:12 -0700, Mark Sapiro wrote: > Mark Sapiro wrote: > > > >I understand why it is removed from the recipient list - that's the > >whole point - but does anyone know/remember why it is also removed > >from the Cc: header? This seems unnecessary and inconsistent since it > >isn't removed from To:, Resent-To: or Resent-Cc:. > > I looked at the subversion (from cvs) log messages and found from Barry: > > process(): If a member has enabled their DontReceiveDuplicates option, > we'll also strip their addresses from CC headers in the list copy. > This helps keep the CC lines from growing astronomically. > > I guess that answers the 'why'. Should we try to address the > inconsistency? We can, although I think in practice it doesn't come up often. I have seen long CC headers but usually the Resents, and even the To header don't get insanely long. But consistency would be good here I think! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060520/577b569f/attachment.pgp From t.d.lee at durham.ac.uk Mon May 22 16:22:50 2006 From: t.d.lee at durham.ac.uk (David Lee) Date: Mon, 22 May 2006 15:22:50 +0100 (BST) Subject: [Mailman-Developers] sender-based authorisation In-Reply-To: References: Message-ID: On Fri, 19 May 2006, Mark Sapiro wrote: > [...] > We definitely want to move towards a single 'user identity/account' per > person per site with a single authorization and multiple email > addresses and subscriptions. Quoting from the todo list > > > # Have one account per user per site, with multiple email addresses and > fallbacks. Allow them to subscribe whichever address they want to > whichever list, with different options per subscription. Thanks for your reply. Much appreciated! (Remember that I'm new to Mailman.) I had seen that item in the "todo". That had felt as if it was oriented towards list members/recipients having a consistent subscription password across all the lists to which they belong (i.e. Mailman's output side) rather than towards posters/senders (Mailman's input side). I could see that in merging these two concepts, while there would be benefits, there might also be drawbacks. (Not sure what those drawbacks would be, but I didn't want to rush into merging two concepts (recipient control; sender control) which might have vital, if subtle, differences.) > Given that infrastructure, it seems simple to implement the authorized > poster concept. This suggests expanding the scope of the recipient-oriented "todo" item to cover potential senders. > In the mean time, I think you could accomplish much of what you want > with a custom handler. It would need to have access to a user file > which defined the user's capabilities and posting password, [...] This would seem to require almost the same data structure and support mechanisms that the "todo" item would require. (Or have I misunderstood?) It feels like a duplication of effort. Wouldn't it be better for any "authorised sender" work that we (our site) might do to be a stepping stone towards achieving that "todo"? (The "todo" had recipients in mind whilst "authorised sender" has posters in mind, but see above for commonality.) > [...] but it > would be simple for it to then use some feature of the message to > validate the poster, remove the secret information and set the > approved flag in the message metadata (not the Approved: header, but > the flag that the Approved header causes to be set.) > > See Mailman/Handlers/Approve.py for an example of doing approval and > see > > for more on custom handlers. ... which (if I understand correctly) would be an application-like thing making use of the services provided by the results of a "todo"-like thing. Summary: The "todo" identifies a use for recipient-oriented accounts. Our "authorised sender" proposal identifies sender-oriented accounts. There is surely scope for signficant (even if not total) overlap in the underlying concepts, data, structures and code. Should we (Mailman community, self included!) start addressing the "todo" account mechanism? -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : From t.d.lee at durham.ac.uk Mon May 22 16:38:20 2006 From: t.d.lee at durham.ac.uk (David Lee) Date: Mon, 22 May 2006 15:38:20 +0100 (BST) Subject: [Mailman-Developers] sender-based authorisation In-Reply-To: <1148142630.30194.69.camel@geddy.wooz.org> References: <1148142630.30194.69.camel@geddy.wooz.org> Message-ID: On Sat, 20 May 2006, Barry Warsaw wrote: > [...] > Another possibility is to extend Approve.py to accept multiple Approved: > headers. [...] OK-ish for techie-like posters. And probably OK for some sites. But for this particular environment at this site, the typical senders are senior university managers, not techies. Even assuming (a big assumption) that (politically) asking them to type ten "Approved:" lines was OK, what about error handling (e.g. two typos in that list? a typo in one of the instances of the "Approved:" word itself causing pw leakage to other lists? when they want (legimately) to post to other lists normally under a department's control? ...) Thanks for the reply. To me (admittedly a complete newcomer to Mailman) the proper solution seems to be in recognising the large commonality of my "authorised sender" query with the "todo" item about personal accounts and going from there. (Also if I, a Mailman newcomer, start charging around in the middle of the code for a local, supposedly "quick fix" usage, I might inadvertently make all sorts of blunders, creating corresponding non-quick support issues.) -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : From msapiro at value.net Tue May 23 17:00:54 2006 From: msapiro at value.net (Mark Sapiro) Date: Tue, 23 May 2006 08:00:54 -0700 Subject: [Mailman-Developers] Topic regexps Message-ID: There is a problem with Topic regexps. The regexp entry is compiled in re.VERBOSE mode. This can be good, but also causes problems as the 'help' doesn't mention this. Further, the description says 'Topic keywords, one per line, to match against each message.' The implication is if I put one two three in the regexp box, that this topic will match keywords 'one', 'two' or 'three', but actually it matches only 'onetwothree'. I see several ways to address this. 1) change the processing of this field to effectively join the lines with '|' - presumably this will break existing multiline entries, but possibly they (at least ones which already contain '|') can be converted. 2) do 1) as a list or mm_cfg option which defaults to not doing it. 3) change the description and help for the regexp to correctly reflect what happens. What do others think? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From barry at python.org Wed May 24 19:12:21 2006 From: barry at python.org (Barry Warsaw) Date: Wed, 24 May 2006 13:12:21 -0400 Subject: [Mailman-Developers] Topic regexps In-Reply-To: References: Message-ID: <1148490741.10975.26.camel@resist.wooz.org> On Tue, 2006-05-23 at 08:00 -0700, Mark Sapiro wrote: > The regexp entry is compiled in re.VERBOSE mode. This can be good, but > also causes problems as the 'help' doesn't mention this. Further, the > description says 'Topic keywords, one per line, to match against each > message.' The implication is if I put > > one > two > three > > in the regexp box, that this topic will match keywords 'one', 'two' or > 'three', but actually it matches only 'onetwothree'. > > I see several ways to address this. > > 1) change the processing of this field to effectively join the lines > with '|' - presumably this will break existing multiline entries, but > possibly they (at least ones which already contain '|') can be > converted. > > 2) do 1) as a list or mm_cfg option which defaults to not doing it. > > 3) change the description and help for the regexp to correctly reflect > what happens. > > What do others think? I have a hard time imagining that anyone would enter one two three and not expect it to match 'one|two|three', so I think I'd opt for 1. I'm not in favor of yet another configuration variable to control this. OTOH, I've never really received much feedback on the whole topics features (thus the dearth of responses to your question ;) so I don't really have a good sense of how people are using this, if they are at all. I'm not sure the verbose interpretation of the text box is the most useful. The other option is to use some special prefix character at the front of the regexp to indicate whether it should be verbose or not. It would have to be something that is impossible in the first position, and it seems like | would be a good choice. Thus if | were in the first position, you'd interpret that to mean each line should be joined with | but if not, then you interpret the entire regexp as a verbose pattern. Thoughts? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060524/8900ce84/attachment.pgp From brad at stop.mail-abuse.org Wed May 24 19:48:26 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed, 24 May 2006 12:48:26 -0500 Subject: [Mailman-Developers] Topic regexps In-Reply-To: <1148490741.10975.26.camel@resist.wooz.org> References: <1148490741.10975.26.camel@resist.wooz.org> Message-ID: At 1:12 PM -0400 2006-05-24, Barry Warsaw wrote: > I have a hard time imagining that anyone would enter > > one > two > three > > and not expect it to match 'one|two|three', so I think I'd opt for 1. That's what I would have expected, and I was very surprised to hear Mark's explanation that this didn't actually happen. > I'm not in favor of yet another configuration variable to control this. > OTOH, I've never really received much feedback on the whole topics > features (thus the dearth of responses to your question ;) so I don't > really have a good sense of how people are using this, if they are at > all. I think the concept is a good one, and on busy lists I would gladly subscribe to a few topics and leave the rest, but I think it needs some additional work before we can get to the point where I'd actually use it. For one thing, you need a way of explicitly selecting the null topic. > I'm not sure the verbose interpretation of the text box is the most > useful. The other option is to use some special prefix character at the > front of the regexp to indicate whether it should be verbose or not. It > would have to be something that is impossible in the first position, and > it seems like | would be a good choice. Thus if | were in the first > position, you'd interpret that to mean each line should be joined with | > but if not, then you interpret the entire regexp as a verbose pattern. Not understanding what a "verbose pattern" is, I'm not really fully understanding this concept. I can say that I think it would be pretty wild to come across a new twist in variable regexps like this, after twenty or so years of mucking about with Unix, etc.... -- 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 LOPSA member since December 2005. See . From msapiro at value.net Fri May 26 05:29:33 2006 From: msapiro at value.net (Mark Sapiro) Date: Thu, 25 May 2006 20:29:33 -0700 Subject: [Mailman-Developers] Topic regexps In-Reply-To: <1148490741.10975.26.camel@resist.wooz.org> Message-ID: Barry Warsaw wrote: > >On Tue, 2006-05-23 at 08:00 -0700, Mark Sapiro wrote: > >> The regexp entry is compiled in re.VERBOSE mode. This can be good, but >> also causes problems as the 'help' doesn't mention this. Further, the >> description says 'Topic keywords, one per line, to match against each >> message.' The implication is if I put >> >> one >> two >> three >> >> in the regexp box, that this topic will match keywords 'one', 'two' or >> 'three', but actually it matches only 'onetwothree'. >> >> I see several ways to address this. >> >> 1) change the processing of this field to effectively join the lines >> with '|' - presumably this will break existing multiline entries, but >> possibly they (at least ones which already contain '|') can be >> converted. >> > >I have a hard time imagining that anyone would enter > >one >two >three > >and not expect it to match 'one|two|three', so I think I'd opt for 1. >I'm not in favor of yet another configuration variable to control this. >OTOH, I've never really received much feedback on the whole topics >features (thus the dearth of responses to your question ;) so I don't >really have a good sense of how people are using this, if they are at >all. I've thought about this some more and what I'm currently thinking is if the topic regexp is multiline, leave it as is in topics, but before compiling it for use, split the lines and then rejoin them with "|", and compile not in VERBOSE mode. I think this would be the natural interpretation from the existing explanation. Then, in order to handle existing multiline topic regexps without breaking them, add code to versions.py to test stored_state.data_version and if it's less than the appropriate value, go through topics and convert any multiline regexp to a single line by deleting unescaped whitespace and comments. >I'm not sure the verbose interpretation of the text box is the most >useful. The other option is to use some special prefix character at the >front of the regexp to indicate whether it should be verbose or not. It >would have to be something that is impossible in the first position, and >it seems like | would be a good choice. Thus if | were in the first >position, you'd interpret that to mean each line should be joined with | >but if not, then you interpret the entire regexp as a verbose pattern. This seems to me to be more of a kludge than my idea of converting the old multiline regexps and just dropping verbose mode all together. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From msapiro at value.net Fri May 26 05:33:25 2006 From: msapiro at value.net (Mark Sapiro) Date: Thu, 25 May 2006 20:33:25 -0700 Subject: [Mailman-Developers] Topic regexps In-Reply-To: Message-ID: Brad Knowles wrote: > > I think the concept is a good one, and on busy lists I would >gladly subscribe to a few topics and leave the rest, but I think it >needs some additional work before we can get to the point where I'd >actually use it. For one thing, you need a way of explicitly >selecting the null topic. There is currently a user option to receive (or not) all posts which don't match any topic. Is this what you mean? > I can say that I think it would be pretty wild to come across a >new twist in variable regexps like this, after twenty or so years of >mucking about with Unix, etc.... Agreed. -- 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 Fri May 26 08:41:19 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 26 May 2006 01:41:19 -0500 Subject: [Mailman-Developers] Topic regexps In-Reply-To: References: Message-ID: At 8:33 PM -0700 2006-05-25, Mark Sapiro wrote: > There is currently a user option to receive (or not) all posts which > don't match any topic. Is this what you mean? Yurffhh. /me removes foot from mouth Yes. /me reinserts food -- 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 LOPSA member since December 2005. See . From jwblist3 at olympus.net Fri May 26 18:42:42 2006 From: jwblist3 at olympus.net (John W. Baxter) Date: Fri, 26 May 2006 09:42:42 -0700 Subject: [Mailman-Developers] Topic regexps In-Reply-To: Message-ID: On 5/25/06 8:29 PM, "Mark Sapiro" wrote: > I've thought about this some more and what I'm currently thinking is if > the topic regexp is multiline, leave it as is in topics, but before > compiling it for use, split the lines and then rejoin them with "|", > and compile not in VERBOSE mode. I think you need to strip any trailing | characters from the strings in the resulting list before joining with |. Otherwise, you might build one||two||three Which clearly isn't what is wanted. Hmmm...I guess I mean "up to one trailing | character"...in case someone really wanted one||two for some really strange reason. > > I think this would be the natural interpretation from the existing > explanation. I agree. When we first installed a Mailman version with topic support, I messed around with it, and it didn't work. Since I didn't care much, I ignored the problem rather than figuring out what I was doing wrong. (This thread has made that obvious, of course.) --John From listservs at egomagick.com Fri May 26 11:13:37 2006 From: listservs at egomagick.com (Joshua Alexander) Date: Fri, 26 May 2006 02:13:37 -0700 Subject: [Mailman-Developers] InviteNewMember question In-Reply-To: References: Message-ID: Hi folks, I'm not sure if this is the right list for this... if so, I apologize, and please let me know where to get support on this. I'm running Mailman on a linux/cpanel server, and trying to hack together an invite_members script, so I took add_members and made minor changes, mostly changing mlist.ApprovedAddMember(userdesc, ack, 0) to mlist.InviteNewMember(userdesc) I'm not sure if that's the correct way to call InviteNewMember, but it worked, mostly... the invite emails went out to some test addresses, but when I click the confirmation link I get: Bug in Mailman version 2.1.6 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. There's nothing recent in the error log, so I'm not sure what to do next. Any help? -Josh From msapiro at value.net Fri May 26 21:23:42 2006 From: msapiro at value.net (Mark Sapiro) Date: Fri, 26 May 2006 12:23:42 -0700 Subject: [Mailman-Developers] InviteNewMember question In-Reply-To: Message-ID: Joshua Alexander wrote: > >I'm not sure if this is the right list for this... if so, I >apologize, and please let me know where to get support on this. I think mailman-users at python.org is the appropriate list. >I'm running Mailman on a linux/cpanel server, But maybe not. See . >and trying to hack >together an invite_members script, so I took add_members and made >minor changes, mostly changing > >mlist.ApprovedAddMember(userdesc, ack, 0) > >to > >mlist.InviteNewMember(userdesc) > >I'm not sure if that's the correct way to call InviteNewMember, but >it worked, mostly... the invite emails went out to some test >addresses, but when I click the confirmation link I get: > >Bug in Mailman version 2.1.6 > >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. > >There's nothing recent in the error log, so I'm not sure what to do next. Find the right Mailman error log. Look in both mm_cfg.py and Defaults.py for assignment to LOG_DIR (mm_cfg.py takes precedence). Or edit the scripts/driver file and change STEALTH_MODE = 1 to STEALTH_MODE = 0 so the traceback will print on the web page. Do other web confirmations work? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From terri at zone12.com Tue May 30 19:21:29 2006 From: terri at zone12.com (Terri Oda) Date: Tue, 30 May 2006 13:21:29 -0400 Subject: [Mailman-Developers] Topic regexps In-Reply-To: <1148490741.10975.26.camel@resist.wooz.org> References: <1148490741.10975.26.camel@resist.wooz.org> Message-ID: <70de898c2365155536236a199e5d5881@zone12.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree that one|two|three makes more sense than onetwothree. I certainly would have expected the former. On 24-May-06, at 1:12 PM, Barry Warsaw wrote: > OTOH, I've never really received much feedback on the whole topics > features (thus the dearth of responses to your question ;) so I don't > really have a good sense of how people are using this, if they are at > all. Just for the record, linuxchix actually does use the topics on one of our lists (used for courses, so we don't have to set up a new list anytime someone wants to give a few lessons on a subject) and I haven't gotten any complaints from our users aside from the odd "please make sure you've got the right subject tag for this course!" stuff. Of course, this could mean that no one uses the topic functionality 'cause they'd rather use clever mutt rules to organize their mail. ;) But I'll assume that the lack of comment on a list that's been running for years is probably a good sign that the topic parser does its job. My only problem with the topics came when I had to explain it to users who might not understand regular expressions. Never was terribly satisfied with this one: http://list.org/mailman-member/node30.html Terri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEfH8kYWvHDqWmQaoRAiF8AJ9r+25W9TEZUJ3u00p6SQCdpR7otgCgvanz o0MZkqzjx/zHIMMEFNZcAOo= =ZsSL -----END PGP SIGNATURE----- From msapiro at value.net Wed May 31 05:38:46 2006 From: msapiro at value.net (Mark Sapiro) Date: Tue, 30 May 2006 20:38:46 -0700 Subject: [Mailman-Developers] Topic regexps In-Reply-To: <70de898c2365155536236a199e5d5881@zone12.com> Message-ID: Terri Oda wrote: > >My only problem with the topics came when I had to explain it to users >who might not understand regular expressions. Never was terribly >satisfied with this one: >http://list.org/mailman-member/node30.html I think it's pretty good. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan