Mailman 3 December 2005 - Mailman-Developers

Mailman / One-Click Unsubscribe
by André Dec. 19, 2005

Dec. 19, 2005

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é

4 3

Scrubber mungs Quoted Printable
by Mark Sapiro Dec. 17, 2005

Dec. 17, 2005

A couple of posts on the mailman-users list (<http://mail.python.org/pipermail/mailman-users/2005-September/046400.html> and <http://mail.python.org/pipermail/mailman-users/2005-October/047367.html>) have pointed out that there is a problem with Scrubber.py. The basic issue is that under some circumstances, the scrubbed message is quoted-printable encoded, but Scrubber unconditionally adds a 'Content-Transfer-Encoding: 8bit' header resulting in garbled content when the message is viewed. The addition of the header was a small part of the patch at <http://sourceforge.net/tracker/index.php?func=detail&aid=655214&group_id=10…> and the associated comment is - Fixes a bug in the scrubber, where a content-transfer-encoding might have survived flattening of the message. 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 have checked this with Tokio, and he agrees, but I don't have any message that would have triggered the original bug to test against nor do I know what the characteristics of such a message would be or if subsequent changes in the Python email library have taken care of it. Thus, before committing this patch, I'd like to see it get a bit more exposure/testing and/or get feedback from someone who knows something about the original bug. -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 4

Spam/Scam button
by Rui Correia Dec. 17, 2005

Dec. 17, 2005

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

13 18

Mailman and OpenID
by Josh Hoyt Dec. 15, 2005

Dec. 15, 2005

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 <josh(a)janrain.com> 1. http://openid.net/ 2. http://www.openidenabled.com/openid/libraries/python/

1 0

Encoding problem: Mailman bails during "Administrative requests"
by Edward Elhauge Dec. 15, 2005

Dec. 15, 2005

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: <ADDRESS>Apache/1.3.33 Server at list.uncanny.net Port 80</ADDRESS> 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(a)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 <ee(a)uncanny.net> "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

3 3

Released: Mailman 2.1.7a1
by Tokio Kikuchi Dec. 13, 2005

Dec. 13, 2005

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/

1 0

Confirmation Messages and Modified Subject Lines
by Adrian Wells Dec. 7, 2005

Dec. 7, 2005

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

3 5

"you are removed" message
by Fil Dec. 7, 2005

Dec. 7, 2005

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

1 0

Bouncer.py syslog differences
by Adrian Wells Dec. 6, 2005

Dec. 6, 2005

Hello. The following is portion of an exchange of ideas between Mark Sapiro and myself (initial comments) which occurred not too long ago on this list: >>>>> >>>>As a minor side note, I noticed the bounce log receives two different >>>>formatted messages for the first bounce and subsequent bounces. An >>>>example: >>>>... >>>>Oct 25 10:50:51 2005 (2687) samplelist: falseaddresstest(a)somedomain.net >>>>bounce score: 1.0 >>>>Oct 25 11:06:54 2005 (2687) falseaddresstest(a)somedomain.net: samplelist >>>>current bounce score: 2.0 >>>>... >>>>This is not a major issue but it is inconsistent and it not clear why >it >>>>should be this way. Is there reason is should be different? >>> >>> >>>I don't think so. All the other log messages from Bouncer are "list: >>>member". I don't see any reason why this one shouldn't also be that >>>way. >> >> >>OK. Should this be entered as a bug on SF? > > Yes, I think so, but I'd be inclined to wait a bit and see if there are more comments from the list. >>>>> 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 <http://sourceforge.net/tracker/index.php?func=detail&aid=1123383&group_id=1…> 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. -Adrian

2 2

Re: [Mailman-Developers] Use of tabs when folding header lines
by Brad Knowles Dec. 5, 2005

Dec. 5, 2005

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, <brad(a)stop.mail-abuse.org> "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 <http://www.sage.org/> for more info.

3 6