From tkikuchi at is.kochi-u.ac.jp Thu Dec 1 02:26:21 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu, 01 Dec 2005 10:26:21 +0900 Subject: [Mailman-Developers] Scrubber mungs Quoted Printable In-Reply-To: References: Message-ID: <438E513D.6030802@is.kochi-u.ac.jp> Hi Mark, I once used this patch for japanese mailman: This re-generation was rejected by Barry because this may impose heavy load (?). This hack should simplify the charset gotcha just below the patched lines. Or, we may have to introduce a new variable to keep watch if the payload is decoded or not in email.Message.Message class. IMHO, mailing list messages should be in plain text without attachments and those who attach should pay (the load) for it. --- Scrubber.py.orig Thu Dec 1 10:01:45 2005 +++ Scrubber.py Thu Dec 1 10:13:17 2005 @@ -28,6 +28,7 @@ from cStringIO import StringIO from types import IntType, StringType +from email import message_from_string from email.Utils import parsedate from email.Parser import HeaderParser from email.Generator import Generator @@ -313,6 +314,9 @@ Url : %(url)s """), lcset) outer = False + # Re-generation of message instance from stringfied one. + # This should normalize the payloads. + msg = message_from_string(msg.as_string()) # We still have to sanitize multipart messages to flat text because # Pipermail can't handle messages with list payloads. This is a kludge; # def (n) clever hack ;). Mark Sapiro wrote: > Mark Sapiro wrote: > >>I think the fix for the current problem is the following patch - >> >>--- mailman-2.1.6/Mailman/Handlers/Scrubber.py >>+++ mailman-mas/Mailman/Handlers/Scrubber.py >>@@ -376,9 +376,8 @@ >> # Now join the text and set the payload >> sep = _('-------------- next part --------------\n') >> del msg['content-type'] >>- msg.set_payload(sep.join(text), charset) >> del msg['content-transfer-encoding'] >>- msg.add_header('Content-Transfer-Encoding', '8bit') >>+ msg.set_payload(sep.join(text), charset) >> return msg > > > I still think this is the correct fix, but it turns out there are some > tricky issues here that I believe come down to an error in the > set_payload() method. > > Under certain circumstances, in particular when charset is 'iso-8859-1', > > msg.set_payload(text, charset) > > 'apparently' encodes the text as quoted-printable and adds a > > Content-Transfer-Encoding: quoted-printable > > header to msg. I say 'apparently' because if one prints msg or creates > a Generator instance and writes msg to a file, the message is > printed/written as a correct, quoted-printable encoded message, but > > text = msg._payload > or > > text = msg.get_payload() > > gives the original text, not quoted-printable encoded, and > > text = msg.get_payload(decode=1) > > gives a quoted-printable decoding of the original text which is munged > if the original text included '=' in some ways. > > This is a problem for Mailman because if Scrubber is processing > individual messages, the 'apparently' quoted-printable message gets > passed ultimately to SMTPDirect which calls Decorate, and Decorate > does msg.get_payload(decode=1) when adding the header and/or footer > and can mung the message in the process. > > There is also an issue with archiving when the archiver gets a > multipart message which is subsequently flattened by Scrubber. > > The following is a transcript of a Python interactive session that > illustrates the above problems with set_payload() and get_payload(). > This session is with Python 2.4.1, but exactly the same behavior > occurs with 2.3.4 and 2.4.2. > > Python 2.4.1 (#1, May 27 2005, 18:02:40) > [GCC 3.3.3 (cygwin special)] on cygwin > Type "help", "copyright", "credits" or "license" for more information. > >>>>import email >>>> >>>>msg = email.message_from_file(open('plain2.eml')) >>>> >>>>print msg > >>From nobody Mon Nov 28 09:18:41 2005 > From: "Mark Sapiro" > To: list1 at localhost > Subject: HTML - all > Date: Sun, 27 Nov 2005 09:02:33 -0800 > MIME-Version: 1.0 > Content-Type: text/plain; charset="iso-8859-1" > > > How about just a line of stuff with some ==== and a few words. > > X=91**2 (x is 91 squared) > > >>>>del msg['content-type'] >>>>del msg['content-transfer-encoding'] >>>>msg.set_payload(str(msg.get_payload()), 'iso-8859-1') >>>> >>>>print msg > >>From nobody Mon Nov 28 09:18:41 2005 > From: "Mark Sapiro" > To: list1 at localhost > Subject: HTML - all > Date: Sun, 27 Nov 2005 09:02:33 -0800 > MIME-Version: 1.0 > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > How about just a line of stuff with some =3D=3D=3D=3D and a few words. > > X=3D91**2 (x is 91 squared) > > >>>>print msg.get_payload() > > > How about just a line of stuff with some ==== and a few words. > > X=91**2 (x is 91 squared) > > >>>>print msg.get_payload(decode=1) > > > How about just a line of stuff with some == and a few words. > > X`**2 (x is 91 squared) > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From fil at rezo.net Thu Dec 1 11:12:28 2005 From: fil at rezo.net (Fil) Date: Thu, 1 Dec 2005 11:12:28 +0100 Subject: [Mailman-Developers] unknown-charset => shunting Message-ID: <20051201101228.GF2581@rezo.net> Hi, I find it unfortunate when Mailman "shunts" messages with an unknown charset. In this case I have: admin(29184): [----- Mailman Version: 2.1.6b2 -----] admin(29184): [----- Traceback ------] admin(29184): Traceback (most recent call last): admin(29184): File "/var/local/mailman/scripts/driver", line 102, in run_main admin(29184): sys.__stdout__.write(tempstdout.getvalue()) admin(29184): IOError: [Errno 32] Broken pipe admin(29184): [----- Python Information -----] Nov 30 12:02:29 2005 (9795) Uncaught runner exception: unknown encoding: iso-8859-8-i Nov 30 12:02:29 2005 (9795) Traceback (most recent call last): File "/var/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/var/local/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/local/mailman/Mailman/Queue/CommandRunner.py", line 241, in _dispose res.do_command('join') File "/var/local/mailman/Mailman/Queue/CommandRunner.py", line 139, in do_command return handler.process(self, args) File "/var/local/mailman/Mailman/Commands/cmd_subscribe.py", line 88, in process h = make_header(decode_header(realname)) File "/var/local/mailman/pythonlib/email/Header.py", line 144, in make_header h.append(s, charset) File "/var/local/mailman/pythonlib/email/Header.py", line 272, in append ustr = unicode(s, incodec, errors) LookupError: unknown encoding: iso-8859-8-i -- Fil From msapiro at value.net Fri Dec 2 07:33:46 2005 From: msapiro at value.net (Mark Sapiro) Date: Thu, 1 Dec 2005 22:33:46 -0800 Subject: [Mailman-Developers] Problem with Mailman FAQ Wizard Message-ID: Sorry to post this to the whole list, but I don't know what group of people can actually make this needed change. Mailman's FAQ wizard appears to be using the faqconf.py default definition of PROLOGUE, namely PROLOGUE = ''' %(title)s

%(title)s

''' There is a problem with this discussed below. I believe the appropriate thing to do is override this in faqcust.py with PROLOGUE = ''' %(title)s

%(title)s

''' The issue is that "http://www.python.org/pics/RedShort.gif" is a white rectangle, 2000 pixels wide by 8 pixels high with a 4 pixels wide by 3 pixels high red rectangle in it's upper left corner. Some browsers, e.g. MSIE 6.0 and Netscape 7.2 on MS Windows and MSIE 5.2 on Mac OS X repeat the background in 8 pixel high strips, thus giving a red 'gear tooth' pattern down the left side of the page. I think this is distracting, but OK. Other browsers such as Netscape 8.0.4 in both IE and Firefox modes on MS Windows display just a plain white background. I think this is best. Still other browsers such as Netscape 7.1 and Safari 1.3.1 on Mac OS X render the background with a thin, maybe 1 pixel high black space or border between each repetition of the background. This gives the appearance of a background of thin, horizontal, black lines spaced about 8 or 9 pixels apart which makes the text very difficult to read. I think we should make the change above which will give a plain white background in all browsers, which I think is the most pleasing rendition anyway. -- Mark Sapiro Any clod can have the facts; San Francisco Bay Area, California having opinions is an art. - C. McCabe, The Fearless Spectator From ppagee at yahoo.com Thu Dec 1 10:58:07 2005 From: ppagee at yahoo.com (Mike Mimic) Date: Thu, 1 Dec 2005 01:58:07 -0800 (PST) Subject: [Mailman-Developers] Disable reponses to the moderation e-mail Message-ID: <20051201095807.21895.qmail@web31113.mail.mud.yahoo.com> Hi! I tried to find a way to disable responses (command results reponse) to replies which discards hold message from moderators. So I checked a code and find in CommandRunner.py in send_response method: Safety valve for mail loops with misconfigured email 'bots. We don't respond to commands sent with "Precedence: bulk|junk|list" unless they explicitly "X-Ack: yes", but not all mail 'bots are correctly configured, so we max out the number of responses we'll give to an address in a single day. And I tryed this (adding Precedence: list) but discovered that such reply was simply discarded and not processed at all. And not (as I hopped) processed as before, but without a response. So I checked code a little more and found out that send_response does not check precedence anywhere and that _dispose checks it. And if it finds it (without X-Ack: yes) it discards the command. I find comment in send_response misleading. But it would be nice if it worked. So that I can discard messages from my e-mail client and not getting a response. I do not like that for every spam I get on my list Mailman sends me another message. I can check logs or login through web interface to check if messages were correctly discarded. Is there some other way to do this? Mike __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From brad at stop.mail-abuse.org Fri Dec 2 10:28:14 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 2 Dec 2005 10:28:14 +0100 Subject: [Mailman-Developers] Problem with Mailman FAQ Wizard In-Reply-To: References: Message-ID: At 10:33 PM -0800 2005-12-01, Mark Sapiro wrote: > Sorry to post this to the whole list, but I don't know what group of > people can actually make this needed change. Best bet would probably be to send this to webmaster at python.org and maybe a copy to pydotorg at python.org. I've complained about it in the past, but have not been able to convince people that this is an important issue to get resolved. I'll leave the rest of your message intact. > Mailman's FAQ wizard appears to be using the faqconf.py default > definition of PROLOGUE, namely > > PROLOGUE = ''' > > > %(title)s > > > BGCOLOR="#FFFFFF" > TEXT="#000000" > LINK="#AA0000" > VLINK="#906A6A"> >

%(title)s

> ''' > > There is a problem with this discussed below. I believe the appropriate > thing to do is override this in faqcust.py with > > PROLOGUE = ''' > > > %(title)s > > > TEXT="#000000" > LINK="#AA0000" > VLINK="#906A6A"> >

%(title)s

> ''' > > The issue is that "http://www.python.org/pics/RedShort.gif" is a white > rectangle, 2000 pixels wide by 8 pixels high with a 4 pixels wide by 3 > pixels high red rectangle in it's upper left corner. > > Some browsers, e.g. MSIE 6.0 and Netscape 7.2 on MS Windows and MSIE > 5.2 on Mac OS X repeat the background in 8 pixel high strips, thus > giving a red 'gear tooth' pattern down the left side of the page. I > think this is distracting, but OK. > > Other browsers such as Netscape 8.0.4 in both IE and Firefox modes on > MS Windows display just a plain white background. I think this is best. > > Still other browsers such as Netscape 7.1 and Safari 1.3.1 on Mac OS X > render the background with a thin, maybe 1 pixel high black space or > border between each repetition of the background. This gives the > appearance of a background of thin, horizontal, black lines spaced > about 8 or 9 pixels apart which makes the text very difficult to read. > > I think we should make the change above which will give a plain white > background in all browsers, which I think is the most pleasing > rendition anyway. > > -- > Mark Sapiro Any clod can have the facts; > San Francisco Bay Area, California having opinions is an art. - > C. McCabe, The Fearless Spectator > > _______________________________________________ > 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-users%40python.org/ > Unsubscribe: >http://mail.python.org/mailman/options/mailman-developers/brad%40python.org > > Security Policy: >http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From brad at stop.mail-abuse.org Fri Dec 2 10:42:35 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 2 Dec 2005 10:42:35 +0100 Subject: [Mailman-Developers] Use of tabs when folding header lines In-Reply-To: <37DC14690351E04386D42BF916E8DC630754F0CA@RED-MSG-41.redmond.corp. microsoft.com> References: <37DC14690351E04386D42BF916E8DC630754F0CA@RED-MSG-41.redmond.corp. microsoft.com> Message-ID: At 3:20 PM -0800 2005-11-28, Nathan Herring wrote: > I am a member of a list which uses mailman 2.1.2, and I am experiencing > strangeness in Outlook as a result of the modifications mailman performs > on list posts. Note that the latest released version of Mailman is 2.1.6, and there have been a number of improvements made since 2.1.2. It is possible that whatever problem you are experiencing has already been fixed, but you should check the latest code. > Specifically, when it (re)folds the Subject: and/or Thread-Topic: headers, > it replaces a space character in the original subject with a tab character. Also keep in mind that Mailman uses a lot of built-in Python routines for handling stuff, and some of those routines might include the handling and formatting of e-mail messages. You want to make sure that you're using the latest version of Python that is compatible with the version of Mailman you've got. Unfortunately, while the people working on Mailman tend to be pretty well aware of the various mail-related RFCs, the people writing the code and libraries within Python itself may not be. You should at least try to check the code to make sure where the fault lies. Other than that, I can't provide any specific assistance to you, but I would be very curious to know what the real problem is, and where the fault lies. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From msapiro at value.net Fri Dec 2 17:49:27 2005 From: msapiro at value.net (Mark Sapiro) Date: Fri, 2 Dec 2005 08:49:27 -0800 Subject: [Mailman-Developers] [Pydotorg] Problem with Mailman FAQ Wizard In-Reply-To: <20051202133718.GB1089@localhost.localdomain> Message-ID: A.M. Kuchling wrote: >On Fri, Dec 02, 2005 at 10:28:14AM +0100, Brad Knowles wrote: >> > I think we should make the change above which will give a plain white >> > background in all browsers, which I think is the most pleasing >> > rendition anyway. > >I've applied this change. Thank you. It is much appreciated. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From msapiro at value.net Fri Dec 2 18:49:40 2005 From: msapiro at value.net (Mark Sapiro) Date: Fri, 2 Dec 2005 09:49:40 -0800 Subject: [Mailman-Developers] Use of tabs when folding header lines In-Reply-To: Message-ID: Brad Knowles wrote: >At 3:20 PM -0800 2005-11-28, Nathan Herring wrote: > >> Specifically, when it (re)folds the Subject: and/or Thread-Topic: headers, >> it replaces a space character in the original subject with a tab character. > > Also keep in mind that Mailman uses a lot of built-in Python >routines for handling stuff, and some of those routines might include >the handling and formatting of e-mail messages. You want to make >sure that you're using the latest version of Python that is >compatible with the version of Mailman you've got. Unfortunately, >while the people working on Mailman tend to be pretty well aware of >the various mail-related RFCs, the people writing the code and >libraries within Python itself may not be. Brad is correct here. Mailman represents messages as instances of the Python email.Message.Message class and is at the mercy of the methods in that class as far header folding and unfolding are concerned. And, for the record, even the Python 2.4.2 email module folds with a . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From nathanh at microsoft.com Fri Dec 2 11:22:46 2005 From: nathanh at microsoft.com (Nathan Herring) Date: Fri, 02 Dec 2005 02:22:46 -0800 Subject: [Mailman-Developers] Use of tabs when folding header lines -- increasing subject length as a test In-Reply-To: Message-ID: On 12/2/05 1:42:35 AM, "Brad Knowles" wrote: > At 3:20 PM -0800 2005-11-28, Nathan Herring wrote: > >> I am a member of a list which uses mailman 2.1.2, and I am experiencing >> strangeness in Outlook as a result of the modifications mailman performs >> on list posts. > > Note that the latest released version of Mailman is 2.1.6, and > there have been a number of improvements made since 2.1.2. It is > possible that whatever problem you are experiencing has already been > fixed, but you should check the latest code. I admit to not having installed it myself, nor looked at any code (a behavior which is frowned upon by my current employer). However, I did review the archive of this list back through to the 2.1.2 relase mail, and then went through the bug reports without seeing any mention of this problem or a fix that would be relevant. >> Specifically, when it (re)folds the Subject: and/or Thread-Topic: headers, >> it replaces a space character in the original subject with a tab character. > > Also keep in mind that Mailman uses a lot of built-in Python > routines for handling stuff, and some of those routines might include > the handling and formatting of e-mail messages. You want to make > sure that you're using the latest version of Python that is > compatible with the version of Mailman you've got. Unfortunately, > while the people working on Mailman tend to be pretty well aware of > the various mail-related RFCs, the people writing the code and > libraries within Python itself may not be. I'll try to find out what versions of the OS and Python are running on my list administratrix's server, in case that makes a difference. > You should at least try to check the code to make sure where the > fault lies. Aye, there's the rub. If I were permitted, I'd have done it already. :/ > Other than that, I can't provide any specific assistance to you, > but I would be very curious to know what the real problem is, and > where the fault lies. I've increased the subject length of this mail, and removed the "[Mailman-developers]" attribution, so we can see firsthand whether or not this list, which purports to be running 2.1.6, and I presume is running a suitable version of Python, has the same issue. -nh From brad at stop.mail-abuse.org Fri Dec 2 23:43:13 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 2 Dec 2005 23:43:13 +0100 Subject: [Mailman-Developers] Use of tabs when folding header lines -- increasing subject length as a test In-Reply-To: References: Message-ID: At 2:22 AM -0800 2005-12-02, Nathan Herring wrote: >> You should at least try to check the code to make sure where the >> fault lies. > > Aye, there's the rub. If I were permitted, I'd have done it already. :/ The code for Mailman is publicly available for download (see ), and the code for Python is available (see ). Most of the people on this list should be capable of checking the code for themselves. I looked through the various routines in Mailman, and found a case in CookHeaders.py where the white space character is set to tab, but I don't know enough about the internal implementations of the other routines or the class, so I can't be sure how that would affect this particular situation. > I've increased the subject length of this mail, and removed the > "[Mailman-developers]" attribution, so we can see firsthand whether or not > this list, which purports to be running 2.1.6, and I presume is running a > suitable version of Python, has the same issue. We are definitely running Mailman 2.1.6, with Python version 2.3.4. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From msapiro at value.net Sat Dec 3 03:13:20 2005 From: msapiro at value.net (Mark Sapiro) Date: Fri, 2 Dec 2005 18:13:20 -0800 Subject: [Mailman-Developers] Use of tabs when folding header lines --increasing subject length as a test In-Reply-To: Message-ID: Nathan Herring wrote: > >I've increased the subject length of this mail, and removed the >"[Mailman-developers]" attribution, so we can see firsthand whether or not >this list, which purports to be running 2.1.6, and I presume is running a >suitable version of Python, has the same issue. and Mark Sapiro previously wrote: > >Brad is correct here. Mailman represents messages as instances of the >Python email.Message.Message class and is at the mercy of the methods >in that class as far header folding and unfolding are concerned. And, >for the record, even the Python 2.4.2 email module folds with a . Clearly what I said above is not the whole story as Nathan's message that I received from the list had the Subject: folded with a , yet other Mailman related headers in the message, namely List-Unsubscribe: and List-Subscribe: are folded with . Upon closer examination, I see that the email.Header.Header class supports a continuation_ws argument which as Brad notes is used in CookHeaders. The prefix_subject function in CookHeaders attempts to determine the continuation-ws character from the existing header by looking at the first character of the first continuation line of the original subject header. If the header isn't continued or if the first character of the first continuation is not a or , it defaults to a . Thus it will try to preserve the continuation-ws of an already folded incoming subject, but will default to . Thus if the incoming subject is not folded, but addition of the prefix lengthens it sufficiently so it folds, it will be continued with a . BTW, this code has been in CookHeaders since 2.1.1, so I don't think anything will change in this respect between 2.1.2 and 2.1.6. It does seem however, that given RFC 2822, the default continuation-ws character in CookHeaders should be and not . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From nathanh at microsoft.com Sat Dec 3 14:48:37 2005 From: nathanh at microsoft.com (Nathan Herring) Date: Sat, 03 Dec 2005 05:48:37 -0800 Subject: [Mailman-Developers] Use of tabs when folding header lines --increasing subject length as a test In-Reply-To: Message-ID: On 12/2/05 6:13:20 PM, "Mark Sapiro" wrote: > Clearly what I said above is not the whole story as Nathan's message > that I received from the list had the Subject: folded with a , > yet other Mailman related headers in the message, namely > List-Unsubscribe: and List-Subscribe: are folded with . The other interesting one from an Outlook or Entourage perspective is the Thread-Topic, which ends up having a tab inserted into it. > Upon closer examination, I see that the email.Header.Header class > supports a continuation_ws argument which as Brad notes is used in > CookHeaders. The prefix_subject function in CookHeaders attempts to > determine the continuation-ws character from the existing header by > looking at the first character of the first continuation line of the > original subject header. If the header isn't continued or if the first > character of the first continuation is not a or , it > defaults to a . Scripts are another matter than source code, so I took a look. > Thus it will try to preserve the continuation-ws of an already folded > incoming subject, but will default to . Thus if the incoming > subject is not folded, but addition of the prefix lengthens it > sufficiently so it folds, it will be continued with a . It seems that for other headers, like Thread-Topic, even regularly folded items get its folding space turned into a folding tab. > BTW, this code has been in CookHeaders since 2.1.1, so I don't think > anything will change in this respect between 2.1.2 and 2.1.6. > > It does seem however, that given RFC 2822, the default continuation-ws > character in CookHeaders should be and not . >From my reading, it seems that email.Header doesn't preserve the FWS in the original header as it should. It would seem that the only time the continuation-ws parameter should be used is if there are sets of characters that need to be turned into multiple adjacent RFC 2047 encoded-words, as that FWS is not considered to be logically part of the header value, but merely an artifact of encoding. If email.Header did the correct preservation, then it would not matter whether you passed in or . However, it is significantly more likely that you'd find a space in a header (like the Subject) than a tab, so I'd concur with the suggestion about using space as a continuation-ws character. Or, get a fix from Python. And now, off to the Python lists... -nh From cfmd at bredband.net Sat Dec 3 18:44:30 2005 From: cfmd at bredband.net (Magnus Danielson) Date: Sat, 03 Dec 2005 18:44:30 +0100 (CET) Subject: [Mailman-Developers] Learn SPAM Message-ID: <20051203.184430.132019945.cfmd@bredband.net> Hi! I have considered methods to let SPAMs which went under the spamassassin radar (i.e. passed spamassassins check) but failed the member of list check (which has so far been a 100% filter for this category) to be somehow sent into the spamassassin learning process, so that list-admins/moderators can teach the spamassassin filter. When doing this on a larger site like the one which my mailman installation sits on also means that I don't have direct access to the spamassassin processing, so some form of passing may be necessary. I've toyed with these alternatives: 1) The moderator gets the option of click a "Is SPAM" check-box for a caught message. A site-configuration decides weither this means forwarding the spam to an email address, tossing it on an MBOX file or saving it as a separate file. 2) The moderator gets a different default forward email address to a hidden list (learnspam at domain), this hidden list archives the emails as normal but has normally no members. 3) Have the front-end of the first proposal but actually use the normal email listing mechanism of the second proposal. The later of these are really just a quick-and-dirty implementation of the first, but it does have its merits. Any thoughts? Cheers, Magnus From msapiro at value.net Mon Dec 5 03:55:46 2005 From: msapiro at value.net (Mark Sapiro) Date: Sun, 4 Dec 2005 18:55:46 -0800 Subject: [Mailman-Developers] Use of tabs when folding header lines--increasing subject length as a test In-Reply-To: Message-ID: Nathan Herring wrote: > >On 12/2/05 6:13:20 PM, "Mark Sapiro" wrote: > >The other interesting one from an Outlook or Entourage perspective is the >Thread-Topic, which ends up having a tab inserted into it. Yes, and this is significant in that Thread-Topic is an MUA (in your case Microsoft-Entourage) header that is completely untouched by Mailman. Therefore, it would appear simply instantiating an email.Message.Message object and later writing it out is sufficient to cause the header continuation white space to change from to . >> Thus it will try to preserve the continuation-ws of an already folded >> incoming subject, but will default to . Thus if the incoming >> subject is not folded, but addition of the prefix lengthens it >> sufficiently so it folds, it will be continued with a . > >It seems that for other headers, like Thread-Topic, even regularly folded >items get its folding space turned into a folding tab. Yes. The logic of trying to determine and preserve the continuation white space of an already continued, incoming header is specific to Mailman's manipulation of Subject: headers in CookHeaders. It is not done elsewhere in Mailman. >From my reading, it seems that email.Header doesn't preserve the FWS in the >original header as it should. It would seem that the only time the >continuation-ws parameter should be used is if there are sets of characters >that need to be turned into multiple adjacent RFC 2047 encoded-words, as >that FWS is not considered to be logically part of the header value, but >merely an artifact of encoding. If email.Header did the correct >preservation, then it would not matter whether you passed in or >. Actually, the email.Header.Header class is a constructor for Header objects. It does not take a 'header' as an input argument. It makes a class instance from a non-continued string or a list of (data, charset) pairs to be RFC 2047 encoded. See the Python library reference, sec. 12.2.5. The resulting Header instance is continued as necessary using the continuation-ws argument as the leading white space on continued lines. Within the class, continuation-ws defaults to , not . There are really two issues here. The first is that CookHeaders manipulates Subject: headers as Header class objects and unless the incoming Subject: header is already continued with a , it specifies a for the continuation-ws character. This is strictly a Mailman issue. The other issue is that the Python email.Parser class API parses message headers into strings, not Header class instances, and the methods for flattening messages continue long header strings with . This is a Python email library issue. To see it in action, just do the following in an interactive Python session. >>> import email >>> from cStringIO import StringIO >>> from email.Generator import Generator >>> x = email.message_from_string('Header: a long string of words that will be ultimately continued because it\n is too long for one line') >>> x['Subject'] = 'Some other long line which we build here and stick into a header to see what happens' >>> fp = StringIO() >>> g = Generator(fp, maxheaderlen=60) >>> g.flatten(x) >>> text = fp.getvalue() >>> text 'Header: a long string of words that will be ultimately\n\tcontinued because it is too long for one line\nSubject: Some other long line which we build here and stick\n\tinto a header to see what happens\n\n' >>> (Lines 4, 5 and 11 above are each one long line in the original, although they may get wrapped in emailing.) Note that the original Header: was continued with a . The flatten method properly unfolds it but then refolds it with a . Likewise it folds the Subject: with a . -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From msapiro at value.net Tue Dec 6 22:18:13 2005 From: msapiro at value.net (Mark Sapiro) Date: Tue, 6 Dec 2005 13:18:13 -0800 Subject: [Mailman-Developers] Bouncer.py syslog differences In-Reply-To: Message-ID: Adrian Wells wrote: > >It does not appear that more comments have been made on this issue. I am >trying to work with the output of the Mailman logs (Brad Knowles has a >great script > >for this but, it would be preferred to store more information in a >database for reporting- not sure the best way to do this yet) and this >minor difference is slightly annoying. Additionally, as Mark noted, no >reason has been given to explain difference from other "current bounce >score" messages. Here is a patch that should correct this difference: > > >--- Bouncer.py.10.25.2005.original 2005-10-25 12:21:57.000000000 -0400 >+++ Bouncer.py.log.patch 2005-11-11 11:27:08.000000000 -0500 >@@ -145,7 +145,7 @@ > info.score += weight > info.date = day > syslog('bounce', '%s: %s current bounce score: %s', >- member, self.internal_name(), info.score) >+ self.internal_name(), member, info.score) > # Continue to the check phase below > # > # Now that we've adjusted the bounce score for this bounce, let's > > >Unless there is a case against filing this as a bug on SourceForge, I'm >willing to file one within the next couple weeks. The above patch has been committed to CVS. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From adrian at whatifnet.com Tue Dec 6 23:21:38 2005 From: adrian at whatifnet.com (Adrian Wells) Date: Tue, 06 Dec 2005 17:21:38 -0500 Subject: [Mailman-Developers] Bouncer.py syslog differences In-Reply-To: References: Message-ID: Mark Sapiro on Tuesday, December 06, 2005 at 4:18 PM +0000 wrote: >Adrian Wells wrote: >>Unless there is a case against filing this as a bug on SourceForge, I'm >>willing to file one within the next couple weeks. > > >The above patch has been committed to CVS. > Thank you. I had not yet taken the time to submit a bug report to SourceForge and imagine there is no reason to do so now. -Adrian From adrian at whatifnet.com Tue Dec 6 23:22:14 2005 From: adrian at whatifnet.com (Adrian Wells) Date: Tue, 06 Dec 2005 17:22:14 -0500 Subject: [Mailman-Developers] Confirmation Messages and Modified Subject Lines Message-ID: Hello all. I recently discovered a concern with the manner in which Mailman handles confirmation messages with modified subject lines. Normally a confirmation message has a subject line such as: confirm xxx... It is understood that the subject line is not to be modified. With all confirmation subscription messages there is a note sent stating as such. Most recipients have no problem with this, but occasionally before a confirmation message reaches its final destination, a spam filter, virus scanner, mail server, etc will modify the subject line so it arrives modified in the end users' mailbox. For example, a tag like "[BULK]" is added: "[BULK] confirm xxx...". Now the end user follows the directions and does not modify the message BUT it's already modified. This extra text in the subject line causes problems (e.g. replies to confirmations are not successfully processed so an user end does not become a member of the list as he/she would expect). However replying to a confirmation message with a prefix like "Re:" does not seem to create problems, for example: Re: confirm xxx... Would it not be better to have Mailman search for a substring, "confirm xxx..."? This would allow any prefixes to be ignored. If this seems like a reasonable change, which component of Mailman is responsible for this? (still learning how Mailman operates). -Adrian From barry at python.org Wed Dec 7 00:07:49 2005 From: barry at python.org (Barry Warsaw) Date: Tue, 06 Dec 2005 18:07:49 -0500 Subject: [Mailman-Developers] A better way of doing templates? In-Reply-To: <43851AF3.7060303@is.kochi-u.ac.jp> References: <1132786513.20488.153.camel@geddy.wooz.org> <43851AF3.7060303@is.kochi-u.ac.jp> Message-ID: <1133910469.15748.60.camel@geddy.wooz.org> On Thu, 2005-11-24 at 10:44 +0900, Tokio Kikuchi wrote: > How about adding current templates into pot/po and pickup and generate > language templates during "make install." I don't know if it could be > done at all but I will look at it this weekend. I see that this is checked in, which I guess means that the idea is working well for you. Cool! If we're going to generate all the template files at build time, I suppose we should remove all those files (and the directories?) from CVS. It's generally not a good idea to check in files that are generated during the build process. What do you think? > As regards the whole translation process, I've already submitted a patch > to select languages when configuring. This should help separating the > translations from the main developement code base. > http://sourceforge.net/tracker/index.php?func=detail&aid=1298355&group_id=103&atid=300103 Very cool. I've also heard requests to reduce the tarball size by separating the languages out into separate downloads. Does anybody think that's worth doing? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051206/a557ace7/attachment.pgp From msapiro at value.net Wed Dec 7 00:16:47 2005 From: msapiro at value.net (Mark Sapiro) Date: Tue, 6 Dec 2005 15:16:47 -0800 Subject: [Mailman-Developers] Confirmation Messages and Modified SubjectLines In-Reply-To: Message-ID: Adrian Wells wrote: >Hello all. I recently discovered a concern with the manner in which >Mailman handles confirmation messages with modified subject lines. > >Normally a confirmation message has a subject line such as: >confirm xxx... > >It is understood that the subject line is not to be modified. With all >confirmation subscription messages there is a note sent stating as such. >Most recipients have no problem with this, but occasionally before a >confirmation message reaches its final destination, a spam filter, virus >scanner, mail server, etc will modify the subject line so it arrives >modified in the end users' mailbox. For example, a tag like "[BULK]" is >added: "[BULK] confirm xxx...". Now the end user follows the directions >and does not modify the message BUT it's already modified. > >This extra text in the subject line causes problems (e.g. replies to >confirmations are not successfully processed so an user end does not >become a member of the list as he/she would expect). However replying to >a confirmation message with a prefix like "Re:" does not seem to create >problems, for example: Re: confirm xxx... Actually, a single extra field such as "[BULK] confirm token_string" should work OK, but "Re: [BULK] confirm token_string" will not work. This is because if the subject itself is not a valid command, the first 'argument' of the subject is removed and the remainder is tried again, but this is only done once. I once worked up a patch to do it up to twice to handle "Re : confirm token_string" which you might be able to find in the archives of mailman-users at python.org or maybe this list. > >Would it not be better to have Mailman search for a substring, "confirm >xxx..."? This would allow any prefixes to be ignored. > >If this seems like a reasonable change, which component of Mailman is >responsible for this? (still learning how Mailman operates). The code is in the do_command() method in Mailman/Queue/CommandRunner.py -- 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 Wed Dec 7 00:46:00 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed, 7 Dec 2005 00:46:00 +0100 Subject: [Mailman-Developers] Confirmation Messages and Modified SubjectLines In-Reply-To: References: Message-ID: At 3:16 PM -0800 2005-12-06, Mark Sapiro wrote: > I once worked up a patch to do it up to twice to handle "Re : confirm > token_string" which you might be able to find in the archives of > mailman-users at python.org or maybe this list. This should be taken to the logical conclusion. Keep popping off prefixes until something useful can be found, or you run out of data. You should probably also strip out all punctuation, too. Heck, strip out all non-alphanumeric data. > The code is in the do_command() method in Mailman/Queue/CommandRunner.py If I can get some time to look at this within the next few months, I hope to be able to fix this. Thanks! -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From tkikuchi at is.kochi-u.ac.jp Wed Dec 7 01:36:20 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed, 07 Dec 2005 09:36:20 +0900 Subject: [Mailman-Developers] [Mailman-i18n] A better way of doing templates? In-Reply-To: <1133910469.15748.60.camel@geddy.wooz.org> References: <1132786513.20488.153.camel@geddy.wooz.org> <43851AF3.7060303@is.kochi-u.ac.jp> <1133910469.15748.60.camel@geddy.wooz.org> Message-ID: <43962E84.30804@is.kochi-u.ac.jp> Barry Warsaw wrote: > On Thu, 2005-11-24 at 10:44 +0900, Tokio Kikuchi wrote: > > >>How about adding current templates into pot/po and pickup and generate >>language templates during "make install." I don't know if it could be >>done at all but I will look at it this weekend. > > > I see that this is checked in, which I guess means that the idea is > working well for you. Cool! Yeah! ;^) > If we're going to generate all the > template files at build time, I suppose we should remove all those files > (and the directories?) from CVS. It's generally not a good idea to > check in files that are generated during the build process. What do you > think? I'm going to do this as a next step soon. >>As regards the whole translation process, I've already submitted a patch >> to select languages when configuring. This should help separating the >>translations from the main developement code base. >>http://sourceforge.net/tracker/index.php?func=detail&aid=1298355&group_id=103&atid=300103 > > > Very cool. I've also heard requests to reduce the tarball size by > separating the languages out into separate downloads. Does anybody > think that's worth doing? This has also been checked in. I'm going to try hack the release script to separate the languages from the main tarball. Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From msapiro at value.net Wed Dec 7 06:12:52 2005 From: msapiro at value.net (Mark Sapiro) Date: Tue, 6 Dec 2005 21:12:52 -0800 Subject: [Mailman-Developers] Confirmation Messages and Modified Subject Lines In-Reply-To: Message-ID: Brad Knowles wrote: > > This should be taken to the logical conclusion. Keep popping off >prefixes until something useful can be found, or you run out of data. >You should probably also strip out all punctuation, too. Heck, strip >out all non-alphanumeric data. I think Brad is on the right track here, but we can't strip out all non alphanumeric characters because this is common code for all commands sent to the list-request address and valid commands can contain '=', passwords and email addresses. I think the correct approach is to keep popping arguments until you hit a valid command or run out of arguments, but there is an issue here as well, although I think it is already an issue anyway. Here it is. Suppose I send an email to list-request at example.com that has Subject: I want to subscribe to the list and body line subscribe a_paswd nodigest This is a valid subscription email, but if we strip arguments off the subject until we hit a valid command word, we'll try to process the command "subscribe to the list" which will fail and the failure will cause the valid command in the body to be skipped. Of course, the same issue currently exists if the valid command is sent in the body with Subject: subscribe to the list but at least here, it is the users 'fault'. -- 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 Wed Dec 7 06:35:00 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed, 7 Dec 2005 06:35:00 +0100 Subject: [Mailman-Developers] Confirmation Messages and Modified Subject Lines In-Reply-To: References: Message-ID: At 9:12 PM -0800 2005-12-06, Mark Sapiro wrote: > This is a valid subscription email, but if we strip arguments off the > subject until we hit a valid command word, we'll try to process the > command "subscribe to the list" which will fail and the failure will > cause the valid command in the body to be skipped. The easy way to handle that is to go ahead and try to process the body of a message, regardless of the success or failure of the ability to process the subject line. -- 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 fil at rezo.net Wed Dec 7 09:20:06 2005 From: fil at rezo.net (Fil) Date: Wed, 7 Dec 2005 09:20:06 +0100 Subject: [Mailman-Developers] [Mailman-i18n] A better way of doing templates? In-Reply-To: <43962E84.30804@is.kochi-u.ac.jp> References: <1132786513.20488.153.camel@geddy.wooz.org> <43851AF3.7060303@is.kochi-u.ac.jp> <1133910469.15748.60.camel@geddy.wooz.org> <43962E84.30804@is.kochi-u.ac.jp> Message-ID: <20051207082005.GB15456@rezo.net> > > Very cool. I've also heard requests to reduce the tarball size by > > separating the languages out into separate downloads. Does anybody > > think that's worth doing? > > This has also been checked in. I'm going to try hack the release script > to separate the languages from the main tarball. I personnally dissent from this idea; one great strength of free software is its internationalization open to everyone both in participating to translations and using them. Making them "optional" is making the software weaker. If the need for smaller tarballs is real (which I doubt, given the bandwidth and diskspace you need to run Mailman :-) ), one option could be, on the contrary, to have a seperate download link for people who *want* a mono-lingual (supposedly US-English?) Mailman. -- Fil From fil at rezo.net Wed Dec 7 09:22:13 2005 From: fil at rezo.net (Fil) Date: Wed, 7 Dec 2005 09:22:13 +0100 Subject: [Mailman-Developers] "you are removed" message Message-ID: <20051207082213.GC15456@rezo.net> re- I'm a bit annoyed by the fact that the "you have been removed" message is a one-liner subject-only email. Or have I been missing something? -- Fil From bv at opera.com Wed Dec 7 13:08:53 2005 From: bv at opera.com (=?utf-8?Q?Bj=C3=B8rn_Vermo?=) Date: Wed, 07 Dec 2005 13:08:53 +0100 Subject: [Mailman-Developers] [Mailman-i18n] A better way of doing templates? In-Reply-To: <20051207082005.GB15456@rezo.net> References: <1132786513.20488.153.camel@geddy.wooz.org> <43851AF3.7060303@is.kochi-u.ac.jp> <1133910469.15748.60.camel@geddy.wooz.org> <43962E84.30804@is.kochi-u.ac.jp> <20051207082005.GB15456@rezo.net> Message-ID: On Wed, 07 Dec 2005 09:20:06 +0100, Fil wrote: >> > Very cool. I've also heard requests to reduce the tarball size by >> > separating the languages out into separate downloads. Does anybody >> > think that's worth doing? >> >> This has also been checked in. I'm going to try hack the release script >> to separate the languages from the main tarball. > > I personnally dissent from this idea; one great strength of free > software is > its internationalization open to everyone both in participating to > translations and using them. Making them "optional" is making the > software > weaker. > > If the need for smaller tarballs is real (which I doubt, given the > bandwidth > and diskspace you need to run Mailman :-) ), one option could be, on the > contrary, to have a seperate download link for people who > *want* a mono-lingual (supposedly US-English?) Mailman. > May I suggest a zero-lingual base version? The only way to make software truly language independent is to avoid the concept of a "default language". If everybody has to get a language file, developers will be forced to think about localization issues. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ From brad at stop.mail-abuse.org Wed Dec 7 15:39:19 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed, 7 Dec 2005 15:39:19 +0100 Subject: [Mailman-Developers] [Mailman-i18n] A better way of doing templates? In-Reply-To: References: <1132786513.20488.153.camel@geddy.wooz.org> <43851AF3.7060303@is.kochi-u.ac.jp> <1133910469.15748.60.camel@geddy.wooz.org> <43962E84.30804@is.kochi-u.ac.jp> <20051207082005.GB15456@rezo.net> Message-ID: At 1:08 PM +0100 2005-12-07, =?utf-8?Q?Bj=C3=B8rn_Vermo?= wrote: > May I suggest a zero-lingual base version? The only way to make software > truly language independent is to avoid the concept of a "default language". > If everybody has to get a language file, developers will be forced to > think about localization issues. You have to use some sort of tag to translate the message into, and that tag is going to have to exist in some language. And the programmers are going to have to think in some language while writing the code which will handle the tag. Or do you propose that all the programmers are going to have to forget all the native languages they know and instead use randomly generated gibberish tags? How do you propose to maintain that code? When you go talking to other people in the world, do you work in a zero-language manner internally, so that you can make sure that you never have to translate from some native language into another native language? When you can do that for all your native language discussions, you can come back here and share with us how that works and how you would modify that to work with programming languages and i18n. -- 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 Wed Dec 7 16:53:50 2005 From: msapiro at value.net (Mark Sapiro) Date: Wed, 7 Dec 2005 07:53:50 -0800 Subject: [Mailman-Developers] Confirmation Messages andModified Subject Lines In-Reply-To: Message-ID: Brad Knowles wrote: > > The easy way to handle that is to go ahead and try to process the >body of a message, regardless of the success or failure of the >ability to process the subject line. You have to be careful about that, or you may reopen a 2.1.4 hole allowing retrieval of another members password. -- 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 Tue Dec 13 04:11:44 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 13 Dec 2005 12:11:44 +0900 Subject: [Mailman-Developers] Released: Mailman 2.1.7a1 Message-ID: <439E3BF0.7090906@is.kochi-u.ac.jp> Hi Developers and i18ners, Mailman 2.1.7a1 was released for alpha test and i18n translations. Here is excerpts from NEWS file. I thank Mark Sapiro for significant contributions in bug-fixes and document/message brushups. Please fetch it from SF download sites or from http://mm.tkikuchi.net/mailman-2.1.7a1.tgz Cheers, Tokio --------------------------------------------------- Here is a history of user visible changes to Mailman. 2.1.7a1 (13-Dec-2005) Security - The fix for CAN-2005-0202 has been enhanced to issue an appropriate message instead of just quietly dropping ./ and ../ from URLs. - A note on CVE-2005-3573: Although the RFC2231 bug example in the CVE has been solved in mailman-2.1.6, there may be more cases where ToDigest.send_digests() can block regular delivery. We put the send_digests() calling part in try - except clause and leave a message in the error log if something happened in send_digests(). Daily call of cron/senddigests will notify more detail to the site administrator. - List administrators can no longer change the user's option/subscription globally. Site admin can change these only if mm_cfg.ALLOW_SITE_ADMIN_COOKIES is set to Yes. - Script tag is disallowd in edithtml script. - Since probe message for the disabled users may reach unexpected persons, the password was excluded from sendProbe() and probe.txt. Note that the default value of VERP_PROBE has been set to `No' from 2.1.6., thus this change doesn't change the default behavior. New Features - Always remove DomainKey (and similar) headers (1287546) from messages sent to the list. - List owners can customize content filter behavior as not to collapse multipart/alternative to its first content. This allows HTML part to pass through after other content filtering is done. Internationalization - New language: Interlingua. Bug fixes and other patches - Fix MTA/Postfix.py to check aliases group permission in check_perms and fix mailman-install document on this matter (1378270). - Fix private.py to go to the original URL after authorization (1080943). - Fix bounce log score messages to be more consistent. - Fix bin/remove_members to accept no arguments when both --fromall and --file= options are specified. - Change cgi-bin and mail wrapper "group not found" error message to be more descriptive of the actual problem. - Apply the list's ban_list to address changes and admin mass subscribe and invite and to confirmations/approvals of address changes, subscriptions and invitations. - Decode quoted-printable and base64 encoded parts before passing to HTML_TO_PLAIN_TEXT_COMMAND (1367783). - Remove Approve: header from post - treat as Approved: (1355707). - Stop removing line following Approve(d): line in body of post (1318883). - Log post in post log with true sender, not listname-bounces (1287921). - Correctly initialize and remember the list's default_member_moderation attribute in the web list creation page (1263213). - Add PEP263 charset in config_list output (1343100). - header_filter_rules get lost if accessed directly and needed authenti- cation by login page (1230865). - Obscure email when the poster doesn't set full name in 'From:' header. - Take preambles and epilogues into account when calculating message sizes for holding purposes (Mark Sapiro). - Logging/Logger.py unicode transform option (1235567). - bin/update crashes with bogus files (949117). - Bugs and patches: 1212066/1301983 (Date header in create/remove notice) -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From r_correia at telkomsa.net Tue Dec 13 13:33:47 2005 From: r_correia at telkomsa.net (Rui Correia) Date: Tue, 13 Dec 2005 14:33:47 +0200 Subject: [Mailman-Developers] Spam/Scam button Message-ID: <008001c5ffe1$79f91a60$0500000a@Laptop> Hi All I've just been cleaning up a list that I administer and suddenly it came to me that we could have a report Scam/Spam button for such items being sent to Mailman lists. Would this be feasible? I know gmail has such a feature - I don't quite know the process it follows once it is reported. Where I see the biggest advantage of this is that individual mail users are not going to / seldom do go to the trouble of reporting because it is too much trouble. Do be able to do so at the click of a button, would exponentially increase the number of senders being reported. Regards, Rui ________________________________________________ ? ? Rui Correia Advocacy, Media and Language Consultant 38 Finch St, Ontdekkers Park, Roodepoort, Johannesburg, South Africa Tel/ Fax (+27-11) 766-4336 Cell (+27) (0) 83-368-1214 From brad at stop.mail-abuse.org Wed Dec 14 02:38:46 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue, 13 Dec 2005 19:38:46 -0600 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <008001c5ffe1$79f91a60$0500000a@Laptop> References: <008001c5ffe1$79f91a60$0500000a@Laptop> Message-ID: At 2:33 PM +0200 2005-12-13, Rui Correia wrote: > I've just been cleaning up a list that I administer and suddenly it came to > me that we could have a report Scam/Spam button for such items being sent to > Mailman lists. Where would this button exist? Who would use it, and how? > Where I see the biggest advantage of this is that individual mail users are > not going to / seldom do go to the trouble of reporting because it is too > much trouble. Do be able to do so at the click of a button, would > exponentially increase the number of senders being reported. Mailman does not provide the end-user MUA functionality. It is not possible for Mailman to pop up a button in Exchange saying "Report this message as spam?", nor is it possible to support all MUAs in this manner. You could add a new "List-" header which would allow compliant MUAs to give users a single button to click on, but there are currently no MUAs that would support such a feature. Moreover, to whom would they report the message as spam -- the mail servers operated by their own providers, or the mail server(s) operated by the mailing list host? How do you prevent abuse of such a button by an attacker? There are a lot of questions you'd have to answer before you could come up with a reasonable scheme for creating a new "List-" header that would perform the desired function while avoiding the creation of any new major weaknesses. -- 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 brad at stop.mail-abuse.org Wed Dec 14 02:47:17 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Tue, 13 Dec 2005 19:47:17 -0600 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: References: <008001c5ffe1$79f91a60$0500000a@Laptop> Message-ID: At 7:38 PM -0600 2005-12-13, Brad Knowles wrote: > At 2:33 PM +0200 2005-12-13, Rui Correia wrote: > >> I've just been cleaning up a list that I administer and suddenly it came to >> me that we could have a report Scam/Spam button for such items >>being sent to >> Mailman lists. > > Where would this button exist? Who would use it, and how? BTW, this thread is operational in nature, and doesn't really belong on this list. If you wanted to discuss Python code that you've written to help implement such features, then this would be the appropriate place to continue this discussion. Otherwise, this thread should be re-started on mailman-users. -- 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 Dale at Newfield.org Wed Dec 14 05:11:45 2005 From: Dale at Newfield.org (Dale Newfield) Date: Tue, 13 Dec 2005 23:11:45 -0500 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: References: <008001c5ffe1$79f91a60$0500000a@Laptop> Message-ID: <9617-SnapperMsg420417FABFC54C26@[68.244.96.31]> On Tue, 13 Dec 2005 19:38:46 -0600 "Brad Knowles" wrote: > Where would this button exist? Who would use it, and how? That is the clearest part of the suggestion. This would be yet another option in moderation. Now "discard" would have a sibling "discard and report as spam." Whether that option shows up and what "report" means would have to be configured by either a the site admin or maybe a list admin. There are a number of reasonable options corresponding with the various spam tools out there, but they all pretty much boil down to "forward it to a pre-specified email address." Not only is this suggestion appropriate for this list, but I also think I recall a previous discussion where the idea was hashed out. I would be willing to bet there's a patch to implement it, because I think the result of the previous discussion was: "Good idea, but too big a new feature for a patch-level release. Provide a patch and people that want it can use it." -Dale Newfield Dale at Newfield.org From brad at python.org Wed Dec 14 06:34:49 2005 From: brad at python.org (Brad Knowles) Date: Tue, 13 Dec 2005 23:34:49 -0600 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <9617-SnapperMsg420417FABFC54C26@[68.244.96.31]> References: <008001c5ffe1$79f91a60$0500000a@Laptop> <9617-SnapperMsg420417FABFC54C26@[68.244.96.31]> Message-ID: At 11:11 PM -0500 2005-12-13, Dale Newfield wrote: > Not only is this suggestion > appropriate for this list, but I also think I recall a previous discussion > where the idea was hashed out. Unless you're talking about Python code you've developed to implement this feature, or commenting on Python code that someone else has developed to implement this feature, I'm pretty certain that this discussion belongs on mailman-users and not here. When we get down to the point where we're talking about going to the archives of the list to see the previous discussion on this topic, and to see the patch that was produced, etc... then we are definitely into mailman-users territory and not mailman-developers. If Barry or JC disagree, then I'm willing to bow to their greater knowledge on this topic, since they've been moderators of this list longer than I have. If Tokio or Mark disagree, I'm willing to bow to their greater knowledge because I know they've been hacking on the code longer than I've been associated with the project. Anyone else is going to have to work pretty hard to convince me. -- Brad Knowles Python.org Postmaster Team From tkikuchi at is.kochi-u.ac.jp Wed Dec 14 08:38:35 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed, 14 Dec 2005 16:38:35 +0900 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <9617-SnapperMsg420417FABFC54C26@[68.244.96.31]> References: <008001c5ffe1$79f91a60$0500000a@Laptop> <9617-SnapperMsg420417FABFC54C26@[68.244.96.31]> Message-ID: <439FCBFB.3010205@is.kochi-u.ac.jp> Hi, Dale Newfield wrote: > On Tue, 13 Dec 2005 19:38:46 -0600 "Brad Knowles" > wrote: > >> Where would this button exist? Who would use it, and how? > > "forward it to a pre-specified email address." Not only is this suggestion > appropriate for this list, but I also think I recall a previous discussion > where the idea was hashed out. I would be willing to bet there's a patch > to implement it, because I think the result of the previous discussion was: > "Good idea, but too big a new feature for a patch-level release. Provide a > patch and people that want it can use it." > I think you are talking about: http://sourceforge.net/tracker/index.php?func=detail&aid=1008865&group_id=103&atid=300103 Hopefully, we will be back to the MAIN CVS tree for the development of mailman-2.2 after the release of 2.1.7. This should be the chance that the patch is integrated in the 2.2 release. Regards, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From iane at sussex.ac.uk Wed Dec 14 11:21:40 2005 From: iane at sussex.ac.uk (Ian Eiloart) Date: Wed, 14 Dec 2005 10:21:40 +0000 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: References: <008001c5ffe1$79f91a60$0500000a@Laptop> Message-ID: --On 13 December 2005 19:38:46 -0600 Brad Knowles wrote: > You could add a new "List-" header which would allow compliant > MUAs to give users a single button to click on, but there are > currently no MUAs that would support such a feature. There is an extension to Thunderbird which supports List- header URLs. Turns them into clickable links. I'm not sure whether it would work for a new List- header - it might look for only the RFC 2369 defined List- headers. Of course, there's also the issue that such a new List- header has no justification in the RFCs. That is to say, we'd have no reason to believe that anyone would add support for it to any MUA. -- Ian Eiloart Servers Team Sussex University ITS From jag at fsf.org Tue Dec 13 18:55:30 2005 From: jag at fsf.org (Joshua Ginsberg) Date: Tue, 13 Dec 2005 12:55:30 -0500 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <008001c5ffe1$79f91a60$0500000a@Laptop> References: <008001c5ffe1$79f91a60$0500000a@Laptop> Message-ID: <1134496531.9097.3.camel@localhost.localdomain> > I've just been cleaning up a list that I administer and suddenly it came to > me that we could have a report Scam/Spam button for such items being sent to > Mailman lists. Where would you have this button? In the admindb interface? In the post itself somewhere? > Would this be feasible? I know gmail has such a feature - I don't quite know > the process it follows once it is reported. Ay. There's the rub. To whom would it be reported, and what might they do with it once reported? > Where I see the biggest advantage of this is that individual mail users are > not going to / seldom do go to the trouble of reporting because it is too > much trouble. Do be able to do so at the click of a button, would > exponentially increase the number of senders being reported. Yes, but as with all distributed effort spam control measures, who is going to police the mob-ocracy? A good idea, to be sure. But there remain many sticky details to iron out. -jag -- Joshua Ginsberg Free Software Foundation - Senior Systems Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051213/aaa8bc90/attachment.pgp From barry at python.org Thu Dec 15 00:26:16 2005 From: barry at python.org (Barry Warsaw) Date: Wed, 14 Dec 2005 18:26:16 -0500 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <008001c5ffe1$79f91a60$0500000a@Laptop> References: <008001c5ffe1$79f91a60$0500000a@Laptop> Message-ID: <1134602776.11466.17.camel@geddy.wooz.org> On Tue, 2005-12-13 at 14:33 +0200, Rui Correia wrote: > I've just been cleaning up a list that I administer and suddenly it came to > me that we could have a report Scam/Spam button for such items being sent to > Mailman lists. A long while ago, I did an experimental integration of Spambayes with Mailman that had a similar concept. Essentially it let you train ham and spam for its bayesian filter. I'm sure the patch is still on SF, but off-hand I don't know whether it still applies to CVS. While in general I think the mailing list is a lousy place to do spam removal (it is better done upstream of the MLM), I do think we could add some useful controls to help here. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051214/4fe5bf9a/attachment.pgp From barry at python.org Thu Dec 15 00:32:46 2005 From: barry at python.org (Barry Warsaw) Date: Wed, 14 Dec 2005 18:32:46 -0500 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <439FCBFB.3010205@is.kochi-u.ac.jp> References: <008001c5ffe1$79f91a60$0500000a@Laptop> <9617-SnapperMsg420417FABFC54C26@[68.244.96.31]> <439FCBFB.3010205@is.kochi-u.ac.jp> Message-ID: <1134603166.11481.22.camel@geddy.wooz.org> On Wed, 2005-12-14 at 16:38 +0900, Tokio Kikuchi wrote: > I think you are talking about: > http://sourceforge.net/tracker/index.php?func=detail&aid=1008865&group_id=103&atid=300103 > > Hopefully, we will be back to the MAIN CVS tree for the development of > mailman-2.2 after the release of 2.1.7. This should be the chance that > the patch is integrated in the 2.2 release. There's also http://sourceforge.net/tracker/index.php?func=detail&aid=713522&group_id=103&atid=300103 which is my Spambayes integration patch. I do think mailman-developers is a reasonable place to discuss this. We can talk about whether it's even reasonable to have anti-spam defenses in Mailman, and if so whether we want to pick one such product to support, or have a pluggable architecture (possibly shipping one by default). I also think there are interesting usability/user interface questions to ask, as well as whether spam filters should be per-list, site-wide, or domain-wide. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051214/0a57fef9/attachment.pgp From barry at python.org Thu Dec 15 00:34:12 2005 From: barry at python.org (Barry Warsaw) Date: Wed, 14 Dec 2005 18:34:12 -0500 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: References: <008001c5ffe1$79f91a60$0500000a@Laptop> Message-ID: <1134603252.11480.25.camel@geddy.wooz.org> On Wed, 2005-12-14 at 10:21 +0000, Ian Eiloart wrote: > There is an extension to Thunderbird which supports List- header URLs. > Turns them into clickable links. I'm not sure whether it would work for a > new List- header - it might look for only the RFC 2369 defined List- > headers. > > Of course, there's also the issue that such a new List- header has no > justification in the RFCs. That is to say, we'd have no reason to believe > that anyone would add support for it to any MUA. And technically, we'd have to add them as X-List-* headers, so it's very doubtful MUAs would support them. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051214/344af3cc/attachment.pgp From ee at uncanny.net Thu Dec 15 02:22:22 2005 From: ee at uncanny.net (Edward Elhauge) Date: Wed, 14 Dec 2005 17:22:22 -0800 Subject: [Mailman-Developers] Encoding problem: Mailman bails during "Administrative requests" Message-ID: <20051215012222.GA37111@uncanny.net> I asked the Mailman-Users list this question last week, but got no useful replies. Since this is a bug in the code, someone here might know how to proceed. I might add to the original question: Would it help to go to the very latest Mailman release? RRRRRRRRRRRRRRRRRRRRRRRR I'd like some help on dealing with this problem permanently. I've been getting this behavior every couple of months and haven't found a good solution yet. The way it happens is that I'm on the "Administrative requests" page for some mailing list and when I submit the deletion requests I get the following reply from the browser: 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. Usually you can then go back an delete individual entries, but there will be one or more that produce the error, with this sort of traceback (below): I take it that the email in question (SPAM email) isn't properly encoded. Any idea on how to get around this problem? In the past I've gone into the queues and deleted files, etc, but the process isn't easy, and of course I won't get any cooperation from the SPAMers sending the messages. The OS is FreeBSD 4.9 and Mailman is 2.1.6_1, built from source. ========== TRACEBACK START Dec 11 13:13:52 2005 admin(10012): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(10012): [----- Mailman Version: 2.1.6 -----] admin(10012): [----- Traceback ------] admin(10012): Traceback (most recent call last): admin(10012): File "/usr/local/mailman/scripts/driver", line 101, in run_main admin(10012): main() admin(10012): File "/usr/local/mailman/Mailman/Cgi/admindb.py", line 163, in main admin(10012): process_form(mlist, doc, cgidata) admin(10012): File "/usr/local/mailman/Mailman/Cgi/admindb.py", line 713, in process_form admin(10012): forward, forwardaddr) admin(10012): File "/usr/local/mailman/Mailman/ListAdmin.py", line 167, in HandleRequest admin(10012): forward, addr) admin(10012): File "/usr/local/mailman/Mailman/ListAdmin.py", line 353, in __handlepost admin(10012): syslog('vette', note) admin(10012): File "/usr/local/mailman/Mailman/Logging/Syslog.py", line 40, in write admin(10012): self.write_ex(kind, msg, args, kws) admin(10012): File "/usr/local/mailman/Mailman/Logging/Syslog.py", line 58, in write_ex admin(10012): logf.write(msg + '\n') admin(10012): File "/usr/local/mailman/Mailman/Logging/StampedLogger.py", line 73, in write admin(10012): Logger.write(self, "%s %s" % (prefix, msg)) admin(10012): File "/usr/local/mailman/Mailman/Logging/Logger.py", line 91, in write admin(10012): f.write(msg) admin(10012): UnicodeEncodeError: 'ascii' codec can't encode character u'\xf3' in position 99: ordinal not in range(128) admin(10012): [----- Python Information -----] admin(10012): sys.version = 2.4.2 (#2, Nov 7 2005, 19:05:41) [GCC 2.95.4 20020320 [FreeBSD]] admin(10012): sys.executable = /usr/local/bin/python admin(10012): sys.prefix = /usr/local admin(10012): sys.exec_prefix = /usr/local admin(10012): sys.path = /usr/local admin(10012): sys.platform = freebsd4 admin(10012): [----- Environment Variables -----] admin(10012): HTTP_REFERER: http://list.uncanny.net/mailman/admindb/wsa-talk admin(10012): SERVER_SOFTWARE: Apache/1.3.33 admin(10012): SCRIPT_NAME: /mailman/admindb admin(10012): SERVER_SIGNATURE:
Apache/1.3.33 Server at list.uncanny.net Port 80
admin(10012): admin(10012): REQUEST_METHOD: POST admin(10012): HTTP_KEEP_ALIVE: 300 admin(10012): SERVER_PROTOCOL: HTTP/1.1 admin(10012): QUERY_STRING: admin(10012): CONTENT_LENGTH: 61108 admin(10012): HTTP_ACCEPT_CHARSET: ISO-8859-1, utf-8;q=0.66, *;q=0.66 admin(10012): HTTP_USER_AGENT: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 admin(10012): HTTP_CONNECTION: keep-alive admin(10012): HTTP_COOKIE: admin(10012): SERVER_NAME: list.uncanny.net admin(10012): REMOTE_ADDR: 192.168.49.49 admin(10012): PATH_TRANSLATED: /Web/hosts/list.uncanny.net/public_html/wsa-talk admin(10012): SERVER_PORT: 80 admin(10012): SERVER_ADDR: 192.168.100.225 admin(10012): DOCUMENT_ROOT: /Web/hosts/list.uncanny.net/public_html admin(10012): PYTHONPATH: /usr/local/mailman admin(10012): SCRIPT_FILENAME: /Web/hosts/list.uncanny.net/public_html/mailman/admindb admin(10012): SERVER_ADMIN: webmaster at uncanny.net admin(10012): HTTP_HOST: list.uncanny.net admin(10012): REQUEST_URI: /mailman/admindb/wsa-talk admin(10012): HTTP_ACCEPT: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1 admin(10012): GATEWAY_INTERFACE: CGI/1.1 admin(10012): REMOTE_PORT: 33142 admin(10012): HTTP_ACCEPT_LANGUAGE: en-us admin(10012): CONTENT_TYPE: application/x-www-form-urlencoded admin(10012): HTTP_ACCEPT_ENCODING: gzip,deflate,compress,identity admin(10012): UNIQUE_ID: Q5yWc8CoZOEAACbkeKA admin(10012): PATH_INFO: /wsa-talk ========== TRACEBACK END -- Edward Elhauge "One allows himself to be fooled once, to be fooled twice; but he who permits himself always to be fooled remains a fool." -- Rudolf Rocker From tkikuchi at is.kochi-u.ac.jp Thu Dec 15 03:48:49 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Thu, 15 Dec 2005 11:48:49 +0900 Subject: [Mailman-Developers] Encoding problem: Mailman bails during "Administrative requests" In-Reply-To: <20051215012222.GA37111@uncanny.net> References: <20051215012222.GA37111@uncanny.net> Message-ID: <43A0D991.4040103@is.kochi-u.ac.jp> Hi, Can you test attached patch in your system? My system accepts non-ascii characters in logging and does not reproduce your error. Edward Elhauge wrote: > I asked the Mailman-Users list this question last week, but got no > useful replies. Since this is a bug in the code, someone here might > know how to proceed. > > I might add to the original question: Would it help to go to the very > latest Mailman release? > > RRRRRRRRRRRRRRRRRRRRRRRR > > I'd like some help on dealing with this problem permanently. I've been > getting this behavior every couple of months and haven't found a good > solution yet. > > The way it happens is that I'm on the "Administrative requests" page for > some mailing list and when I submit the deletion requests I get the > following reply from the browser: > 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. > > Usually you can then go back an delete individual entries, but there > will be one or more that produce the error, with this sort of traceback > (below): > > I take it that the email in question (SPAM email) isn't properly > encoded. Any idea on how to get around this problem? In the past I've > gone into the queues and deleted files, etc, but the process isn't easy, > and of course I won't get any cooperation from the SPAMers sending the > messages. > > The OS is FreeBSD 4.9 and Mailman is 2.1.6_1, built from source. > > ========== TRACEBACK START > Dec 11 13:13:52 2005 admin(10012): > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > admin(10012): [----- Mailman Version: 2.1.6 -----] > admin(10012): [----- Traceback ------] > admin(10012): Traceback (most recent call last): > admin(10012): File "/usr/local/mailman/scripts/driver", line 101, in > run_main > admin(10012): main() > admin(10012): File "/usr/local/mailman/Mailman/Cgi/admindb.py", line > 163, in main > admin(10012): process_form(mlist, doc, cgidata) > admin(10012): File "/usr/local/mailman/Mailman/Cgi/admindb.py", line > 713, in process_form > admin(10012): forward, forwardaddr) > admin(10012): File "/usr/local/mailman/Mailman/ListAdmin.py", line > 167, in HandleRequest > admin(10012): forward, addr) > admin(10012): File "/usr/local/mailman/Mailman/ListAdmin.py", line > 353, in __handlepost > admin(10012): syslog('vette', note) > admin(10012): File "/usr/local/mailman/Mailman/Logging/Syslog.py", > line 40, in write > admin(10012): self.write_ex(kind, msg, args, kws) > admin(10012): File "/usr/local/mailman/Mailman/Logging/Syslog.py", > line 58, in write_ex > admin(10012): logf.write(msg + '\n') > admin(10012): File > "/usr/local/mailman/Mailman/Logging/StampedLogger.py", line 73, in write > admin(10012): Logger.write(self, "%s %s" % (prefix, msg)) > admin(10012): File "/usr/local/mailman/Mailman/Logging/Logger.py", > line 91, in write > admin(10012): f.write(msg) > admin(10012): UnicodeEncodeError: 'ascii' codec can't encode character > u'\xf3' in position 99: ordinal not in range(128) > admin(10012): [----- Python Information -----] > admin(10012): sys.version = 2.4.2 (#2, Nov 7 2005, 19:05:41) > [GCC 2.95.4 20020320 [FreeBSD]] > admin(10012): sys.executable = /usr/local/bin/python > admin(10012): sys.prefix = /usr/local > admin(10012): sys.exec_prefix = /usr/local > admin(10012): sys.path = /usr/local > admin(10012): sys.platform = freebsd4 > admin(10012): [----- Environment Variables -----] > admin(10012): HTTP_REFERER: > http://list.uncanny.net/mailman/admindb/wsa-talk > admin(10012): SERVER_SOFTWARE: Apache/1.3.33 > admin(10012): SCRIPT_NAME: /mailman/admindb > admin(10012): SERVER_SIGNATURE:
Apache/1.3.33 Server at > list.uncanny.net Port 80
> admin(10012): > admin(10012): REQUEST_METHOD: POST > admin(10012): HTTP_KEEP_ALIVE: 300 > admin(10012): SERVER_PROTOCOL: HTTP/1.1 > admin(10012): QUERY_STRING: > admin(10012): CONTENT_LENGTH: 61108 > admin(10012): HTTP_ACCEPT_CHARSET: ISO-8859-1, utf-8;q=0.66, *;q=0.66 > admin(10012): HTTP_USER_AGENT: Mozilla/5.0 (X11; U; Linux i686; en-US; > rv:0.9.2.1) Gecko/20010901 > admin(10012): HTTP_CONNECTION: keep-alive > admin(10012): HTTP_COOKIE: > admin(10012): SERVER_NAME: list.uncanny.net > admin(10012): REMOTE_ADDR: 192.168.49.49 > admin(10012): PATH_TRANSLATED: > /Web/hosts/list.uncanny.net/public_html/wsa-talk > admin(10012): SERVER_PORT: 80 > admin(10012): SERVER_ADDR: 192.168.100.225 > admin(10012): DOCUMENT_ROOT: /Web/hosts/list.uncanny.net/public_html > admin(10012): PYTHONPATH: /usr/local/mailman > admin(10012): SCRIPT_FILENAME: > /Web/hosts/list.uncanny.net/public_html/mailman/admindb > admin(10012): SERVER_ADMIN: webmaster at uncanny.net > admin(10012): HTTP_HOST: list.uncanny.net > admin(10012): REQUEST_URI: /mailman/admindb/wsa-talk > admin(10012): HTTP_ACCEPT: text/xml, application/xml, > application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, > image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1 > admin(10012): GATEWAY_INTERFACE: CGI/1.1 > admin(10012): REMOTE_PORT: 33142 > admin(10012): HTTP_ACCEPT_LANGUAGE: en-us > admin(10012): CONTENT_TYPE: application/x-www-form-urlencoded > admin(10012): HTTP_ACCEPT_ENCODING: gzip,deflate,compress,identity > admin(10012): UNIQUE_ID: Q5yWc8CoZOEAACbkeKA > admin(10012): PATH_INFO: /wsa-talk > ========== TRACEBACK END > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Syslog.py.patch Url: http://mail.python.org/pipermail/mailman-developers/attachments/20051215/d63f7cd2/Syslog.py-0001.pot From jwblist at loricamail.com Thu Dec 15 04:36:48 2005 From: jwblist at loricamail.com (John W. Baxter) Date: Wed, 14 Dec 2005 19:36:48 -0800 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <1134603166.11481.22.camel@geddy.wooz.org> Message-ID: On 12/14/05 3:32 PM, "Barry Warsaw" wrote: > I do think mailman-developers > is a reasonable place to discuss this. We can talk about whether it's > even reasonable to have anti-spam defenses in Mailman, and if so whether > we want to pick one such product to support, or have a pluggable > architecture (possibly shipping one by default). > > I also think there are interesting usability/user interface questions to > ask, as well as whether spam filters should be per-list, site-wide, or > domain-wide. We're happy with spam and virus defenses in the MTA which receives from the world and does the spam and virus work before handing off the messages to the MTA on the Mailman machine. The Mailman machine can't be reached on port 25 (or 587 or 465) from the world. If anything is shipped with Mailman (beyond tuneups to what is there now, which we mostly don't have to use), we'd likely want it able to be turned off. --John From sub1.dev.mailman at msquared.id.au Thu Dec 15 05:04:46 2005 From: sub1.dev.mailman at msquared.id.au (Msquared) Date: Thu, 15 Dec 2005 12:04:46 +0800 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <1134496531.9097.3.camel@localhost.localdomain> References: <008001c5ffe1$79f91a60$0500000a@Laptop> <1134496531.9097.3.camel@localhost.localdomain> Message-ID: <20051215040446.GT28460@sliderule.msquared.com.au> On Tue, Dec 13, 2005 at 12:55:30PM -0500, Joshua Ginsberg wrote: > > Would this be feasible? I know gmail has such a feature - I don't > > quite know the process it follows once it is reported. > > Ay. There's the rub. To whom would it be reported, and what might they > do with it once reported? Perhaps spamcop? This can be done simply by forwarding the offending spam as an attachment to a spamcop email address that you are given for submissions. Regards, Msquared... From ee at uncanny.net Thu Dec 15 09:39:35 2005 From: ee at uncanny.net (Edward Elhauge) Date: Thu, 15 Dec 2005 00:39:35 -0800 Subject: [Mailman-Developers] Encoding problem: Mailman bails during "Administrative requests" In-Reply-To: <43A0D991.4040103@is.kochi-u.ac.jp> References: <20051215012222.GA37111@uncanny.net> <43A0D991.4040103@is.kochi-u.ac.jp> Message-ID: <20051215083935.GA37522@uncanny.net> * Tokio Kikuchi wrote on [2005-12-14 18:49]: > Hi, > > Can you test attached patch in your system? My system accepts non-ascii > characters in logging and does not reproduce your error. Your patch worked. And yes I have Python 2.4.2. Thank you very much. I'd like to ask this list another question. Would there be any philosophical objection to a config flag in Python that would /dev/null the "Post by non-member to a members-only list"? I've done this in the past, for older versions, but not in a configurable form. I'd be would be willing to submit a patch for this as a per-maillist configurable feature if it had a chance to be folded into a release. This feature makes sense if you have a heavily spam targeted list. It's also less blunt than the "Discard all messages marked Defer". > Edward Elhauge wrote: > >I asked the Mailman-Users list this question last week, but got no > >useful replies. Since this is a bug in the code, someone here might > >know how to proceed. > > > >I might add to the original question: Would it help to go to the very > >latest Mailman release? > > > >RRRRRRRRRRRRRRRRRRRRRRRR > > > >I'd like some help on dealing with this problem permanently. I've been > >getting this behavior every couple of months and haven't found a good > >solution yet. > > > >The way it happens is that I'm on the "Administrative requests" page for > >some mailing list and when I submit the deletion requests I get the > >following reply from the browser: > > Bug in Mailman version 2.1.6 ... -- Edward Elhauge "One allows himself to be fooled once, to be fooled twice; but he who permits himself always to be fooled remains a fool." -- Rudolf Rocker From brad at stop.mail-abuse.org Thu Dec 15 10:06:32 2005 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu, 15 Dec 2005 03:06:32 -0600 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <1134602776.11466.17.camel@geddy.wooz.org> References: <008001c5ffe1$79f91a60$0500000a@Laptop> <1134602776.11466.17.camel@geddy.wooz.org> Message-ID: At 6:26 PM -0500 2005-12-14, Barry Warsaw wrote: > While in general I think the mailing list is a lousy place to do spam > removal (it is better done upstream of the MLM), I do think we could add > some useful controls to help here. I can certainly see the advantage in allowing Mailman to take advantage of additional information placed within the headers of the message by the anti-spam processing system (improved in 2.1.6 over previous versions). And I can see the usefulness of having a "discard and report as spam" option for list owners and moderators, as mentioned by Dale -- basically, just forward the message to a pre-configured e-mail address. However, I would seriously question the usefulness of trying to integrate a full-blown anti-spam system into Mailman (e.g., SpamBayes). IMO, that kind of thing needs to be integrated into the MTA, not Mailman. My bigger concern here is that people understand who sees this "discard as spam" button, and how it works. This is not something that would be exposed or otherwise available to the regular mailing list recipients, and I believe that it will be important to manage user expectations in this respect. -- 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 lists05 at equinephotoart.com Thu Dec 15 00:04:23 2005 From: lists05 at equinephotoart.com (JC Dill) Date: Wed, 14 Dec 2005 15:04:23 -0800 Subject: [Mailman-Developers] On-topic-ness for -users and -dev In-Reply-To: References: <008001c5ffe1$79f91a60$0500000a@Laptop> <9617-SnapperMsg420417FABFC54C26@[68.244.96.31]> Message-ID: <43A0A4F7.1050706@equinephotoart.com> Brad Knowles wrote: > Unless you're talking about Python code you've developed to > implement this feature, or commenting on Python code that someone > else has developed to implement this feature, I'm pretty certain that > this discussion belongs on mailman-users and not here. > > When we get down to the point where we're talking about going to > the archives of the list to see the previous discussion on this > topic, and to see the patch that was produced, etc... then we are > definitely into mailman-users territory and not mailman-developers. > > If Barry or JC disagree, then I'm willing to bow to their greater > knowledge on this topic, since they've been moderators of this list > longer than I have. If Tokio or Mark disagree, I'm willing to bow to > their greater knowledge because I know they've been hacking on the > code longer than I've been associated with the project. IMHO, -users is for discussions about using mailman (installing it, using the features it has, integrating it with other software, etc.). The posts we are hoping to keep OFF of -dev and ON -users are the posts by users who are having what they believe are "complicated" use problems and they want "advanced support" and thus try to post a -users appropriate question to -dev to get an answer faster or from someone with more "knowledge" than those who answer posts on -users. (This is almost always an inappropriate use of -dev and an intrusion on developer time.) As long as the topic brought here is about *how* to develop a new feature, I believe it's on-topic for -dev. It can often be a good idea to get feedback on the idea and the proposed implementation before spending time on writing the code. This way one can avoid writing one's way into a rat-hole because of a lack of knowledge about why it is the way it is now, and learn the best way to incorporate the proposed fix into the existing design. Then go code it! I believe the discussion about a "this is spam" button is appropriate for -dev. I agree that there are a lot of technical issues that need to be addressed about if or how to implement it.[1] I believe that -dev IS the right list for that discussion. When all is said and done though, I'm not a developer. My role here is more of "product manager" - I help with input on priorities, user interface, and of course with the boring details of administering -users and -dev so that the developers can spend their time on actual code development. So Barry (and Tokio and Mark, et al) really have the final say on what they want -dev to include or exclude. Until one of the key developers opines that "this is off-topic" I encourage using -dev for further discussion on the "this is spam" button topic. jc [1] Does it belong in the headers, the footer, the body? Should it be a configuration option to place it in one or more of these locations? What happens when the button (or link) is clicked? What if non-spam is reported? What about RFCs? Etc. From jag at fsf.org Thu Dec 15 17:14:33 2005 From: jag at fsf.org (Joshua Ginsberg) Date: Thu, 15 Dec 2005 11:14:33 -0500 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: References: <008001c5ffe1$79f91a60$0500000a@Laptop> <1134602776.11466.17.camel@geddy.wooz.org> Message-ID: <1134663274.12150.1.camel@localhost.localdomain> I personally agree that MM is a poor place to do spam management. What we're considering doing is using some Courier-IMAP-fu to make it work all pretty like. If SA/dspam/whatever tags a post to a list as spam, it is delivered to an IMAP mailbox folder that the list administrators can access. To approve messages mismarked as spam, they simply move the message to another IMAP folder that is just a pipe back into Mailman. -jag On Thu, 2005-12-15 at 03:06 -0600, Brad Knowles wrote: > At 6:26 PM -0500 2005-12-14, Barry Warsaw wrote: > > > While in general I think the mailing list is a lousy place to do spam > > removal (it is better done upstream of the MLM), I do think we could add > > some useful controls to help here. > > I can certainly see the advantage in allowing Mailman to take > advantage of additional information placed within the headers of the > message by the anti-spam processing system (improved in 2.1.6 over > previous versions). And I can see the usefulness of having a > "discard and report as spam" option for list owners and moderators, > as mentioned by Dale -- basically, just forward the message to a > pre-configured e-mail address. > > However, I would seriously question the usefulness of trying to > integrate a full-blown anti-spam system into Mailman (e.g., > SpamBayes). IMO, that kind of thing needs to be integrated into the > MTA, not Mailman. > > > My bigger concern here is that people understand who sees this > "discard as spam" button, and how it works. This is not something > that would be exposed or otherwise available to the regular mailing > list recipients, and I believe that it will be important to manage > user expectations in this respect. > -- Joshua Ginsberg Free Software Foundation - Senior Systems Administrator -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051215/8cb611a1/attachment.pgp From nigel.metheringham at dev.intechnology.co.uk Thu Dec 15 17:27:39 2005 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Thu, 15 Dec 2005 16:27:39 +0000 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <1134663274.12150.1.camel@localhost.localdomain> References: <008001c5ffe1$79f91a60$0500000a@Laptop> <1134602776.11466.17.camel@geddy.wooz.org> <1134663274.12150.1.camel@localhost.localdomain> Message-ID: <1134664059.21766.14.camel@localhost.localdomain> While agreeing that MM is not really a good spam control place, my life would be made easier if:- * Marking a message as spam killed all other messages sent by the same sender address to that and all other lists currently awaiting moderation. * Marking a message as spam killed all other messages sent with the same subject to that and all other lists currently awaiting moderation. Those 2 together would reduce the messages I see in moderation substantially - in general I get multiple lists hit with copies of the same stuff within a few seconds.... Additionally automatically discarding messages where identical subject combos hit *different* lists on the box and both going to moderation within a short timeframe would also be a great helper. Although frankly I'm tempted to just say sod it and make everything that would be moderated get trashed. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From rmg at terc.edu Thu Dec 15 17:51:49 2005 From: rmg at terc.edu (Robby Griffin) Date: Thu, 15 Dec 2005 11:51:49 -0500 Subject: [Mailman-Developers] Encoding problem: Mailman bails during "Administrative requests" In-Reply-To: <20051215083935.GA37522@uncanny.net> References: <20051215012222.GA37111@uncanny.net> <43A0D991.4040103@is.kochi-u.ac.jp> <20051215083935.GA37522@uncanny.net> Message-ID: On Dec 15, 2005, at 03:39, Edward Elhauge wrote: > I'd like to ask this list another question. Would there be any > philosophical objection to a config flag in Python that would > /dev/null the "Post by non-member to a members-only list"? > > I've done this in the past, for older versions, but not in a > configurable form. I'd be would be willing to submit a patch > for this as a per-maillist configurable feature if it had > a chance to be folded into a release. Then I take it you haven't used a "newer" version yet? It sounds like you want to set DEFAULT_GENERIC_NONMEMBER_ACTION = 3 in mm_cfg.py, or twiddle the setting to "Discard" on some of your lists. The generic_nonmember_setting appears second from the bottom on the admin//privacy/sender page. --Robby From lists05 at equinephotoart.com Thu Dec 15 19:47:59 2005 From: lists05 at equinephotoart.com (JC Dill) Date: Thu, 15 Dec 2005 10:47:59 -0800 Subject: [Mailman-Developers] Spam/Scam button In-Reply-To: <1134664059.21766.14.camel@localhost.localdomain> References: <008001c5ffe1$79f91a60$0500000a@Laptop> <1134602776.11466.17.camel@geddy.wooz.org> <1134663274.12150.1.camel@localhost.localdomain> <1134664059.21766.14.camel@localhost.localdomain> Message-ID: <43A1BA5F.3000500@equinephotoart.com> Nigel Metheringham wrote: > While agreeing that MM is not really a good spam control place, my life > would be made easier if:- > * Marking a message as spam killed all other messages sent by the > same sender address to that and all other lists currently > awaiting moderation. > * Marking a message as spam killed all other messages sent with > the same subject to that and all other lists currently awaiting > moderation. If this marking is taking place within the mailman admin webpage structure, this could be accomplished by providing checkboxes for each of these actions, and the default setting would be to have those boxes pre-checked so that when you click the button, those actions happen. The setting should be changeable within the mailman configuration so that one or both of these boxes are not pre-checked if desired by that mailman admin. jc From josh at janrain.com Thu Dec 15 22:48:48 2005 From: josh at janrain.com (Josh Hoyt) Date: Thu, 15 Dec 2005 13:48:48 -0800 Subject: [Mailman-Developers] Mailman and OpenID Message-ID: <34714aad0512151348i48736ce0v17b91ec9abbb1b9b@mail.gmail.com> Hello, I'm interested in using OpenID[1,2], a decentralized single-sign-on system for the Web, as an alternative to passwords for authorizing Mailman users. I have not yet gotten a good understanding of the Mailman code base. I have a few questions: Is there developer orientation documentation somewhere? Is this the kind of change that could get accepted as a new feature of Mailman? If not, is there a recommended way of providing patches? Is it a problem that OpenID only works through the Web and has no e-mail fallback? Can someone help me get started on figuring out where I can add new Web actions? Thanks in advance, Josh Hoyt 1. http://openid.net/ 2. http://www.openidenabled.com/openid/libraries/python/ From tkikuchi at is.kochi-u.ac.jp Sat Dec 17 06:19:22 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 17 Dec 2005 14:19:22 +0900 Subject: [Mailman-Developers] Scrubber mungs Quoted Printable In-Reply-To: References: Message-ID: <43A39FDA.7090707@is.kochi-u.ac.jp> Hi Mark, I've just committed my patch to this problem in 2.1 CVS branch. I used this example and looks OK for both with and without Content-Transfer-Encoding header. Mark Sapiro wrote: > The following is a transcript of a Python interactive session that > illustrates the above problems with set_payload() and get_payload(). > This session is with Python 2.4.1, but exactly the same behavior > occurs with 2.3.4 and 2.4.2. > > Python 2.4.1 (#1, May 27 2005, 18:02:40) > [GCC 3.3.3 (cygwin special)] on cygwin > Type "help", "copyright", "credits" or "license" for more information. > >>>>import email >>>> >>>>msg = email.message_from_file(open('plain2.eml')) >>>> >>>>print msg > >>From nobody Mon Nov 28 09:18:41 2005 > From: "Mark Sapiro" > To: list1 at localhost > Subject: HTML - all > Date: Sun, 27 Nov 2005 09:02:33 -0800 > MIME-Version: 1.0 > Content-Type: text/plain; charset="iso-8859-1" > > > How about just a line of stuff with some ==== and a few words. > > X=91**2 (x is 91 squared) > > >>>>del msg['content-type'] >>>>del msg['content-transfer-encoding'] >>>>msg.set_payload(str(msg.get_payload()), 'iso-8859-1') >>>> >>>>print msg > >>From nobody Mon Nov 28 09:18:41 2005 > From: "Mark Sapiro" > To: list1 at localhost > Subject: HTML - all > Date: Sun, 27 Nov 2005 09:02:33 -0800 > MIME-Version: 1.0 > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > How about just a line of stuff with some =3D=3D=3D=3D and a few words. > > X=3D91**2 (x is 91 squared) > > >>>>print msg.get_payload() > > > How about just a line of stuff with some ==== and a few words. > > X=91**2 (x is 91 squared) > > >>>>print msg.get_payload(decode=1) > > > How about just a line of stuff with some == and a few words. > > X`**2 (x is 91 squared) > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From stephen at xemacs.org Sat Dec 17 18:45:45 2005 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 18 Dec 2005 02:45:45 +0900 Subject: [Mailman-Developers] On-topic-ness for -users and -dev In-Reply-To: <43A0A4F7.1050706@equinephotoart.com> (JC Dill's message of "Wed, 14 Dec 2005 15:04:23 -0800") References: <008001c5ffe1$79f91a60$0500000a@Laptop> <9617-SnapperMsg420417FABFC54C26@[68.244.96.31]> <43A0A4F7.1050706@equinephotoart.com> Message-ID: <87r78baa7q.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "JC" == JC Dill writes: JC> The posts we are hoping to keep OFF of -dev and ON -users are JC> the posts by users who are having what they believe are JC> "complicated" use problems and they want "advanced support" [...] JC> As long as the topic brought here is about *how* to develop a JC> new feature, I believe it's on-topic for -dev. +1. And good job of presenting, at that. FAQ material? JC> [1] Does it belong in the headers, the footer, the body? JC> Should it be a configuration option to place it in one or more JC> of these locations? What happens when the button (or link) is JC> clicked? What if non-spam is reported? What about RFCs? JC> Etc. Niggle: these questions are appropriate for -developers, but should also be polled on -users. -- 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 msapiro at value.net Sat Dec 17 23:06:38 2005 From: msapiro at value.net (Mark Sapiro) Date: Sat, 17 Dec 2005 14:06:38 -0800 Subject: [Mailman-Developers] Scrubber mungs Quoted Printable In-Reply-To: <43A39FDA.7090707@is.kochi-u.ac.jp> Message-ID: Tokio Kikuchi wrote: > >I've just committed my patch to this problem in 2.1 CVS branch. I used >this example and looks OK for both with and without >Content-Transfer-Encoding header. That's great Tokio! When I get a chance, I'll try some additional testing, but it looks good. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From as at avalonmail.de Mon Dec 19 15:10:31 2005 From: as at avalonmail.de (=?ISO-8859-15?Q?Andr=E9?=) Date: Mon, 19 Dec 2005 15:10:31 +0100 Subject: [Mailman-Developers] Mailman / One-Click Unsubscribe Message-ID: <43A6BF57.5080205@avalonmail.de> Hi all, we are using mailman as a newsletter-system for several customers and would like to implement a "one click unsubsribe" - each mail should contain a user-specific link for unsubscribing the user. The problem is that we have legal requirements (and fairly "unexperienced users") that force us to set up a real "one click" system - the standard webpage for unsubscribing from mailman is a little to complicated (as you still have to read some text..:-) I read in the archives that there was a short discussion about that in 2004, but that, unfortunately, did not really help me. First of all - is there anybody who already implemented that and is willing to share his/her ideas upon that? If there's no "ready-to-run"-solution for our problem, could please anyone give me a hint on how to do that? We could of cource set up a php or python-based website that can pass commands to the shell-interface of mailman, but how do we secure that, so that it's not possible to unsubscribe anyone from the list? Or are there any other strategies you have thought about? Thanks a lot for any advice/ideas; Andr? From msapiro at value.net Mon Dec 19 19:43:30 2005 From: msapiro at value.net (Mark Sapiro) Date: Mon, 19 Dec 2005 10:43:30 -0800 Subject: [Mailman-Developers] Mailman / One-Click Unsubscribe In-Reply-To: <43A6BF57.5080205@avalonmail.de> References: <43A6BF57.5080205@avalonmail.de> Message-ID: <43A6FF52.30302@value.net> Andr? wrote: > > we are using mailman as a newsletter-system for several customers and would > like to implement a "one click unsubsribe" - each mail should contain a > user-specific link for unsubscribing the user. I'm sure you recognize that this precludes digests as digests currently can't be personalized. > The problem is that we have legal requirements (and fairly "unexperienced > users") that force us to set up a real "one click" system - the standard > webpage for unsubscribing from mailman is a little to complicated (as you > still have to read some text..:-) I don't know if this will satisfy your requirement or not, but you could construct a mailto: link in the msg_footer. e.g., Unsubscibe - mailto:%(real_name)s-request@%(host_name)s?subject=unsubscribe%%20%(user_password)s%%20address=%user_address)s -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From bob at nleaudio.com Mon Dec 19 20:20:45 2005 From: bob at nleaudio.com (Bob Puff@NLE) Date: Mon, 19 Dec 2005 14:20:45 -0500 Subject: [Mailman-Developers] Mailman / One-Click Unsubscribe In-Reply-To: <43A6BF57.5080205@avalonmail.de> References: <43A6BF57.5080205@avalonmail.de> Message-ID: <43A7080D.2060502@nleaudio.com> Hi Andre, I've implemented something similar - email me off-list if you want the scripts. Bob Andr? wrote: > Hi all, > > we are using mailman as a newsletter-system for several customers and would > like to implement a "one click unsubsribe" - each mail should contain a > user-specific link for unsubscribing the user. > > The problem is that we have legal requirements (and fairly "unexperienced > users") that force us to set up a real "one click" system - the standard > webpage for unsubscribing from mailman is a little to complicated (as you > still have to read some text..:-) > > I read in the archives that there was a short discussion about that in > 2004, but that, unfortunately, did not really help me. > > First of all - is there anybody who already implemented that and is willing > to share his/her ideas upon that? > > If there's no "ready-to-run"-solution for our problem, could please anyone > give me a hint on how to do that? > > We could of cource set up a php or python-based website that can pass > commands to the shell-interface of mailman, but how do we secure that, so > that it's not possible to unsubscribe anyone from the list? > > Or are there any other strategies you have thought about? > > Thanks a lot for any advice/ideas; > > Andr? > _______________________________________________ > 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-users%40python.org/ > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > From jag at fsf.org Mon Dec 19 21:23:29 2005 From: jag at fsf.org (Joshua Ginsberg) Date: Mon, 19 Dec 2005 15:23:29 -0500 Subject: [Mailman-Developers] Mailman / One-Click Unsubscribe In-Reply-To: <43A7080D.2060502@nleaudio.com> References: <43A6BF57.5080205@avalonmail.de> <43A7080D.2060502@nleaudio.com> Message-ID: <1135023810.17094.19.camel@localhost.localdomain> This is something the XMLRPC patch previously submitted could help with. -jag On Mon, 2005-12-19 at 14:20 -0500, Bob Puff at NLE wrote: > Hi Andre, > > I've implemented something similar - email me off-list if you want the scripts. > > Bob > > Andr? wrote: > > > Hi all, > > > > we are using mailman as a newsletter-system for several customers and would > > like to implement a "one click unsubsribe" - each mail should contain a > > user-specific link for unsubscribing the user. > > > > The problem is that we have legal requirements (and fairly "unexperienced > > users") that force us to set up a real "one click" system - the standard > > webpage for unsubscribing from mailman is a little to complicated (as you > > still have to read some text..:-) > > > > I read in the archives that there was a short discussion about that in > > 2004, but that, unfortunately, did not really help me. > > > > First of all - is there anybody who already implemented that and is willing > > to share his/her ideas upon that? > > > > If there's no "ready-to-run"-solution for our problem, could please anyone > > give me a hint on how to do that? > > > > We could of cource set up a php or python-based website that can pass > > commands to the shell-interface of mailman, but how do we secure that, so > > that it's not possible to unsubscribe anyone from the list? > > > > Or are there any other strategies you have thought about? > > > > Thanks a lot for any advice/ideas; > > > > Andr? > > _______________________________________________ > > 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-users%40python.org/ > > Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com > > > > Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > > > _______________________________________________ > 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-users%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: 189 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051219/75c3dc0a/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Tue Dec 20 04:27:32 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 20 Dec 2005 12:27:32 +0900 Subject: [Mailman-Developers] Released: Mailman 2.1.7b1 Message-ID: <43A77A24.7000309@is.kochi-u.ac.jp> Hi all, I've just released Mailman 2.1.7b1 for beta test and i18n translations. I'm tempted to jump into RC because the 2.1-maint branch is so stable and 2.1.7 is mainly for bug fixes, but we need more translations before the final release. Please download it from SF or: http://mm.tkikuchi.net/mailman-2.1.7b1.tgz Cheers, Tokio ------------------------------------------------------- Here is a history of user visible changes to Mailman. 2.1.7b1 (20-Dec-2005) Security - The fix for CAN-2005-0202 has been enhanced to issue an appropriate message instead of just quietly dropping ./ and ../ from URLs. - A note on CVE-2005-3573: Although the RFC2231 bug example in the CVE has been solved in mailman-2.1.6, there may be more cases where ToDigest.send_digests() can block regular delivery. We put the send_digests() calling part in try - except clause and leave a message in the error log if something happened in send_digests(). Daily call of cron/senddigests will notify more detail to the site administrator. - List administrators can no longer change the user's option/subscription globally. Site admin can change these only if mm_cfg.ALLOW_SITE_ADMIN_COOKIES is set to Yes. - Script tag is disallowd in edithtml script. - Since probe message for the disabled users may reach unexpected persons, the password was excluded from sendProbe() and probe.txt. Note that the default value of VERP_PROBE has been set to `No' from 2.1.6., thus this change doesn't change the default behavior. New Features - Always remove DomainKey (and similar) headers (1287546) from messages sent to the list. - List owners can customize content filter behavior as not to collapse multipart/alternative to its first content. This allows HTML part to pass through after other content filtering is done. Internationalization - New language: Interlingua. Bug fixes and other patches - Fix Scrubber.py mungs quoted-printable bug with introducing 'X-Mailman-Scrubbed' header for marking that the payload is scrubber-munged. The flag is referenced in ToDigest.py, ToArchive.py, Decorate.py and Archiver. Similar problem in ToDigest.py where the plain digest is generated is also fixed. - Fix Syslog.py to write quopri encoded message when it fail to write 8-bit characters. - Fix MTA/Postfix.py to check aliases group permission in check_perms and fix mailman-install document on this matter (1378270). - Fix private.py to go to the original URL after authorization (1080943). - Fix bounce log score messages to be more consistent. - Fix bin/remove_members to accept no arguments when both --fromall and --file= options are specified. - Change cgi-bin and mail wrapper "group not found" error message to be more descriptive of the actual problem. - Apply the list's ban_list to address changes and admin mass subscribe and invite and to confirmations/approvals of address changes, subscriptions and invitations. - Decode quoted-printable and base64 encoded parts before passing to HTML_TO_PLAIN_TEXT_COMMAND (1367783). - Remove Approve: header from post - treat as Approved: (1355707). - Stop removing line following Approve(d): line in body of post (1318883). - Log post in post log with true sender, not listname-bounces (1287921). - Correctly initialize and remember the list's default_member_moderation attribute in the web list creation page (1263213). - Add PEP263 charset in config_list output (1343100). - header_filter_rules get lost if accessed directly and needed authenti- cation by login page (1230865). - Obscure email when the poster doesn't set full name in 'From:' header. - Take preambles and epilogues into account when calculating message sizes for holding purposes (Mark Sapiro). - Logging/Logger.py unicode transform option (1235567). - bin/update crashes with bogus files (949117). - Bugs and patches: 1212066/1301983 (Date header in create/remove notice) From tkikuchi at is.kochi-u.ac.jp Fri Dec 23 01:22:31 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Fri, 23 Dec 2005 09:22:31 +0900 Subject: [Mailman-Developers] [Mailman-Users] filename too long error - stopping list In-Reply-To: <20051222154037.GA14616@patch.com> References: <20051222142655.GA3498@patch.com> <20051222152158.GA14240@patch.com> <20051222154037.GA14616@patch.com> Message-ID: <43AB4347.6000704@is.kochi-u.ac.jp> Hi Michael, You can set Scrubber.py not to use the orginal filename in the message by adding followin line in mm_cfg.py (mailman-2.1.6 and above). SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = True Developers, May be we should set this default in Defaults.py.in in the next release of 2.1.7. Thoughts? Michael Rasmussen wrote: > Resolved. The digest keeps a seperate mbox file at > {MMDIR}lists/LISTNAME/digest.mbox removing the email from that location > was the solution to my immediate problem. > > This does expose a DOS attack potential for MM lists. The too long > attachment name needs to be handled in a more graceful manner. > > Michael Rasmussen wrote: > >>Update: >> >>I've found the offending message and purged it from the list archives, >>purged it from the shunt files, and purged it from everywhere I could >>find it. >> >>Yet the problem persists. So I'm looking for the temp file/mail area >>where the file that contains this attachment may be found. >> >> >>Michael Rasmussen wrote: >> >>>I have a list that was sent a file with an attachement with too long a >>>name. (See error below) now all mail to the list is being shunted. >>> >>>the filename listed does not exist on my system. There is no file on my system with that name. >>>The directory /var/lib/mailman/archives/private/rca-l/attachments/20051207/3d04c3a4 is empty. >>> >>>What do I need to do to resolve this problem? >>> >>>========== Error message ===================== >>>Dec 22 06:08:46 2005 (2233) Uncaught runner exception: [Errno 36] File name too long: '/var/lib/mailman/archives/private/rca-l/attachments/20051207/3d04c3a4/iso-8859-1QThe_surface_of_the_SunA0_The_sun_has_a_rigid_iron_surfaceiso-8859-1Q_located_under_the_photosphere_that_is_revealed_by_satelliiso-8859-1Qte_imagery.A0_The_solar_surface_sits_beneath_the_suns_viiso-8859-1Qsible_photosphere_and_is_electrically_active..obj' >>>Dec 22 06:08:46 2005 (2233) Traceback (most recent call last): >>> File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop >>> self._onefile(msg, msgdata) >>> File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 167, in _onefile >>> keepqueued = self._dispose(mlist, msg, msgdata) >>> File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose >>> more = self._dopipeline(mlist, msg, msgdata, pipeline) >>> File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline >>> sys.modules[modname].process(mlist, msg, msgdata) >>> File "/var/lib/mailman/Mailman/Handlers/ToDigest.py", line 91, in process >>> send_digests(mlist, mboxfp) >>> File "/var/lib/mailman/Mailman/Handlers/ToDigest.py", line 132, in send_digests >>> send_i18n_digests(mlist, mboxfp) >>> File "/var/lib/mailman/Mailman/Handlers/ToDigest.py", line 306, in send_i18n_digests >>> msg = scrubber(mlist, msg) >>> File "/var/lib/mailman/Mailman/Handlers/Scrubber.py", line 265, in process >>> url = save_attachment(mlist, part, dir) >>> File "/var/lib/mailman/Mailman/Handlers/Scrubber.py", line 447, in save_attachment >>> fp = open(path, 'w') >>>IOError: [Errno 36] File name too long: '/var/lib/mailman/archives/private/rca-l/attachments/20051207/3d04c3a4/iso-8859-1QThe_surface_of_the_SunA0_The_sun_has_a_rigid_iron_surfaceiso-8859-1Q_located_under_the_photosphere_that_is_revealed_by_satelliiso-8859-1Qte_imagery.A0_The_solar_surface_sits_beneath_the_suns_viiso-8859-1Qsible_photosphere_and_is_electrically_active..obj' >>> >>>Dec 22 06:08:46 2005 (2233) SHUNTING: 1135258825.4376719+99568bcc1187c910d48aae8b9ae8f68ed3aa643b >>> >>>========== Error message ===================== >>>-- >>> Michael Rasmussen, Portland Oregon -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From stephen at xemacs.org Fri Dec 23 03:18:25 2005 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 23 Dec 2005 11:18:25 +0900 Subject: [Mailman-Developers] [Mailman-Users] filename too long error - stopping list In-Reply-To: <43AB4347.6000704@is.kochi-u.ac.jp> (Tokio Kikuchi's message of "Fri, 23 Dec 2005 09:22:31 +0900") References: <20051222142655.GA3498@patch.com> <20051222152158.GA14240@patch.com> <20051222154037.GA14616@patch.com> <43AB4347.6000704@is.kochi-u.ac.jp> Message-ID: <87wthwk13i.fsf@tleepslib.sk.tsukuba.ac.jp> >>>>> "Tokio" == Tokio Kikuchi writes: Tokio> SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = True Tokio> May be we should set this default in Defaults.py.in in the Tokio> next release of 2.1.7. Thoughts? I think that's a good idea. Very few users have any idea what the file name is (and their programs have less, lots of my colleagues send files with names beginning ESC $ B -- which are the escape codes to switch to Japanese! the programs don't know how to encode them properly) They just click on the link. So I think it's mostly harmless. We should provide a FAQ for the admins who do want the feature. For 2.2 we should think about truncating the buffer. -- 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 as at avalonmail.de Fri Dec 23 11:38:10 2005 From: as at avalonmail.de (=?ISO-8859-15?Q?Andr=E9?=) Date: Fri, 23 Dec 2005 11:38:10 +0100 Subject: [Mailman-Developers] Mailman / One-Click Unsubscribe Message-ID: <43ABD392.5020509@avalonmail.de> Hi, thanks for the comments/tips upon a solution for a "One-Click Unsubscribe". For anyone interested, here is a short summary of what we did: * we decided to implement our own frontends to mailman, as we feel everything about mailman is great - everything but the frontends :-) * we integrated the MySQL MemberAdaptor from http://www.orenet.co.uk/opensource/MailmanMysql/ * we wrote frontends in php as an extension to the open source cms "papaya CMS" (www.papaya-cms.com - note: the page is only available in german until spring '06) * papaya now has a complete double-opt-in / opt-out system to manage subscriptions und unsubscriptions and keeps track of all relevant dates, due to requirements of the german laws * papaya syncs this database with the mailman maysql-database * and everything is fine ;-) Again, thanks for any comments upon our problem - and thanks to the developers for mailman and the MySQL MemberAdaptor... Best regards! Andr? From barry at python.org Sat Dec 24 00:47:35 2005 From: barry at python.org (Barry Warsaw) Date: Fri, 23 Dec 2005 18:47:35 -0500 Subject: [Mailman-Developers] [Mailman-Users] filename too long error - stopping list In-Reply-To: <43AB4347.6000704@is.kochi-u.ac.jp> References: <20051222142655.GA3498@patch.com> <20051222152158.GA14240@patch.com> <20051222154037.GA14616@patch.com> <43AB4347.6000704@is.kochi-u.ac.jp> Message-ID: <1135381655.25760.5.camel@geddy.wooz.org> On Fri, 2005-12-23 at 09:22 +0900, Tokio Kikuchi wrote: > May be we should set this default in Defaults.py.in in the next release > of 2.1.7. Thoughts? It's probably a good idea, but also as Stephen says, it might be a good idea to shorten the filename (keeping the extension) even when this value is left as False. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/mailman-developers/attachments/20051223/d3b23e65/attachment.pgp From tkikuchi at is.kochi-u.ac.jp Sat Dec 24 08:30:36 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 24 Dec 2005 16:30:36 +0900 Subject: [Mailman-Developers] [Mailman-Users] Released: Mailman 2.1.7b1 Message-ID: <43ACF91C.50801@is.kochi-u.ac.jp> Hi all, I've just released Mailman 2.1.7rc1 Release Candidate. I'm sorry for the violation of file name extension convention because I made a small mistake when tagging the release number. I will be releasing 2.1.7 final by December 31 if there is no problem. Please download it from SF or: http://mm.tkikuchi.net/mailman-2.1.7rc1.tar.gz Cheers, Tokio ------------------------------------------------------- 2.1.7rc1 (24-Dec-2005) Security - The fix for CAN-2005-0202 has been enhanced to issue an appropriate message instead of just quietly dropping ./ and ../ from URLs. - A note on CVE-2005-3573: Although the RFC2231 bug example in the CVE has been solved in mailman-2.1.6, there may be more cases where ToDigest.send_digests() can block regular delivery. We put the send_digests() calling part in try - except clause and leave a message in the error log if something happened in send_digests(). Daily call of cron/senddigests will notify more detail to the site administrator. - List administrators can no longer change the user's option/subscription globally. Site admin can change these only if mm_cfg.ALLOW_SITE_ADMIN_COOKIES is set to Yes. - Script tag is disallowd in edithtml script. - Since probe message for the disabled users may reach unexpected persons, the password was excluded from sendProbe() and probe.txt. Note that the default value of VERP_PROBE has been set to `No' from 2.1.6., thus this change doesn't change the default behavior. New Features - Always remove DomainKey (and similar) headers (1287546) from messages sent to the list. - List owners can customize content filter behavior as not to collapse multipart/alternative to its first content. This allows HTML part to pass through after other content filtering is done. Internationalization - New language: Interlingua. Bug fixes and other patches - Defaults.py.in: SCRUBBER_DONT_USE_ATTACHMENT_FILENAME is set to True for safer operation. - Fix Scrubber.py mungs quoted-printable bug with introducing 'X-Mailman-Scrubbed' header for marking that the payload is scrubber-munged. The flag is referenced in ToDigest.py, ToArchive.py, Decorate.py and Archiver. Similar problem in ToDigest.py where the plain digest is generated is also fixed. - Fix Syslog.py to write quopri encoded message when it fail to write 8-bit characters. - Fix MTA/Postfix.py to check aliases group permission in check_perms and fix mailman-install document on this matter (1378270). - Fix private.py to go to the original URL after authorization (1080943). - Fix bounce log score messages to be more consistent. - Fix bin/remove_members to accept no arguments when both --fromall and --file= options are specified. - Change cgi-bin and mail wrapper "group not found" error message to be more descriptive of the actual problem. - Apply the list's ban_list to address changes and admin mass subscribe and invite and to confirmations/approvals of address changes, subscriptions and invitations. - Decode quoted-printable and base64 encoded parts before passing to HTML_TO_PLAIN_TEXT_COMMAND (1367783). - Remove Approve: header from post - treat as Approved: (1355707). - Stop removing line following Approve(d): line in body of post (1318883). - Remove Approve(d): from all text/* parts in addition the initial text/plain part. It still must be the first non-blank line in the first text/plain part or it won't be found or removed at all (1181161). - Log post in post log with true sender, not listname-bounces (1287921). - Correctly initialize and remember the list's default_member_moderation attribute in the web list creation page (1263213). - Add PEP263 charset in config_list output (1343100). - header_filter_rules get lost if accessed directly and needed authenti- cation by login page (1230865). - Obscure email when the poster doesn't set full name in 'From:' header. - Take preambles and epilogues into account when calculating message sizes for holding purposes (Mark Sapiro). - Logging/Logger.py unicode transform option (1235567). - bin/update crashes with bogus files (949117). - Bugs and patches: 1212066/1301983 (Date header in create/remove notice) From tkikuchi at is.kochi-u.ac.jp Sat Dec 24 08:35:43 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 24 Dec 2005 16:35:43 +0900 Subject: [Mailman-Developers] Mailman 2.1.7rc1 (was Re: [Mailman-Users] Released: Mailman 2.1.7b1) In-Reply-To: <43ACF91C.50801@is.kochi-u.ac.jp> References: <43ACF91C.50801@is.kochi-u.ac.jp> Message-ID: <43ACFA4F.3010803@is.kochi-u.ac.jp> Oops, Sorry for the typo in the message title. I mean Released: Mailman 2.1.7rc1 Release Candidate Tokio Kikuchi wrote: > Hi all, > > I've just released Mailman 2.1.7rc1 Release Candidate. I'm sorry for > the violation of file name extension convention because I made a small > mistake when tagging the release number. I will be releasing 2.1.7 > final by December 31 if there is no problem. > > Please download it from SF or: > http://mm.tkikuchi.net/mailman-2.1.7rc1.tar.gz > > Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From dag at janrain.com Fri Dec 30 22:08:59 2005 From: dag at janrain.com (Dag Arneson) Date: Fri, 30 Dec 2005 13:08:59 -0800 Subject: [Mailman-Developers] OpenID login for Mailman Message-ID: <43B5A1EB.30307@janrain.com> Hello Mailman Developers. I'm in the process of writing a patch to allow users and site admins to log in using OpenID, a protocol using browser redirects for delegating authentication to a special site, using a URL as an identifier. (see www.openidenabled.com and/or www.openid.net for more info) I downloaded 2.1.7rc1 and I have been investigating what it will take to write this patch. I have had trouble connecting to the cvs server, "cvs [login aborted]: reading from server: Connection reset by peer" or I would be looking at the latest cvs. Anyhow... I noticed the two modules MemberAdaptor.py and OldStyleMemberships.py, the latter of which contains an implementation while the former does not. It appears that the membership system is in some sort of transition, and I wondered what the plans were, and how I could help, especially to make it easier to use OpenID or other similar systems. Dag Arneson JanRain Inc. From tkikuchi at is.kochi-u.ac.jp Sat Dec 31 14:02:23 2005 From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi) Date: Sat, 31 Dec 2005 22:02:23 +0900 Subject: [Mailman-Developers] RELEASED Mailman 2.1.7 Message-ID: <43B6815F.4060302@is.kochi-u.ac.jp> I'm pleased to announce the release of GNU Mailman 2.1.7. This is a significant release, which includes security enhancement fixes, a new language (ia: Interlingua) support, a couple of new features, and many bug fixes. Mailman is free software for managing email mailing lists and e-newsletters. This release enhances the fixes for CAN-2005-0202 and CVE-2005-3573 which were fixed in mailman release 2.1.6, and reduces the chance of list admin privilege abuse. Because of these and other fixes, it is highly recommended that all sites update to 2.1.7. For more information, see: http://mailman.sourceforge.net/ For links to download the Mailman 2.1.7 source tarball, see: http://sourceforge.net/project/showfiles.php?group_id=103 Best regards and a happy new year! -- Tokio Kikuchi From jwblist at loricamail.com Sat Dec 31 19:24:32 2005 From: jwblist at loricamail.com (John W. Baxter) Date: Sat, 31 Dec 2005 10:24:32 -0800 Subject: [Mailman-Developers] RELEASED Mailman 2.1.7 In-Reply-To: <43B6815F.4060302@is.kochi-u.ac.jp> Message-ID: On 12/31/05 5:02 AM, "Tokio Kikuchi" wrote: > I'm pleased to announce the release of GNU Mailman 2.1.7. This > is a significant release, which includes security enhancement > fixes, a new language (ia: Interlingua) support, a couple of new > features, and many bug fixes. Well done! Thank you, all involved. Shouldn't Mark Shapiro be recognized in the ACKNOWLEDGEMENTS file now? --John